system-design

What Interviewers Actually Score You On (Rubrics by Level)

The interviewer is filling out a scorecard, not admiring your architecture. Knowing what’s on that scorecard — and how the bar shifts by level — lets you aim at the right target.

Prerequisites: The Framework, Interview Formats Time to read: ~16 minutes

The scorecard exists

🚨 After the interview, the interviewer fills out a structured rubric — not “did I like the design?” but ratings across specific dimensions. Knowing those dimensions tells you what to demonstrate, and knowing how the bar rises by level tells you what “good enough” means for the role you’re targeting.

The dimensions are consistent across companies (the specifics vary):

The scoring dimensions

🚨 What every design interview evaluates:

1. Requirements & scoping — Did you clarify the problem, ask the right questions, and scope appropriately? → Requirements Gathering

2. Estimation — Can you size a system with sound reasoning and use the numbers? → Estimation

3. High-level design — Is the architecture sound, and does it meet the requirements? Are the components justified?

4. Depth / technical knowledge — Can you go deep on components, and do you understand how they work and fail? → Deep Dives

5. Trade-offs & judgment — 🚨 Do you reason about costs and alternatives, or recite? Often the highest-weighted dimension. → Trade-off Vocabulary

6. Handling failure & scale — Do you address what breaks, and design for failure?

7. Communication — 🚨 Can you explain clearly, drive collaboratively, narrate your thinking? A silent genius scores poorly.

8. Handling ambiguity/pushback — How do you respond to “that won’t work” and to reaching your knowledge limit? → Handling Uncertainty

🚨 Notice: only about half are “technical.” Communication, judgment, and handling ambiguity are weighted heavily — a technically-correct design delivered poorly scores worse than a slightly-imperfect one delivered with clear reasoning and good trade-offs.

The bar by level

🚨 The same question is asked at every level; what changes is what a passing answer looks like. (See also Interview Formats.)

Dimension	Junior (L3)	Mid (L4/SDE-2)	Senior (L5)
Drive	Interviewer guides; you follow well	You drive; occasional nudges	You drive entirely, including scoping and time
Requirements	Ask some when prompted	Ask unprompted, scope down	Challenge the premise; find the real constraint
Estimation	Can do with help	Unprompted, right order of magnitude	Use estimates to make decisions
Design	Working single-region design	Correct cache/queue/shard use, justified	Multiple viable designs compared; picks and defends
Depth	One level (“we’d use Redis”)	Two (“cache-aside, 5-min TTL, invalidation”)	Three (“…and when it fails, and the race, and the cost”)
Failure	Mentions if asked	Handles main failure modes	Designs for them from the start; blast radius
Trade-offs	Recognizes them	States them	Quantifies them, ties to business impact
Operations	Not expected	Basic monitoring	Rollout, migration, on-call, cost

🚨 The single clearest junior→mid→senior progression is depth (deep dives): naming (junior) → configuring (mid) → failure-modes-and-trade-offs (senior). Aim one level above your target to be safe.

What separates a “strong hire” from a “hire”

🚨 Beyond meeting the bar, these push you into “strong hire”:

Bringing up things unprompted — idempotency, the celebrity problem, cost, a failure mode — before being asked. → Deep Dives
Connecting decisions to requirements — “because we said it’s read-heavy…” — showing the design is derived, not pattern-matched.
Owning the design’s weaknesses — “the downside of this is X.” → Trade-off Vocabulary
Recovering well from being wrong — 🚨 when the interviewer says “that won’t work,” a graceful recovery scores higher than never being challenged. → Handling Uncertainty
Managing the time yourself — reaching a complete design without being rushed.
Cost and operational awareness — mentioning cost and operability unprompted (rare, high-signal).

What tanks an interview

🚨 Regardless of level, these fail candidates:

Jumping to a solution without requirements — signals inexperience.
No trade-offs / reciting components — the mid-level ceiling.
Silence — the interviewer can’t evaluate what you don’t say.
Over-engineering — sharding/microservices for a small system signals poor judgment.
Ignoring failure — only the happy path.
Not driving (at mid+) — waiting to be led.
Bluffing when you don’t know — worse than reasoning honestly.
Defensiveness when challenged — arguing instead of engaging.

The reframe: it’s a job simulation

🚨 The rubric maps directly to the job. Each dimension tests something you’d do daily:

Requirements → specs are always ambiguous.
Estimation → deciding capacity before building.
Trade-offs → every real decision has a cost.
Failure → everything fails at scale.
Communication → convincing a team.
Handling ambiguity → most of engineering.

