The System Design Interview: A Repeatable Framework
Most people who fail a system design interview don't fail because they don't know what a cache is. They fail because they ramble. With no structure, forty-five minutes disappears into one corner of the problem and the interviewer never sees breadth. This post gives you a framework you can run on almost any prompt, six questions that come up again and again, and the mistakes that quietly sink strong candidates.
Why structure beats knowledge
A senior interviewer is not grading whether your design is the right one — there isn't one. They're watching how you think: do you clarify before you build, do you reason about trade-offs, do you know where the bottlenecks are. A candidate who calmly walks a clear path through an average design usually outscores one who knows more but jumps around. Structure is the signal.
Published guidance points the same way. Meta says its design interview is 45 minutes and almost never involves coding; Amazon’s SDE II prep page says to expect at least one system-design question and to ask questions to complete and validate your design; and Google’s SRE workbook, describing how its engineers approach large designs, says sound reasoning and assumptions matter more than any final values.
A framework you can run every time
Spend your time roughly in this order. The percentages matter more than the exact minutes.
- Clarify requirements (~15%). Separate functional ("users can post and follow") from non-functional (scale, latency, consistency, availability). Ask for rough numbers: how many users, reads vs writes, payload sizes.
- Estimate the scale (~10%). Do back-of-the-envelope math: requests per second, storage per year, bandwidth. It sets the whole design — 100 RPS and 1M RPS are different problems.
- Define the API and data model (~15%). A handful of endpoints and the core entities. This anchors everything that follows.
- Draw the high-level design (~25%). Client, load balancer, service(s), database, cache, queue. Keep it simple first — you'll add depth where asked.
- Go deep where it matters (~25%). Pick the interesting bottleneck — the hot read path, the write fan-out, the storage choice — and drill in. This is where senior signal lives.
- Address bottlenecks and trade-offs (~10%). Single points of failure, hotspots, consistency vs availability. Name what you'd monitor.
The levers you'll reach for
Almost every design is assembled from the same handful of pieces. Know when each earns its place:
- Caching — cut read latency and DB load; think about invalidation and staleness.
- Load balancing — spread traffic; horizontal scale of stateless services.
- Replication — availability and read scaling; introduces consistency lag.
- Sharding / partitioning — scale writes and storage past one machine; watch for hot shards.
- Queues — decouple producers from consumers; smooth spikes; enable async work.
- CDN — push static and cacheable content near users.
The skill isn't listing these — it's justifying which ones the problem actually needs, and what each one costs.
Six questions that come up again and again
If you can confidently design these, you're ready for most variations:
- Design a URL shortener (key generation, redirect read path, analytics).
- Design a news feed (fan-out on write vs read, ranking, hot users).
- Design a chat / messaging system (delivery guarantees, presence, ordering).
- Design a rate limiter (token bucket, distributed counters).
- Design a file storage / sharing service (metadata vs blobs, dedup, consistency).
- Design a ride-hailing or nearby-search service (geospatial indexing, matching).
These recur because each one forces a distinct trade-off — write fan-out, geospatial indexing, delivery semantics. For a deeper walkthrough of how a live assistant structures answers to prompts like these, see our system design interview AI page.
Mistakes that quietly cost you
- Building before clarifying. Jumping to a database schema before you know the read/write ratio signals inexperience.
- Staying shallow everywhere. Touching ten components for thirty seconds each shows no depth. Go deep on one.
- Ignoring numbers. "It'll scale" means nothing without an estimate behind it.
- No trade-offs. Every choice has a cost. Saying "I'd use a cache, but it adds staleness we'd bound with a short TTL" is the whole game.
- Silence. The interviewer can only grade what you say out loud. Narrate your thinking.
How to practice
Pick one prompt from the list above and run the full framework end to end, out loud, in forty-five minutes — ideally whiteboard or a blank doc, no notes. Record yourself or grab a peer. Review where time actually went: most people discover they spent thirty minutes on the data model and never reached scaling. Do this five times across different problem types and the structure becomes muscle memory — which is exactly what frees you to think on the day.
Sources
- Meta Careers — Preparing for your software engineering interview at Meta — tech-screen format and timing, 45-minute design and behavioural interviews, “think out loud” (checked 14 Oct 2026)
- Amazon Jobs — SDE II interview prep — online assessment, four 55-minute interviews, at least one system-design question (checked 14 Oct 2026)
- Google SRE Workbook — Non-Abstract Large System Design — how Google SREs approach large designs; reasoning over final numbers (checked 14 Oct 2026)
FAQ
How should I structure a system design interview?
Run the same path every time: clarify requirements and scale, define the API, sketch the data model, draw the high-level components, then go deep where the interviewer pushes, and close with bottlenecks and trade-offs. Structure is what is graded — a familiar path stops you freezing on an unfamiliar domain.
How much detail is expected in a system design round?
Enough to justify each choice, not enough to design the whole thing. State the trade-off out loud — consistency versus availability, read path versus write path, cost versus latency — and go deeper only where you are asked.
What are the most common system design mistakes?
Starting to draw before asking about scale, listing technologies instead of reasoning about them, and ignoring failure modes. Naming a queue is not a design; saying what happens when it backs up is.
How do I practise system design?
Take one familiar product and design it out loud in forty minutes against the same framework, then repeat weekly with a different one. Practising the path matters more than memorising architectures.