System design interviews: what the interviewer is actually scoring

Design a URL shortener. Design a news feed. You have probably read a walkthrough of both, and if you reproduce it faithfully you will still very likely be scored as mid-level.

That is because the diagram is not the artefact being judged. Two candidates can draw an almost identical architecture and get opposite decisions, and the difference is entirely in what they said while drawing it.

The six things being scored

1. Did you pin down the problem before solving it

The question is deliberately underspecified. Diving straight into boxes is the most common and most costly opening mistake, because everything downstream is then unjustified.

Spend the first several minutes establishing who uses it, what the read and write volumes look like, what has to be consistent versus what can be stale, and what is explicitly out of scope. Then say the numbers out loud. A system at a thousand writes a day and one at a hundred thousand a second are not the same design problem, and stating which one you are solving is the sentence that makes the rest of your answer legible.

2. Can you quantify

You do not need precision. You need an order of magnitude and the willingness to produce one. Estimate the write rate, the storage growth per year, the read to write ratio.

This matters because it decides the design. If your estimate lands at a few hundred gigabytes, sharding is over-engineering and proposing it counts against you. If it lands in petabytes, a single database is a non-answer. Candidates who skip the numbers end up defending arbitrary choices.

3. Does your data model follow from the access patterns

This is where seniority separates hardest, and where the largest number of candidates lose the round without noticing.

Do not name a database and move on. Say what the entities are, what the primary read path is, and how the storage choice serves that path. A design that reads by user and time should say so, and then the index or partition key follows naturally. Working forward from the query is the senior move; working backward from a favourite technology is the junior one.

4. Do you know where it breaks first

Every interviewer eventually asks what happens at ten times the load. The strong answer names the specific component that gives out first and why, rather than sprinkling caches and replicas everywhere.

The best version volunteers it: 'the first thing to break here is the fan-out on write, because a celebrity account with ten million followers turns one post into ten million inserts'. That sentence tells the interviewer you have thought past the diagram.

5. What happens when something is down

Every box you draw is a thing that fails at 3am. Interviewers want to hear you reason about partial failure, not perfect operation.

• What does the user see when this dependency is unavailable?
• Is the write path retried, and is a retried write safe to apply twice?
• What is the blast radius if this cache is empty, or this queue is backed up by an hour?
• Which parts genuinely need to be strongly consistent, and which are fine eventually consistent?

Idempotency is the single most valuable concept to have loaded for this section. Retries are inevitable, and a design that cannot absorb a duplicate is not finished.

6. Can you defend a decision without digging in

The interviewer will push back, often on something you got right. They are testing whether the choice was reasoned or borrowed.

Give the reason you chose it and the condition that would change your mind. If their counter-argument is better, say so and adjust. Conceding well is a positive signal. Defending a weak position because you said it first is the worst outcome available.

An order that works

1. Clarify scope and users. State what you are not building.
2. Put rough numbers on it, out loud.
3. Sketch the high-level path of a single request, end to end.
4. Do the data model, driven by the main access patterns.
5. Find the bottleneck and address it, one at a time.
6. Walk the failure cases and say what degrades.
7. Summarise the trade-offs you accepted and what you would revisit first.

That last step is the one candidates skip when time runs short, and it is worth more than another five minutes of detail. A crisp closing summary is often the strongest ninety seconds of the whole round.

The failure modes

• Buzzword architecture. Naming a technology per box with no reason attached. Every named component invites a follow-up you must survive.
• Designing for scale nobody asked for. Sharding a system with four thousand users is a judgement failure, and it is read as one.
• Silence while drawing. The diagram is not self-explanatory. The narration is the answer.
• Never mentioning failure. A design that only describes the happy path reads as one that has never been operated.
• Running out of time in the data model. Watch the clock and leave room for scaling and failure.

How to prepare without memorising walkthroughs

Memorised designs collapse on the first follow-up, because the follow-up is about your specific words. A better exercise is to take a system you have actually worked on and interrogate it: what would break at ten times the traffic, what would you change now, what did you accept at the time and why.

Then practise saying it aloud in the order above, inside forty minutes. The constraint is real and it is part of the skill. If you want the reasoning technique that carries all of this, trade-offs is the piece that most reliably moves candidates up a level.