The System Design Interview Approach
System design interviews are deliberately open-ended and can feel overwhelming without a repeatable structure, because there is no single correct answer and the interviewer is primarily evaluating process: how a candidate scopes an ambiguous problem, makes and justifies trade-offs, and communicates architecture clearly under time pressure. A proven approach breaks the typically 45-60 minute session into distinct phases — requirements clarification, capacity estimation, high-level design, deep dives, and identifying bottlenecks/trade-offs — allocating roughly proportional time to each so the conversation doesn't stall on premature detail or run out of time before covering the architecture end-to-end.
Cricket analogy: Like a T20 innings with no fixed script, a captain still splits 20 overs into powerplay, middle overs, and death overs rather than winging it ball by ball under pressure.
Phase 1: Clarify Requirements and Estimate Scale
Spend the first 5-10 minutes explicitly asking about functional scope (which features are in scope) and non-functional targets (expected daily active users, read/write ratio, latency expectations, consistency needs). Then perform back-of-envelope capacity estimation: convert user counts into requests per second, estimate storage growth per year, and estimate bandwidth — these numbers directly justify later choices, such as whether a single database can suffice or sharding is necessary from day one. Skipping this phase is the single most common reason candidates receive weak scores, because every subsequent design choice becomes unanchored guesswork.
Cricket analogy: Like a team checking the pitch report and asking whether it's a batting or bowling wicket before setting a target, clarifying scope up front (users, latency, consistency) anchors every later strategy call instead of guessing mid-innings.
Phase 2: High-Level Design, Then Deep Dive
Next, sketch a high-level architecture covering the major components (client, API layer, application services, cache, database, queue) and how a request flows through them end-to-end for the core use case, checking in with the interviewer before moving on. Only after the high-level shape is agreed upon should the candidate go deep on 1-2 components the interviewer signals interest in — this might mean designing the database schema and sharding key for a specific service, working through a rate limiter algorithm, or reasoning about cache invalidation for a specific read path. Trying to design every component to the same depth wastes time; the skill is prioritizing depth where it demonstrates the most engineering judgment.
Cricket analogy: Like a captain setting the field for a new batsman — slips, gully, mid-on — before deciding whether to bring in a short leg for a specific weakness, the high-level field comes first, then targeted adjustments follow.
Typical 45-min structure:
1. Requirements + scale estimation (~5-10 min)
2. High-level architecture (boxes/arrows) (~10-15 min)
3. Deep dive on 1-2 components (~15-20 min)
4. Bottlenecks, trade-offs, failure modes (~5-10 min)
5. Wrap-up / summary (~2-3 min)Strong candidates narrate their reasoning out loud continuously — 'I'm choosing a message queue here instead of a synchronous call because the write doesn't need to block on downstream processing, trading immediate consistency for higher write throughput.' Interviewers score the reasoning trail as much as the final diagram, since the diagram alone can't convey why choices were made.
A frequent failure mode is silently designing in your head and only presenting a finished diagram at the end. This gives the interviewer no opportunity to redirect a wrong assumption early, and a flawed early assumption (e.g., misjudging the read/write ratio) can invalidate 20 minutes of subsequent design work.
- A repeatable structure — requirements, estimation, high-level design, deep dive, trade-offs — prevents an open-ended interview from stalling or running out of time.
- Clarifying functional and non-functional requirements first anchors every later design decision.
- Back-of-envelope capacity estimation (RPS, storage growth, bandwidth) justifies specific architectural choices like sharding or caching.
- High-level design should be agreed upon with the interviewer before diving deep into any single component.
- Deep dives should focus on 1-2 components rather than spreading equal depth across everything.
- Narrating trade-off reasoning continuously is more valuable to the interviewer than a polished final diagram alone.
Practice what you learned
1. What are system design interviewers primarily evaluating?
2. Why is skipping the requirements-clarification phase considered the most common cause of a weak interview score?
3. What is the purpose of back-of-envelope capacity estimation in a system design interview?
4. After sketching a high-level design, what should a candidate typically do next?
5. Why do strong candidates narrate their reasoning continuously rather than presenting a finished diagram silently?
Was this page helpful?
You May Also Like
What Is System Design?
An introduction to the discipline of designing large-scale software systems, covering what system design means, why it matters, and how it differs from low-level coding.
Functional vs Non-Functional Requirements
How to distinguish what a system must do (functional requirements) from how well it must do it (non-functional requirements), and why both shape architecture.
System Design Interview Questions
A curated set of representative system design interview prompts across difficulty levels, with notes on what interviewers are actually evaluating for each.
Common System Design Mistakes
A catalog of recurring architectural and interview mistakes — over-engineering, ignoring tradeoffs, false precision, and skipping requirements gathering — with how to avoid each.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 40 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics