The System Design Interview Rubric Nobody Shows You
The Hidden Checklist Behind Your System Design Score, Made Explicit So You Can Audit Your Own Answers Against It
Every serious system design interview is evaluated against a rubric.
Interviewers are trained on it, calibrated against it, and expected to justify their ratings using it.
The rubric defines what a strong answer looks like, what a weak one looks like, and the specific behaviors that distinguish them. It is a real, concrete document, and it shapes the outcome of every interview.
Candidates never see it.
They prepare for one of the most consequential rounds of their careers without knowing the exact criteria they will be measured against. They study concepts and practice problems, hoping their effort lines up with what interviewers want, but they are essentially guessing at the target.
This is the central problem with system design preparation.
The standard exists, it is specific, and it is hidden from the very people being judged by it.
The good news is that these rubrics are remarkably consistent across companies, because the underlying skills they measure are universal.
The categories, the criteria, and the behaviors that earn a pass or a flag follow patterns that can be reconstructed in detail.
Once a candidate can see the rubric clearly, preparation stops being a guess and becomes a precise exercise in producing the right evidence.
This article reconstructs the system design interview rubric, category by category, in the level of detail interviewers actually use.
For each category, it lays out the specific criteria, what earns a pass, and what earns a flag.
The goal is to hand candidates the checklist that is normally kept behind the door, so they can audit their own answers against the real standard rather than an imagined one.
How to Read This Rubric
Before the categories, a note on how the rubric works in practice.
Interviewers do not award points for mentioning the right words. They look for observable behaviors that serve as evidence of a skill.
Each criterion below is something an interviewer can watch for and record, and each has a clear version that earns a pass and a clear version that earns a flag.
The rubric is also not a simple checklist where every item carries equal weight.
Some categories, such as depth and trade-offs, weigh more heavily than others, and a single serious flag in a critical category can outweigh several passes elsewhere.
The weighting is covered after the categories themselves.
Finally, the rubric is read against the candidate’s target level.
The same behavior can be a pass at the mid-level and a flag at the senior or staff level, because the bar rises.
With these points in mind, here is the rubric, category by category.
Category 1: Problem Definition
The first category evaluates how the candidate establishes what they are building before they build it.
It is assessed in the opening minutes and sets the tone for the entire interview.
Criterion: Clarifying functional requirements. The interviewer checks whether the candidate identifies what the system must actually do. A pass looks like asking specific questions about the core features and confirming which ones are essential. A flag looks like assuming the features without asking, or listing vague goals rather than concrete capabilities.
Criterion: Clarifying non-functional requirements. The interviewer checks whether the candidate surfaces the qualities the system must have, such as the expected scale, the latency targets, the availability needs, and the consistency requirements. A pass looks like explicitly asking how many users, how much data, and how fast the system must respond. A flag looks like designing without ever establishing the scale, which leaves the entire design ungrounded.
Criterion: Establishing scope. The interviewer checks whether the candidate decides what to focus on and what to leave out. A pass looks like stating plainly that they will concentrate on certain core flows and set others aside for now, with a reason. A flag looks like trying to cover everything at once, or never defining boundaries, which leads to a thin, unfocused answer.
Criterion: Confirming before designing. The interviewer checks whether the candidate aligns on the problem before jumping into a solution. A pass looks like summarizing the agreed requirements and scope before drawing anything. A flag looks like beginning to design within the first thirty seconds, which signals a rush to solve a problem that has not been understood. This category is heavily watched because skipping it is one of the most common and damaging early mistakes.
Category 2: Estimation and Sizing
The second category evaluates whether the candidate grounds the design in numbers. Estimation is short but influential, because it determines whether the architecture is appropriate for the scale.
Criterion: Doing the rough math. The interviewer checks whether the candidate calculates the key quantities, such as requests per second, storage growth, and bandwidth. A pass looks like a clear, simple calculation, for example deriving that 100 million daily users making 10 requests each produces roughly 11,500 requests per second on average. A flag looks like skipping the math entirely or producing numbers with no visible reasoning.
Criterion: Using estimates to drive decisions. The interviewer checks whether the numbers actually inform the design or sit idle. A pass looks like the candidate using the calculated scale to justify a decision, such as concluding that the write volume exceeds what a single database can handle and therefore requires sharding. A flag looks like doing the math as a ritual and then designing without reference to it, which wastes the estimation entirely.
Criterion: Knowing which numbers matter. The interviewer checks whether the candidate focuses on the estimates that affect the architecture rather than getting lost in precision. A pass looks like quickly identifying the one or two figures that drive the design and not belaboring the rest. A flag looks like spending excessive time on exact calculations that do not change any decision, which signals poor judgment about where effort belongs.
Category 3: High-Level Design
The third category evaluates the overall architecture.
This is where the candidate translates requirements into a working structure, and it forms the backbone of the answer.
Criterion: Producing a coherent architecture. The interviewer checks whether the design holds together as a sensible whole. A pass looks like a clear set of components connected in a logical flow, where each piece has a purpose. A flag looks like a disjointed collection of parts with unclear relationships, or a design that contradicts itself.