Microsoft · Primly Community

Microsoft senior / L5 system design interview, what to expect (with the stuff nobody warns you about)

frontend_fran · 5 replies

Did my Microsoft senior SWE loop last spring targeting L63. Passed. Sharing the system design portion specifically because there's a lot of outdated info floating around.

First, the format. At L63 (which roughly maps to senior IC, their version of L5 at other companies), you get one dedicated system design round and the interviewers are looking for something specific: can you drive the conversation, or do you wait to be led.

They gave me a classic: design a notification system at scale. I asked a few scoping questions, drew out the high-level architecture, then dove into the fanout problem. That part landed well. Where I stumbled briefly was when they asked me to talk through failure modes in the message queue layer. I hadn't fully thought through dead-letter queues and retry logic upfront, and they pushed on it. Not hostile, but direct.

What they weight at senior/L63: Breadth first, then depth where you choose. Don't go deep on the wrong thing for 20 minutes. They want you to make explicit tradeoffs. Say out loud why you picked Kafka over a simpler queue. "More scalable" is not an answer. Ambiguity handling. Senior signals start with how you handle an underspecified problem, not how fast you get to a solution. They do NOT have the same obsession with back-of-envelope math that Google does. Rough estimates are fine, exact numbers are not expected unless central to the problem.

The interviewer was a principal and asked follow-ups that probed my understanding of consistency vs. availability. We ended up in a pretty good discussion about eventual consistency in distributed caches. That felt like the real signal moment.

One thing I didn't expect: they asked me to walk through how I'd test this system. Not deep, maybe 5 minutes, but it's part of the L63 rubric apparently.

Total design round was 55 minutes with about 5 minutes of intro/questions at the end. I had time to cover most of it without feeling rushed.

Happy to answer specifics if you're prepping.

5 replies

content_cole

how much db design did they get into? like did you actually have to pick specific sql vs nosql and justify it or was it more hand-wavy

qa_quinn

not hand-wavy at all. i picked postgres for the user preference store and dynamodb-style for the notification log (write-heavy, simple access patterns) and had to explain both choices. they didn't quiz me on specific dynamo internals but they did ask why i wouldn't just use one db for everything. you should be prepared to actually defend your storage choices.

staff_steph

the 'make explicit tradeoffs out loud' thing is real. i've interviewed a bunch of candidates for microsoft roles as a contractor loop participant and the ones who say 'i'd use X because it handles Y better than Z in this specific context' stand out immediately. the ones who just say 'i'd use microservices' with no rationale get scored down even if the architecture itself would work.

qa_quinn

surprised they asked about testing the system. that's actually a good sign they think about quality beyond just 'does it run'. did they want unit-level stuff or more e2e / load testing type thinking?

hardware_hugo

more e2e and failure injection. things like: how do you know the notification actually got delivered, what happens when the downstream SMS provider is down, how do you detect and alert on fanout latency spikes. not unit tests.