Scoping and Requirements

TL;DR: "Design Uber" has hundreds of interpretations. Your job is to narrow it to a solvable core in 5 minutes. Ask questions across four themes: primary capabilities, rules, error handling, and scope boundaries. Write the requirements down visibly.

The #1 Missing Skill

Most candidates lose LLD interviews not because their code is bad, but because they designed the wrong thing. They hear "Design a Parking Lot" and immediately start coding a ParkingLot class — without asking whether it's a single-level lot or a multi-story garage, whether it has different spot sizes, or whether they need to handle fees at all.

Every LLD prompt is deliberately vague. This is not a flaw in the question. It's the test. The interviewer wants to see whether you can take an ambiguous problem and turn it into a concrete, buildable specification.

If you start designing before scoping, one of two things happens:

1. You build something too broad and run out of time before implementing anything meaningful.
2. You build something too narrow and the interviewer asks about a feature you didn't consider.

Both are avoidable with 5 minutes of targeted questions.

The 4 Question Themes

You don't need to memorize a checklist of 20 questions. Every scoping question falls into one of four themes:

1. Primary Capabilities

What are the core actions the system must support?

"What are the main operations a user can perform?"
"Is this a single-player or multiplayer system?"
"Do we need real-time updates or is polling acceptable?"
"Are there different user roles with different permissions?"

2. Rules and Completion

What defines success, failure, and completion?

"How does a game end? By win, draw, or forfeit?"
"What determines the price — flat rate, hourly, or tiered?"
"Can a user cancel mid-operation? What happens to the state?"
"Are there capacity limits? What happens when we hit them?"

3. Error Handling

What can go wrong, and how should the system respond?

"What if two users try to book the same seat simultaneously?"
"What if a payment fails after a reservation is confirmed?"
"Should we retry on failure or fail fast?"
"Do we need to support undo/rollback?"

4. Scope Boundaries

What should we explicitly NOT build?

"Should I worry about persistence/database, or in-memory is fine?"
"Do we need a UI, or just the backend classes?"
"Should I handle authentication and authorization?"
"Is multi-threading in scope?"

Interview tip: Scope boundary questions are the most valuable because they save the most time. "Should I handle concurrent access?" can be the difference between a 5-class solution and a 15-class solution. Ask early.

Worked Example: Tic Tac Toe

Here's what the scoping process looks like in practice.

Prompt: "Design a Tic Tac Toe game."

Your questions and the interviewer's answers:

You:  "Is this a 2-player game on the same machine, or networked?"
Them: "Same machine, 2 players."

You:  "Standard 3x3 board, or configurable size?"
Them: "Let's start with 3x3. Think about how you'd extend to NxN."

You:  "How does the game end — win, draw, or can a player resign?"
Them: "Win or draw. No resign."

You:  "Do we need to track player statistics or game history?"
Them: "No, just the current game."

You:  "Should I handle input validation — like a player trying 
       to place on an occupied cell?"
Them: "Yes, that's important."

You:  "Any UI, or just the game logic classes?"
Them: "Just the classes. No UI."

Requirements (write these visibly):

REQUIREMENTS:
1. 2-player game, same machine, players alternate turns
2. 3x3 board (discuss NxN extension at the end)
3. Players place marks (X/O) on empty cells
4. Game detects win (3 in a row/column/diagonal) or draw (board full)
5. Invalid moves (occupied cell, out of bounds) are rejected
6. No persistent state — single game session

OUT OF SCOPE:
- Networked multiplayer
- AI opponent
- Game history / statistics
- UI / rendering
- Undo move

This took about 3 minutes. Now you have a clear, bounded problem that you can design and implement in the remaining 35 minutes.

How to Say "Out of Scope" Without Losing Points

Putting something out of scope is not the same as saying "I don't know how to build it." Frame it as a deliberate decision:

Bad: "I'm not going to handle concurrency."

Good: "For this design, I'll assume single-threaded access. If we needed concurrent access, I'd add synchronization around the booking operations — I can discuss that at the end if you'd like."

The second version shows you know the concern exists, you've made a conscious choice, and you're willing to address it. The first version sounds like you're avoiding something hard.

Interview tip: When you put something out of scope, briefly mention how you'd approach it. This turns a potential negative ("they didn't handle X") into a positive ("they identified X and had a plan for it").

Write Requirements Visibly

Whether you're at a whiteboard, in a shared doc, or on a notepad, write your requirements down where the interviewer can see them. This serves three purposes:

1. Alignment. The interviewer can correct you immediately if you misunderstood something.
2. Reference. You can point back to specific requirements when making design decisions. "Requirement 4 says we need win detection, so the Game class needs a checkWin method."
3. Structure signal. It shows the interviewer you have a process. Most candidates skip this entirely.

Format them as a numbered list. Keep each requirement to one sentence. Separate the "in scope" list from the "out of scope" list.

Worked Example: Parking Lot

Prompt: "Design a Parking Lot system."

This prompt is deceptively simple. The design space is enormous. Here is how you narrow it.

Your questions and the interviewer's answers:

