System design interviews scare people because they're open-ended. No single right answer — just a blank canvas and “design Twitter.” But that open-endedness is exactly why a repeatable process beats cramming architectures. The interviewer wants to see how you scope, structure, and trade off. They are not checking whether you've memorised how someone once built a URL shortener.
So stop collecting reference diagrams. Build a process you can run on any prompt, then practise running it out loud.
A framework that travels
- Clarify first. Design nothing yet. Nail scope, scale, and the one thing that must be great. Read-heavy or write-heavy? How many users? Five minutes here saves you from designing the wrong thing beautifully.
- Estimate roughly. Back-of-envelope numbers — requests per second, storage per year. They anchor every later decision and show you reason with quantities, not vibes.
- Sketch the high level. Client, API, services, data stores, the happy path. Simple before optimal.
- Go deep where it counts. Pick the interesting bottleneck — the feed, the counter, the storage — and design it properly.
- Address scale and failure. Caching, sharding, replication; what breaks at 10x; what happens when a component dies.
- Name the trade-offs. “I'd pick X over Y here because we care more about availability than strict consistency.” That sentence is what they're listening for.
Before I design, a few questions: - Who uses this and what's the core action? [read vs write] - Roughly how many users / requests per second? - What must be great — latency, consistency, or availability? - Any features I should treat as out of scope for now?
A worked prompt: design a URL shortener
Here's the process running end to end, narrated the way you'd actually say it. Notice it's mostly talking, not drawing.
“Let me scope it. Core actions: shorten a long URL, and redirect a short code to the original. I'll assume it's massively read-heavy — maybe 100 reads per write. Say 100M new links a month, so ~40 writes/sec average, and reads maybe 100x that. Redirects need to be fast — low latency matters more than perfect consistency. Custom aliases and analytics I'll treat as out of scope unless you want them.”
“Two endpoints: POST /urls takes a long URL, returns a short code; GET /{code} returns a 301/302 redirect. For the code I'll base62-encode a unique ID — 7 characters gives ~3.5 trillion combinations, plenty. Storage is a simple key-value mapping: code → long URL, plus created-at and owner. That's a natural fit for a key-value or wide-column store since I only ever look up by code.”
“Reads dominate, so I'd put a cache in front — most traffic hits a small set of popular links, so a cache with high hit-rate absorbs it. The mapping is immutable once created, which makes caching trivially safe. For the ID, a central counter is a bottleneck, so I'd use a range-allocation service or a distributed ID scheme so app servers mint IDs without coordinating on every request. Trade-off: I'm accepting eventual consistency on analytics counts to keep redirects fast — I'd rather serve a redirect instantly and tally the click asynchronously.”
That's the whole game: requirements to API to data to scale, narrating each choice and naming what you traded away. A narrated approach reads as senior even when the design is ordinary.
What changes by level
Do not pretend one bar fits everyone. The same prompt is graded differently depending on the role.
Junior
You're expected to produce a sensible high-level design and know the vocabulary — load balancer, cache, database, queue. It's fine to be led. Clarifying well and not freezing is most of the win. Depth on one component beats hand-waving across ten.
Intermediate
Now they want you to drive. Pick the bottleneck yourself, estimate without prompting, and justify each store and pattern. You should surface at least one real trade-off unprompted and handle “what happens at 10x?” without panic.
Senior or staff
The design is assumed; the interview is about judgment. Where's the blast radius? What's the migration path? What breaks first, how would you detect it, and what do you deliberately not build? You're expected to challenge the requirements themselves — “do we actually need strong consistency here, or is that going to cost us availability we care about more?” Reliability thinking bleeds in here; the overlap with SRE interviews is real.
Sounds junior
“I'd use a database to store the URLs and a server to redirect.”
Sounds senior
“It's read-heavy and the mapping is immutable, so I'd cache aggressively and pick a store I only ever query by key. The real risk is the ID generator becoming a coordination bottleneck — that's what I'd design carefully.”
Doing it remotely
Most of these are now remote, which changes the mechanics. You'll share a screen or a collaborative diagram tool. Two things trip people up: going silent while they draw, and letting the tool fight them.
- Narrate while you diagram. The interviewer is watching a cursor move in silence otherwise. Say what each box is as you place it.
- Keep the canvas legible. Boxes and arrows, labelled. A tidy diagram they can follow beats a beautiful one they can't.
- Restate before you move on. On a video call it's easy to talk past each other — “so we've got the write path sorted; shall I go deep on reads?” keeps you in sync.
Topics worth being fluent in
Load balancing, caching, SQL vs NoSQL trade-offs, sharding and replication, queues and async processing, consistency models, and rough estimation. You don't need encyclopedic depth — enough to reason out loud and defend a choice.
Jumping straight to the fancy part — “I'd use Kafka and a CDN” — before clarifying scope. It reads as pattern-matching, not thinking. Scope first, always. The buzzwords land far harder once they're attached to a requirement you established.
- Can you run the six-step framework on a cold prompt without notes?
- Can you do a back-of-envelope estimate out loud without freezing on the arithmetic?
- Have you practised on a shared diagram tool, narrating while you draw?
- For your target level, can you name trade-offs unprompted (mid) or challenge the requirements (senior)?
- Do you have two or three prompts you can design end to end in 40 minutes?
Take one prompt — “design a rate limiter” — set a 40-minute timer, and design it fully out loud as if someone's listening. Requirements, API, data, scale, trade-offs. Record yourself. Play it back and mark every point where you went silent for more than ten seconds. Those silences are what nerves will stretch to a minute on the day.
Practising system design in your head fails, because the entire exam is verbal. One spoken rep is worth ten silent ones. Build the plan around that — and if you want a full prep structure, the realistic technical prep plan shows how design fits alongside coding and behavioural rounds.
Practise a design prompt out loud
Run a realistic voice mock system-design interview, narrate your reasoning, and get a scored report with a model answer. Free to start — no credit card.
Start freeFrequently asked questions
How do I prepare for a system design interview?
Learn a repeatable process — clarify scope, estimate, sketch the high level, go deep on the bottleneck, handle scale and failure, and name trade-offs — then practise designing prompts out loud against a timer. Process beats memorising specific architectures.
What do system design interviewers look for?
Structured thinking, sensible trade-offs, and clear communication under ambiguity. Juniors are graded on a sound high-level design; seniors on judgment, blast radius, and challenging the requirements. How you reason out loud matters more than reproducing a textbook diagram.
How is a system design interview different by level?
Juniors produce a sensible design and know the vocabulary. Intermediates drive, estimate unprompted, and justify trade-offs. Seniors and staff are graded on judgment — failure modes, migration paths, and pushing back on the requirements themselves.