You have 45 minutes to design a complex distributed system. The instinct is to start drawing immediately — boxes, arrows, databases, load balancers. It feels productive. It looks busy. And it is almost certainly the reason you did not get the offer.
The engineers who consistently pass system design interviews at FAANG and MANGOS companies — Google, Meta, Anthropic, OpenAI — do something counterintuitive: they spend the first 10 minutes not designing at all. They ask questions.
This is not a formality. It is the foundation of the entire interview. Here is why, and exactly how to do it.
Why Clarifying Questions Matter More Than You Think
System design is fundamentally about making trade-offs given constraints. You cannot make the right trade-offs without knowing the constraints.
Consider the question: "Design a URL shortener."
- If the system handles 100 requests per day, a single server with a SQLite database is the right answer.
- If it handles 100 million requests per day with global users, you need distributed storage, CDN caching, and a globally replicated read path.
- If it handles 1 billion requests per day and needs 99.999% uptime, you need everything above plus a completely different approach to the write path.
These are not variations of the same design. They are fundamentally different systems. An interviewer who asks "design a URL shortener" is watching to see whether you recognise this.
Candidates who assume scale and start designing are gambling. Candidates who ask and confirm are engineering.
The Five Categories of Clarifying Questions
Strong candidates cover five dimensions before drawing a single component.
1. Scale and Traffic
- How many users does this system serve? Daily active users or monthly?
- What is the expected request rate? Requests per second, per minute?
- What is the read/write ratio? Is this a read-heavy or write-heavy system?
- Is the traffic uniform, or does it spike? (Flash sales, viral events, scheduled jobs)
- Are we designing for current scale or projected scale over the next 3-5 years?
Why this matters: Scale determines storage engine choice, replication strategy, caching requirements, and whether you need sharding. Everything flows from this.
2. Latency and Performance
- What are the latency requirements? Is there a P99 SLA?
- Is this user-facing (latency-sensitive) or batch processing (throughput-sensitive)?
- Are there different latency tiers for different users or operations?
- What is acceptable degradation under peak load — slower responses, or request rejection?
Why this matters: Optimising for P50 latency is a different problem from optimising for P99. The design choices (synchronous vs. asynchronous, caching strategy, database choice) differ completely.
3. Consistency and Availability
- What consistency guarantees are required? Can users see slightly stale data?
- What is the acceptable downtime? What is the SLA for availability?
- In a network partition, is it better for the system to return stale data (availability) or refuse to serve (consistency)?
- Are there specific operations that must be strongly consistent while others can be eventually consistent?
Why this matters: This is the CAP theorem in practice. Most systems make different consistency/availability trade-offs for different operations. Social media posts can be eventually consistent; financial transactions cannot.
4. Data and Storage
- What data does the system store, and roughly how large is it?
- Does data ever get deleted, or only added?
- Are there compliance or regulatory requirements (data residency, GDPR, retention policies)?
- Does the system need full-text search, geospatial queries, or time-series analysis?
- Is data access primarily by primary key (key-value), by range (B-tree), or by arbitrary query (relational)?
Why this matters: The answers determine whether you use a relational database, document store, wide-column store, or time-series database. Getting this wrong makes the entire architecture suspect.
5. Business and Feature Constraints
- Are there specific features the system must support that affect architecture? (Multi-tenancy, internationalisation, real-time vs. batch)
- Are there existing systems this must integrate with?
- What is the most important outcome to optimise for? (Cost, latency, correctness, developer experience)
- Are there features that are out of scope for this design?
Why this matters: "Design Instagram" means something completely different if you scope it to photo upload and feed, versus including Stories, Reels, DMs, and commerce. Setting explicit scope prevents you from designing forever.
How to Ask Clarifying Questions Professionally
There is a wrong way to ask clarifying questions: nervously firing a list of questions without writing anything down, or asking redundant questions that waste interview time.
The right approach:
Open with a framing statement. "Before I start designing, I want to spend a few minutes clarifying requirements so I can make the right trade-offs. Is that okay?" This signals intentionality and earns buy-in.
Group your questions. Ask about scale first, then latency, then consistency. Do not jump randomly between topics.
Write down the answers. This is visible evidence that you are using the information. It also gives you a reference during the design phase.
Confirm out loud. "So we are designing for approximately 10 million DAU, P99 latency under 100ms for reads, and we can tolerate eventual consistency for most operations but need strong consistency for writes — does that sound right?" This validates your understanding and gives the interviewer a chance to correct you.
Do not ask what you can calculate. "How much storage do we need?" is a question you should be able to answer yourself from the information you have gathered. Ask for inputs, not outputs.
The Clarifying Question Phase in Different Interview Formats
Not all companies run the clarifying phase the same way.
At Google (L5+): Interviewers often deliberately give sparse problem statements to see whether you probe. Do not expect them to volunteer information. You have to ask.
At Meta: The interviewer may give more initial context but still expects you to probe the unstated constraints. Scale numbers are often left for you to estimate.
At Anthropic: The clarifying phase is often extended and evaluated explicitly. Anthropic interviewers are interested in how you structure ambiguity — which questions you ask, in what order, and what you do with the answers. For AI-related systems, safety constraints are sometimes implied rather than stated — strong candidates ask about them anyway.
At Amazon: The clarifying phase connects directly to scope decisions, which Amazon evaluates through the lens of engineering ownership. Who owns the non-functional requirements? What happens when requirements conflict?
How to Practice This Skill
Here is the uncomfortable truth: you cannot build this skill by reading. You build it by practising in an interactive, conversation-style format.
Reading a system design solution tells you what the answer looks like. It does not train your instinct for which questions to ask, how to prioritise them, or how to pivot when the interviewer gives you unexpected constraints.
Effective practice looks like this:
- Start with a blank problem statement.
- Before reading any solution, write down your clarifying questions.
- Then compare your questions to what an experienced engineer would ask.
- Practice receiving answers and updating your design.
- Repeat with a partner who plays the interviewer, introducing constraints mid-design.
The goal is not to memorise a list of questions. It is to develop the habit of thinking in constraints before thinking in solutions.
A Quick Reference: The Clarifying Question Checklist
Before drawing your first box, confirm:
- Scale: DAU, QPS, read/write ratio
- Latency: P50/P99 targets, latency tier differences
- Consistency: What can be eventually consistent? What must be strongly consistent?
- Storage: Data volume, access patterns, query types
- Availability: SLA, failure mode preference (degrade vs. reject)
- Scope: What features are in and out of scope?
If you can answer all six categories before designing, you are more prepared than the majority of candidates.
Frequently Asked Questions
How long should the clarifying question phase take? Five to ten minutes for a 45-minute interview. If your questions run past ten minutes, you are asking too many or going too deep. Keep them scoped to information that materially changes your design.
What if the interviewer says "make reasonable assumptions"? Make them, but state them explicitly and write them down. "I will assume 10 million DAU with a 10:1 read/write ratio and P99 latency under 200ms. Let me know if you want me to adjust any of these." This is not the same as skipping the step — you are still establishing a basis for your design decisions.
Is there such a thing as asking too many clarifying questions? Yes. Asking detailed questions about topics that do not affect the architecture (e.g., "What font should the UI use?") wastes time and signals lack of focus. Good clarifying questions are ones where a different answer would change your design.
Does clarifying question skill matter more at senior levels? Yes, significantly. For L4 / E4 roles, interviewers expect good fundamentals. For L5+ / E5+ (senior, staff), the ability to structure ambiguous problems is an explicit competency. Skipping or rushing the clarifying phase is a much stronger negative signal at senior levels.