You:  "Single-level lot or multi-story garage?"
Them: "Single level is fine."

You:  "Do we have different spot sizes — compact, regular, large?"
Them: "Yes, three sizes. Vehicles should be assigned to matching spots."

You:  "Do we need to handle fees and payment?"
Them: "Yes, hourly rate. Keep the fee logic simple."

You:  "Multiple entry/exit gates, or just one?"
Them: "One entry, one exit."

You:  "Do I need to handle concurrent access — multiple cars entering simultaneously?"
Them: "No, assume single-threaded for now."

You:  "Should I handle reserved/handicapped spots?"
Them: "No, out of scope."

Requirements:

REQUIREMENTS:
1. Single-level lot with spots of three sizes: SMALL, MEDIUM, LARGE
2. Vehicles enter and receive a ticket with entry time and assigned spot
3. Vehicles assigned to the smallest spot that fits their type
4. On exit, fee calculated based on hourly rate x duration
5. System tracks available spots per size
6. Reject entry if no matching spot is available

OUT OF SCOPE:
- Multi-story / multiple lots
- Multiple gates / concurrent access
- Reserved / handicapped spots
- Payment processing (just calculate the fee)
- Persistence / database

Notice how the "multiple gates" question alone saved you from designing a dispatcher, a queue, and concurrency control. One question, 20 minutes saved.

Worked Example: Uber (Ride Sharing)

Prompt: "Design Uber."

This is the most common over-scoped prompt in LLD interviews. "Uber" has dozens of features: ride matching, surge pricing, payments, driver ratings, live tracking, ride history, support tickets, driver onboarding. You cannot design all of this in 45 minutes.

Your questions and the interviewer's answers:

You:  "Uber has many features. Should I focus on the ride matching 
       and trip lifecycle — request a ride, match a driver, complete 
       the trip?"
Them: "Yes, that's the core. Focus on that."

You:  "Single ride type (UberX) or multiple types (Pool, XL, Black)?"
Them: "Start with a single type. Think about how you'd extend."

You:  "Do I need to handle the matching algorithm — finding the 
       nearest driver — or can I assume a driver is provided?"
Them: "Model the matching. You don't need a real distance algorithm, 
       but show how you'd select a driver."

You:  "Do I need to handle payment and fare calculation?"
Them: "Calculate the fare, but don't build payment processing."

You:  "Is the rider/driver location updated in real-time, or is it 
       snapshot-based?"
Them: "Snapshot is fine for this design."

Requirements:

REQUIREMENTS:
1. Rider requests a trip with pickup and dropoff locations
2. System finds an available driver (nearest or first available)
3. Driver accepts/declines the trip
4. Trip progresses through states: REQUESTED → MATCHED → IN_PROGRESS → COMPLETED
5. Fare calculated on completion based on distance
6. Driver becomes available again after trip completion

OUT OF SCOPE:
- Multiple ride types (Pool, XL)
- Real-time GPS tracking
- Payment processing
- Surge pricing
- Driver ratings and history
- Ride cancellation mid-trip

Key insight: Your first question transformed "Design Uber" (impossible in 45 minutes) into "Design a trip matching system" (very doable). The interviewer was testing whether you could make this transformation.

Worked Example: Splitwise (Expense Sharing)

Prompt: "Design Splitwise."

Your questions and the interviewer's answers:

You:  "Should I focus on the core expense splitting and balance 
       tracking, or do you also want group management?"
Them: "Expense splitting and balance tracking. Groups are optional."

You:  "For splitting, do we need equal split only, or also 
       percentage and exact-amount splits?"
Them: "Equal split for now. Think about extensibility to other types."

You:  "Do we need to track individual transactions, or just the 
       net balance between users?"
Them: "Track both — individual expenses and net balances."

You:  "Should I handle settlement — marking debts as paid?"
Them: "Yes, that's important."

You:  "Do I need to simplify debts? For example, if A owes B $10 
       and B owes A $5, the net is A owes B $5?"
Them: "Yes, show net balances."

You:  "Multi-currency support?"
Them: "No, single currency."

Requirements:

REQUIREMENTS:
1. Users can add expenses with a payer and list of participants
2. Expenses are split equally among participants
3. System tracks who owes whom and how much (net balances)
4. Users can settle debts (full or partial payment)
5. System shows each user's total balance (net owed / net owing)

OUT OF SCOPE:
- Groups / group management
- Percentage or exact-amount splits
- Multi-currency
- Expense categories / tags
- Reminders / notifications
- Transaction history export

Worked Example: Movie Booking System

Prompt: "Design a Movie Ticket Booking System."

Your questions and the interviewer's answers:

You:  "Is this the booking flow — browsing movies, selecting a 
       showtime, choosing seats, and confirming — or the full 
       theater management system?"
Them: "Just the booking flow."

You:  "Can multiple users try to book the same seat at the same time?"
Them: "Good question. Yes, handle that case."

You:  "Do we need different seat types — regular, premium, VIP — 
       with different prices?"
Them: "No, all seats are the same price."

You:  "Can users cancel bookings?"
Them: "Yes, with a full refund."

