After clarifying requirements, you now face a crucial decision: What will you actually design?

The prompt says "Design Uber." But Uber is a massive system: rider app, driver app, matching, routing, payments, surge pricing, safety, ratings, customer support, fleet management, and more. You have 40-50 minutes remaining. Attempting to design everything is a recipe for failure—you'll cover each feature superficially, demonstrating depth in none.

The art of scoping is knowing what to include, what to exclude, and how to communicate those boundaries clearly.

Scoping isn't about limiting your design—it's about focusing your expertise. The best candidates design a subset of the system with exceptional depth, rather than the whole system with embarrassing shallowness.

Scoping failures are among the most common reasons candidates underperform in system design interviews. The failure modes are distinct but equally damaging:

Failure Mode 1: Scope Too Broad

• Attempt to cover every feature
• Spend 2-3 minutes per component
• No depth anywhere—just a skeleton diagram
• Interviewer sees a candidate who can't prioritize

Failure Mode 2: Scope Too Narrow

• Focus on a trivial subset
• Finish design in 15 minutes
• Nothing substantial to evaluate
• Interviewer sees a candidate who underestimates complexity

Failure Mode 3: Scope Misaligned

• Deep dive into features the interviewer doesn't care about
• Miss the features they specifically wanted to see
• Interview feels like ships passing in the night
• Interviewer sees poor communication and judgment

Effective scoping follows a systematic process. Rather than arbitrarily choosing features, use a framework that ensures strategic, defensible decisions:

The MCDF Framework:

• Must-Haves: Core features without which the system doesn't function
• Critical Path: The primary user journey you'll design in detail
• Deferrals: Features explicitly out of scope (with justification)
• Future Considerations: Mentioned but not designed in depth

This framework creates transparent boundaries that interviewers can follow and engage with.

Must-have features are the minimum viable system—the features without which the system doesn't provide its core value. Identifying them requires asking: "What is the irreducible essence of this system?"

The Essence Test:

• Remove each feature mentally. Does the system still achieve its purpose?
• If removing a feature makes the system useless, it's a must-have
• If removing a feature makes the system less polished but still functional, it's not a must-have

Example: Twitter

Core essence: Users post short messages that others can read.

Must-haves:

• Post creation (tweets)
• User accounts/identity
• Feed/timeline viewing

Not must-haves (important but deferrable):

• Retweets (enhancement to sharing)
• Likes (engagement metric)
• Hashtags (discovery feature)
• Direct messages (secondary communication channel)
• Trending topics (discovery feature)

The critical path is the primary user journey through your system—the sequence of operations that represents the core value proposition. This is where you'll spend most of your design effort.

Why Critical Path Matters:

In a 45-minute interview, you can realistically design 3-5 components with depth. The critical path tells you which components. Everything on the critical path must be solid; things off the path can be sketched loosely.

Critical Path Identification Process:

1. Identify the primary user — Who is the main actor? (rider, buyer, viewer)
2. Identify their primary goal — What are they trying to accomplish?
3. Trace the steps — What sequence of actions achieves that goal?
4. Note the systems touched — Each step involves system components—these are your focus areas.

Secondary Paths:

Most systems have multiple user types with different journeys. For Uber, there's also the driver path:

• Go online → Receive ride request → Accept/decline → Navigate to pickup → Complete ride → Get paid

You likely won't fully design all paths. Choose the most interesting/complex one for depth, and briefly acknowledge others exist.

Communicating Your Choice:

"I'll focus on the rider's journey from requesting a ride through matching and completion. The driver experience mirrors many of these components. I'll note where they differ but won't design the driver onboarding flow in detail."

This shows awareness of the full system while justifying your focus.

Deferring features isn't admitting defeat—it's demonstrating prioritization. The key is how you defer. Poor deferrals seem like ignorance; strategic deferrals demonstrate judgment.

The Deferral Formula:

"I'm going to defer [feature] for now because [reason]. This would involve [brief technical insight], which I'm happy to discuss if we have time."

This formula:

1. States the deferral explicitly (no ambiguity)
2. Provides rationale (shows you thought about it)
3. Demonstrates you could design it (brief insight)
4. Keeps the door open (offers to return later)

Categories of Deferrals:

1. Orthogonal Systems — Systems that plug in but don't change core architecture

• Authentication/Authorization
• Monitoring/Logging
• Admin interfaces
• Analytics pipelines

Deferral rationale: "These are important but standardized. The interesting design is elsewhere."

