Guidance on using the first five minutes of system design interviews to ask clarifying, architecture-influencing questions and state assumptions with measurable constraints.
Early in the interview I introduced a six-step framework. The very first step is to clarify requirements with the interviewer — and the first five minutes matter. If you don’t ask the right clarifying questions up front, you risk designing the wrong system and derailing the conversation.
Begin by translating a vague prompt into a concrete target. For example, if asked to design a photo-sharing service, clarify which flavor of photo-sharing is intended. “Instagram” implies billions of small images and low-latency feeds; “Flickr” implies fewer users and large original uploads. These are fundamentally different architectures and trade-offs.
Interviewers often open with intentionally vague prompts to evaluate how you handle ambiguity. That does not mean you should rattle off a memorized checklist. Ask targeted questions that reveal constraints or create branching design choices rather than general ones that change nothing.
Filter every question with a simple rule: will the answer change my design? If the interviewer’s response leads to two distinct architectures (A vs B), the question is worth asking. If it won’t affect your decisions, prefer to assume and state that assumption clearly.
Ask only clarification questions that change your design choices. If you must assume something, state the assumption explicitly (for example: Assume 10M DAU, read-heavy traffic) and confirm it quickly with the interviewer.
Some high-level choices — like SQL versus NoSQL — depend on data model and access patterns. These are your decisions to justify, not something to hand back to the interviewer. Focus your clarifying questions on the specifics that determine those choices.
Instead of asking vague non-functional questions like “Do we need the system to be scalable?”, ask measurable, concrete questions that pin down requirements you can design to:
How many users do we expect (DAU/MAU)?
How quickly is the user base growing?
Is the workload read-heavy or write-heavy?
What data can we not afford to lose (durability constraints)?
What are target latencies for key user actions?
When pressed to pick numbers, choose defensible estimates and explain your reasoning. Example: “This looks like a consumer photo-sharing app; I will assume 10 million daily active users and a read-heavy pattern because people scroll far more than they post. Does that sound reasonable?” If the interviewer agrees, use those numbers for capacity planning and trade-offs.
Example walk-through: ticket booking (like Ticketmaster). Use a small set of incisive questions to reveal scope and the hardest engineering problems.Top early questions for a ticketing system:
Are we only responsible for customer-facing booking, or also for event organizers (create/manage events)? — defines scope.
What peak concurrency should we expect when tickets go on sale (e.g., thousands vs millions of concurrent requests)? — drives scale and traffic patterns.
When a user starts checkout, is the seat reserved for them? If so, how long? — determines locking, reservations, and timeout semantics.
Do users search within the app for events or arrive via direct deep links? — impacts search, routing, and UX priorities.
These four questions reveal scope, scale, consistency challenges, and the feature set to prioritize.
When to ask vs when to assume
When to ask
When to assume (but state it)
Answer creates two different architectures (e.g., read-heavy vs write-heavy)
Peripheral details that don’t affect your core design
Requirements that change scaling or consistency models
Small UI behavior or minor limits unless interviewer asks
Ambiguity around the hardest engineering constraint (e.g., seat reservations)
Reasonable defaults like session timeout values
Anything that defines scope (features, external integrations)
Implementation-level choices you can justify later
To summarize:
Use the first five minutes to clarify functional and non-functional requirements that affect design.
Only ask questions whose answers change your architecture; otherwise state assumptions and proceed.
When you pick numbers or constraints, provide a short rationale so the interviewer can challenge your trade-offs.
Following this approach keeps your design focused, defensible, and aligned with what the interviewer expects.