🎙️ So the meta-strategy is: behave like a good senior engineer in a design review — ask, estimate, propose, weigh trade-offs, handle failure, communicate, and respond well to feedback. The rubric is measuring whether you’d be good to work with, not whether you memorized an architecture.

🚨 Interview traps

Not knowing what’s being scored — aiming at “cool architecture” instead of the rubric.
Underestimating the non-technical dimensions — communication and judgment are heavily weighted.
Aiming at your exact target level — aim one above for margin.
Not going deep enough for the level — the junior→mid→senior gap is mostly depth.
Not bringing up things unprompted — the strong-hire differentiator.
The tanking behaviours above.

🎙️ Soundbites

“Let me address what happens when this fails, and the trade-off I’m making here…” (hitting the high-weight dimensions unprompted)
“Because we established this is read-heavy, I’m choosing to…” (connecting to requirements)
“The weakness of this approach is X, which I’d accept because Y.” (owning it)
“Good point — that wouldn’t handle the celebrity case. Let me revise to a hybrid approach.” (recovering from a challenge — scores high)

🛠️ Try it

1. Self-score a mock against the rubric. After a timed mock, rate yourself 1-5 on each of the eight dimensions. Your low scores are your study list — and you’ll notice the non-technical ones (communication, trade-offs) are easy to neglect. → Self-Grading Checklist

2. Identify your current level per dimension. Using the level table, honestly place yourself (junior/mid/senior) on each dimension for a recent mock. The gap to your target level is specific and actionable — usually “go deeper” and “state more trade-offs.”

3. Practice the strong-hire behaviours. In a mock, deliberately bring up idempotency, a failure mode, and a cost unprompted. Practice making these automatic — they’re the difference between “hire” and “strong hire.”

4. Practice recovering from a challenge. Have a partner say “that won’t work” to a design decision. Practice engaging gracefully and revising rather than defending — recovery scores higher than never being wrong.

Check yourself

1. What dimensions does a design interview actually score, and why are half of them non-technical?

Roughly eight dimensions: requirements and scoping, estimation, high-level design, technical depth, trade-offs and judgment, handling failure and scale, communication, and handling ambiguity/pushback. Only about half of these — high-level design, depth, failure/scale — are purely technical; the others (requirements, estimation as reasoning, trade-offs, communication, handling ambiguity) are about *how you think and interact*, not just what you know. They're weighted heavily because the interview is a *simulation of the job*, and the job is far more than producing correct architectures: you must clarify ambiguous specs (requirements), decide capacity before building (estimation), weigh the cost of every decision (trade-offs), convince teammates (communication), and make progress under uncertainty (handling ambiguity) — every single day. A technically brilliant engineer who can't communicate their reasoning, never considers trade-offs, or gets defensive when challenged is genuinely worse to work with and less effective than a slightly-less-brilliant one who does those things well, and the rubric reflects that. So a technically-correct design delivered silently, with no trade-offs and no failure handling, scores worse than a marginally-imperfect design delivered with clear narration, explicit trade-offs, and graceful handling of pushback. Candidates who focus only on the technical dimensions — obsessing over the "right" architecture — miss that half their score comes from the softer dimensions that predict whether they'd be a good colleague, which is ultimately what the company is trying to assess.

2. The same question is asked at every level — what changes, and what's the clearest progression?

What changes is what a *passing answer* looks like on each dimension — the question ("Design Twitter") is often identical across levels, but the depth, autonomy, and sophistication expected rise. A **junior** candidate can be guided by the interviewer, produces a working single-region design, goes one level deep ("we'd use Redis"), mentions failure if asked, and recognizes trade-offs. A **mid-level** candidate drives the design with occasional nudges, scopes requirements unprompted, estimates correctly, uses caches/ queues/sharding appropriately *with justification*, goes two levels deep ("cache-aside, 5-minute TTL, invalidation strategy"), handles the main failure modes, and states trade-offs explicitly. A **senior** candidate drives entirely (including scoping and time management), may challenge the premise to find the real constraint, uses estimates to *make* decisions, compares multiple viable designs and defends a choice, goes three levels deep (configuration *plus* failure modes, races, and costs), designs for failure from the start, and quantifies trade-offs tied to business impact. The single clearest progression is **depth**: naming a component (junior) → configuring it (mid) → understanding its failure modes, edge cases, and trade-offs (senior). This is actionable — to move up a level, the most reliable improvement is going deeper on components, from "what to use" to "how to configure it" to "how it breaks and what it costs." The practical advice is to aim one level above your target, so that even a below-your- best performance clears the bar for the role you actually want.

