Every problem statement is incomplete. Not because the author is careless, but because language inherently cannot capture all relevant detail. Between the words on the page lies a vast space of unspecified behavior, undefined edge cases, and unexpressed assumptions.

The difference between a junior and senior engineer isn't that seniors somehow receive clearer requirements. It's that seniors systematically identify what's unclear and proactively seek clarification before investing in solutions that might be wrong.

The high cost of unresolved ambiguity:

Imagine designing a parking lot system. The requirements state 'vehicles can park in spots.' Seems clear enough. But consider the ambiguities:

• Can any vehicle park in any spot? Or do sizes matter?
• What happens if a motorcycle takes a car spot?
• Can multiple motorcycles share one large spot?
• Are there reserved spots (handicapped, EV charging)?
• What does 'park' mean? Is it instant or does it involve a flow?

Each unresolved ambiguity is a design decision you're making implicitly. You might assume sizes matter when they don't, overcomplicating your design. Or assume they don't when they do, requiring a redesign.

Clarification is not weakness:

Inexperienced engineers sometimes fear that asking questions shows they 'don't get it.' The opposite is true. Asking incisive clarifying questions demonstrates:

• Thoroughness in problem analysis
• Experience with real-world complexity
• Communication skills essential for working with stakeholders
• Awareness that requirements are never complete

Ambiguities in requirements fall into recognizable categories. Understanding these categories helps you systematically scan for what might be unclear.

Category 1: Entity Ambiguity

What things exist in this system? Are there subtypes?

• 'Users can book rooms' — Is a User just one type, or are there Guests vs Admins?
• 'Vehicles park in spots' — What kinds of vehicles? Cars, motorcycles, trucks?
• 'Products are orderable' — Physical products? Digital? Subscriptions?

Category 2: Relationship Ambiguity

How do things relate to each other?

• 'A user can have orders' — How many? Is there a history or just active orders?
• 'Drivers accept rides' — One ride at a time? Multiple?
• 'Books are in branches' — Is a book catalog shared, or does each branch have its own?

Category 3: Behavior Ambiguity

What exactly happens during operations?

• 'User borrows a book' — What steps are involved? Immediate checkout or approval?
• 'System matches driver' — By what criteria? Nearest? Highest rated? Random?
• 'Order is shipped' — What state transitions occur? Who triggers this?

Category 4: Constraint Ambiguity

What are the limits, and when are they enforced?

• 'Users can borrow books' — Any limit? Per day? Per total?
• 'Spots are limited' — Limited per floor? Per type? Total?
• 'Fines apply' — When exactly? What thresholds?

Rather than hoping to notice ambiguities, use a systematic approach that guarantees coverage.

The 5W1H Framework:

For each major feature or capability, ask:

• WHO — Who performs this action? Who else is affected?
• WHAT — What exactly is being done? To what?
• WHEN — When does this happen? What triggers it? What sequence?
• WHERE — In what context/location/state? Where does data go?
• WHY — What's the purpose? (Helps clarify intent when implementation is ambiguous)
• HOW — What are the steps? What mechanisms are involved?

The Entity Deep-Dive:

For each entity, systematically probe:

1. Identity — What uniquely identifies this entity?
2. Variants — Are there subtypes with different attributes/behaviors?
3. Lifecycle — What states can it be in? How does it transition?
4. Relationships — What other entities does it connect to?
5. Behaviors — What can be done to/with/by this entity?
6. Constraints — What limits apply to this entity's data or behavior?

This structured probing catches ambiguities that casual reading misses.

Not all questions are equally valuable. Effective clarifying questions have specific characteristics that maximize information gain and demonstrate thoughtfulness.

Characteristics of Good Clarifying Questions:

The Question Layering Technique:

Good clarification often involves layered questions that drill down:

Layer 1: High-level clarification

'You mentioned reservations. When a book is reserved, what happens to the waiting member?'

Layer 2: Follow-up on the answer

'So they get notified. Is it first-come-first-served, or is there a priority system?'

Layer 3: Edge case exploration

'If the person doesn't pick up within 48 hours, does the reservation expire?'

Each layer drills deeper into behavior, revealing design requirements.

The 'Because' Connector:

Always explain why you're asking. This:

• Shows you're thinking ahead to design implications
• Helps the stakeholder understand what level of detail you need
• Opens dialogue about what matters

'Does the loan limit of 5 apply across branches? I'm asking because if it's per-branch, the Member entity needs to track loans per location, which changes the relationship structure.'

When you identify an ambiguity, you have several strategies for resolution:

Strategy 1: Direct Clarification

Ask directly. This is the gold standard when stakeholders (or interviewers) are available.

'The requirements mention fines for overdue books. How are fines calculated—flat rate or per-day? Is there a maximum cap?'

Strategy 2: Propose-and-Confirm

State your assumption and seek confirmation. This is efficient when you have a reasonable default.

'I'll assume fines are calculated at $0.50 per day with no cap. Please let me know if different.'

Strategy 3: Provide Options

Present alternatives and let the stakeholder choose. This works when you don't have a strong default.

'For matching drivers, I could design for: (A) nearest driver wins, (B) highest-rated driver wins, or (C) first to accept wins. Which approach should I take?'

Strategy 4: Document and Defer

Some ambiguities don't affect immediate design. Log them for later.

'The exact search algorithm is unclear, but I'll design a SearchService interface. The algorithm can be decided during implementation.'

The Assumption Register:

Whenever you resolve an ambiguity via assumption (Strategies 2, 4, 5), document it. This serves multiple purposes:

1. Transparency — Others know what you assumed
2. Traceability — If assumptions prove wrong, you know where to fix
3. Defense — If questioned, you can show you explicitly acknowledged the ambiguity

In an interview, verbalize your assumptions. In documentation, use an assumption register:

In interviews and meetings, you can't ask unlimited questions. You must prioritize and time your questions strategically.

Prioritization Framework:

Rank questions by design impact and risk:

Example Prioritization for Library System:

Timing Your Questions:

Early (During requirement reading): Ask P0 questions. Don't even start designing until these are resolved.

Before class design: Ask P1 questions. These affect your entity list and relationships.

During design: Ask P2 questions as they become relevant. 'I'm designing the Fine class. Is there a maximum cap?'

Defer/Assume: P3 questions can be stated as assumptions and moved on.

Edge cases are a special category of ambiguity. They're the unusual situations that problem statements rarely specify but designs must handle.

Why Edge Cases Matter in LLD:

Edge cases reveal:

• Missing state transitions
• Needed error handling
• Implicit business rules
• Concurrency challenges
• Data integrity requirements

Systematic Edge Case Discovery:

For each major flow, explore the boundaries:

Edge Case Analysis Example:

Sometimes you can't get clarification. The stakeholder doesn't know, the interviewer wants to see your judgment, or you're working from documentation with no one to ask.

Guidelines for Unilateral Assumption:

When you must decide alone, follow these principles:

1. Choose the simpler option unless there's a reason not to

'Are there multiple user types?' → Assume single type. Multi-type adds complexity that should be justified by explicit requirements.

2. Choose the more extensible option when in doubt

'Is pricing fixed or dynamic?' → Design with PricingStrategy interface. Even if currently fixed, the abstraction costs little and enables extension.

3. Follow industry/domain conventions

'How should loans be tracked?' → Libraries universally track per-copy, not per-book. Follow the domain pattern.

4. Choose the option with less risk

'Should fines cap at a maximum?' → Including a cap is safer (prevents extreme fines); can be set to infinity if uncapped.

Stating Unilateral Assumptions:

Whenever you make an assumption without clarification, explicitly state it:

'Without further specification, I'm assuming single-tier membership. If tiers are needed, I'd introduce a MemberType or use a strategy pattern for privileges.'

This shows:

• You recognized the ambiguity
• You made a reasoned choice
• You understand how to handle the alternative

All of these are senior-level signals.

The interview environment creates specific challenges for clarification. Master these patterns:

The Structured Clarification Flow:

Managing Question Quantity:

How many questions are too many? Guidelines:

• 3-5 initial questions are expected and valued
• 2-3 questions during design show active thinking
• >10 total questions may suggest over-dependence or analysis paralysis

Red flags to avoid:

• Asking so many questions that you run out of design time
• Asking low-priority questions while skipping high-priority ones
• Asking the same question multiple times (shows you're not listening)
• Never asking questions (shows you don't recognize ambiguity)

Interviewers value candidates who:

• Ask clarifying questions that reveal design implications
• Propose reasonable defaults while seeking confirmation
• Know when to stop asking and start designing
• Explicitly state assumptions when answers aren't available

Ambiguity is inherent in every problem statement. Your ability to identify and resolve it determines whether your design solves the right problem. Let's consolidate the key principles:

What's Next:

With ambiguities clarified, the final page in this module covers Implicit vs. Explicit Requirements—understanding the difference between what's directly stated versus what's understood but unwritten, and how to systematically account for both in your designs.