🎚️ Level Calibration

Prerequisites: The Delivery Framework, Nonfunctional Requirements | You'll be able to: name the four competencies every rubric scores; predict how a mid, senior, and staff answer to the same question differ; self-diagnose your level and deliberately signal the next one.

🧨 The problem (why this exists)

Two candidates walk out of the same interview — "Design Dropbox" — having drawn almost the same boxes on the whiteboard. One gets a strong hire; the other gets a no-hire. They both produced a working design. So what separated them?

The uncomfortable truth is that there is no single passing bar in a system design interview. The question is a constant; the bar is a variable that slides with the level you're being interviewed for. A high-level design that earns a mid-level engineer a clear pass is a disappointment from a staff candidate. The interviewer isn't grading the whiteboard — they're grading it against an internal rubric calibrated to a specific level.

This trips people up in both directions. Junior candidates over-index on drawing more boxes, thinking breadth is the goal, and never go deep enough to signal senior. Experienced engineers under-prepare, assuming their years of experience will "show" — then spend forty minutes narrating a competent-but-generic design and get dinged for never going deep on anything. Both failed to calibrate: to understand what "good" looks like at the level they're targeting and to deliberately produce that signal.

This lesson makes the sliding bar explicit. Once you can see the rubric the interviewer is using, you can aim at it on purpose.

💡 Intuition first

Forget rubrics for a second. Imagine you're the interviewer, and your only job at the end is to write one sentence: "I would trust this person to own ____ on my team." Fill in the blank and you've basically found the level.

• For a mid-level hire, the blank is "a well-scoped feature, with guidance." You need confidence they can take a defined problem, build something that works, and reason competently when you point at a weak spot. You expect to lead them there. You are the senior engineer in the room and they are pairing with you.

• For a senior hire, the blank is "an entire component or service, independently." You need confidence they'll drive the design without you holding the pen, that they'll go genuinely deep in the areas that matter, and that they'll spot the non-functional concerns (scale, failure, consistency) before you have to ask. You're a peer looking over their shoulder, not a guide.

• For a staff hire, the blank is "an ambiguous, cross-cutting problem — and the people around it." You need confidence they'll walk into a vague prompt, find the genuinely hard part faster than you did, make a contentious call and defend it, and connect the design back to operational and organizational reality. You're a colleague being convinced, sometimes being taught something.

Notice what changed as the level rose: not whether they produced a working design — everyone must clear that — but how much they drove, how deep they went, and how much ambiguity they could absorb. That's the whole game. The rest of this lesson is just the precise vocabulary for those three shifts.

⚙️ How it works

Every company writes its own rubric, but they're strikingly similar — they specify the same underlying competencies with different words. Distilled, they come down to four dimensions every system design interview scores:

1. Problem Navigation. Can you take a big, ambiguous problem, break it into manageable pieces, prioritize the important ones, and move through them to a solution? This is often the single most important dimension and the one most candidates struggle with. The classic failure modes are: not exploring the problem enough to gather real requirements, burning time on trivial parts instead of the interesting ones, and getting stuck on a piece with no way forward.

2. High-Level Design. With the problem broken down, can you actually solve each piece and compose them into a coherent whole? This is where your grasp of core concepts shows. Failure modes: not knowing the concepts well enough to solve a piece, ignoring scaling and performance, and "spaghetti design" — a solution that technically works but nobody can follow.

3. Technical Excellence (sometimes "technical depth"). Do you know current technologies and how to apply them with well-recognized patterns? Failure modes: not knowing what's available, not knowing how to apply it to this problem, and not recognizing common patterns and best practices.

4. Communication and Collaboration. An interview is a proxy for what it's like to work with you. Can you explain complex ideas clearly, respond well to feedback, and collaborate to solve the problem? Failure modes: can't communicate complex concepts clearly, gets defensive or argumentative on feedback, gets lost in the weeds and can't work with the interviewer.

