What system design interviews test

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.

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.

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.

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 is above the roughly 20,000 simple reads per second that this course plans one relational primary for (see the table below), so reads must be served from cache or replicas. 1,200 writes per second is well under the roughly 5,000 committed writes per second we plan for, 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.

Two more anchors belong in your head. Quote latency as a percentile, not an average: p99 is what one user in a hundred sees, and a request that fans out to many backends hits the slow tail of at least one of them far more often than any single backend does (the "tail at scale" effect). And an availability target is only meaningful alongside how you measure it: an SLI (for example, the fraction of requests answered in under 300 ms without an error) and an SLO (the target for that fraction, over a window). The error budget is simply what the SLO leaves you to spend.

The ranges above are wide on purpose. 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

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

Dry run: the five-phase arc applied to "design a service that shows a user their order history"

Notice phase 5 answers a question that phase 1 asked and phase 2's numbers never touched — that's the arc doing its job. The prompt changes every time; running clarify → estimate → design → deep-dive → failure in order, and using each phase's output in the next one, is the part that doesn't.