System design interview prep
A system design interview is a 45-minute conversation, not a diagramming exercise. The candidates who do well ask sharper clarifying questions, narrate trade-offs unprompted, and defend a choice under pressure — the same structure works whether the prompt is a URL shortener or a global news feed.
It is not the diagram
Most system design prep online is architecture diagrams: boxes for services, arrows for calls, a cache here, a queue there. That is the least useful thing to study, for a simple reason — interviewers do not have a reference diagram they are comparing yours against. Real systems at this scale have dozens of defensible architectures. What an interviewer is actually evaluating is the conversation that produces whichever diagram you land on: did you ask what actually matters before designing anything, did you state the trade-off behind each major decision without being asked, and can you defend a choice when the interviewer pushes on it.
That is why this section leads with structuring your answer before either problem walkthrough. The structure — clarify requirements, estimate scale, sketch a high-level design, go deep on one or two components, then discuss trade-offs and failure modes — is the actual transferable skill. A candidate who has internalized the structure can walk into an unfamiliar prompt (design a notification system, design a parking garage, design anything) and produce a coherent 40-minute answer. A candidate who has memorized one specific design falls apart the moment the interviewer changes a constraint.
Where to start
The 5-phase structure that keeps you from freezing at minute one, or rambling past minute thirty
Design a URL ShortenerThe canonical warm-up problem — small enough to finish, deep enough to probe trade-offs
Design a Rate LimiterA Senior/Staff favorite — correctness under concurrency and distributed state, not just a diagram
How much gets asked, by level
System design emphasis rises steadily up the ladder, roughly the inverse of DSA. An SDE 1 loop rarely includes it. By SDE 2 it is typically one stage, scoped narrowly (a single service, not a distributed system). By Senior it becomes a major stage with real depth expected — data model, scalability, and reliability trade-offs, not just a happy-path sketch. By Staff and Principal, system design stops being one stage among several and becomes close to the entire interview, extended past a single service into cross-team architecture, technical strategy, and the blast radius of a wrong call. The two problem walkthroughs in this section are calibrated to show that range — the same URL-shortener prompt looks very different answered at an SDE 2 bar versus a Staff bar, and the walkthroughs call that out explicitly rather than pretending one difficulty fits everyone.
Frequently asked questions
- Is system design interviewing about drawing a correct architecture?
- No. Two candidates can draw nearly identical boxes-and-arrows diagrams and score completely differently, because the interviewer is grading the reasoning that produced the diagram — what you asked before you started, which trade-offs you named out loud, and whether you can defend a choice under a "what if traffic grew 10x" follow-up. The diagram is evidence of the thinking, not the thing being scored.
- How much system design gets asked at each level?
- It scales up sharply as DSA scales down. SDE 1 loops rarely include it at all; by SDE 2 it is one stage; by Senior it is a major stage; by Staff and Principal it is effectively the interview, extended into technical strategy, cross-team trade-offs, and blast radius. See interview prep by level for the specifics.
- Should I memorize designs for common systems (URL shortener, rate limiter, news feed)?
- Memorizing one specific design is a trap — interviewers vary constraints specifically to see if you adapt or recite. What transfers across every prompt is the structure (clarify → estimate → high-level design → deep dive → trade-offs) and a working vocabulary of the primitives (load balancer, cache, queue, replication, sharding, consistency models). Learn the structure and the primitives; treat any specific "designs" as worked examples of applying both, not scripts.
Related
Practice the structure, not just the vocabulary
Free account. System-design depth and difficulty scale with your target level, from an SDE 2 introduction to a Staff-level strategy conversation.