The system design round is where senior engineering offers are made and lost. You walk into 45 to 60 minutes with a prompt like "design Twitter" or "design a ride-sharing dispatch system" and you have to architect a service end-to-end — out loud, with a whiteboard, while the interviewer probes every tradeoff. This guide covers the structure strong candidates follow, what interviewers actually score, and how to get enough reps under realistic conditions to stop freezing on ambiguity.
What a system design interview looks like
Most rounds share a common arc:
- Requirements and scoping (5–10 min). You clarify functional and non-functional requirements. Daily active users, read/write ratio, latency targets, consistency expectations, and what is explicitly out of scope.
- Capacity estimation (3–5 min). Back-of-envelope numbers — queries per second, storage per year, bandwidth at peak. You are not expected to be exact; you are expected to be within an order of magnitude and to show your math.
- High-level architecture (10–15 min). You sketch the major components — clients, load balancers, API gateway, services, data stores, caches, queues. You pick specific technologies only where it matters.
- Deep dive (15–25 min). The interviewer picks one or two components and asks you to go deeper. Database schema. Sharding strategy. Cache invalidation. Failure handling.
- Tradeoffs and followups (5–10 min). What breaks at 100x the scale? What would you do differently? How would you roll this out safely?
Senior candidates are expected to drive the structure. Junior candidates are often rescued when they stall. The level of the interview dictates how much the interviewer helps.
What interviewers actually score
The rubric lives in four to five dimensions, though the names vary by company:
- Requirements discipline. Did you establish clear functional and non-functional requirements before designing? Did you push back on vague prompts?
- Architecture quality. Does the design actually meet the requirements? Are the component responsibilities clean? Does data flow coherently?
- Tradeoff reasoning. When you chose a SQL database over NoSQL, did you explain why? When you picked eventual consistency, did you name what that costs?
- Depth under pressure. When the interviewer drills into your data model or your cache strategy, can you keep producing real answers?
- Communication. Is the whiteboard readable? Can the interviewer follow the data path through your diagram without you narrating?
At principal engineer level, operational concerns carry more weight — deploy strategy, observability, incident response, migration paths. New-grad interviews lean on the first three axes.
Common prompts
The canonical prompts cluster into a small number of patterns. Once you can handle one per cluster fluently, most questions fall into a familiar shape.
- Social feed systems. Design Twitter, design Instagram feed, design a newsfeed. Tests fanout on write vs. read, caching, ranking.
- Communication systems. Design WhatsApp, design Slack, design a chat app. Tests message ordering, delivery guarantees, presence.
- Marketplace and dispatch. Design Uber, design DoorDash, design Lyft. Tests geo-indexing, real-time matching, state machines.
- Streaming and video. Design YouTube, design Netflix, design Zoom. Tests CDN strategy, encoding pipelines, live vs. VOD.
- Storage and sharing. Design Dropbox, design Google Drive. Tests chunking, deduplication, sync protocols.
- Search and recommendation. Design Google autocomplete, design a top-K trending system. Tests indexing, approximate counting, ranking.
- Rate limiting and traffic. Design a rate limiter, design a URL shortener with analytics. Tests single-machine algorithms extended to distributed systems.
- Payment and financial. Design a payment processor, design an idempotent API. Tests consistency, exactly-once semantics, reconciliation.
Preparation roadmap
- Weeks 1–2: Building blocks. Load balancers, reverse proxies, SQL vs. NoSQL, caching layers, CDNs, queues, pub/sub. For each, you should be able to explain when it helps, when it hurts, and what it costs.
- Weeks 3–4: Canonical systems. Work through 10–15 canonical designs from a reliable source. Write the design out from memory afterwards. If you cannot, you do not actually understand it yet.
- Week 5: Deep dives. Pick one of your canonical systems per day and spend an hour going deep — write the schema, work out the sharding key, think about the failure modes. Depth is what separates senior candidates from mid-level ones.
- Week 6: Full mocks. Four to six full-length mock interviews with voice, with follow-ups, against a timer. Get comfortable being interrupted mid-sentence and pivoting.
Reading design books is necessary but not sufficient. The failure mode is passive absorption — you recognize the patterns when you read them but cannot produce them under time pressure in front of a skeptical interviewer.
How to practice with InterviewDen
The System Design track on InterviewDen runs a full design interview with a voice-driven AI interviewer that behaves like a senior engineer — it pushes back on vague answers, asks for capacity numbers, drills into your data model, and adds scale twists once you have something on the board. You get a shared whiteboard, a scratchpad for back-of-envelope math, and a live transcript.
The scored debrief breaks down requirements clarity, architectural soundness, tradeoff reasoning, depth, and communication, with specific moments in the transcript flagged — the interviewer quotes back exactly where you were vague, where you hand-waved, and where you were strong.
Start a mock from system design practice.
Common mistakes
- Designing before scoping. Jumping into boxes and arrows before agreeing on what the system does is the fastest way to end up redesigning halfway through.
- Naming technologies as answers. "I'll use Cassandra" is not a design decision until you have said what about your access pattern makes Cassandra the right choice over, say, DynamoDB or a sharded SQL database.
- Skipping capacity estimation. Interviewers use your numbers to grade the rest of your design. Without them, the deep dive is disconnected from reality.
- Refusing to pick. "It depends" is correct but incomplete. Strong candidates say what it depends on, then pick and defend a choice.
- Flat answers to depth questions. When the interviewer asks how your cache handles invalidation, "we'll use TTL" is not enough. Spell out the tradeoffs: stale reads vs. thundering herd vs. complexity.
- Ignoring failure. What happens when a region goes down? When the leader election flaps? Strong candidates raise failure cases unprompted.
FAQ
How much should I memorize vs. reason from first principles?
Memorize the building blocks — what a consistent hash is, how a Raft cluster elects a leader, why write-ahead logs exist. Reason about the architecture from those blocks. The prompts are too varied to memorize full designs.
What if I do not know a specific technology the interviewer mentions?
Say so, then ask for its semantics and reason from there. Senior candidates say "I have not used Pulsar, but if it has similar ordering guarantees to Kafka, I would..." and the interview proceeds normally.
How detailed should my capacity estimates be?
Order of magnitude. "About 10 billion messages per day" beats "10,231,450,322 messages per day" — the second number is fake precision and interviewers notice.
Can I use a tool like draw.io during a virtual interview?
Ask. Most interviewers are fine with a shared whiteboard tool, but some prefer you use theirs. Default to whatever they provide.
How is this different from a real system design at work?
It is the same skill with tighter time pressure and fewer data points. Real designs take weeks; interviews compress the decision loop to minutes. The quality of tradeoff reasoning should be identical.
Do I need to code in a system design interview?
Usually not. If the interviewer asks for pseudocode, keep it short. The round is about architecture and reasoning.
Is it worth specializing in one domain (e.g., payments, streaming)?
Only if the role explicitly targets it. For generalist interviews, breadth across six or seven patterns beats depth in one.