The System Design Interview: What's Actually Being Evaluated

System design interviews are scored on process, not architecture. Interviewers with a written rubric (increasingly the norm) are rating how you probe requirements, whether your trade-offs are honest, how you respond to constraint changes, and whether they could work with you at a whiteboard. Candidates who memorize reference architectures optimize the one thing the rubric barely counts. This guide explains what evaluators actually score and how to practice for it.

This is not another how-to-scale-a-social-network tutorial; those exist in abundance. It is the evaluator’s-side view, which changes how you spend prep time.

Why companies run this format

Design questions are deliberately too big and too vague to finish. That is the point: the format simulates the ambiguity of real senior work, where requirements are incomplete, constraints conflict, and the first job is figuring out what problem you are solving. Well-run companies design this stage deliberately (the interviewer’s side of this is covered in the technical interview methods guide they may well be following), and they calibrate expectations by level: a mid-level engineer is expected to reason cleanly within a design; a senior engineer to own one end to end; a staff engineer to interrogate whether the right thing is being built at all.

What the rubric actually rewards

1. Requirements before architecture

The strongest signal in the first five minutes: does the candidate design for the problem or for the problem they prepared? Concretely, that means asking before drawing: who uses this, how many of them, read-heavy or write-heavy, what latency matters, what can be eventually consistent, what is explicitly out of scope.

Interviewers deliberately underspecify. Jumping straight to microservices boxes without sizing the problem is the most common failure, and it fails candidates who “knew” the answer.

2. Honest trade-offs

Every real design decision has a cost. Rubrics reward naming it: “I’d start with a single Postgres instance because the write volume doesn’t justify sharding complexity; here’s the point where that stops being true.” The pattern to internalize: choice, because, cost, revisit-when.

The inverse fails: presenting a choice as free, or name-dropping technologies without a reason attached (“we’ll use Kafka” …for what, exactly?). An interviewer’s follow-up (“why not a simple queue?”) is not a trap; it is the rubric asking for the because.

3. Adaptation under changed constraints

Mid-design, the interviewer moves a goalpost: “now make it global,” “now the payload is video,” “now cut the budget in half.” This is scripted, and it is the highest-weight moment for senior candidates: they are scoring whether you revise your design honestly (including saying “that invalidates my earlier choice, let me back up”) or defend sunk decisions.

4. Communication at the board

You are being evaluated as a future design-review colleague: do you narrate your thinking, check in (“does this direction match what you had in mind?”), keep a legible structure on the board, and land somewhere concrete in forty-five minutes? Silent drawing followed by a reveal scores badly even when the reveal is good.

5. Depth on demand, honestly bounded

Expect one “zoom in”: consistency model, cache invalidation, the failure path. Rubrics reward real depth in your strong areas and honest boundaries elsewhere. “I haven’t operated Cassandra; my reasoning from first principles is…” outperforms confident vagueness every time, and experienced interviewers probe until vagueness confesses.

A shape that works (not a script)

Budget for a 45-minute session: ~5 minutes on requirements and scale estimates, ~15 on the core high-level design, ~15 on the deep dive wherever the interviewer steers, ~5 on failure modes and evolution, keeping ~5 in reserve for the constraint change. Announce the plan out loud at the start; structure is itself scored, and it keeps you from spending thirty minutes on the easy part.

Two habits worth drilling until automatic: do arithmetic out loud when sizing (a wrong number reasoned transparently beats a suspiciously round one), and keep a visible list of “things I’m punting on” so scope cuts read as judgment rather than omission.

How to practice

• Design real systems you already use, out loud, at a whiteboard or shared doc: how would you build the group-chat app, the parking sensor network, the CI system? Familiar products keep you honest about requirements.
• Practice the interruption. Have a partner (or an AI running the interviewer side; using AI to prepare has setups) inject constraint changes mid-design. Solo prep never trains this and the interview always includes it.
• Review your own trade-offs from actual work using choice/because/cost/revisit-when; these become your depth reservoir, and they connect to the same story bank your behavioral answers draw from.
• Calibrate against your level. Ask the recruiter what this stage evaluates at your level; companies with structured processes will tell you, often in their candidate prep materials.

Fold this into the wider plan in the technical interview prep hub: design rounds are one stage of a loop, and the loop rewards the same thing throughout: visible reasoning about true things.