Interview Playbook
Knowing the pieces is half the job. A repeatable structure shows seniority.
- 5/5/15/15/5 minthe five phases of a 45-minute round
- 2 deep diveson the riskiest areas, with failure modes
- 3, 7, 21 daysspaced repetition gaps for redoing questions
Show what to say
“I use the same structure every time: requirements with numbers, an estimate, the API and data model, a high-level design, two deep dives, then trade-offs and a summary, in about 45 minutes. I say every choice as X because Y at the cost of Z, and if I'm stuck I go back to requirements and numbers.”
Trade-offs
- Breadth vs depth: go broad until the design works end to end, then deep where risk is highest, at the cost of skipping other areas.
- Simple vs scalable: the simple option is enough at 4K QPS but scales less far; name the load at which you would switch.
- 302 vs 301: a 302 sends every click to your servers but keeps the click analytics you promised; a 301 is faster.
Bring it up before they ask
Ignoring failure is the common miss: every box can die and every network call can time out, so say what breaks and how you recover.
Use the same steps every time: requirements, numbers, API and data model, design, two deep dives, trade-offs, in about 45 minutes. Say every choice as "X because Y, at the cost of Z". When stuck, go back to requirements and numbers.
Why it matters
Knowing the pieces is half the job; the other half is showing them in order under a clock.
Read more · 189 words
Interviewers score scope, numbers, a working design, depth and trade-offs. Fixed steps cover every row even when you are nervous. A round is only 45 minutes: without a plan, the first 20 go to boxes and the deep dives never happen.
Every level gets the same question. The bar is what moves.
| Signal | Mid | Senior | Staff |
|---|---|---|---|
| Requirements | Asks some questions | Drives scope, adds numbers | Reframes the problem |
| Design | A working design | Clean data flow, scaling | Evolution path, operations |
| Deep dive | One area | Two areas, with failures | The riskiest area, quantified |
| Trade-offs | Names some | Justifies each | Cost and team impact |
The same sentence scores differently by how much it carries. Take "the database is the bottleneck".
| Level | What it sounds like |
|---|---|
| Mid | "I'd add a cache." |
| Senior | "Reads are 4,000 a second, so Redis with cache-aside. At 95% hits the database sees 200 reads a second." |
| Staff | "Same, but I'd watch the hit ratio and evictions, set an alert on both, and cost the Redis cluster against two read replicas before committing." |
Each step up adds a number, a failure or a cost, never a longer list of tools.
The 45-minute plan
Five phases: 5, 5, 15, 15 and 5 minutes.
Read more · 478 words
Press play to fill them in. Behind? Say so and move on: "I'll keep the data model brief so we have time for the deep dives."
Each step leaves something on the board for the next.
Requirements (minutes 0 to 5)
Ask, don't draw: four good questions turn an open prompt into a problem you can finish. Who uses it and how many, which 3 to 5 features, what targets matter (speed, uptime, consistency), and what is out of scope. Write the answers in a corner of the board. If the interviewer says "you decide", pick, say the assumption aloud, and move on.
Estimation (minutes 5 to 10)
Each number must end in a sentence that starts with "so": "read-heavy, so ." The chain is always the same: a volume per day or month, divided by about 100,000 seconds a day (86,400, rounded), gives writes per second; times the read ratio gives reads per second; times bytes per row gives storage. Round hard: 2 times off is fine; 100 times off changes the design.
API (still minutes 5 to 10)
Two minutes: the 3 to 5 endpoints that matter, with status codes.
Data model
The main entity with its key. Tables or keys, picked by how you read them.
High-level design (minutes 10 to 25)
Draw the simplest boxes that work, then walk one request through them with numbered steps. Do the write path and the read path separately; they usually look different. The numbers let the interviewer interrupt precisely ("go back to step 3") and prove the design works before you go deep. Still adding boxes at minute 25? You have no time for the part that scores most.
Deep dives (minutes 25 to 40)
Two areas, about eight minutes each. Ask: what breaks first here, and what does it cost to fix? For each: state the problem with a number, name two options, pick one and say why, then say what happens when it fails.
Trade-offs and wrap-up (minutes 40 to 45)
Leave a clear picture: two choices and their cost, the next bottleneck, then a summary. The summary is 30 seconds: "Reads dominate, so a cache in front of one Postgres. Codes come from ranges, not a global counter. The next bottleneck is write volume, and I would by code hash. I'd also add per-code metrics." Never trail off; end on your own sentence.
Estimation is four formulas, in back-of-envelope.js. Practise them aloud.
5 minutes of requirements, 5 of estimation and API, 15 of high-level design, 15 of deep dives (two areas), and 5 to wrap up with trade-offs. Each marker is a checkpoint: if you're behind, say so and move on.
Text description
- Requirements: Scope (0–5 min)
- Estimation + API: QPS, API (5–10 min)
- High-level design: Components + data flow (10–25 min)
- Deep dives: Deep dive 1 (25–33 min), Deep dive 2 (33–40 min)
- Wrap-up: Summary (40–45 min)
// The estimation step in four formulas. Round freely out loud: being 2× off is fine, 100× is not.
const SECONDS_PER_DAY = 86_400; // ≈ 100K, so 1M a day ≈ 12/s
export const perSecond = perDay => perDay / SECONDS_PER_DAY;
export function estimate({ writesPerDay, readsPerWrite = 0, bytesPerWrite = 0, years = 1, replicas = 1, peakFactor = 3 }) {
const writeQps = perSecond(writesPerDay);
const readQps = writeQps * readsPerWrite;
const storedBytes = writesPerDay * 365 * years * bytesPerWrite;
return {
writeQps,
readQps,
peakQps: (writeQps + readQps) * peakFactor, // traffic isn't flat: plan for 2–5× the average
storageTB: storedBytes / 1e12,
withReplicasTB: (storedBytes * replicas) / 1e12,
};
}
// URL shortener: estimate({ writesPerDay: 100e6 / 30, readsPerWrite: 100, bytesPerWrite: 500, years: 5, replicas: 3 })
// → ~39 writes/s, ~3,900 reads/s, ~12K/s at peak, ~3 TB (~9 TB with replicas)Frontend variant: RADIO
Frontend rounds use the same idea in five stages, Requirements, Architecture, Data model, Interface, Optimizations.
Read more · 130 words
Play Typeahead to see what you say at each one.
| Letter | Stage | What to cover |
|---|---|---|
| R | Requirements | Features, devices, offline, speed targets |
| A | Architecture | Component tree, where state lives |
| D | Data model | Client state shape, what is cached |
| I | Interface | Props, events, endpoints |
| O | Optimizations | Virtualisation, splitting, accessibility |
The order matters because optimizations only make sense once the data flow is clear. Naming before the component tree is the frontend version of naming before the requirements. Try it on the typeahead and infinite feed questions.
Tap any box to see what it is and what it talks to.
- DNS
- Service
- Database
- API gateway
- CDN
Text description
- Requirements: suggestions appear within 100 ms of a keystroke, work on mobile, and a keyboard user can pick one.
- Architecture: an input, a suggestion list and a hook that owns the query. Only the hook knows about the network.
- Data model: the query string, a list of results, a loading flag, and a cache keyed by the prefix.
- Interface: props for onSelect and fetcher, and GET /suggest with a prefix and a limit.
- Optimizations: debounce 150 ms, cancel stale requests, cache by prefix, and ARIA roles for the list.
Talking through trade-offs
Interviewers score reasoning, not a perfect answer. Use this shape:
Read more · 403 words
"I'll use X because Y. The cost is Z. If W changes, I'd switch to V."
For example: "I'll return a 302 because we promised click analytics. The cost: every click reaches our servers."
The numbers tell you when to stop adding machinery: 40 writes a second needs one Postgres, roughly 40,000 needs . Play the three scenarios in order.
At 40 writes a second say: "One Postgres is enough, so no ." At roughly 40,000: "Now I'd shard by a hash of the code." The skill is naming both the choice and the load that would change it. Stopping early is the signal that you read the numbers.
Two moments decide most rounds, so rehearse them.
- Pushback is a hint, not an attack. Digging in sounds defensive and giving in sounds like the first choice was a guess. Restate the concern ("you are pointing at write scale"), tie it to a number, and name the point where you would change your mind.
- "What breaks?" Answer in four parts: what breaks, the number that changes, what you do about it, and how you would know. "It should not go down" always loses points, because every box can die. A that absorbs 95% of 4,000 reads a second leaves 200; without it, the database sees 20 times more.
| Moment | Weak | Strong |
|---|---|---|
| A choice | "We use Kafka." | "Kafka, because we need replay. The cost is running it." |
| A number | "It's a lot of traffic." | "About 12K reads a second at peak." |
| A gap | "Um, I'm not sure." | "I don't know X in detail, but I'd reason like this." |
| Switch point | "This scales." | "Fine at 40 writes a second; at 40K I'd shard." |
| When | Say |
|---|---|
| The prompt is vague | "Who uses it, and how many?" |
| Your numbers come out small | "One database is enough. I'll skip sharding." |
| You are asked about failure | "If this box dies, X takes over, detected by Y." |
| You are behind | "I'll keep this brief so we reach the deep dives." |
Tap any box to see what it is and what it talks to.
- Client
- Service
- Cache
- Database
Text description
- 40 writes a second. One Postgres handles thousands of simple writes a second, so this is far below its limit.
- Say it: one database is enough. I will skip sharding and add it only if the numbers change.
Quick checkThe interviewer questions your database choice. Best first move?
Driving the conversation and getting unstuck
You hold the marker, so you set the agenda.
Read more · 156 words
A silent candidate hands control to the interviewer, who must then rescue the round. Three phrases cover most of it:
- Signpost: "Scope is agreed, next I'll size it."
- Check in: "Does this match what you had in mind?"
- Offer a menu: "I see two risks, the id generator and the read path. Which first?" The interviewer steers while you still choose the options.
Stuck is normal and visible; what scores is how you recover. Walk the tree from the top and stop at the first answer that fits. Never go quiet for more than about 10 seconds; think aloud ("I'm weighing two options").
Behind at minute 25? Say so and compress; do not speed up everything. Finish the design in three minutes, take one deep dive for ten, and name the second in one sentence ("I'd also look at code collisions, using a retry on conflict"). The interviewer still sees that you know it is there.
Can you restate what the requirements say about this part?
Quick checkYou are stuck mid-answer. What is the first step?
Raising the core topics on cue
The four topics every round touches are , queues, and consistency.
Read more · 414 words
Raise one too early and it sounds memorised; raise it on the trigger and it sounds earned.
| If you hear or compute | You raise | Your first sentence |
|---|---|---|
| Reads far above what the database serves | Caching | "The database is 20 times short, so I'd cache." |
| Work the user should not wait for | A queue | "I'd accept it, return 202, and process behind a queue." |
| Writes or data beyond one primary | Sharding | "One primary tops out, so I'd shard by user id." |
| A replica or cache read after a write | Consistency | "Which reads must be fresh, and which may lag?" |
- Caching: only after a number shows the database is short. Say the number, then the pattern ( with ), then what you leave uncached, then the risk. See Caching.
- Queues: when work is slow, bursty or flaky and the user does not need the result in the same request. The trigger phrase is "this can happen later": emails, thumbnails, . Follow with the cost: , so workers. See Async messaging.
- Sharding: last, and only when the numbers force it; the real decision is the key, not the word. Say the key and why it spreads load, then what you give up: cross-shard joins and easy . See sharding strategies.
- Consistency: ask which reads must be fresh; that question alone shows you see the trade-off. Money and ownership checks read the ; feeds and counters can lag. Say it per read, not for the whole system. See consistency and CAP.
Compare Good key and Bad key.
Tap any box to see what it is and what it talks to.
- Client
- Load balancer
- Database
Text description
- Trigger: 30,000 writes a second, and one primary tops out far below that. Say it, then ask about the key.
- Say: shard by a hash of user id. Users spread evenly, so each of 3 shards takes about 10,000 writes a second.
Quick checkWhen do you raise sharding?
Common mistakes
Most lost rounds come from a few habits, each fixable in advance.
Read more · 364 words
- Jumping to tools. Naming ", Cassandra" in minute 2 invites "why?", and you have no numbers to answer. Hold every tool name until a requirement or a number asks for it.
- Over-engineering. Multi-region for 40 writes a second is a missed read of your own numbers. Ask: did the estimate show one database cannot keep up? No: keep one database. Yes, mostly reads: add a (a 95% cuts reads twentyfold), then . Yes, writes or data size: by a key and name its cost.
- Ignoring failure. Every box can die and every call can time out, so walk the request path and kill each box in turn. For each say what takes over, how you detect it, and what the user sees. A timeout on every call is the cheapest answer, and the one most candidates forget.
- Going silent. Silence reads as stuck. Narrate: "I'm choosing between a counter and ranges." If you need real quiet, say so ("give me ten seconds") and keep it short. Prepare two lines: pushback ("Good point. If that matters, I'd change...") and a gap ("I don't know X in detail, but here is how I'd reason about it").
Play Happy path only, then Kill each box.
Drawing conventions. Your board is how the interviewer follows you.
- One shape each for services, data stores and queues.
- Label every arrow with what flows.
- Number the request flow, so you can say "step 4".
- Keep your assumptions in a corner box.
Tap any box to see what it is and what it talks to.
- Client
- Load balancer
- Service
- Database
Text description
- A request goes in.
- It reaches an app server.
- It reads the database and returns. The candidate stops here, and the interviewer asks what happens when something breaks.
Practice plan
Work in this order, aloud and on a timer: URL shortener, rate limiter, notification system, chat, news feed, then payments.
Read more · 258 words
Pick a question and run the clock; the timer shows what should be done by each minute.
- Redo each after 3, 7 and 21 days.
- Record yourself. Playback exposes silences and skipped numbers.
- Use the playground to get graded.
- Score every run 1 to 4 per row below.
| Dimension | 1: needs work | 4: strong |
|---|---|---|
| Requirements | Starts drawing at once | Scope and numbers agreed by minute 5 |
| Estimation | No numbers | QPS, storage, and what they imply |
| API and data model | Vague endpoints | Clear endpoints, keys, access patterns |
| High-level design | Boxes, no flow | A numbered flow, end to end |
| Deep dives | Stays on the surface | Two areas in depth |
| Failure modes | Not mentioned | What breaks, how it is detected and recovers |
| Trade-offs | Choices stated as facts | Each choice's cost, and when to switch |
| Communication | Draws in silence | Thinks aloud, manages the clock |
When you play a recording back, check three things first: the minute you finished the design (target 25), the count of numbers you said (target 10 or more), and the longest silence (target under 10 seconds).
Printable checklist (also on the cheatsheet):
- Requirements, with numbers and an out-of-scope list
- Average and peak , storage, read:write ratio
- Key endpoints with status codes
- Tables or keys, and the access pattern
- Diagram with a numbered request flow
- 2 deep dives
- Failure modes: what breaks, then what
- Trade-offs: the choice, its cost, when to switch
- 30-second summary
Interview questions
How do you handle an ambiguous problem?
Ask questions, state assumptions, and confirm before designing. They want to see you narrow scope.
The interviewer pushes back on your choice. What do you do?
Treat it as a hint: restate the concern, then defend with numbers or adapt.
How deep should you go?
Broad until the design works end to end; then deep where the risk is highest.
What if you get stuck?
Back to requirements and numbers, simplify, then scale step by step out loud.
You are at minute 25 and the design is not finished. What now?
Say so, finish it in about three minutes, take one deep dive, and name the second in a sentence.
Check yourself
Question 1 of 5Score 2 out of 3 or better to mark this page complete.