The first few minutes of a system design interview are critical. How you gather requirements sets the tone for the entire interview and demonstrates your ability to think systematically about problems.
Why Requirements Matter
Many candidates rush to start drawing boxes and arrows immediately. This is a mistake. Without clear requirements, you might:
- Build the wrong system entirely
- Over-engineer or under-engineer your solution
- Miss critical constraints
- Waste valuable interview time
Spending 5-10 minutes on requirements is time well spent. It's easier to adjust your approach early than to redesign halfway through.
Functional Requirements
Functional requirements describe what the system should do. These define the core features.
Questions to Ask
- What are the main features we need to support?
- Who are the users of this system?
- What actions can users perform?
- What are the core use cases?
Example: Designing Twitter
- Can users post tweets?
- Can users follow other users?
- Can users see a timeline of tweets?
- Can users like and retweet?
- Do we need direct messaging?
- Do we need search?
Non-Functional Requirements
Non-functional requirements describe how the system should behave. These are equally important.
Scale
- How many users do we expect?
- How many requests per second?
- How much data do we need to store?
- What's the read-to-write ratio?
Performance
- What's the acceptable latency?
- How consistent does the data need to be?
- What's more important: availability or consistency?
Reliability
- What's the acceptable downtime?
- How do we handle failures?
- What's our disaster recovery plan?
The Requirements Framework
Use this framework to systematically gather requirements:
1. Users and Use Cases
"Let me start by understanding who uses this system.
Are we designing for end consumers, businesses, or both?"
2. Core Features
"What are the 2-3 most important features we need to support?
I want to make sure we focus on the right things."
3. Scale
"What scale are we designing for?
Millions of users? Billions of requests per day?"
4. Constraints
"Are there any specific constraints I should know about?
Latency requirements, consistency needs, regional requirements?"
Level-Based Expectations: Requirements
What interviewers expect varies by your target level:
| Requirements Gathering Expectations by Level | |
|---|---|
| Name | Description |
Mid-Level (L4) | Ask 3-5 clarifying questions covering users, core features, and basic scale. State assumptions clearly. Time: 3-5 minutes. |
Senior (L5) | Proactively scope the problem. Identify functional vs. non-functional requirements. Discuss trade-offs (consistency vs. availability). Time: 5-7 minutes. |
Staff+ (L6+) | Frame requirements in business context. Anticipate constraints interviewer hasn't mentioned. Propose phased approach (MVP vs. full system). Time: 5-10 minutes. |
Engineering Manager | Focus on stakeholder needs and success metrics. Consider team implications and delivery phases. Connect technical requirements to business outcomes. |
Common Mistakes
Asking Too Many Questions
Don't spend 20 minutes asking questions. Focus on the most impactful ones.
Not Prioritizing
You can't build everything. Always ask: "If we can only build one feature, which should it be?"
Ignoring Scale
Scale dramatically affects your design. A system for 100 users is very different from one for 100 million.
Making Assumptions
State your assumptions explicitly. "I'm assuming we need to support 1 billion users. Does that sound right?"
Putting It Together
Here's how a good requirements discussion might flow:
You: "Before I start designing, I'd like to understand the requirements better. First, who are the primary users of this system?"
Interviewer: "We're building this for consumers, so regular users who want to share short posts."
You: "Got it. For core features, I'm thinking: posting content, following users, and viewing a feed. Are there other must-haves, or should I focus on these?"
Interviewer: "Those are the main ones. Let's focus on those."
You: "Perfect. For scale, should I design for Twitter-scale, so hundreds of millions of users and billions of posts?"
Interviewer: "Yes, let's design for that scale."
You: "Last question: is the feed timeline more important to be real-time, or is a slight delay acceptable?"
Interviewer: "Slight delay is fine, maybe up to a few seconds."
You: "Great, let me summarize: We're building a social platform for consumers with posting, following, and feed features, at the scale of hundreds of millions of users, with near-real-time but not instant feed updates. I'll start with the high-level architecture."
Notice how this conversation is quick (under 3 minutes) but covers all the essentials. Practice this flow until it becomes natural.
Requirements Gathering Practice
You're asked to "Design a ride-sharing app like Uber." What questions would you ask to clarify requirements?
See suggested questions
User & Use Cases:
- Are we focusing on riders, drivers, or both?
- Is this for a specific region or global?
- Do we need to support ride scheduling in advance?
Core Features:
- What types of rides? (Standard, premium, shared?)
- Do we need real-time tracking?
- Is in-app payment required, or can we assume it exists?
Scale:
- How many concurrent rides at peak?
- How many drivers and riders total?
- What latency is acceptable for matching?
Constraints:
- How accurate does ETA need to be?
- What happens when no drivers are available?
- Any regulatory requirements (receipts, driver records)?
Good summary: "So we're building a ride-sharing platform for consumers in major US cities, focusing on the core flow: requesting a ride, matching with a driver, real-time tracking, and payment. We expect millions of users with hundreds of thousands of concurrent rides at peak, and matching should happen within seconds."
What's Next
Now that you know how to gather requirements, the next step is to identify your core entities and design the APIs that interact with them. This foundational work sets up everything that follows in your design.