How to Run the First Five Minutes of a System Design Interview

Most system design interviews are decided in the first five minutes, and not because the candidate said something brilliant. They are decided because the candidate either turned a vague prompt into a specific problem with agreed boundaries, or did not, and spent the next forty minutes designing the wrong thing while the interviewer tried to steer.

Every design post on this blog opens with “clarify, then estimate, then find the hard part.” This is the post that says exactly how, minute by minute, with the questions to ask, the numbers to compute, and the sentence that ends the opening and starts the design.

The Question

There is no single question. The opening is the same regardless of the prompt:

• “Design a URL shortener.”
• “Design a ticket booking system.”
• “Design the backend for a food delivery app.”
• “We want to build an internal metrics platform. How would you approach it?”

Each of these is deliberately underspecified. The interviewer is not being lazy. The gap between the prompt and a buildable specification is the first thing they are measuring.

What They Are Really Checking

1. Can you turn ambiguity into a problem statement? In the job, nobody hands an architect a specification. They hand them a sentence from a product manager and a deadline.
2. Do you know which questions matter? Anyone can ask questions. The interviewer wants questions whose answers change the design.
3. Can you cut scope on purpose? Saying “I will leave refunds out unless you want them” is a skill. Trying to design everything is the opposite of a skill.
4. Can you find the hard part? Every system has one or two decisions that matter and a dozen that do not. Naming the hard part by minute four tells the interviewer you have built things.
5. Can you make a plan and get agreement? The candidate who says “here is the order I will go in, does that work for you” has just turned an examination into a working session.

A weak opening asks two ritual questions, gets “assume whatever you want,” and starts drawing boxes. A strong opening produces a written list of requirements, three numbers, one sentence naming the hard part, and an agreed plan, in about five minutes.

The Gotchas

Gotcha 1: Ritual questions. “How many users?” asked because the book said to, with no visible effect on what you do next. Every question should be followed, out loud, by what its answer changes. If you cannot say what a question changes, do not ask it.

Gotcha 2: Too many questions. Ten minutes of clarification is its own failure. Cap yourself at five or six questions and then state defaults for everything else.

Gotcha 3: Not cutting anything. “Users can browse, search, book, pay, refund, resell, review, and get recommendations.” You have forty minutes. Choose the core flow and say what you are deferring.

Gotcha 4: Never naming the hard part. The interviewer is waiting for the sentence “the hard part of this system is X.” Without it, the deep dive later has no target and you will spend it on whatever the interviewer happens to poke.

Gotcha 5: Estimating everything, or nothing. Three numbers: the write rate, the read rate, and the storage. Maybe a fourth if the system has a peak that dominates. Anything more is theater; anything less means you cannot justify the design. The numbers are in the back-of-envelope post.

Gotcha 6: No agreement on the plan. You start with the data model, the interviewer wanted the API, and at minute twenty they redirect you. Ten seconds of “here is my order, is that what you want” prevents it.

Gotcha 7: Dead air. Thirty seconds of silent thinking feels like five minutes to the interviewer. Narrate. “I am deciding whether the read path or the write path is the harder one here.”

Gotcha 8: Mishandling “assume whatever you want.” That is not permission to skip the step. It is an invitation to state your defaults and move on. “Then I will assume 10 million daily users and a 10 to 1 read-write ratio, and I will flag if a choice depends on that.”

Gotcha 9: Not writing it down. Requirements go top-left on the board and stay there. Every later decision points back to them. A candidate who has to re-ask the scale at minute twenty-five looks like they were not listening to themselves.

Gotcha 10: Treating the interviewer as an examiner. They are a colleague for forty-five minutes. Check in. “Does that match what you had in mind?” Interviewers grade collaboration, and most of them will help you if you let them.

How to Answer

The five minutes, minute by minute

