Course Content
System Design Interview
31 sections · 71 lessons
What the system design round is and how it is scored
A system design interview is a 45-minute conversation in which you and a working engineer design a system together, starting from a prompt that is deliberately too vague to answer.
This lesson covers what happens in that hour and what the interviewer writes down afterwards. The first half is the round itself: its shape, why the prompt is vague, and why there is no answer key. The second half is the scoring: most companies score this round on four axes, and the same answer can read as mid-level or staff-level depending on which axes it hits.
The shape of the hour
The prompt arrives in the first two minutes and is usually three or four words: "Design Twitter." "Design a rate limiter." "Design a system that shortens URLs." Nothing else is given. No user count, no latency target, no budget, no list of features.
What follows is roughly this, and Section 4 (A Framework for System Design Interviews) turns it into a procedure you can execute:
| Minutes | What happens |
|---|---|
| 0–10 | You ask questions and pin the problem down to something buildable |
| 10–25 | You draw boxes, define an application programming interface (API), sketch the data |
| 25–40 | The interviewer picks one part and you go three levels deep on it |
| 40–45 | You name your own bottlenecks and what you would do next |
Why the prompt is vague on purpose
Because that is the shape of real work. Nobody hands a senior engineer a specification with the queries per second already computed. Somebody says "we need search" and the engineer's first job is to find out what that means, what it must not do, and how big it has to be. The vagueness is not an obstacle placed in front of the test. It is the test.
There is no answer key
Two candidates can produce different architectures for the same prompt and both pass. For a social feed, one might precompute every user's feed when a post is written; another might assemble it when the feed is read. Section 13 (Design a News Feed System) shows that both are used in production, by the same companies, for different user segments. Neither is the answer.
What separates a pass from a fail is not which one you picked. It is whether you named the other option, said what it costs, and chose with a reason attached.
What the interviewer is doing while you talk
They are usually a senior engineer with a rubric, and they are running two loops at once: listening for whether your design holds together, and deciding where to push. When they ask "what happens if that cache goes down?" they are rarely trying to trap you. They are sampling the depth of your knowledge at a point they chose rather than one you chose.
This is why rehearsed answers underperform. A memorised architecture survives until the first question that steps outside the memorised part, and then it collapses in an obvious way.
The four axes
The rubric that interviewer is holding has four rows. Most companies use some version of them, even when the wording differs.
1. Requirement handling. Did you turn a vague prompt into a bounded problem? Did you separate what the system does (functional requirements) from the constraints it must meet (non-functional requirements: scale, latency, availability, consistency)? Did you stop asking questions in time to leave room to design?
2. High-level design. Is there a coherent architecture, with an API and a data model, that would actually serve the requirements you wrote down? Can a reader follow a request through it end to end?
3. Depth on demand. When the interviewer picks a component, can you go three levels down — mechanism, failure mode, and numbers — without rambling or bluffing?
4. Trade-off reasoning. Every significant decision presented as a choice between named options, with what each costs, and a recommendation. This axis is the one that moves level more than any other.
The same question at three levels
Take "Design a URL shortener" (Section 10). Here is roughly what each level sounds like.
| Axis | Mid-level | Senior | Staff |
|---|---|---|---|
| Requirements | Asks 2–3 questions, mostly about features | Asks about read-to-write ratio and derives that reads dominate 100:1 | Also asks about abuse, custom aliases, and what happens at expiry — and says which of these are out of scope and why |
| Design | Web tier, database, cache | Same, plus a considered key-generation strategy and a stated data model | Same, plus explicitly separating the read path from the write path because they scale differently |
| Depth | Explains what a cache does | Computes the hot-set size and picks an eviction policy for a reason | Discusses cache-stampede behaviour on a cold start and what the system does while the cache is warming |
| Trade-offs | Names one option | Names two and picks one with a reason | Names two, picks one, states the condition under which the other becomes correct |
Notice the pattern down the columns. Level is not a function of knowing more components. It is a function of conditionality — the senior answer says "I choose A"; the staff answer says "I choose A, and here is the number at which A stops being right."
This is the same point as "there is no answer key", seen from the scoring side. The interviewer is not checking your architecture against a reference. They are checking whether each choice came with its alternative, its cost and its limit.
What sinks otherwise strong candidates
- Designing before scoping. Fifteen minutes of boxes for a problem never bounded.
- Asserting without arithmetic. "That will not scale" carries no marks. Section 3 (Back-of-the-Envelope Estimation) fixes this.
- Defending a design after the interviewer has pointed at a real hole in it.
- Silence. A correct thought you did not say out loud scores zero.