How do you approach a system design interview question?
System designJunior
In shortClarify requirements and scope first, estimate the scale, sketch the API and data, draw a high-level design that handles the main flows, go deep on the hard parts, and finish with bottlenecks and trade-offs.
Model answer
I use the same six steps for any question, and say them out loud so the interviewer can follow:
- Requirements (about 5 minutes). Functional: the two or three main features. Non-functional: scale, latency, availability, how fresh data must be. I write them down and agree on what’s out of scope.
- Estimates (about 5 minutes). Requests per second (per day ÷ 100,000, times 2 to 5 for peak), storage per year, read/write ratio, and what the numbers mean: read-heavy, so cache; terabytes of files, so object storage.
- API and data model. The main endpoints and records.
- High-level design. Load balancer, stateless servers, cache, database, queues where work can be delayed. I trace each main use case through it.
- Deep dives. The one to three parts that are hard for this problem, explained as trade-offs: what I gain, what I give up, and why it fits the requirements.
- Wrap-up. Bottlenecks at 10× scale, failure cases, what I’d monitor.
If the interviewer steers me somewhere, I follow; they’re showing me what they want to evaluate.
What they're looking for
A clear, repeatable structure that starts with requirements, numbers that lead to decisions, and an understanding that trade-offs and communication are what's being evaluated.
Common mistakes
- Starting with technologies before any requirements.
- Estimating numbers and never using them.
- Spending the whole interview on boxes without any deep dive.
- Long silences instead of thinking aloud.