Minute	What you do	What ends up on the board
0 to 1	Restate the problem in one sentence and name the shape of the system	The problem sentence
1 to 2	Scope the functional requirements: three to five core features in, the rest explicitly out	“In” and “Out” lists
2 to 3	Name the non-functional requirements that will drive the design: scale, latency, consistency, availability	Four or five short lines
3 to 4	Estimate three numbers and say what they imply	Write rate, read rate, storage, and a “so”
4 to 5	Find the hard part and propose the plan. Get agreement	“Hard part: X” and a numbered order

Now each minute in detail.

Minute 0 to 1: Restate and classify

Say the problem back in one sentence, including who the user is and what the core action is. Then name the shape of the system, because the shape determines where the difficulty lives:

Shape	Examples	Where the difficulty usually is
Read-heavy lookup	URL shortener, product catalog, profile service	Cache and read path; writes are trivial
Write-heavy ingest	Metrics, logging, clickstream	Ingest path, storage tiering, downsampling
Fan-out	News feed, notifications, chat	Delivery to many recipients; hot users
Contended writes	Ticketing, inventory, auctions	Consistency on a hot row; the peak moment
Coordination	Scheduler, workflow engine, locks	Leases, exactly-once claims, failure recovery
Real-time	Ride matching, live location, collaborative editing	Latency, ordering, stateful connections

“This is a contended-writes problem” is a more useful sentence than anything about load balancers.

Minute 1 to 2: Scope the features

List what is in and what is out, and say the word “out.” A pattern that works: “The core flow is A, B, C. I will leave D and E out unless you want them, and I will mention where they would attach.” Interviewers almost always accept the cut and sometimes add one thing back, which tells you what they care about.

Minute 2 to 3: Non-functional requirements

Ask, or state as defaults, only the ones that will change a decision:

Question	What its answer changes
How many users, and how many of the core action per user per day?	Everything downstream of the estimate
Is there a peak that dominates, or is load smooth?	Whether you design for average or for a spike
Where must reads be strongly consistent, and where is stale acceptable?	Cache strategy, replica reads, database choice
What latency does the core action need?	Whether a synchronous path is even possible
What must never be lost?	Durability, replication, and what goes through a queue
Single region or global?	The data layer, and whether cross-region calls are allowed on the hot path
Any existing constraints: cloud, team size, must-use systems?	Proportionality. A three-person team does not get a service mesh

Pick the three or four that matter for this system. Skip the rest.

Minute 3 to 4: Three numbers and a “so”

Write rate, read rate, storage. Say the assumptions, round hard, and finish with the conclusion. The whole thing is four lines:

Writes:   100M / month  ≈ 40/s, plan 400/s at peak
Reads:    10:1          ≈ 400/s, 4,000/s at peak
Storage:  500 B × 100M × 12 × 5 yr ≈ 3 TB
So:       one DB holds it; the design is the read path and the ID scheme

If the system has a peak that is the whole problem, add a fourth line for it. A ticketing system’s average is irrelevant; its on-sale minute is the design.

Minute 4 to 5: The hard part and the plan

Say the sentence: “The hard part of this system is X, and that is where I want to spend the deep dive.” Then propose the order:

1. API for the core flow, two or three endpoints
2. Data model, the main entities and the keys
3. High-level diagram, the boxes and the arrows
4. Deep dive on the hard part
5. Failure modes, bottlenecks, and what you would do with more time

Then ask: “Does that order work, or is there a part you want me to go deeper on?” Wait for the answer. That is the end of the opening.

The rest of the interview, for context

Segment	Time	Goal
Opening (this post)	5 min	Agreed problem, numbers, hard part, plan
API and data model	5 min	Concrete enough that the diagram has something to move
High-level design	10 min	Every box justified by a requirement on the board
Deep dive	15 to 20 min	The hard part, with trade-offs named and a recommendation
Wrap-up	5 min	Bottlenecks, failure modes, what you would cut or add

The opening is a tenth of the time and determines whether the other nine tenths are aimed at anything.

A worked example: “Design a ticket booking system”

Here is the opening as a script, with timestamps.

