What system design interviews test
There is no answer key — the interviewer is scoring how you got there, not where you landed.
The interviewer is scoring a process, not an answer
A coding interview has a correct answer: the tests pass or they don't. A system design interview does not. Two candidates can draw the same boxes on the same whiteboard and receive opposite recommendations, because the artifact being evaluated is not the diagram — it's the sequence of decisions that produced it. The interviewer is filling in a rubric with rows like "gathered requirements before designing" and "articulated a tradeoff without being prompted." Your drawing is only evidence.
This is why strong engineers with real production experience sometimes fail the loop. They design the way they design at work — quietly, in their head, then present a conclusion. In a 45-minute interview an unspoken thought is a thought that did not happen.
| What the rubric row says | Weak signal | Senior / staff signal |
|---|---|---|
| Requirement gathering | Starts drawing from the one-line prompt | Spends 5-8 minutes turning a vague prompt into a bounded problem, and writes the scope down where both of you can see it |
| Structured thinking | Jumps between topics as they occur; the board becomes a mess | Announces the plan ("requirements, then scale math, then a high-level design, then we pick something to go deep on") and visibly follows it |
| Explicit tradeoffs | Names a technology ("I'd use Kafka") | Names the alternative they rejected and the property that decided it ("a queue over direct calls, because I want the write path to survive the consumer being down — cost is end-to-end latency and an at-least-once contract") |
| Calibration to scale | Shards a database for a 500-employee internal tool | Sizes the solution to the stated load and says out loud what would have to change to justify more |
| Depth | Every component gets one sentence | Can go three levels down on any box they drew — data model, failure behaviour, and what happens at 10x |
| Knowing what you don't know | Bluffs a confident wrong number | "I don't know Spanner's exact commit latency; I know it's bounded by the TrueTime uncertainty window, so single-digit to low tens of milliseconds. I'd design assuming 10 ms and verify." |
| Collaboration | Treats interviewer questions as attacks to deflect | Treats them as new requirements, updates the design, and says what the change costs |
The last row is the one candidates underrate most. The interviewer is simulating a design review with a colleague. If disagreeing with you is unpleasant, that is a hire-signal problem no amount of correct architecture fixes.
The 45-minute arc
Almost every system design round at a large company follows the same shape, whether or not the interviewer states it. Knowing the shape lets you budget time instead of discovering at minute 40 that you never discussed failure.
| Phase | What you produce | The failure mode |
|---|---|---|
| Clarify (0-8) | A written list of in-scope features, out-of-scope features, and the non-functional targets you'll design against | Accepting the prompt at face value and designing something nobody asked for |
| Estimate (8-13) | QPS (average and peak), storage per year, and one derived number that constrains the design | Arithmetic theatre — computing numbers you never refer to again |
| High-level (13-23) | 6-10 boxes, the data flow for the one or two critical paths, and the data model | Twenty boxes with no data model; the model is what proves you understand the problem |
| Deep dive (23-38) | One component taken to implementation-level detail, chosen by the interviewer | Staying at the same altitude you were at in the high-level phase |
| Failure (38-45) | What breaks first under 10x, what happens when each dependency dies, how you'd detect it | Never getting here because the earlier phases ran long |
Functional vs non-functional, and why only one of them shapes the design
Functional requirements are what the system does: users can shorten a URL, followers see a post, a rider is matched to a driver. They determine your API surface and your data model. Non-functional requirements are the properties the system must hold while doing it: latency, availability, consistency, durability, scale, cost. They determine the architecture.
This distinction earns its keep because functional requirements are usually easy and non-functional ones are where the interesting decisions live. "Users can post a tweet" is a row insert. "A tweet is visible to 100 million followers within two seconds" is the entire design.
| Non-functional requirement | Ask it as | What the answer changes |
|---|---|---|
| Scale | "How many daily actives, and what's the read-to-write ratio?" | Whether you need caching, replicas, sharding — or none of the above |
| Latency | "What's the p99 target for the read path?" | Cache placement, whether cross-region calls are allowed on the critical path, sync vs async work |
| Consistency | "If a user updates their profile, must they see it on the next read? Must their friends?" | Read-your-writes routing, whether replicas can serve reads, single-leader vs multi-leader |
| Availability | "Is it acceptable to be read-only during a regional outage?" | Multi-region topology, failover strategy, and how much complexity is justified |
| Durability | "Is losing the last second of writes a bug or a catastrophe?" | Synchronous vs asynchronous replication, write-ahead log fsync policy, queue acknowledgement semantics |
| Cost | "Are we optimising for engineer time or infrastructure spend?" | Managed services vs self-hosted; whether "just add a bigger box" is allowed |
Estimation you can do in your head, out loud
The point of the scale math is not the number, it's the decision the number unlocks. You are looking for an order of magnitude that tells you which of three or four architectures is appropriate. Round aggressively; nobody wants to watch you long-divide.
A worked pass, in the amount of detail you'd actually speak: 100 million daily actives, each reading their feed 10 times a day, is 1 billion reads a day, so about 12,000 reads per second average and call it 30,000 at peak. Writes at one post per user per day is 100 million a day, roughly 1,200 per second — a 10-to-1 read/write ratio. At 1 KB per post that's 100 GB of new post data per day, so 36 TB a year before replication, media, or indexes.
Now use it. 30,000 reads per second will not come off a single relational primary, so reads must be served from cache or replicas. 1,200 writes per second will fit on one well-tuned Postgres box, which means sharding the write path is not yet justified and saying so is a senior signal. 36 TB a year means the hot dataset and the cold archive should not live in the same place. Three architectural decisions from four multiplications.
| Anchor | Value to quote |
|---|---|
| Seconds in a day | ~100,000 (86,400) |
| 1M requests/day | ~12 QPS |
| Peak-to-average traffic ratio | 2-3x for consumer apps; 5-10x for event-driven spikes |
| A tweet-sized text record | ~200 bytes to 1 KB with metadata |
| A compressed photo | ~200 KB - 1 MB; a minute of 1080p video ~ 50 MB |
| One commodity app server | Thousands of RPS for simple JSON, hundreds if it does real work per request |
| One relational primary | ~5,000-20,000 simple reads/sec, ~1,000-10,000 writes/sec |
| One cache node | ~100,000 ops/sec, sub-millisecond |
These are deliberately wide ranges. Quoting a range with the caveat "depends on row size and whether it's index-only" reads as experience; quoting "Postgres does 8,342 QPS" reads as memorised trivia and invites a follow-up you can't answer.
Why "it depends" is the right answer — and why it's usually said wrong
"It depends" alone is the single most common way to sound senior and score as junior. It is a correct observation that transfers the work back to the interviewer. The complete form has three parts, and takes about fifteen seconds:
- It depends on X — name the specific variable, not "the use case"
- Here's how I'd decide — the threshold or test that resolves X
- Absent that information, here's my default and why — commit to something
The third part is what separates the two grades. A staff-level candidate is someone a team can be pointed at an ambiguous problem with, and who returns with a decision. Endless conditionality is the opposite of that.
The deep dive: they pick the component, you supply three levels
Somewhere around minute 23 the interviewer will point at a box and ask you to expand it. This is not random — they are steering toward the part of the problem they consider interesting, and toward the depth signal they still need. Whatever they pick, the expansion has the same three levels:
- Mechanism — what data structure or algorithm is inside the box, and the concrete data model (table columns, key format, index)
- Behaviour under load — what the hot path costs, where the contention is, what happens at 10x traffic
- Behaviour under failure — what happens when this box dies mid-request, when it's slow rather than dead, and how a client experiences that
A useful discipline while sketching: don't draw a box you can't take to level three. If you write "recommendation service" on the board and have no model for what's inside it, you have handed the interviewer a place to probe where you will have nothing. Either be ready to open it, or name it explicitly as out of scope: "there's a ranking service here; I'll treat it as a black box that returns an ordered list of IDs unless you want to go into it."
The failure modes that actually end interviews
| Failure mode | What it looks like | The fix |
|---|---|---|
| Drawing at minute 2 | The prompt is 12 words and there are already six boxes on the board | Force the requirements phase; write scope in a corner of the board and refer back to it |
| Designing for a billion when told a thousand | Kafka, sharding, and a service mesh for an internal admin tool | Match the design to the stated scale, then name the trigger that would change it |
| Silence | Thirty seconds of quiet thinking; the interviewer can't score what they can't hear | Narrate the search, not just the conclusion: "I'm weighing whether the fan-out happens on write or on read..." |
| Buzzword placement | Naming a technology without a property to justify it | Always pair the noun with the property: not "Redis", but "an in-memory store because I need sub-millisecond lookups on a small hot set" |
| Breadth as avoidance | Adding new components whenever a question gets hard | Depth is the scored axis after minute 23; go down, not sideways |
| Defending instead of updating | Treating "what if writes are 100x higher?" as a criticism | Treat every question as a new requirement: "then my single primary is out — here's what changes" |
| Bluffing | Inventing a mechanism for a system you've only read the name of | Say what you do know, name the boundary, reason from principles from there — this scores well, and getting caught bluffing is often terminal |
Notice that only two of these are about knowledge. The rest are about conduct in a room. This is the actual reason system design is the biggest differentiator at senior and staff levels: it is the only round that measures how you behave when the problem is underspecified and someone is disagreeing with you.
Recognizing it in an unseen problem
- The prompt is one sentence and deliberately ambiguous ("design Twitter") — that ambiguity is the first thing being tested, not an oversight to work around
- If the interviewer volunteers a number ("about a thousand internal users"), it is a constraint they will hold you to; designing above it reads as poor judgement, not ambition
- When they ask "why?" they are almost never disagreeing — they are giving you a scoring opportunity to state the tradeoff you skipped
- When they say "let's say traffic grows 100x", they have moved to the bottlenecks phase; stop adding features and start naming what breaks first
- If you have drawn a box you cannot open to three levels of detail, either open it now or declare it out of scope before they ask
- If you find yourself saying "it depends" without immediately naming the variable and your default, you have handed back the question — finish the sentence