A system design interview is 45 minutes and it has a shape.
On this page
Spend the first 8 on requirements and numbers. Then 5 on the API and the data.
Spend 12 building one complete design, and 13 breaking it and fixing it.
The last 7 go on saying what you left out.
Senior candidates lose this round by starting at minute 3.
Candidates start designing before they know what they are designing.
You cannot memorise your way out of this. There are too many questions and the interviewer can go anywhere.
What works is a procedure you run every time, regardless of the question.
Here is the one I use. Both when I am asked, and when I am asking.
The shape of 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? |
If you are still on requirements at minute 20, you will not finish. If you are drawing boxes at minute 3, you are guessing.
Minutes 0 to 8: what numbers do you need?
Four of them, and you write them on the board.
Daily active users, and the read to write ratio.
What must never break, and what is out of scope. Then do the arithmetic out loud.
Ten million daily users at 20 requests each is 200 million a day.
Roughly 2,300 per second. Call it 7,000 at peak.
Ask questions until you have all 4. Do not skip this to look decisive. It reads as the opposite.
Who uses it and how many
Daily active users, not registered users.
Daily and registered users differ by an order of magnitude, and that changes everything downstream.
What is the read to write ratio
A system read 1,000 times per write is a different machine from a 1:1 one.
The read to write ratio decides most of your caching and replication story.
What must never break, and what may be stale
Ask the question plainly. “If this component goes down for 10 minutes, what does the user see?”
Some answers are “nothing”. Some are “we lose money”.
Design accordingly.
What is out of scope
Say it out loud and get agreement.
“I am not going to design authentication or the mobile client.” Now you have 45 minutes for 1 problem instead of 5.
Say the numbers when you have them. Every later decision refers back to them.
Minutes 8 to 13: the API and the data
Write 3 or 4 endpoints. Not a full spec, just enough to fix the contract.
Write the main entities and their fields next. Not a full schema, but enough that the storage discussion is about real data.
The entity list is where you decide relational or not. Say why in 1 sentence.
“These are mostly independent documents with no cross-entity transactions.”
“So a document store is fine.” That is a defensible sentence.
“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 satisfies the requirements.
Client, load balancer, service, database, and whatever the problem actually needs.
Finish it before you improve it.
A complete simple design beats half of a sophisticated one, every time.
The interviewer can see you can deliver a working system.
Walk 1 request through it out loud, end to end. “A user posts.
The request hits the load balancer and goes to the write service.
We validate, we write to the primary, we publish an event.”
Walking one request end to end finds your own gaps before the interviewer does.
Minutes 25 to 38: how do you break your own design?
You attack it in 4 places, in this order. Find the bottleneck at your peak number.
Kill every box in turn and say what the user sees. Find where the data gets hot, because uniform load is a fiction.
Say how stale your cached reads are, and who notices.
Failure and hot data is the part that separates levels, so slow down here.
Where is the bottleneck at your peak number?
Point at it. Usually it is the database, sometimes the fan-out.
What happens when that box dies?
Ask the question of every single box.
If the answer is “the site is down”, say so. Then fix the ones that matter.
Where does the data get hot?
One celebrity user, 1 popular item, 1 region. Interviewers know uniform load does not happen.
What is the consistency story?
If you added a cache or a replica, you introduced staleness. Say how stale, and say who notices.
Apply the fixes in the order that buys the most.
Caching the hot reads, then partitioning the write path.
Queueing the work that does not have to be synchronous comes third.
Adding machines comes last.
Each fix costs something. Say what. A cache costs staleness and a warm-up problem. Sharding costs cross-shard queries.
A queue costs ordering guarantees and a new failure mode when it backs up.
Minutes 38 to 45: what should you admit you did not do?
Volunteer the gaps out loud. Multi-region, abuse handling, the thing you would change if a requirement moved.
Volunteering the gaps is the strongest 5 minutes available, and most candidates spend it silent.
Saying which requirement your design hangs on is the best answer available in the round.
“I have not designed for multi-region. If we needed that, the write path is the hard part.
Right now there is a single primary.”
“I have not handled the abuse case. In production this needs rate limiting per account, not per IP.”
“If the read to write ratio turned out to be 1:1 rather than 1000:1.”
“I would drop the cache layer and spend that complexity on the write path.”
Naming what you would drop says something specific. My design is a function of the requirements.
What mistakes lose a system design interview?
Four of them, and I see all 4 most weeks. Designing the biggest possible version of a problem that has 10,000 users.
Naming products instead of properties. Going silent while drawing, so the interviewer has nothing to write.
Giving a design with no arithmetic in it is the third mistake. A picture is not an answer.
Designing the biggest possible version
People rehearse the 100-million-user answer and give it to a problem that has 10,000 users.
Designing for scale you do not have is a judgement failure. Judgement is what is being scored.
Naming products instead of properties
“I will use Kafka” says less than the property behind it.
“I need an ordered, replayable log that decouples producer from consumer.”
Say the property first, then name a thing that has it.
Silence while drawing
If you stop talking, the interviewer has nothing to write. Narrate.
No numbers
The arithmetic is what makes a drawing into an engineering answer.
How do you practise a system design interview alone?
Take 6 well-known systems. Run the full procedure on each, out loud, with a timer.
A URL shortener, a news feed, a chat system.
A rate limiter, a file store, a ride matcher.
Out loud is the part people skip and the part being tested. Record it and listen back to the first 8 minutes.
Your first spoken design will be much worse than your first written one. That gap is exactly what the interview measures.
When you listen back, ask whether a stranger would 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 procedure on any question and you will never be lost.
Even on a system you have never thought about.
You can have it scored rather than practised alone.
I run system design rounds at the bar used by Zalando and Shopify.
A mock interview is 60 minutes and 100 euro.
The written scorecard comes back within a day.