The prompt lands. A senior engineer, capable and prepared, starts drawing boxes. Load balancer, service tier, message broker, cache. Three minutes in, they are talking about shard counts.
The design is not wrong. It is not a design either. It is a collection of patterns assembled against a problem that has not been defined.
A system design prompt is deliberately loose. “Design a notification system for ten million users” has four different answers depending on what kind of notifications and which ones can be lost. “Design a URL shortener” has one shape at a thousand users and a different one at a billion. The looseness is the test. A person doing this work in production would not touch a whiteboard until the brief was tight enough to design against. The candidate who treats the interview as a different kind of activity from the work has missed what the interview is for.
The questions that come first
The kind of brief-narrowing that happens in production is concrete. How many users, daily active and peak concurrent. The read-to-write ratio. The latency budget. The consistency guarantees that actually matter for this domain. The failure budget and what acceptable degradation means. These are not filler – they define the problem. A URL shortener for a thousand users is a different system from one for a billion. A notification system with best-effort delivery is a different architecture from one where every message must arrive exactly once.
The constraints shape the solution. The candidate who asks these questions before drawing is not stalling. They are doing the first piece of the actual work.
What separates the levels
The diagram is not the artifact. There is no reference solution to compare it against. The panel is watching the first five minutes – whether the candidate redraws the problem before drawing a solution, whether they can name what they have chosen not to decide yet, whether they handle not-knowing without bluffing.
Three patterns repeat in the candidates who fall short.
The first is pattern-dropping. “Kafka for the stream, Redis for cache, Elasticsearch for search” is a template, not a design. Naming technologies without the tradeoffs behind them signals memorization, not understanding. Every component chosen carries a one-line reason; if the reason is hard to articulate, the choice is probably wrong.
The second is starting complex. The first version does not need global replication, multi-region failover, or a reference Netflix architecture. A working answer starts with one database, a monolith, basic caching, and names where that breaks and how the system evolves from there. A candidate who can sketch an incremental path usually knows more than one who draws the endgame first.
The third is bluffing. “I have not worked with this pattern directly, but the approach would be …” is a strong answer. “We would use consistent hashing here” when the candidate cannot explain what consistent hashing actually does is a weak one. Panels have heard hundreds of answers. The difference between someone reasoning through a problem and someone performing is audible within a sentence or two.
The interview as design conversation
The panel is not adversarial. The session works best when the candidate treats it as two engineers at a whiteboard – asking, bouncing tradeoffs, using the other person to test constraints. “I am thinking of using a write-ahead log here for durability; does that fit the constraints we discussed?” is how design happens in production. The panel sees how the candidate collaborates, not just how the candidate performs.
The candidates who clear the bar for principal tend to pause. Not long. Long enough to ask what kind of system, which failure modes matter, what the cost function actually looks like. They treat the brief as the first thing they own, not the last thing they have been handed.
A senior engineer can produce a working system from an under-specified brief. A principal engineer makes the brief less under-specified first. That is the gap the first five minutes exposes.