A system design interview is 45 minutes and it has a shape.
On this page
8 minutes on requirements and numbers, 5 on the API and data. 12 building one design, 13 breaking it, 7 on what you left out.
Senior candidates lose this round by drawing at minute 3. They design before they know what they are designing.
You cannot memorise your way out; the interviewer can go anywhere. What works is a procedure you run every time. Here is mine.
How to approach a system design interview
| Minutes | What you are doing | What the interviewer is scoring |
|---|---|---|
| 0-8 | Requirements and numbers | Do they design for the actual problem? |
| 8-13 | The API and the data | Do they know what they are storing? |
| 13-25 | The first design, end to end | Can they build a whole thing, not a piece? |
| 25-38 | Scale it, break it, fix it | Do they know why their design fails? |
| 38-45 | Tradeoffs and what is missing | Do they know what they did not do? |
Minutes 0 to 8: the 4 numbers
Write them on the board. Daily active users, not registered users; the two differ by an order of magnitude.
The read to write ratio. A system read 1,000 times per write is a different machine from a 1:1 one.
What must never break. Ask it plainly: “If this goes down for 10 minutes, what does the user see?”
What is out of scope. “I am not designing authentication or the mobile client.” Now it is 1 problem, not 5.
Then do the arithmetic out loud. 10 million users at 20 requests each is 200 million a day. That is 2,300 a second, 7,000 at peak.
Minutes 8 to 13: the API and the data
Write 3 or 4 endpoints and the main entities with their fields.
The entity list is where you decide relational or not. Say why in 1 sentence.
“Independent documents, no cross-entity transactions, so a document store is fine.” That is defensible.
“I will use NoSQL because it scales” gets written down as a red flag.
Minutes 13 to 25: build the whole thing once
Draw the simplest design that meets the requirements. Client, load balancer, service, database.
Finish it before you improve it. A complete simple design beats half of a sophisticated one.
Walk 1 request through it out loud. “A user posts. The load balancer sends it to the write service.”
“We validate, write to the primary, publish an event.” The walk finds your gaps first.
Minutes 25 to 38: break your own design
Attack it in 4 places, in this order.
Find the bottleneck at your peak number. Usually the database, sometimes the fan-out.
Kill every box in turn and say what the user sees. If the answer is “the site is down”, say so.
Find where the data gets hot: 1 celebrity user, 1 popular item, 1 region. Uniform load is a fiction.
Say how stale your cached reads are, and who notices. This part separates levels.
Apply the fixes in the order that buys the most. Cache the hot reads. Partition the write path.
Queue the work that does not have to be synchronous. Add machines last.
Each fix costs something, so say what. A cache costs staleness, sharding costs cross-shard queries, a queue costs ordering.
Minutes 38 to 45: what you did not do
Volunteer the gaps. Most candidates spend these 5 minutes silent.
“I have not designed for multi-region. The write path is the hard part; there is a single primary.”
Then name the requirement your design hangs on. “If the ratio were 1:1, I would drop the cache.”
That sentence says your design is a function of the requirements. It is the best answer in the round.
System design interview mistakes to avoid
I see all 4 most weeks.
Designing the 100-million-user version of a problem that has 10,000 users. Judgement is what is scored.
Naming products instead of properties. “I need an ordered, replayable log” says more than “I will use Kafka”.
Going silent while drawing. If you stop talking, the interviewer has nothing to write.
Giving a design with no arithmetic in it. A picture is not an answer.
How to practice a system design interview alone
Take 6 systems. A URL shortener, a news feed, a chat. A rate limiter, a file store, a ride matcher.
Run the procedure on each, out loud, with a timer. Out loud is the part people skip and the part being tested.
Record it and listen to the first 8 minutes. Would a stranger know what you were building?
Common questions
Do you need to know specific technologies for this round?
Not by name. You need the properties. An ordered replayable log, a key value store with predictable latency. A queue that survives a restart. Name a product after you have named the property. An interviewer who hears “I will use Kafka” writes down that you named a product.
What happens if you run out of time?
Say where you are and what is left. “I have the write path and the storage.” “I have not done the read path or failure handling.” An unfinished design you can account for scores far better. Better than a finished one you rushed and cannot defend.
Is this round different at staff level?
The question is often the same and the scoring is not. At staff the problem is left more ambiguous on purpose. Choosing what to build is part of the answer. You are also expected to name the organisational cost of a design. Not only the technical one.
How many system design questions are there really?
About 10 shapes, wearing different names. A feed, a chat, a shortener, a rate limiter, a file store. A matcher, a search index, a scheduler, a payment ledger, a notification fan-out. Run the procedure on all 10. A new question is then a variation rather than a surprise.
What is a system design interview?
A system design interview is a 45-minute round. You design a system from a one-line prompt. You ask for numbers, define an API, draw the system, then break it yourself. It scores judgement under ambiguity. It does not score how many technologies you can name.
The short version
8 minutes on requirements and numbers. Then the API and the data. Then 1 complete simple design.
Break it yourself and fix it in cost order. Then say what you left out and what would change your mind.
Run that on any question and you will never be lost.
To have it scored rather than practised alone, book a system design mock interview. The written scorecard comes back within a day.