Topic 0.6
The 45-Minute Interview Framework
In one line
Interviewers grade the process as much as the design. A disciplined time budget keeps you from spending 30 minutes on requirements or reaching the deep dive with no time left.
Think of it like this
A cricket innings. You don't hit sixes from the first ball: you settle in (requirements), build a base (simple design), then accelerate (deep dives), and you keep an eye on the overs left (the clock).
Key ideas
- 01
0–5 min, requirements: confirm 3–5 core features, explicitly cut the rest, and pin the NFRs (scale, latency, consistency, availability).
- 02
5–10 min, estimation and API: size QPS, storage, and bandwidth, then write the 3–5 API signatures that define the contract.
- 03
10–15 min, data model: list the entities, the access patterns, and the store for each one, with a reason.
- 04
15–25 min, high-level design: draw the boxes and trace one write path and one read path end to end. Keep it simple and working before it gets clever.
- 05
25–40 min, deep dives: pick the 2–3 hardest parts (the fan-out, the hot key, the consistency boundary) and go deep. This is where seniority shows.
- 06
40–45 min, wrap-up: bottlenecks, failure modes, monitoring, and what you'd do with more time or at 10× scale.
- 07
Drive the conversation: narrate your reasoning, check in at each transition ('does this scope work for you?'), and follow the interviewer's hints rather than your script.
- 08
Levelling signals: mid-level engineers produce a working design; senior engineers identify the bottleneck unprompted and quantify trade-offs; staff engineers discuss evolution, operations, org and cost constraints.
- 09
Common failure modes: jumping to technology names ('use Kafka') before requirements, silent drawing, over-engineering for scale that wasn't asked for, and never stating what a choice costs.
Code & diagrams
Phrases that structure the conversation and signal seniority.
SCOPE "Let me confirm the core flows: A, B, C. I'll leave D and E
out of scope unless you'd like them. Sound good?"
NFR "I'll assume 100M DAU, read-heavy at ~100:1, p99 < 200ms for
reads, and eventual consistency is fine for the feed."
ESTIMATE "That's ~1k writes/s. One primary handles it, so sharding is
a later concern. Reads at 100k/s mean caching is mandatory."
DESIGN "Let me get a simple end-to-end design first, then find the
bottlenecks."
DEEP DIVE "The hardest part here is X. Two options: P and Q. P costs us
___ and Q costs us ___. Given our NFRs I'd pick P."
FAILURE "If this node dies, here is what the user sees and how we
recover..."
WRAP "At 10× scale the first thing to break is ___. I'd address it
by ___."Explain without notes
You're at minute 25 and haven't drawn a diagram yet. What do you say, and what do you cut?
What distinguishes a senior answer from a mid-level answer on the same 'design a URL shortener' prompt?
Practice
Run a timed mock: set a 45-minute timer and design a URL shortener, recording yourself. Check your time at each phase transition.
Write the 'deep dive' paragraph for three systems: Twitter (fan-out), Uber (geo-index), and a payment system (idempotency and ledgers).
Trade-offs
- ↔
Breadth vs depth: covering every box shallowly reads as junior, while going deep on one box too early leaves the design incomplete. Get to a working skeleton first, then go deep where the risk is.
Completion checklist
I can run a design interview end to end inside 45 minutes with a visible time budget.
I state at least one quantified trade-off and one failure mode for every deep dive.