Pick one of fourteen canonical prompts (or randomise). Start the timer. Work through the seven phases the same way a real interview is structured. The reference solution from the playbook unlocks when the timer ends — don't open it before. This is the most useful single drill if you're prepping a single L5 / L6 round.
Like bit.ly. Take a long URL, return a short one. Clicks redirect. ~100M URLs created/day, ~1B clicks/day. 99.99% available. Sub-100ms p99 redirect.
Lock down the requirements that aren't in the prompt: read/write ratio, latency budget, geographic distribution, what "available" means, the consistency model the product needs, what counts as a hot key, the size of the largest object/row. 5–6 questions, not 20.
On a napkin: requests per second (peak, not average), bytes per request, storage in TB or PB, total bandwidth, cache size at hit ratio X. Numbers tell you whether you need one box or a thousand. If estimates don't shape the design that follows, redo them.
Sketch the public API (REST endpoints or RPC method signatures with the important fields). Sketch the data model (tables or KV-shapes). Don't worry about exact types; do worry about uniqueness, indexes, and what the hot read path will touch. This is the longest section you can skim through.
Boxes and arrows. Client → load balancer → app tier → caches → data store(s). Add any specialised systems (search index, queue, blob store). Each box gets a one-sentence justification. Aim for the simplest design that can plausibly meet the requirements; complexity is added in the next phase, not invented now.
Pick the load-bearing component (hot read path, write fanout, the queue at scale, the matching algorithm — whichever this design depends on) and go deep. Show how it scales, what fails first, what the recovery mode is. This is the section interviewers actually grade.
How do the numbers from "capacity math" change at 10× the load? What's the next bottleneck? What happens if a region goes down, a queue backs up, a hot key emerges, a deploy goes bad? You don't need to solve every failure mode — you need to know what they are and where you'd look.
Name two things you traded away and why: consistency vs latency, storage cost vs flexibility, complexity vs blast radius. Name two things you'd add with more time. Most interviewers leave 3–4 minutes for follow-up questions; use them to flag the seams in your design before they do.
Set up a quiet 50 minutes (45 for the round plus 5 to diff). Have a whiteboard, paper, or Excalidraw open. When the timer starts, work through the phases at the suggested pace — don't get stuck on phase 02 trying to do exact math; back-of-envelope is fine. When the timer ends, open the reference and look for the gaps. The first two or three rounds will feel slow; this is normal. Most candidates internalise the phase rhythm within a week of practice.
A common pattern is to do one round every other day for two weeks before a loop. That's seven rounds — enough to surface the recurring gaps, not so many that you burn out. Pair it with the distributed-systems flashcards on the off days.
The structure mirrors what experienced interviewers grade against. Phases 01 (clarify) and 02 (capacity math) demonstrate that you scope problems before solving them — candidates who skip phase 01 are the candidates who solve the wrong problem. Phase 03 (API + schema) shows you can move from requirements to interface. Phase 04 (high-level architecture) is where most candidates spend too much time — keep it boxes-and-arrows. Phase 05 (deep dive) is where you separate from other candidates; it's the part the interviewer remembers, and the largest minute allocation in the round reflects that. Phase 06 (scaling and failure modes) shows you can think one order of magnitude ahead. Phase 07 (trade-offs and follow-ups) shows self-awareness about your design's seams.
Some companies allocate 50 minutes or 60 minutes; the proportions stay similar. If your loop runs longer, give yourself another two minutes per phase from clarify through deep dive, and three to scaling. The minute counts here are the ones we have seen work best at the 45-minute Google / Meta / Amazon shape.
This is the phase candidates most often shortchange. Five minutes feels long when the clock is ticking, but a round that drifts into a 400 QPS write path when the real requirement was 4M QPS spent the whole hour solving the wrong problem. Ask five to six questions — not twenty. The six that matter most:
Senior candidates lose points here in two ways: by skipping the math entirely, or by spending eight minutes calculating to four significant figures. Aim for one order of magnitude. The three numbers you almost always need:
Memorise the powers of two and the seconds in a day. 2^10 ≈ 10^3, 2^20 ≈ 10^6, 2^30 ≈ 10^9, 2^40 ≈ 10^12. 86,400 seconds/day; ~30M seconds/year. The printable cheat sheets include a one-page version of these numbers.
Twelve minutes is the longest single section. The candidates who do well in this section nominate the deep dive — they point at the load-bearing component and say "the rest depends on this; let me go deep here". The candidates who do badly wait for the interviewer to ask. By then, the interviewer has lost some confidence.
How to pick: the load-bearing component is usually the hot read path (for read-heavy systems), the write fan-out (for systems with high write multiplication, like notifications or feed-on-write), the matching or ranking algorithm (for systems where the algorithm is the value), or the failure-recovery flow (for systems where availability is the headline requirement). One per round. Defend the pick: "of these four components, this one is where the design lives or dies because X."
Drawing client → load balancer → app → cache → database for the full round is the most common L4-grade answer at an L5 interview. The interviewer wants you to pick something in that diagram and go deep on it. If you don't nominate the deep dive, you have implicitly answered "everything is equally important" — which is never true.
"We use consistent hashing" is a statement. "We use consistent hashing because it bounds key movement to K/N keys when a node joins or leaves, at the cost of an extra hop on miss" is an owned trade-off. Senior rounds grade the second; the first reads as memorised. The same applies to CAP, idempotency, sagas, and CRDTs — each pattern is a knob; name what it costs.
Walking through three options without picking one is a senior anti-pattern. Pick, state the trade-off you accepted, defend it. The interviewer will push back, and you will refine — but the design has to start somewhere. Indecision under pressure is a leadership signal.
Senior rounds expect at least one substantive answer to "what fails first?". Hot keys, slow downstream services, region outages, queue backpressure, runaway clients — pick one and walk through symptom, detection, blast radius, recovery. If you've run anything in production, this is the phase where that shows.
A round that ends mid-phase-04 has effectively skipped phases 05–07 — the phases the interviewer cares most about. Pace yourself. The phase clock at the top of this simulator exists for that reason. If you're behind, cut detail from earlier phases; do not skip later ones.
Open the reference; spend five minutes diffing your work against it. If your high-level architecture was off, work through the playbook walkthrough. If you ran out of time before deep dive, the next round practise that specific transition. Track the recurring gaps over five to ten rounds — they're almost always the same two or three areas (write fan-out, hot-key handling, idempotency are the usual suspects).
Walk back to the system-design study path if a specific topic keeps tripping you up, and to the fourteen-entry playbook for the full reference solutions.
Five to ten timed rounds in the two weeks before the loop. Less than five and the pacing hasn't internalised. More than ten and you start memorising specific prompts rather than the general structure. Quality over quantity — diff each round against the reference, write down two gaps, fix them before the next round.
Practise on what your interviewer will use. Most virtual loops in 2025 use Excalidraw, Whimsical, or Miro; some still use a Google Doc with ASCII boxes. In-person loops are still mostly whiteboards. Pick your tool a week in advance and practise on it — fumbling the tool in the round costs minutes you can't get back.
Say so. "I don't know off the top of my head — here's how I'd think about it" is a strong senior answer. "Let me reason through it: if X then Y, so the answer is probably Z" demonstrates the same reasoning the interviewer wants. The worst answer is to bluff a confident wrong answer; the interviewer will dig and you will lose ground.
Draw the high-level architecture (phase 04) and the deep dive (phase 05). Everything else — clarify, capacity, API sketch, scaling, trade-offs — can be talked through, with key numbers written down. Drawing for the sake of drawing eats your minute budget.
Yes. The prompts are the same at L5, L6, and staff. The grading bar is different — at L6, expect to be pushed harder in phases 05 and 06 (deep dive and scaling), and to be asked to defend more controversial trade-offs in phase 07. The structure of the round, and the prompts, do not change.