How Senior System Design Interviews Are Scored

1. What the Interviewer Is Actually Writing Down

In a system design interview, you are most likely to be asked to design a system you have already built. And that's the problem.

Engineers who have shipped a real system answer from memory. The answer sounds like a report: the architecture, what ran, how it behaved at scale. It is accurate and complete, and it is routinely scored below the level they are working at. Somebody with less experience and a weaker design scores higher, which is infuriating until you see what the interviewer is writing down.

Interviewers are not comparing your boxes against a reference answer, because for any question worth asking there is no single right design. What they write down is behavior, and many companies give them a sheet that names four behaviors, each scored on its own.

• Scoping under ambiguity. What you did with a question that was left vague on purpose.
• Trade-off reasoning. Whether you can name both sides of a choice and then actually choose.
• Depth on demand. Whether any box you drew survives three follow-up questions.
• Judgment. Whether the design is the right size for the problem.

Two consequences follow, and both are uncomfortable. The first explains why the experienced answer loses: a reasonable design, scoped well and defended with real reasoning, beats an excellent design with none of that. Interviewers are not grading the drawing. They are predicting how you will behave on a real problem where nobody knows the answer in advance.

The second is that the four are scored separately, so you can be strong on three and still be rated a level lower because of the fourth. The most common pattern is a candidate with excellent depth who never scoped, which reads as somebody who builds well and chooses badly.

2. Scoping Under Ambiguity

The question is vague on purpose. "Design a ride-sharing system" is not missing information because the interviewer forgot to include it. The missing information is the test.

Strong scoping looks like this in practice:

• Narrowing the problem out loud. "This could mean matching, payments, or maps. I will treat matching as the core and mention the others where they connect. Does that work for you?"
• Asking for the numbers that change the design. Daily active users, read-to-write ratio and the size of the largest single object all move your architecture. The company's launch date does not.
• Stating what is out of scope, so the interviewer knows it was a decision rather than an omission.

Weak scoping is usually not silence. It is four or five questions that sound thorough and change nothing, followed by the design the candidate had already decided on.

The strongest thing you can do here is connect a question to a decision before you ask it. "How large is the largest file, because that decides whether this can go through the request path at all" is a different signal from "how large are the files."

3. Trade-off Reasoning

Every design decision that matters has at least two defensible answers. The signal is not which one you pick. It is whether you knew you were picking.

A complete trade-off has three parts, and most candidates give only the last one, without its condition.

1. The options, stated fairly. Describe the one you will reject in a way somebody who prefers it would recognize.
2. The cost of each, in terms that could actually be measured.
3. The choice, with the condition attached. "I am choosing A. If the write rate turned out to be ten times higher, I would choose B instead."

The condition is what separates a decision from an opinion. It also protects you, because an interviewer who disagrees with your choice can now disagree with the condition rather than with your competence.

Saying "it depends" is correct and worthless on its own. Saying "it depends on the read-to-write ratio, and here is what I would do on either side of ten to one" is the same insight made usable. The difference costs one sentence.

4. Depth on Demand

At some point the interviewer will point at one box and ask how it works. This is not a trap. It is the cheapest way to find out whether your design is understood or recited.

The working assumption is simple: you drew it, so you own it. "I would use a managed service for that" is an acceptable answer only if you can also say what the service does and what it costs you.

Three follow-ups is roughly the depth that gets tested. If you draw a queue, expect to be asked what happens when a consumer fails, then what happens when it fails repeatedly, then what happens to ordering while that is going on. Each layer is fair, and each is where a recited design stops having answers.

So do not put a component on the board to look thorough. Every box is a promise that you can go three levels down, and a smaller design you understand completely scores better than a larger one you cannot defend.