You:  "Do I need to model multiple theaters / screens?"
Them: "Yes, a theater has multiple screens, each with its own layout."

You:  "How should I handle the seat layout? Fixed grid?"
Them: "Yes, rows and columns."

Requirements:

REQUIREMENTS:
1. Theater has multiple screens, each with a fixed seat layout (rows x columns)
2. Movies have showtimes assigned to specific screens
3. Users browse available showtimes for a movie
4. Users select and book available seats for a showtime
5. Concurrent booking for the same seat: first to confirm wins
6. Users can cancel bookings (seats become available again)

OUT OF SCOPE:
- Payment processing
- Seat types / pricing tiers
- User accounts / authentication
- Movie search / filtering
- Recurring showtimes

Notice how the concurrency question changed the design significantly. Without it, seat booking is trivial. With it, you need to think about atomicity -- how to prevent two users from booking the same seat. This is exactly the kind of question that earns you points.

Good vs Bad Scoping Conversations

BAD scoping -- too vague, no commitment:

You:  "So... what features should I build?"
Them: "It's up to you."
You:  "OK, I'll just start coding then."

This candidate didn't scope at all. They'll build either too much or too little.

BAD scoping -- asking about implementation, not requirements:

You:  "Should I use a HashMap or a List?"
You:  "Should I implement the Singleton pattern?"  
You:  "What data structure should the board be?"

These are implementation questions, not scoping questions. You're asking about how before knowing what.

BAD scoping -- over-scoping by accepting everything:

Them: "Design a Parking Lot."
You:  "OK, I'll handle multi-story, multiple gates, reserved spots, 
       EV charging stations, monthly passes, valet service, and 
       an admin dashboard."

This candidate will finish zero features in 45 minutes.

GOOD scoping -- targeted, value-driven:

You:  "What's the core flow I should focus on? Entry, parking, 
       and exit with fee calculation?"
Them: "Yes, exactly."
You:  "Single level or multi-story?"
Them: "Multi-story."
You:  "Multiple entry/exit gates with concurrent access?"
Them: "Let's keep it single-threaded."
You:  "Great. I'll handle multi-story spot assignment with fee 
       calculation. I'll put EV charging and reserved spots out of 
       scope, but I can discuss how to add them at the end."

This candidate narrowed the problem, made deliberate choices, and signaled where they'd extend. The interviewer now knows exactly what to expect.

How to Handle "Design Everything" Interviewers

Some interviewers resist scoping. They say things like:

• "Just build whatever you think is important"
• "I want to see everything"
• "Don't narrow it down, show me the full system"

This is a trap. If you try to design everything, you'll produce a shallow, incomplete mess. Here's how to handle it:

Strategy: Scope by volume, then expand.

"There's a lot to cover, so let me start with the core flow -- [the most interesting part]. I'll get a solid design for that first, and then we can layer on additional features. That way you'll see my full design process on at least one flow, rather than a shallow sketch of everything."

Most interviewers will agree. If they push back:

"I want to make sure I go deep enough for you to evaluate my design skills. If I spread across five features, each one will be superficial. Would you prefer depth on the core flow, or breadth across all features?"

This forces them to choose, and 90% of the time they'll choose depth. You've just scoped the problem without them realizing it.

The Exact Words to Use

Saying "out of scope" bluntly can sound dismissive. Here are phrases that work better:

Situation	What to Say
Excluding a feature	"I'll set [feature] aside for now, but if we have time I'd love to come back to it."
Feature you know how to build but choosing not to	"I know how I'd handle [feature] -- I'd use [brief approach]. But I want to go deep on the core flow first."
Feature the interviewer clearly cares about	"That's interesting and I see why it matters. Let me note it and come back to it after the core design is solid."
Feature you're unsure about	"I'd need to think more about [feature]. Let me start with what I'm confident about and we can discuss [feature] together."

The common thread: never say "I can't do that" or "I don't know how." Always frame it as a deliberate prioritization decision.

Common Scoping Mistakes

Mistake	Why It Hurts	Fix
No questions asked	You guess at requirements and build the wrong thing	Always ask at least 4-5 questions before designing
Too many questions	You spend 15 minutes scoping and run out of implementation time	Cap at 5 minutes. Ask the highest-value questions first.
Scope too broad	"I'll handle multiplayer, AI, undo, persistence..." and you finish nothing	Aggressively cut scope. A complete simple design beats an incomplete complex one.
Scope too narrow	You build a trivial system that doesn't demonstrate design skill	Include enough features to show class separation and extensibility
Not writing it down	You forget what you agreed on, or the interviewer thinks you're freestyling	Always write requirements visibly

Quick Recap

Concept	What it means	Why it matters
4 question themes	Capabilities, Rules, Errors, Scope boundaries	Covers all the dimensions of a problem in a structured way
Write requirements visibly	Numbered list of what's in scope and what's not	Creates alignment and a reference point for design decisions
Frame out-of-scope positively	Mention the concern and briefly note how you'd handle it	Shows awareness without wasting time
5-minute cap	Spend no more than 5 minutes on scoping	Enough to narrow the problem, not so much that you run out of design time