Most system design interviews are scored on a feeling. The interviewer leaves the call, opens the hiring tool, types "strong technical depth, good communicator, leaning hire", and that is the artifact. Two weeks later nobody can reconstruct why one candidate got a three and another got a four, so the debrief goes to whoever argues hardest.
I have written that mush. I have also watched a team I was growing from four engineers to more than thirty-five absorb people who interviewed better than they worked. The fix was not a harder question. It was writing down, before the first candidate was scheduled, what a weak, solid and strong answer sounds like on each thing I claimed to be measuring.
A system design interview rubric
is a fixed set of scoring dimensions with written behavioural anchors — what a weak, solid and strong answer sounds like on each one — agreed before the first candidate is scheduled.
Google's re:Work guide on structured interviewing calls exactly this a rubric, and describes documenting "what a poor, borderline, solid, and outstanding answer would cover" for every attribute a question targets. That guide also reports that pre-made questions and rubrics save about 40 minutes per interview, and that rejected candidates who went through a structured interview were 35% happier than those who did not. What follows is mine rather than Google's, built for a 45-minute round.
The five dimensions and what each one is measuring
The rubric has five dimensions — problem framing, trade-off reasoning, depth on one component, failure modes and operability, and communication under a constraint change — each scored one to four against written anchors, with two of the five carrying the hire decision and the rest shaping the level.
| Dimension | What it is actually measuring | Weight in the decision | Fastest way to fail it |
|---|---|---|---|
| Problem framing | Whether an unbounded problem gets narrowed to a designable one, and whether the constraints chosen are the ones that shape the architecture | Gate | Ask the memorised clarifying questions, then design as though the answers had been different |
| Trade-off reasoning | Whether each choice arrives with its cost stated in this problem's units, and a named condition that would reverse it | Decides | Recite generic pros and cons that would be equally true of any system |
| Depth on one component | How many layers down one drawn box can be built before the answer becomes a vendor name | Decides | Answer "we would use Kafka" to a question about how the queue works |
| Failure modes and operability | Whether the failure path gets drawn unprompted, and whether anybody finds out when it fires | Level discriminator | Add "and we would have monitoring" after being asked twice |
| Communication under a constraint change | What the candidate does with twenty-nine minutes of prior work when one requirement moves | Tiebreak, and the hardest to fake | Defend the original design, or silently start over |
The scale is four points, not five, because a five-point scale is a machine for producing threes. One means the dimension was absent. Two means it appeared when prompted and stayed shallow. Three means solid and unprompted. Four means the candidate did something with it that I had not thought of.
The level anchors sit on top of the same five rows. This is the part most loops skip, and it is why "is this a senior or a staff answer" turns into an argument.
| Dimension | Mid-level bar | Senior bar | Staff bar |
|---|---|---|---|
| Problem framing | Asks enough to start and gets functional scope right | Extracts scale, latency and consistency targets, states what is out of scope | Names the one requirement everything else is downstream of, and says so before drawing anything |
| Trade-off reasoning | Knows the standard trade-offs and applies one correctly | States the cost of each choice in this problem's units | Names the reversal condition and the cheapest experiment that would settle it |
| Depth on one component | Can go one layer down when asked | Goes three layers down on the component they chose | Goes deep unprompted on the component carrying the risk, not the one they know best |
| Failure modes and operability | Mentions retries when prompted | Draws blast radius, idempotency and a dead-letter path unprompted | Says which failures are not worth preventing, and how they would detect them instead |
| Communication under a constraint change | Updates the affected box | Says what survives and what does not, then re-derives | Says what the change reveals about an assumption they made earlier and got wrong |
Every section below takes one dimension, using the same question throughout: design the system that sends our appointment reminders. Deliberately unglamorous, and it has the useful property that almost nobody has memorised an answer to it.
What does good problem framing actually sound like?
Problem framing scores on whether the candidate turns an unbounded problem into a designable one inside the first eight minutes, and on whether the constraints they pick are the ones that will actually shape the architecture. Duration is not the measurement. Consequence is.
The weak version is requirements theatre. The candidate asks the questions the book taught them — read-heavy or write-heavy, how many daily actives, what is the latency budget — writes the answers in the corner of the canvas, and draws the architecture they were always going to draw. The diagnostic is free: answer one clarifying question with a surprising number and watch whether the design bends. Tell them two hundred million reminders fall inside the same fifteen-minute window. If the next box is still a cron job selecting from a Postgres table, the framing was decorative.
A solid answer extracts four things: what a reminder is (SMS, push, email, all three), a volume figure, a timing target, and an explicit statement of what is out of scope. That last one is underrated. "I am not going to design message composition, assume it hands me rendered text" buys the candidate twenty minutes and tells me they know where the interesting problem is.
A strong answer names the requirement everything else hangs off, out loud, before drawing. On reminders that sentence is usually some version of: this system talks to carriers I cannot roll back, so exactly-once delivery is not on the menu, and the whole design is about making a duplicate cheap rather than impossible. Every later decision now has somewhere to be judged from.
Alex Xu's four-step sequence — establish scope, propose a high-level design and get buy-in, deep dive, wrap up — puts this first for the same reason. Meta's own careers guidance describes the round's purpose as assessing the ability to solve a non-trivial engineering design problem, and isolating the non-trivial part is the candidate's job, not the interviewer's.
How do you tell real trade-off reasoning from the rehearsed kind?
Real trade-off reasoning states what a choice costs in the units of this problem and names the condition under which the candidate would choose the other thing. Rehearsed trade-off reasoning states facts that would be equally true if the problem were a photo-sharing app, and it has no reversal condition, because a memorised trade-off has never been reversed by anything.
The probe is one question: what would have to be true for you to pick the other option? It is astonishing how much separation a single sentence produces.
| What the candidate says | Score | Why |
|---|---|---|
| "We will use Kafka, it is durable and scales" | 1 | True of Kafka, unconnected to reminders, and would survive being pasted into any other answer |
| "Kafka, because a reminder that fails at 3am has to be replayable in the morning without re-reading the appointments table" | 3 | The cost of the alternative is named, in this problem's terms |
| "Kafka for replay, and I would drop it for SQS the moment we stop needing to re-read a partition, because right now we are paying for a log we only use as a queue" | 4 | Reversal condition stated, and the candidate has priced their own choice |
That third row is not a trick. It is the thing senior engineers do and juniors do not: hold a decision and its expiry date at the same time. In what studying 55 production architectures taught me, the recurring pattern was ordinary technology chosen for a stated reason, plus a much rarer willingness to say when the reason had stopped applying.
One failure fools people. The candidate who says "it depends" to everything and never lands is not demonstrating nuance, they are refusing to be scored. Ask them to commit, tell them you will not hold them to it, and if they still will not choose, that is a two.
Why does depth on one component decide more than breadth?
Depth decides more than breadth because breadth is now free. Any candidate can produce a plausible box diagram in 2026, and several can produce one without understanding it. Depth is scored by taking one box the candidate drew and asking them to build it, then counting the layers before the answer becomes a brand name.
On the reminder system, the scheduler is the box that earns its keep.
How do you find the reminders due in the next minute? An index on due_at, scanned each tick. Fine, that is layer one.
Two million are due in the same second — what happens? Now they need bucketing, or a partitioned scan, or a time-wheel. Layer two.
Two workers claim the same bucket. What happens? This is where the answer either becomes a lease with a fencing token and a story about clock skew, or becomes the sentence "we would use a distributed lock", which is a vendor name wearing a hat. Layer three is where mid and senior separate almost perfectly.
The worker dies holding the lease with half the bucket sent. Layer four, and now the answer requires per-message idempotency keys and a durable record of what was dispatched before it was dispatched — the same ordering problem that shows up in designing an agent workflow orchestrator, where a tool call succeeds and the orchestrator dies before recording it.
Two scoring rules. Let the candidate choose the component, then judge the choice — volunteering the deep dive on the piece carrying the actual risk is a different level from steering you toward the caching layer they revised last night. And do not reward encyclopedic recall of a database's internals that arrived unconnected to the problem. Depth means depth on this system.
What do failure modes and operability look like on a scorecard?
They look like the failure path being drawn without being asked, followed by a specific answer to "who finds out first, and how". Most candidates draw the happy path and then bolt reliability on when prompted, which is a two, and it is by far the most common score on this dimension.
The anchors are unusually easy to write here, because engineers say almost exactly the same words at each level.
| What you hear | Score | What it tells you |
|---|---|---|
| "And we would have monitoring and alerting" | 1 | Reliability is a word they know is expected |
| "Retries with exponential backoff, and a dead-letter queue for what still fails" | 2 | Correct, generic, and prompted |
| "If the SMS provider degrades, reminders queue rather than drop, we page on dispatch-lag exceeding the reminder's own window, and the on-call runbook is to flip the channel to push" | 3 | Blast radius, a signal, and a human action |
| "I am not going to defend against the provider returning 200 and silently dropping the message. I would detect it by reconciling delivery receipts against dispatches on a rolling window and alert on the gap" | 4 | Chose what not to prevent, and named the detection instead |
That last row is the sentence I listen for hardest, and it is the cleanest single discriminator between senior and staff I have found. Deciding what not to make reliable is a judgement call that requires knowing the cost of the alternative, which is why it almost never appears in a rehearsed answer.
Two adjacent things belong on this dimension. Idempotency, because the job is talking to third parties that will occasionally take your request twice — the idempotency key pattern Stripe made standard is the expected answer, and not knowing it is a real gap at senior. And cost: a candidate who says "this will be dominated by per-message carrier cost, not by infrastructure" has understood the system better than one who optimises the database. I built a cost estimator that prices an architecture before it exists because that reflex is rare and expensive to lack.
Failure intuition also comes from having broken things. Engineers who deliberately break architectures and repair them spot single points of failure in unfamiliar designs faster than engineers who have only built, and it shows within about four minutes.
What happens when you change one constraint at minute thirty?
You find out whether the previous twenty-nine minutes were reasoning or recall. Changing a single requirement late in the round is the highest-signal probe available, because it is the only part of the interview nobody can prepare for, and because the reaction is almost involuntary.
Weak candidates defend. They explain why the original design still works, which is occasionally true and usually a tell. The next tier wipes the canvas and starts over, throwing away work that was mostly still correct — the same instinct that makes engineers treat a run that completed six of nine steps as a failure rather than as six durable results.
A solid response separates what survives from what does not, out loud, before touching anything. A strong one says what the change reveals about an earlier assumption that turned out to be load-bearing and wrong. That admission is not a penalty. It is the most senior thing a candidate can do in the room.
Pick the constraint deliberately, because different changes probe different dimensions.
| The constraint you change | What it actually probes | The answer that scores |
|---|---|---|
| Delivery must happen within five seconds of the trigger, not the minute | Whether the scheduler design was understood or copied | Bucket granularity and claim latency change; storage, idempotency and dispatch do not |
| Legal says message bodies cannot be retained beyond 24 hours | Whether data flow was ever really considered | Retention split from the audit trail; render late, store pointers, keep the receipt not the text |
| One engineer, six weeks, ship it | Reversibility and negative scope | What gets deleted from the diagram, in order, and which cut is hardest to undo later |
| Reminders now go to four countries with different carriers | Whether the third-party boundary was modelled or assumed | Per-provider adapters, per-provider failure policy, and the admission that dedupe semantics now vary |
The six-week variant is the one I use most in startup loops, and it is uncomfortable in a productive way. A candidate who cannot delete anything from their own diagram has never shipped under a real deadline.
Which two dimensions actually decide hire or no hire?
Trade-off reasoning and depth on one component. Everything else shapes the level or the debrief narrative — but when I have reread a scorecard six months later and understood why the decision was right or wrong, it has been those two rows doing the work.
The reason is that the job is those two things. Someone hands you an ambiguous problem and needs a decision they can live with, which is trade-off reasoning under time pressure. Then somebody has to build one piece of it properly, which is depth. Framing and communication are the gates that let those two be observed at all.
The interesting case is when the two disagree, and it happens often enough to need a policy.
Deep but no trade-off sense is a specialist. Excellent inside a well-defined boundary, and needs someone else to draw the boundary. That is a hire on a team that has an architect and a no-hire on a team of five.
Broad trade-off talk with no depth is the more dangerous profile, because it interviews beautifully. Fluent, opinions about CAP, four queues compared from memory, and when you ask them to build one they cannot. If the loop has no depth probe, this candidate passes every time. That is the specific failure the rubric exists to prevent.
What do candidates over-prepare that earns no score at all?
Back-of-the-envelope arithmetic, memorised reference architectures, and the component zoo. Those three absorb most of the preparation time I see, and on their own they move a score by almost nothing.
Estimation theatre. Computing 2,314 queries per second and then drawing the architecture you were always going to draw is arithmetic, not design. A number scores when it changes a decision — "that is 40 terabytes a year, which rules out keeping it all in the primary" beats a full page of multiplication. Say your assumptions are invented, out loud, because made-up numbers you flag as made up are a legitimate design tool while made-up numbers presented as measurements are how candidates get caught.
Reciting somebody else's architecture. How Uber does dispatch is not an answer to a question about reminders. Of the 55 production architectures I pulled apart, 51 ran on asynchronous message passing; the component list was never the differentiator. It is the same gap I keep hitting when watching engineers learn system design on a canvas — the knowledge is complete and the judgement about which constraint calls for which piece was never trained.
Naming components as though naming were designing. "We would add a CDN, a load balancer, an API gateway" is a zero, and the gateway is the reliable tell: routing everything through one is the most common architecture mistake I see in interviews, and the candidate almost never notices they have drawn a single point of failure, a throughput bottleneck and a deployment chokepoint in the same box.
| What candidates spend prep time on | What it scores on its own | What would have scored instead |
|---|---|---|
| Back-of-envelope arithmetic | Close to nothing | One estimate that eliminates one option, stated in a single sentence |
| Memorised FAANG architectures | Nothing, and it can go negative if it does not fit | The reasoning that produced the architecture, applied to this problem |
| Naming components and drawing them neatly | Nothing | Saying what breaks if you remove each box |
| Rehearsed trade-off lists | One point | The reversal condition for one trade-off that matters here |
| Depth on one component of their choosing | Two points, and it decides the hire | The same, but on the risky component rather than the familiar one |
The diagram itself scores nothing, which surprises people. I build a diagramming product, so read that with the appropriate suspicion, but a rough sketch with reasoning attached beats a tidy one without it every single time. Neatness is not a dimension.
Three answers to the same question, scored
Below are three answers to the reminders question, each scored on the five dimensions. These are constructed illustrations, not transcripts of real candidates — I wrote them to sit exactly on the anchors above, so the difference shows up in prose rather than in a table cell.
Answer A opens with the component list: API gateway, queue, worker pool, notification service. Two clarifying questions get asked and the answers change nothing. Told that a duplicate reminder is worse than a late one, the design keeps at-least-once delivery with no deduplication anywhere. Asked how the scheduler finds due reminders: a cron job that queries the database. Asked what happens at two million due in the same minute: we would scale the workers.
Answer B establishes that a reminder means SMS and push, gets the volume, and asks whether a duplicate or a late message is worse. Told duplicates are worse, it designs a due-time bucket table, workers claiming buckets under a lease, an idempotency key per appointment-channel-time triple, a dead-letter path, and a reconciliation loop over delivery receipts. It explains why not Kafka. When the latency constraint changes to five seconds, it names bucket granularity as the thing that has to change and keeps the rest.
Answer C contains everything in B and opens differently. The design is dominated by one fact: the system talks to carriers it cannot roll back, so exactly-once is unavailable and the job is making duplicates cheap rather than impossible. It uses the provider's own idempotency key where one exists and its own ledger where none does. It names the failure it will not defend against — a provider returning success and silently dropping the message — and detects it by reconciliation instead. When the constraint changes, it says an earlier assumption about batch size was wrong and names the measurement that would settle it.
| Dimension | Answer A | Answer B | Answer C |
|---|---|---|---|
| Problem framing | 1 | 3 | 4 |
| Trade-off reasoning | 1 | 3 | 4 |
| Depth on one component | 1 | 3 | 4 |
| Failure modes and operability | 1 | 3 | 4 |
| Communication under a constraint change | 2 | 3 | 4 |
| Verdict | No hire | Hire, senior | Strong hire, staff |
Answer A is not a bad engineer. It is very often a good engineer answering the question they prepared for. That is the whole problem, and it is why the anchors have to exist before the interview rather than after it.
How does the bar differ at a Series A startup versus a large company?
The dimensions do not change, the weights do. At a Series A the operability and negative-scope rows carry far more weight and the deep-dive row carries less, because there is nobody to hand the operational half to. At a large company the depth row dominates, because the operational surface genuinely is somebody else's job and the candidate will be judged on how well they build one component inside an existing platform.
| Dimension | Series A weighting | Large company weighting | Why they differ |
|---|---|---|---|
| Problem framing | High | Medium | At a startup the requirements are genuinely unknown, so narrowing is the job rather than a warm-up |
| Trade-off reasoning | High, biased to reversibility | High, biased to correctness | A startup needs cheap decisions it can undo; a large company needs decisions that survive review |
| Depth on one component | Medium | Very high | Startup engineers go one layer down across five components; platform engineers go five layers down on one |
| Failure modes and operability | Very high | Medium | Nobody is going to carry the pager for you at eleven engineers |
| Constraint change | High | Medium | The constraint change is the whole experience of working at a Series A |
Dropbox's published engineering career framework describes its Staff level as designing "systems with significant ambiguity and/or lots of systems that depend on it" and being accountable for "making tradeoffs where appropriate". Good definition, large-company shaped. Transplant it unmodified into an eleven-person startup and you will reject people who would have been your best hire, because at that size ambiguity is not a level, it is Tuesday.
The mistake runs both ways. Small teams copy a big-company loop they cannot calibrate and hire someone who has never owned a pager. Large companies penalise pragmatism and reject the candidate who wanted to delete a service. Both are rubric failures, not candidate failures.
What the scorecard is really for
The scorecard's job is not ranking candidates. It is making the debrief a conversation about evidence, where "I scored trade-off reasoning a two, here is the exchange" is answerable and "I got a bad vibe" is not. That change alone improves hiring more than any question you could swap in.
Copy the five-dimension table into whatever free-text field your ATS gives you, fill it in during the interview rather than after, and write one quoted sentence from the candidate beside each score. The quotes are what make the debrief work, because six months later they are the only part you will still trust.
One warning, and it applies to my rubric as much as anyone's. This measures how a person performs in a 45-minute artificial exercise about a system they will never build. It is a better proxy than a vibe. It is still a proxy, and the day you forget that is the day you start rejecting people for failing the interview rather than for being wrong about systems.
Questions people actually ask
- What do interviewers actually score in a system design interview?
- Five things, in my loop: how the candidate narrows an unbounded problem, whether their trade-offs come with a stated cost and a reversal condition, how far down they can go on one component before the answer becomes a vendor name, whether they draw the failure path without being asked, and what they do when a requirement changes late in the hour. The middle two carry the decision. The others gate it.
- Why do strong engineers fail system design interviews?
- Usually because they answer a different question than the one being scored. They demonstrate that they know what every component does, which almost every candidate above two years of experience can do, rather than showing why this particular problem called for this particular component. Naming a message queue earns nothing. Saying what breaks without it, and what it costs to have it, earns the score.
- What is the difference between a senior and a staff system design answer?
- A senior answer is correct and justified. A staff answer reframes the problem before solving it, and it is explicit about what it is choosing not to defend against. The clearest tell is negative scope. Senior candidates tell you what they would build. Staff candidates tell you what they deliberately would not build, what that leaves exposed, and how they would detect the exposure instead of preventing it.
- How much does back-of-the-envelope estimation matter in a system design interview?
- Far less than the preparation material implies. An estimate only scores when it changes a decision. Computing queries per second to three significant figures and then drawing the same architecture you were always going to draw is arithmetic, not design. The version that scores is short and consequential, something like the storage figure ruling out one database, said out loud, in one sentence.
- How long should you spend clarifying requirements in a system design interview?
- Around five to eight minutes of a forty-five minute round, and the test is not the duration but whether the answers you get visibly bend the design. Alex Xu's book puts requirements first in its four-step sequence for good reason. But asking the standard clarifying questions and then ignoring the responses is worse than asking none, because it tells the interviewer the questions were a performance.
- Should a startup use the same system design interview as a big tech company?
- Same dimensions, different weights. At a Series A company nobody inherits a platform team, so operability, cost and the ability to say what will not be built matter more than depth on a single distributed component. At a large company the depth dimension carries far more weight because the operational surface is already someone else's job. Copying a big-company loop wholesale is how small teams hire people who cannot ship.