These four dimensions are constant across levels. What changes is the bar on each one — and above all, how the emphasis shifts between breadth (touching every part of the system) and depth (going to the bottom of the hard parts).

Here is the ladder. Each rung keeps everything below it and adds a new demand:

The single most important thing to read off this ladder: the floor never moves. Every level, from mid to staff, must deliver a working design that satisfies the requirements. The most common reason to fail a system design interview at any level is not delivering a working system — usually because of a lack of structure in the approach (which is exactly what the Delivery Framework exists to fix). Seniority is what you build on top of that floor, not a substitute for it. A dazzling deep dive into consensus that leaves the design incomplete is a no-hire at every level.

Let's put the per-dimension bars side by side. Read each column as "what a passing answer looks like at this level":

The rows on who drives and proactivity are the ones candidates most often misjudge. A senior candidate who waits to be asked "how would you scale the reads?" has already signaled mid-level, no matter how good the answer is once prompted. The timing of the insight — did you bring it up, or did the interviewer have to drag it out of you? — is itself the signal.

⚖️ Trade-offs

The central trade-off in a system design interview is breadth versus depth, and the right balance is set entirely by your target level. You have a fixed budget — roughly 45 minutes — and you spend it either touching more of the system (breadth) or going deeper into fewer parts (depth). You cannot maximize both.

The balance is best quantified with a memorable heuristic:

The trade-off cuts both ways, and both directions are real failure modes:

The art is sequencing: get to a complete, working high-level design first (protecting the floor), then deliberately spend your remaining budget on depth proportional to your level. The Delivery Framework is built around exactly this sequence — high-level design first, deep dives second.

Here's the breadth/depth split made visual — the same 45-minute budget, sliced three ways:

As you move up, the blue (breadth) block shrinks and the orange (depth) block grows — but neither ever disappears. Even a staff candidate needs enough breadth to produce a complete design; even a mid candidate needs some depth to prove the components aren't just names.

🔢 Numbers that matter

The figures below are rules of thumb from this book's leveling framework, not hard cutoffs — but they're the numbers that actually anchor how interviewers calibrate.

• The breadth/depth splits: 80/20 → 60/40 → 40/60. Mid, senior, staff. The most-cited numbers in the whole framework. Memorize them and use them to plan how you'll spend the clock.
• The interview clock: ~45 minutes of design. From the Delivery Framework: roughly Requirements ~5 min, Core Entities ~2 min, API ~5 min, High-Level Design ~10-15 min, Deep Dives ~10 min. Your level determines how you weight the last two phases — a staff candidate compresses the high-level design to buy more deep-dive time; a mid candidate does the reverse.
• Deep dives: 1-2 areas at senior, 3-4 at staff. A senior candidate is expected to go deep in the one or two areas where they have real hands-on experience. A staff candidate is expected to carry several such dives and to have chosen them deliberately.
• Where the interview happens by level: most entry-level roles have no system design interview at all; it appears at mid-level and becomes the norm at senior and above. If you're interviewing for senior, assume this round is decisive, not a formality.

A worked example of the split, using "Design Dropbox" (see Dropbox), with Meta's ladder notation [web: levels.fyi] used illustratively — exact ladders vary by company:

• Mid (E4): cleanly define the API and data model; land a high-level design that handles upload, download, and share. Not expected to know pre-signed URLs, direct-to-S3 transfer, or chunking up front — but expected to reason toward them when the interviewer asks "you're uploading the file twice, how do we avoid that?"
• Senior (E5): breeze the high-level design so there's time to go deep on uploading large files specifically — proactively weighing several options and arriving at a reasoned solution; many will name multipart upload and explain how it works.
• Staff+: deep-dive the complex scenarios, possibly steer the conversation toward a facet they find most interesting, and articulate the trade-offs between solutions fluently — treating the interviewer as a peer.

Same question. Three completely different uses of the same 45 minutes.

🏭 In production

