The Delivery Framework

Here's a thing that almost nobody tells you about the system design interview: there is no clock on the wall. Not a real one, anyway. You're on a video call, you're drawing, you're talking, you're thinking hard — and time is passing at a rate you have completely lost track of.

Then the interviewer says "we've got about five minutes left," and your stomach drops, because you have a beautiful, meticulous, half-finished design and no way to land it.

That failure has nothing to do with what you know. You knew the material. You just spent it in the wrong places. So this lesson is about the one resource the interview is genuinely scarce in — and how to spend it deliberately.

Two things in that picture are worth noticing before we take them apart.

First, the widest block is the deep dive — not the diagram. Most people's instinct is the reverse, and we'll spend a whole section on why that instinct is expensive.

Second, the flags above the bar aren't durations, they're positions: where you should be at a few specific moments. That distinction turns out to be the difference between a budget you can actually use and one you'll abandon four minutes in.

If you go looking for a method, you'll drown in them. There's a four-step framework and a six-step framework and an eight-step one. There are acronyms — RESHADED, PEDALS. There are named methodologies from every major prep site, each presented as the structure.

This is genuinely confusing when you're preparing, because it looks like the experts disagree about something fundamental. They don't. Line them up and the disagreement turns out to be almost entirely about vocabulary and how finely you slice.

Strip the branding and every one of them is the same five moves in the same order:

1. Requirements — what you're building, committed.
2. Estimation — the numbers, but only where they change a decision.
3. High-level design — end-to-end, broad before deep.
4. Deep dive — open up where the risk actually lives.
5. Wrap-up — bottlenecks, trade-offs, what you'd do next.

One framework splits core entities and API contract into their own steps; another folds both into "sketch it." One says "evaluation," another says "wrap up." Nobody reverses the order. Nobody deep-dives before sketching.

What they do genuinely disagree about is the clock. The recommended minutes differ from source to source — and one well-regarded guide refuses to give timings at all, arguing that you'd end up practising clock-watching instead of designing. Hold onto that objection; it's a good one and we'll come back to it.

The order is invariant. The proportions are roughly invariant. The minutes are not.

So don't memorize an acronym. Learn the arc — and understand why it can't be reordered, which is the next thing.

The sequence isn't a convention people agreed on. It's forced, because each phase eats the output of the one before it.

You can't size a system you haven't scoped — how many what, exactly? You can't sketch sensibly without the targets, because the targets are what justify the components — the whole argument of Requirements & NFRs That Matter. You can't deep-dive before there's a design to dive into. And you can't meaningfully step back and name bottlenecks in something that isn't finished.

There's a name for the shape this produces: an upside-down pyramid. Start wide — the whole system, shallow, end to end. Then narrow — a couple of components, deep. The pyramid is upside down because most people's instinct is the opposite: start with the piece they find most interesting and build outward from it. That instinct produces an interview where minute thirty arrives and there's a gorgeous, fully-specified caching layer floating in space, connected to nothing.

Breadth first, then depth. Always. It's the single most protective habit in the whole method, because it means that at every moment after minute twenty, you have a complete answer — a rough one early, a sharp one later, but always complete. If the interview ended right now, you'd have delivered a system.

Now the numbers. Here's what the major published frameworks actually recommend for a forty-five minute round — and it's worth seeing them disagree, because that's informative in itself:

They don't match. But squint and the shape is remarkably stable, and that shape is what to internalize:

• ~15% Requirements — about 7 minutes
• ~10% Estimation — about 4 minutes
• ~30% High-level design — about 13 minutes
• ~35% Deep dive — about 16 minutes, the largest single block
• ~10% Wrap-up — about 5 minutes

Proportions travel; minutes don't. A sixty-minute interview isn't five extra phases, and a tighter problem doesn't get a shorter deep dive — the ratios hold and the absolute numbers stretch.

One note on the sizing phase, since Requirements & NFRs That Matter deliberately left it hanging: you are not obliged to do arithmetic. Do the math only where a number changes a decision — whether one instance suffices or you need to shard, whether the working set fits in memory. The failure to avoid is grinding through storage and bandwidth calculations and then concluding "okay, so it's a lot." That's four minutes for nothing. (The arithmetic itself lives in Back-of-the-Envelope: Estimate Like an Engineer.)