2. Advanced Features — Extensions to core functionality

• Search and discovery
• Recommendation engines
• Notifications
• Internationalization

Deferral rationale: "These enhance but aren't essential. I'll note where they plug in."

3. Edge Cases — Rare scenarios requiring special handling

• Fraud detection
• Abuse prevention
• Disaster recovery
• Compliance features

Deferral rationale: "Critical for production but not necessary to demonstrate design skills."

One powerful scoping technique is phased design—presenting your solution as evolving through stages. This approach mirrors real-world system development and demonstrates maturity in how systems are actually built.

Why Phased Design Works:

1. Mirrors Reality — Production systems evolve through MVP → Scale → Optimization phases
2. Manages Complexity — You can defer advanced features to later phases naturally
3. Shows Vision — You demonstrate awareness of the full solution while focusing on what's achievable
4. Provides Flexibility — Interviewers can ask you to 'fast forward' to interesting phases

Transitioning Between Phases:

As you design, explicitly mention when you're addressing different phases:

"For the MVP, a single database with read replicas works fine. In Phase 2, we'd shard by user ID when we hit read scaling limits."

"I'm designing the chronological feed first. In Phase 3, we'd introduce a ranking service that sits between the timeline service and the client."

This gives interviewers clear hooks to dig deeper if they want, while keeping you focused on the MVP path.

How you communicate scope decisions matters as much as the decisions themselves. The goal is to make your reasoning transparent, invite collaboration, and ensure alignment with the interviewer's expectations.

The Scope Presentation:

After clarifying requirements and before detailed design, take 1-2 minutes to explicitly state your scope:

1. Summarize the system — What are we building?
2. State your focus — What will you design in depth?
3. Acknowledge breadth — What else exists in the full system?
4. Note deferrals — What are you explicitly leaving out?
5. Invite feedback — Does this align with expectations?

Not every interviewer will accept your proposed scope. Some will push back—either to test your flexibility or because they have specific areas they need to evaluate. Handling pushback gracefully is a skill.

Common Pushback Scenarios:

1. "Can you include [feature] in your design?"

• The interviewer wants to see something you deferred
• Response: Adjust scope to include it, potentially deferring something else
• "Absolutely—let me add that to the scope. I'll keep [other feature] lighter to focus there."

2. "I think [feature] is too complex for an interview."

• The interviewer thinks you've bitten off too much
• Response: Graciously reduce scope
• "Good point. Let me simplify—I'll focus on [subset] and treat [rest] as a later phase."

3. "Why did you exclude [feature]?"

• The interviewer is probing your reasoning
• Response: Defend your rationale clearly
• "I excluded it because it's orthogonal to the main distributed systems challenges. Happy to add it if you'd like to see how it integrates."

The Pivot Strategy:

If the interviewer significantly changes scope mid-design, pivot cleanly:

1. Acknowledge the change — "Good point—let's focus on that instead."
2. Update your scope documentation — Visibly adjust your IN SCOPE/DEFERRED lists
3. Identify what transfers — "The database design I have still works. I'll need to rethink the caching layer for this use case."
4. Don't panic — Pivots happen. The ability to adjust shows real-world readiness.

Interviewers sometimes pivot scope deliberately to see how you handle changing requirements. It's a signal of flexibility and adaptability—both valuable traits.

Different system types have different natural scopes. Understanding typical scope for common system design problems helps calibrate your expectations.

The complexity varies:

• Simple systems (URL shortener) might be scoped broadly in one session
• Complex systems (social network) require aggressive scoping to reach depth

Here's a calibration guide for common interview problems:

Reading the Room:

Interview level also affects scope expectations:

• Junior/Mid-Level: Interviewers expect narrower scope with solid fundamentals
• Senior: Interviewers expect broader awareness with depth in critical areas
• Staff+: Interviewers expect comprehensive system thinking with deep dives plus trade-off discussion

When in doubt, propose scope and ask if it matches what the interviewer wants to evaluate. They'll tell you.

Even candidates who understand scoping in theory make common mistakes in practice. Recognizing these pitfalls helps you avoid them:

Let's see complete scoping decisions for two common interview problems:

Strategic scoping separates candidates who finish confidently from those who scramble at the end. Let's consolidate the key insights:

What's Next:

With scope defined, you'll inevitably make assumptions about unstated details—user behavior, traffic patterns, technology choices. The next page covers Documenting Assumptions—how to make implicit assumptions explicit, communicate them clearly, and use them strategically throughout your design.