The short answer
A system design interview is usually scored on five things: how well you clarify requirements and estimate scale, the quality of your high-level design, your data model and storage choices, how you reason about scale and trade-offs, and how clearly you communicate. Each is marked on a scale (we use 1 to 5), and the marks are read against the level you are interviewing for, so the same answer can be a hire for a mid-level role and a lean no hire for a senior one. There is rarely one right design; the path you take is what gets scored.
Why there is no single right answer
A coding question usually has a correct output. A design question does not. Ask ten strong engineers to design a notification service and you will get ten different diagrams, all defensible. So interviewers cannot score the diagram against an answer key. They score the decisions behind it: what you asked, what you assumed, what you chose, what you rejected and why.
That is why a rubric matters. Without one, two interviewers watching the same answer can come away with different verdicts, one impressed by the breadth of components and the other worried that nothing was justified. A rubric splits the round into lines that can each be judged on their own, and makes the interviewer write down what they saw for each line before they pick a verdict.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Requirements and estimates | Questions before drawing, an agreed scope, and rough numbers (requests per second, storage per day) that later choices lean on. |
| High-level design | Written APIs, a few components each with a reason, and a request path that can be followed end to end. |
| Data and storage | Keys and access patterns stated first, a storage choice that fits them, and a plan for growth. |
| Scale and trade-offs | The bottleneck found without prompting, two options compared, and what is given up said out loud. |
| Communication | Thinking out loud, checking in, using hints well and finishing on time. |
What a 1, a 3 and a 5 look like
Marks only mean something if the interviewer knows what each one looks like. This is roughly how our interviewers read each line. A 2 or a 4 sits between the descriptions.
| Skill | 1: a clear gap | 3: solid but shallow | 5: strong at this level |
|---|---|---|---|
| Requirements and estimates | Starts drawing straight away; requirements surface only when the interviewer forces them. | Lists the main features and gives rough numbers, but the numbers do not shape any later choice. | Separates must-haves from nice-to-haves, agrees numbers, and uses them later to justify caching, storage or partitioning. |
| High-level design | Components appear without a reason; the request path is hard to follow. | A sensible set of components and APIs that would work at modest scale. | A small, clean design where every component has a job, the APIs are written down and the request path is easy to trace. |
| Data and storage | No data model, or a database named without saying what is stored or how it is read. | A reasonable schema and a storage choice that fits, with little thought about growth. | Keys and access patterns first, then a storage choice that fits them, with a plan for indexes, partitioning and retention. |
| Scale and trade-offs | Says the system will "scale horizontally" without saying where the pressure is. | Spots the main bottleneck when asked and offers one fix. | Finds the bottleneck unprompted, compares two options honestly and says what each one costs, including failure and consistency. |
| Communication | Long silences, or talks without checking in; runs out of time. | Explains clearly but needs prompting to move on or to summarise. | Thinks out loud, checks in at the right moments, takes hints without losing the thread and finishes on time. |
How the bar changes by level
The rubric lines stay the same from junior to principal. What changes is the mark you need on each line for a hire.
For junior and mid-level engineers, interviewers mostly want a working design with clear APIs, a sensible data model and a request path that holds together. Scale and trade-offs matter, but a candidate who handles the basics well and needs a nudge on bottlenecks can still be a hire.
For senior engineers, scale and trade-offs carry the most weight. The interviewer expects you to name the hard part of the problem early, spend your time there, and talk about failure: what happens when a region goes down, when a queue backs up, when one key gets most of the traffic.
For lead and principal roles, the conversation widens again: cost, operability, how a team would build and run this, how it would change over two or three years. A design that is technically fine but ignores how it would be run day to day often lands as a lean hire at these levels.
A worked example
This is a made-up example to show how marks are given, not a real candidate. The question: design a link shortener that shows the owner how many times each link was opened. The candidate is interviewing at mid level.
They open by asking how many links are created per day and how often each is opened, agree on a read-heavy system, and estimate reads at a few thousand per second. Good start: requirements and estimates gets a 4. They write two APIs (create and redirect), sketch an app tier, a cache and a database, and walk a redirect from the browser to the database and back. High-level design gets a 4.
For storage they pick a key-value store keyed by short code, which fits the access pattern, but when asked how the counts are stored they suggest incrementing a counter on every redirect in the same table. The interviewer asks what happens to a popular link; the candidate sees the hot-row problem only after a hint and moves counting to an asynchronous queue. Data and storage gets a 3, scale and trade-offs a 3. They explain clearly throughout and finish with five minutes to spare: communication 4.
Verdict at mid level: hire, with the report naming two things to fix first. Separate the write path for analytics from the read path before being asked, and practise spotting hot keys. At senior level the same answer would more likely be a lean hire, because the bottleneck needed a hint.
How to use the rubric when you practise
- Practise the first ten minutes on their own. Write requirements and numbers for five problems without drawing anything.
- After each practice design, mark yourself on the five lines and write one sentence of reasoning for each mark. Vague reasons mean you are not sure what the line asks for.
- Pick your weakest line and design two problems focusing only on it, for example storage: write the keys and access patterns before anything else.
- Time every attempt. Communication includes finishing; a strong design at minute 70 fails a 60-minute round.
- Get marked by someone else at least once. Your own marks drift upwards, because you know what you meant.
What the verdict means
After the marks, the interviewer gives a verdict on a five-step scale: strong hire, hire, lean hire, lean no hire or no hire. It is not an average of the marks. One very weak line, such as no data model at all, can pull a round down on its own, and one excellent line rarely rescues the rest. In a mock interview, the verdict is the interviewer's honest read of how the round would likely land in a real interview at your level. The marks and notes tell you why.