Just finished a senior SWE loop at D.E. Shaw last month. The system design round was the most interesting one I've done in recent memory, so sharing notes.
The setup
One interviewer, 50 minutes. I got a whiteboard-style shared doc, not an actual diagramming tool. The interviewer was clearly technical and asked probing follow-up questions throughout, not just at the end.
What they asked me
I was asked to design a real-time market data distribution system. The company does quant trading, so the focus quickly moved to: latency requirements, ordering guarantees, how to handle bursts at market open, and how you'd reason about data loss vs. latency tradeoffs.
They're not purely looking for textbook distributed systems knowledge. They want you to reason about domain-specific constraints. What does 'eventually consistent' mean when you're pushing tick data to ten trading desks simultaneously? What happens if one consumer is slower than others?
Things that mattered: Being explicit about tradeoffs, not just listing options Sizing estimates that were clearly driven by reasoning, not memorized numbers Showing you understood that the 'right' architecture depends heavily on SLA requirements
What didn't matter as much
I didn't go deep on specific AWS service names. They seemed more interested in architectural reasoning than whether you'd pick SQS vs. Kafka specifically (I mentioned Kafka and they asked me to just describe the properties I needed from a broker, abstractly).
For a senior / effectively-L5 equivalent role, expect them to push harder once you give an answer. My interviewer kept asking 'what breaks at 10x load' and 'what would you do differently if latency budget was 50 microseconds instead of 10 milliseconds.'
Overall the round felt more like a real engineering conversation than a gotcha. But you need to know distributed systems properly, not just the vocabulary.