Now, the objection from earlier — the guide that refuses to give timings, on the grounds that clock-watching is the wrong skill to practise. They're right, and here's the resolution.

You cannot watch a clock while you are designing. Try it. You're mid-sentence explaining why the write path needs a queue, and the idea that you're also tracking a stopwatch is fantasy. Anyone who tells you to spend "twelve and a half minutes" on a phase has never tried to do it under pressure.

What you can do — what actually works — is know where you should be at a small number of moments. Not how long something takes. Where you are.

• ~minute 7 — requirements committed, scope agreed out loud.
• ~minute 12 — the one or two numbers that change the design, established.
• ⭐ ~minute 20 — an end-to-end design is on the board. This is the one that matters.
• ~minute 38 — deep dives done; start landing the plane.

That third one is load-bearing, and it's the most concretely actionable fact in this entire lesson. Interviewers generally want to see your high-level design within the first twenty minutes. If minute twenty arrives and there's no complete picture yet, you are already in trouble — not because you're slow, but because nothing that follows can happen. There's nothing to deepen. Nothing to stress-test. Nothing to defend.

And here's why checkpoints beat a budget: a checkpoint is recoverable. A blown budget is just a fact you discover too late. If you glance up, notice the design isn't up yet and you're past twenty, you know — immediately, without arithmetic — to stop polishing and go wide. One glance, one decision.

So much for how the budget should look. Here's how it usually looks — and it's the same distortion nearly every time.

Most candidates spend around sixty percent of the clock on the high-level diagram and then rush the part interviewers care about most. The budget doesn't just drift — it inverts.

It's worth being fair about why, because "just do it differently" is useless advice. Drawing boxes is the most comfortable phase of the interview. It feels productive: something visible appears on the screen with every stroke. It's the phase where you feel most in control, because you're not being challenged yet — you're presenting. And crucially, nothing in the moment signals waste. Adding one more component feels like progress right up until the interviewer says "five minutes left."

Meanwhile the deep dive — the uncomfortable phase, where you get pushed and might be wrong — is where the depth marks live, and depth is a big slice of the scorecard you met in Anatomy of the System Design Interview.

There's a sharper way to see it. The high-level sketch mostly demonstrates judgment — and if you scoped well, you already banked that. More boxes don't add more judgment; past a point they subtract, because every component is one more thing you owe a justification for. The deep dive is the only phase that can demonstrate depth, and an unfinished one demonstrates nothing at all.

Every extra minute in the sketch is borrowed from the only phase that can show depth.

You can't learn pacing by reading about pacing, in the same way you can't learn to parallel park from a diagram. So here's a live interview clock.

Forty-five minutes run in about a minute. Nothing advances on its own — leaving a phase is your call, every time, exactly as it is in the room. The interviewer will cut in unannounced, and each time you get a real decision: go deep on their question now, or answer in one line and park the rest. Both cost real minutes.

Watch two things. The minute-twenty line creeping toward your playhead — try to get an end-to-end design up before it passes. And at the end, your actual budget laid over the invariant proportions, so you can see the exact shape of your drift.

Run it twice. The second time, deliberately over-love the high-level phase — linger there, add another component, make it beautiful — and watch what it costs you at the far end. That's the lesson landing in the only way it really lands.

You will be behind at some point. Everyone is. What separates people is having a move prepared instead of quietly panicking.

The triage rule, and it is not close: a structured, complete overview beats an over-engineered design that never lands. If you have fifteen minutes and forty minutes of material, you cut depth, never completeness. Get the whole system standing, then deepen whatever time allows. An interview that ends with a finished simple design and one solid deep dive scores well. An interview that ends mid-sentence on a magnificent sharding scheme, with no working system around it, does not.

Say it out loud. This is the part people miss, and it's the difference between looking senior and looking lost:

"I've got about fifteen minutes left. Rather than cover everything shallowly, I'd like to go deep on the write path — that's where the risk is. Does that work for you?"