3. What separates a "strong hire" from a plain "hire"?

Going beyond meeting the bar to demonstrate proactive judgment and grace under pressure. Specific behaviours that push a candidate into "strong hire": **bringing up important considerations unprompted** — raising idempotency for a payment flow, the celebrity fan-out problem for a feed, cost implications, or a failure mode *before* the interviewer asks, which shows you naturally think about these rather than only addressing them when prompted. **Connecting every decision back to requirements** ("because we established this is read-heavy, I'm choosing..."), showing the design is *derived* from the problem rather than pattern-matched from memory. **Owning the design's weaknesses** proactively ("the downside of this approach is X, which I'd accept because Y, or fix with Z"), demonstrating you understand your own design deeply enough to critique it. **Recovering gracefully when told "that won't work"** — engaging with the challenge and revising, which counterintuitively scores *higher* than never being challenged, because it shows how you handle being wrong (a constant in real work). **Managing time yourself** to reach a complete design without being rushed. And **cost and operational awareness** — mentioning cost or operability unprompted, which is rare and high-signal because most candidates ignore it entirely. The common thread is *proactivity and maturity*: a plain "hire" does the framework competently when led, while a "strong hire" drives it, anticipates the hard parts, owns the trade-offs, and handles pushback like an experienced engineer in a real design review — signaling not just competence but that they'd elevate the team.

4. Why does recovering well from being told "that won't work" score higher than never being challenged?

Because how you handle being wrong is one of the most important and predictive things about working with someone, and the interview is a proxy for that. Being challenged is inevitable in the interview (interviewers often push specifically to test this) and in the job (your designs *will* have flaws that colleagues point out), so the interview is genuinely trying to observe your response to pushback — and a graceful, engaged recovery reveals traits that a smooth, unchallenged performance can't: intellectual honesty (you acknowledge the valid point rather than defending a flawed position), collaborative openness (you treat the feedback as helpful input, not an attack), adaptability (you can revise your thinking under new information), and composure (you stay constructive under pressure). Saying "good point — that wouldn't handle the celebrity case; let me revise to a hybrid approach" demonstrates all of these and shows you'd be someone teammates can give feedback to and who improves designs collaboratively. By contrast, a candidate who's never challenged has simply not been *tested* on this crucial dimension — the interviewer learned nothing about how they handle disagreement — and a candidate who responds to challenges *defensively* (arguing, dismissing the concern, doubling down on a flawed choice) reveals the opposite: someone difficult to work with, who mistakes ego for correctness. Since real engineering is full of "that won't work" moments — from code review, design review, incident retros — the ability to receive that gracefully and improve is a core competency, and demonstrating it (which requires *being* challenged) is more valuable evidence than a flawless run that never surfaced it. Interviewers sometimes manufacture a challenge precisely to elicit this signal.

5. How does viewing the rubric as a "job simulation" change your strategy?

It reframes the goal from "produce an impressive architecture" to "behave like a good senior engineer in a design review," which aligns your effort with what's actually scored. Each rubric dimension maps directly to a daily job activity: requirements-gathering because product specs are always ambiguous and you must clarify them; estimation because you decide capacity before building; trade-offs because every real engineering decision has costs to weigh; failure-handling because everything fails at scale; communication because you must convince teammates and stakeholders; handling ambiguity because most of engineering is progressing under uncertainty. Recognizing this tells you the interview isn't testing whether you memorized how Twitter is built — it's testing whether you'd be effective and pleasant to work with on hard, open-ended problems. So the meta-strategy becomes: ask clarifying questions like you would about a real spec, estimate to inform decisions, propose an architecture and *weigh its trade-offs* out loud, proactively address how it fails, communicate your reasoning continuously, drive the conversation while remaining collaborative, and respond to feedback with engagement rather than defensiveness. This strategy naturally hits every high-weight dimension, because those dimensions exist precisely to detect this behaviour. It also relieves the pressure of finding the "right answer" — there isn't one, and the interviewer knows it; they're watching your *process*, and a good process (the behaviour of a strong engineer in a design review) is what you can reliably control and what actually determines the score. Instead of trying to impress with a clever design, you aim to demonstrate that you'd be excellent to have in the room — which is what the rubric is measuring.