0:00. “So users browse live events and buy specific seats, and the core action is purchasing a seat for an event without it being sold twice. That makes this a contended-writes problem more than a scale problem. Does that match your framing?”

0:45. “For scope, I will take: browse events, view a seat map, hold a seat, pay, and confirm. I will leave out refunds, resale, recommendations, and venue management unless you want one of them. I will mention where refunds would attach when we get to the data model.”

1:45. “Non-functional: no double-selling, so seat state is strongly consistent. Browsing can be eventually consistent and heavily cached. Seat map under 200 milliseconds, purchase under two seconds. Purchases are never lost. And the load is not smooth: a major on-sale has a spike that is the whole design. Single region is fine to start. Is there a scale you have in mind, or should I assume?”

2:45. “Assuming 10,000 events a month and 100 million tickets a year, the average is about three purchases a second, which is nothing. The peak is the point: a popular on-sale might have 100,000 people hitting 50,000 seats in the first minute, so tens of thousands of requests a second against one event. Storage is trivial, tens of gigabytes a year. So: the design is about a thundering herd on a single hot event with seat-level contention, not about volume.”

3:45. “The hard part is the on-sale spike with strongly consistent seat holds. Everything else is standard.”

4:15. “I will do the API, then the seat data model with the hold mechanism, then a high-level diagram, and then deep dive on the spike: a waiting room, hold TTLs, and idempotent payment. Does that order work for you?”

Five minutes, and the interviewer now knows the candidate understands the problem, has cut it to something buildable, has numbers, has named the difficulty, and has a plan. Whatever happens next happens on purpose.

What the board looks like at minute five

DESIGN: Ticket booking. Contended writes on a hot event.

IN:  browse, seat map, hold, pay, confirm
OUT: refunds, resale, recs, venue mgmt (attach later)

NFR: no double-sell (strong on seat) | browse eventual, cached
     seat map <200ms | purchase <2s | purchases durable
     peak-driven: on-sale spike | single region

NUMBERS: avg ~3/s (irrelevant) | peak 10k-50k/s on ONE event
         storage ~tens of GB/yr (trivial)
SO: hot-event thundering herd + seat-level consistency

HARD PART: on-sale spike + consistent holds

PLAN: 1 API  2 data model + holds  3 diagram  4 deep dive spike  5 failures

Everything after this points back to that block.

Follow-Up Questions to Expect

• “Just start designing.” Some interviewers test whether you will skip the step under pressure. Compress it, do not skip it: “Thirty seconds of assumptions so the design has something to aim at,” then state defaults and go.
• “Assume Twitter scale.” Convert it to numbers immediately. “So hundreds of millions of daily users and a fan-out problem. Then the hard part changes to delivery, and I will re-plan around that.”
• “We do not care about the numbers.” They care whether you can derive them. Do the four lines in thirty seconds and move on. It costs nothing and it shows the habit.
• “What would you cut if you had half the time?” Name the thing furthest from the hard part. This is a proportionality test.
• “Which part would you build first?” The hard part, as a prototype, to retire the risk. Then the standard parts. Ties back to the decision-making lesson in the architecture-decision post.
• “Is that really the hard part?” Defend it or update it. Either is fine. Refusing to engage is not.

Key Takeaways

• The opening is five minutes and it aims the other forty.
• Restate the problem and name the system’s shape. The shape tells you where the difficulty lives.
• Cut scope out loud. Three to five features in, the rest explicitly deferred.
• Ask only questions whose answers change a decision, and say what they change.
• Three numbers and a “so.” Four if a peak dominates.
• Say “the hard part of this system is X” by minute four.
• Propose the order and get agreement. That sentence turns an exam into a working session.
• Write it all top-left and point back to it for the rest of the interview.

Further Reading

• Alex Xu, System Design Interview, chapter on the four-step framework
• Gergely Orosz, Preparing for the Systems Design and Coding Interview
• Jackson Gabbard, Intro to Architecture and Systems Design Interviews (the classic 2016 talk)
• Donne Martin, The System Design Primer: how to approach a question