Naming the constraint and proposing the trade-off is the senior move. Silently running out of time is the junior one. Same clock, opposite signal — and you've just handed the interviewer a chance to redirect you to what they actually wanted.

Know the three time traps, because they're where the minutes actually vanish. The interviewer picks at one decision and you defend it for eight minutes. Back-of-the-envelope math nobody asked for. And the detail you can't let go of — the one where you almost have it. If you're stuck on something for more than a minute or two, name it and move on: "I'd want to look at the exact eviction policy, but let me come back — it isn't the risky part here."

Park it. The cheapest recovery tool there is. "Good question — let me note that and come back once the end-to-end is up." You've acknowledged them, you've shown you heard it, and you've protected the clock. Just actually come back.

Now the part almost nobody teaches, and the reason a framework can hurt you.

Interviewers know these frameworks. They've watched hundreds of candidates run them. And some of them deliberately probe to see whether you can leave the script — because following a recipe under easy conditions proves nothing about how you'd work with them on a Tuesday.

The failure looks like this. The interviewer asks something pointed about the write path, and the candidate says "I'll get there — I haven't done estimation yet" and carries on with their sequence. That is a flexibility failure, and it reads badly out of all proportion to how small it seems: it says you're executing a plan rather than having a conversation. A checklist mentality also produces the robotic version of the previous lesson — asking clarifying questions in a rehearsed order without actually listening to the answers.

The rule: the interviewer outranks the framework. Always. If they pull you somewhere, go. They're either steering you toward what they want to grade or handing you a hint. Both are good news.

What keeps that from becoming chaos is a single sentence when you surface: "Good — that's covered. Let me pick back up at the high level, since I want to make sure we have the end-to-end picture." You went where they wanted, and you found your way back out loud. That's not abandoning the structure; that's using it as a map rather than a script.

Which is the honest way to hold all of this: the framework is scaffolding, not a cage. When someone changes the scale assumption mid-flight, injects a failure, or asks for an alternative, the strong response treats it as an extension of the same problem rather than an interruption to your plan — and adapting calmly is one of the strongest signals you can give.

One calibration note, so you're not tuned to a fiction.

The length genuinely varies. Google typically runs a single round of roughly forty-five minutes; Meta and Amazon commonly run sixty. Some senior and infrastructure loops stretch to ninety. So "the 45-minute framework" is a useful default, not a universal.

Scaling it is simpler than it sounds: keep the proportions, and give almost all the extra time to deep dives. An extra fifteen minutes doesn't mean fifteen more minutes of scoping — your requirements don't get better after minute ten. It means one or two more components opened up properly. That's also why the deep-dive block grows with seniority: the more senior the role, the more the interview is about how deep you can go and how well you own the consequences.

House styles differ too, and they shift where the depth should land. Google will often ask you to build a component rather than name a managed service, so budget for explaining mechanism. Amazon leans on operational thinking and cost — tie decisions to customer impact and what it takes to run the thing. It's worth asking at the start: "How long do we have, and is there anything you'd particularly like me to spend the time on?" Two seconds, and you've just been told how to spend your budget.

It's easy to read all this as "follow these steps and you'll pass," and that's not the claim. Plenty of people run the framework perfectly and still don't get the offer, because the framework isn't what's being graded.

What it actually buys you is working memory. A system design interview asks you to hold an enormous amount in your head at once — the requirements, the components, the data flow, the failure modes, the thing the interviewer said four minutes ago that you promised to come back to. If you're also spending attention on "what should I do next?", you have less left for the actual thinking, and the thinking is the graded part.

The framework's job is to make what next free. It's a floor, not a ceiling: it stops you freezing, stops you skipping something structural, and guarantees you deliver a complete system. It doesn't make the design good. You make the design good — with the attention the structure just freed up.

So: five moves, in an order that can't be permuted. Proportions rather than minutes. Three or four checkpoints instead of a stopwatch. A triage rule for when you're behind, and permission — the obligation, really — to leave the script whenever the interviewer wants something else.

What you don't have yet is what actually goes on the board while all this is running: the reusable skeleton you can lay down at minute zero and fill in as you go. That's next, in The Design Template.