Interview rubrics don't exist in a vacuum — they're proxies for what companies actually need at each level, and the calibration shifts across companies and interview loops in ways worth knowing.

Interview type changes the emphasis. A Product Design interview ("design the backend for Slack") leans on high-level design and problem navigation. An Infrastructure Design interview ("design a rate limiter" or "design a message broker") sits deeper in the stack and weights technical depth — consensus, durability, low-level mechanics — much more heavily, so the depth bar effectively rises for everyone. The same seniority label demands more depth in an infra loop than a product loop. Object-Oriented / Low-Level Design and Frontend Design interviews are different beasts again, scoring class structure or client architecture rather than distributed backends.

Leveling maps to internal ladders. The "E4 / E5" notation above is Meta's; Google has L3-L7, Amazon SDE I-III and Principal, and so on (illustrative; exact ladders vary by company and change over time). The mid/senior/staff buckets in this lesson are the portable abstraction over all of them. When a recruiter tells you the level you're being assessed for, translate it into "am I being graded on the 80/20, 60/40, or 40/60 bar?" — that's the calibration that matters, whatever the ladder calls it.

Down-leveling and up-leveling happen at the rubric. Many companies interview you at a target level but let a strong performance up-level you, or a weak one down-level you to an offer at the rung below. The four competencies are how that decision gets made: a candidate interviewing for staff who produces a clean, complete, senior-quality design but never finds the truly hard part or drives the ambiguity is a textbook down-level to senior — a hire, but not at the level they walked in for.

Some questions have a level ceiling. Not every question can be asked at every level. "Design a URL shortener" or "Design LeetCode" are on the easier side — a staff+ candidate is rarely asked them, because there isn't enough inherent hard part to fill a 60%-depth interview. Harder, more open prompts (a real-time system with contention, a globally-distributed store) are chosen precisely because they have room for staff-level depth. If you're handed an "easy" question at a senior+ loop, that's a signal to manufacture depth yourself — find the scaling wall, the consistency edge case, the failure mode — because the interviewer is waiting to see whether you can.

🪤 Pitfalls & interview traps

The traps here are mostly about miscalibration — aiming at the wrong bar, or violating the floor while chasing the ceiling.

Beyond the score-cappers, the level-specific traps:

• The over-broad senior. You produce a competent tour of the entire system and never go deep on anything. You've delivered a mid-level answer with senior years on your résumé — a down-level or a no-hire. Fix: pick your 1-2 deep dives deliberately and signal you're going there.
• The premature deep-diver. You find the interesting part in minute 8 and dive in before a working end-to-end design exists. You run out of clock, the design is incomplete, and you hit the number-one failure mode. Fix: protect the floor first — complete high-level design, then depth.
• The passive expert. You clearly know a lot, but you wait to be asked. Every insight the interviewer has to extract is proactivity you didn't demonstrate — and proactivity is precisely what separates senior from mid and staff from senior. Fix: narrate what you're about to check before they ask ("before I move on, let me stress-test the write path under a hot partition").
• The defensive candidate. You treat feedback as an attack and argue instead of incorporating. This tanks the Communication dimension outright and reads as "hard to work with" — a career-level red flag, not just a leveling one.
• Mistaking name-dropping for depth. Listing Kafka, Redis, Cassandra, and Flink is breadth, not depth. Depth is explaining why this one, how it behaves under load, and what breaks. Interviewers probe exactly here — see Traps & Follow-ups.

✅ Check yourself

🔬 PoC — Proof of concepts

Depth is calibrated by comparison — read enough real designs and the expected level for each seniority becomes concrete:

• awesome-system-design-resources — case studies at varying depth, useful for seeing what "goes one level deeper" actually looks like.
• awesome-scalability — real engineering write-ups; the senior-level detail (trade-offs, failure modes, numbers) that calibration rewards.
• System Design Primer — the breadth baseline every level is expected to cover before depth is judged.

📚 Sources

Original synthesis on interview delivery and calibration; this book's own framing.