The First 15 Minutes of a System Design Interview
System design interviews reward candidates who drive a conversation, not those who recite architectures. And most of the signal an interviewer collects happens in the opening — how you scope an ambiguous problem before you draw a single box. Here's a repeatable way to spend those first 15 minutes.
Minute 0–4: Clarify the problem
The prompt ("Design a URL shortener," "Design a news feed") is deliberately vague. Your first move is to make it concrete by asking:
- Who uses it and how many? Daily active users, requests per second, read vs. write ratio.
- What are the core features? Pick two or three; explicitly defer the rest.
- What matters most? Latency, consistency, availability, cost — you can't maximize all of them.
Write the answers down where the interviewer can see them. You're establishing scope you'll be held to, and you're showing that you don't build before you understand.
Minute 4–8: Estimate scale
Turn the numbers into back-of-the-envelope estimates: reads/writes per second, storage growth per year, bandwidth. You don't need precision — you need to show you can reason about whether a single database will hold up or whether you'll need sharding and a cache. Say your assumptions out loud so the interviewer can correct a wrong one early instead of at minute 40.
Minute 8–15: Sketch the high-level design
Now draw the boxes: clients, load balancer, application servers, data stores, caches, queues. Keep it high level — you'll go deep on one component later. As you draw, narrate the data flow for the primary use case end to end. A clear happy path buys you credibility to then discuss the hard parts: hot keys, consistency, failure modes.
Common opening mistakes
The two failure patterns are opposite. Some candidates jump straight to a database schema and lose the interviewer who wanted to see scoping. Others stay abstract too long, asking clarifying questions well past the point of usefulness. Calibrate: clarify enough to size the problem, then commit to a design you can defend.
Practice the muscle, not the answer
You can't memorize system design — there are too many variations — but you can rehearse the opening ritual until it's automatic. Our question bank includes technical and system design prompts organized by difficulty, and running a few in a full mock interview trains you to talk and diagram at the same time under real time pressure, which is the actual skill being tested.
Key takeaways
- Spend the first minutes clarifying users, features, and priorities — don't design yet.
- Do rough scale estimates out loud so wrong assumptions surface early.
- Sketch a high-level design and narrate the happy path before going deep.
- Avoid both extremes: premature schemas and endless clarifying questions.