How the Interview Works
What happens in a 45 to 60 minute system design interview, what the interviewer scores, how to split the time, and what an interruption means.
On this page
A candidate hears "Design a photo-sharing app", says "OK", and starts drawing. Forty minutes later the whiteboard holds fourteen boxes, a queue, three caches and a sharded database. The feedback says "no hire": the candidate never asked how many users there were, could not say why the queue existed, and talked over two hints from the interviewer.
Nothing on that board was wrong. The candidate treated the interview as a drawing test. It is a design meeting with a colleague, scored on how you think out loud under time pressure.
The format
Most system design interviews last 45 or 60 minutes. A few minutes go to introductions and a few at the end to your questions, so a 45-minute slot gives you about 40 minutes of design. You get a short, vague prompt ("design a chat app") on purpose. You work on a whiteboard or a shared drawing tool, and the interviewer plays a teammate who knows the answers to your questions.
There is no single correct design. Two candidates can draw different systems and both pass. What the interviewer writes down is evidence about five things.
| What is scored | Strong signal | Weak signal |
|---|---|---|
| Problem exploration | Asks about features, scale and priorities, then states what is in and out of scope. | Starts drawing after the prompt, or asks twenty questions and never commits. |
| Design | A simple design that works end to end, where each box has a reason. | Popular components added by reflex, or a path that does not connect. |
| Trade-offs | Names at least two options, picks one, says what it costs and what would change the choice. | "We add a queue because it scales." No cost, no alternative. |
| Depth | Goes several levels down on the hard part: data layout, failure, the numbers. | Stays at box level everywhere, or goes deep on something easy. |
| Communication | Thinks out loud, checks in, takes hints and builds on them. | Long silences, or defends a choice after the interviewer has shown it breaks. |
Seniority changes how much depth and how much leading is expected, not the list itself. The lesson on what changes by level covers that.
How to spend the time
Time is the scarce resource. The usual failure is spending 20 minutes on requirements and estimates and never reaching the part where you show depth. Plan the hour before you walk in.
The middle blocks are the steps of a framework for any design, which gives minutes per step. In a 60-minute slot, keep the early steps about the same length and give most of the extra 15 minutes to deep dives and failure. That is where a longer interview is meant to dig.
When the interviewer interrupts
Interruptions are not a sign you are failing. The interviewer has a list of signals to collect in 40 minutes, and an interruption is usually them steering toward one. Work out which kind it is.
- A steer. "Let's assume the database handles it. How do clients get new messages?" You are spending time on something they already believe you can do. Let it go and follow.
- A probe. "What happens if this cache dies?" They are testing depth or failure thinking. Answer directly, with numbers if you have them, then return to where you were.
- A hint. "Is a database write on every click a problem?" There is a flaw. Do not defend it. Say what breaks, fix it, and build on their point.
- A curveball. "Now it has to work in three regions." A new requirement, to see if you adapt. Restate it, say which parts of your design change, and change only those.
- A time check. "We have ten minutes left." Pick the single most interesting remaining topic and go there.
| Option | Good at | Bad at | Pick it when |
|---|---|---|---|
| Defend your current plan | Keeps your structure intact. | Ignores the signal. If it was a hint, you just walked past the answer. | Only when they ask you to choose and you have a reason, stated with the cost. |
| Drop everything and follow | Responsive; the interviewer gets what they asked for. | You can lose the thread and leave the design half connected. | A clear steer away from something they consider done. |
| Answer, park, resume Usual default | Shows you heard them and that you still run the session. | Costs a few seconds of narration. | Probes and hints, which is most interruptions. |
"Park" means saying it out loud: "Good question, the cache failing means reads fall through to the database at 10 times the normal load, so I'd add replicas. Going back to the write path..." One sentence of answer, one of return.
In the interview
The first two minutes set the tone. Do not draw yet. Say what you are going to do, so the interviewer can follow and correct you early.
- Opening: "I'll start with a few questions on features and scale, do a quick estimate, then sketch the API and a high-level design, and leave time to go deep on the hardest part."
- Checking in: "Does this level of detail work, or should I go deeper on storage?"
- Committing: "I'll go with a relational database here because bookings need transactions. If writes grow 50 times, I'd revisit."
- Admitting a gap: "I haven't run that system in production, but here is how I'd reason about it."
Quick question before you go on. Your feed service calls the database on every request. Is that OK?
No. At 3,000 feed loads a second and about 10 reads each, that is 30,000 reads a second on one primary. I'd cache each user's feed for a minute and serve reads from replicas. The cost is that a new post can take up to a minute to appear, which I think is fine for a feed.
So back to the write path: when someone posts, ...
Quick question before you go on. Your feed service calls the database on every request. Is that OK?
Yes, it should be fine, databases are fast. We can always scale it later.
Follow-up questions you should expect near the end, with short answers:
- "What would you build first?" The smallest version that serves the main path: one region, one database, no sharding. Say what metric would make you add the next piece.
- "How would you know it is working?" Name two or three numbers you would watch (latency at the 99th percentile, error rate, queue depth) and an alert on each. See observability.
- "What would you change with more time?" Pick the weakest part of your own design and say how you would fix it. Interviewers like candidates who can see their own gaps.
Common mistakes
A 60-minute interview spends 5 minutes on introductions and 5 on your questions. You plan 10 minutes for clarifying and estimating, 6 for the API and data model, and 10 for the high-level design. How many minutes are left for deep dives and failures?
You are describing how users upload photos. The interviewer says: "Let's assume uploads work. How does someone see their friends' new photos?" What is happening?
Which answer shows the trade-off signal interviewers score?
What to practice next
Learn the steps that fill those 40 minutes in A Framework for Any Design, then see them in a full answer in Design a URL Shortener.