Morgan Stanley · Primly Community

Morgan Stanley senior / L5 system design interview, what to expect (went through it last month)

staff_steph · 4 replies

Just cleared the Morgan Stanley senior SWE loop for a VP-level role in their Technology division, NYC. The system design round was a full 60 minutes and nothing like what I prepped for at FAANG.

First thing to know: they care a lot about financial systems constraints. Not just "design Twitter" style. My prompt was essentially: design a high-throughput order execution system that can handle 100k+ events per second with strict consistency guarantees. They were specifically probing whether you understood why eventual consistency is a non-starter for anything touching trade settlement.

What they tested: Low-latency vs. throughput tradeoffs in a financial context Exactly-once message delivery (Kafka, idempotency, deduplication keys) How you'd handle a downstream failure without dropping an order Database choice: why not Postgres at that scale, what you'd use instead (they seemed happy with ClickHouse + Redis combo for different layers) Audit logging requirements. This came up unprompted and they nodded visibly when I mentioned regulatory retention requirements.

The interviewer was a principal engineer. He would not just let me wave my hands. When I said "we'd shard the database," he immediately asked how I'd handle cross-shard transactions for multi-leg trades. I didn't have a perfect answer but I talked through the tradeoffs openly and that seemed fine.

Time management matters here. I spent too long on the initial design and rushed the deep dive. They didn't cut me off but I could tell we were behind. Aim to have your high-level diagram done by minute 15 so you have 40 minutes to go deep.

Level they're interviewing for affects expectations a lot. At VP equivalent (their internal ladder is VP / Executive Director / MD), they expect you to bring up operational concerns like oncall, observability, and disaster recovery without being prompted. These are not bonus points; they are signals they're looking for.

One note on the room: it was a video call even for the "onsite." They use their own MS Teams setup. Not ideal for whiteboarding. I used a shared Google Doc and just typed out an ASCII-ish diagram. Worked fine.

4 replies

marketer_mei

The exactly-once delivery question is so classic financial services. I got something similar at a different bank and the answer they wanted was basically "use a unique idempotency key per order, write it to Postgres before you process, and check on every retry." Simple in theory, painful in practice when you have 100k TPS.

staff_steph

Exactly. They weren't looking for a clever solution, they were looking for whether you understood WHY correctness matters more than throughput here. Once I framed it that way the conversation got much better.

qa_quinn

Did they ask about testing the system at all? Like, how do you verify your order matching logic is correct under load? I'm coming from a QA background and curious if that angle ever comes up in SWE design rounds.

staff_steph

Not directly. The interviewer touched on observability (metrics, alerting, tracing) but didn't go deep on test strategy. That might be different if you're interviewing for a more QA-adjacent role there.