101
0/246
Loading content...
You've asked essential questions. You've scoped the problem. You've documented your assumptions. But before investing 30-40 minutes in detailed design, there's one final step that separates confident engineers from hopeful ones: confirming understanding.
This isn't merely asking 'Did I get it right?' It's a structured verification that ensures you and the interviewer share the same mental model of what you're about to build. Without this step, you might design brilliantly—for the wrong problem.
By the end of this page, you will know how to synthesize gathered requirements into a confirmation statement, present it effectively, handle corrections gracefully, and create shared understanding that provides a stable foundation for design. This skill prevents the devastating 'that's not what I meant' moment deep into an interview.
Consider this scenario:
After 5 minutes of clarifying questions, you begin designing a parking lot system. Thirty minutes later, you've created an elegant multi-level structure with vehicle tracking, payment processing, and real-time availability. You're proud of your work.
The interviewer asks: 'This is nice, but I was hoping to see how you'd handle the valet parking aspect.'
You never asked about valet parking. They never mentioned it. But it was what they really wanted to evaluate.
Confirmation prevents this disaster.
The further into design you go before discovering a misalignment, the more costly the correction. Five minutes in, you pivot easily. Twenty-five minutes in, you've built on flawed foundations and may not have time to rebuild. Confirmation is insurance against catastrophic late-stage failure.
An effective confirmation statement synthesizes everything you've gathered into a coherent summary. It should be comprehensive yet concise—covering key points without becoming a lecture.
The Five-Part Confirmation Structure:
| Component | Duration | Purpose |
|---|---|---|
| Problem Restatement | 15-20 seconds | Verify you understand the fundamental goal |
| Scope Summary | 30 seconds | Align on boundaries—what's in, what's out |
| Core Entities | 20 seconds | Preview your modeling approach |
| Key Assumptions | 30 seconds | Surface high-risk assumptions for validation |
| Success Criteria | 15 seconds | Clarify what 'done' looks like |
| Total | ~2 minutes | Complete alignment before design |
Your confirmation statement should take approximately 2 minutes. Shorter risks missing important elements. Longer becomes a presentation rather than a confirmation. Practice until you can synthesize complex requirements concisely.
Let's see how to craft each component of an effective confirmation statement.
Part 1: Problem Restatement
Restate the core problem in your own words. This immediately reveals if you've fundamentally misunderstood the problem.
Part 2: Scope Summary
Clearly state boundaries. This prevents scope creep and sets expectations.
"In scope:- Vehicle entry with spot allocation by size- Multiple vehicle types: motorcycle, car, bus- Payment processing with multiple payment methods- Real-time availability tracking Out of scope (for time):- Advance reservations- Multi-location management- License plate recognition- Valet services I'll design extensibility points for the deferred features."Part 3: Core Entities Preview
Name the primary classes you'll design. This gives the interviewer a preview and an opportunity to redirect if you're heading in the wrong direction.
"My core entities will be:- ParkingLot: The main orchestrator, containing levels and managing entry/exit- ParkingLevel and ParkingSpot: The physical structure with size-based spots- Vehicle hierarchy: Motorcycle, Car, Bus with size awareness- Ticket: Links vehicle entry to spot and enables payment calculation- Payment-related: PaymentStrategy abstraction for different payment methods"Part 4: Key Assumptions Highlight
Surface the most design-impactful assumptions for validation.
"Key assumptions I'm making:- Multi-threaded operation (concurrent entry gates)- Hourly pricing based on vehicle type- Full lot means rejection, not waiting queue- Buses require 5 contiguous car-sized spots- In-memory storage acceptable for this design I'll document all assumptions but wanted to confirm these high-impact ones."Part 5: Success Criteria
Define what a complete design looks like. This aligns expectations on deliverables.
"For a successful design, I'll deliver:- Class diagram showing entities and relationships- Key method signatures for core operations- Design pattern applications where appropriate (Strategy for payment, Factory for vehicles)- Discussion of thread-safety approach- Walkthrough of a vehicle entry-to-exit flow Would you like me to also show actual implementation code, or is the design sufficient?"Here's a complete confirmation statement that brings all five parts together. Study this as a reference for your own confirmations.
CANDIDATE: "Let me confirm my understanding before I start designing. PROBLEM:I'll design a parking lot management system that handles vehicles entering, parking in appropriate spots, and paying upon exit. The system manages a multi-level structure with different spot sizes for different vehicles. SCOPE:In scope: Vehicle entry and exit, spot allocation by vehicle size for motorcycles, cars, and buses, payment processing with multiple methods, and real-time availability tracking. Out of scope: Advance reservations, multi-location management, license plate recognition—though I'll design for extensibility on these. CORE ENTITIES:I'll design: ParkingLot, ParkingLevel, ParkingSpot, Vehicle hierarchy (Motorcycle, Car, Bus), Ticket, and a PaymentStrategy abstraction. KEY ASSUMPTIONS:- Concurrent access from multiple entry/exit points (thread-safe design)- Hourly pricing differentiated by vehicle type- Full lot rejects new entries rather than queueing them- Buses require 5 contiguous spots on a single level- In-memory storage is acceptable SUCCESS CRITERIA:I'll provide a class diagram, key method signatures, pattern applications including Strategy for payment and Factory for vehicles, thread-safety discussion, and a walkthrough of entry-to-exit flow. Does this align with what you're looking for? Should I adjust any priorities or add anything before I proceed?" INTERVIEWER:"That sounds good. One addition: I'd like you to also handle the case where spots are differently priced by location—closer spots cost more." CANDIDATE:"Great point—I'll add proximity-based pricing. That reinforces the Strategy pattern for pricing, where I'll have both vehicle-based and location-based factors. I'll update my assumptions to include variable spot pricing. Thanks for the clarification—proceeding now."Notice how the confirmation statement flows logically from problem to scope to entities to assumptions to success criteria. Each section naturally leads to the next. This isn't just dumping information—it's telling a coherent story of your understanding.
Confirmation isn't just for show—it's for catching misalignments. When the interviewer corrects or adds to your understanding, handle it gracefully.
Common Correction Types:
| Correction Type | Example | Response Strategy |
|---|---|---|
| Scope Addition | 'Actually, include reservations too.' | Acknowledge, adjust scope, note trade-off: 'Got it—I'll include reservations. That may reduce depth on payment processing.' |
| Scope Removal | 'Skip the payment part for now.' | Accept, identify reallocation: 'Understood—I'll focus on spot allocation algorithms instead. More depth there.' |
| Assumption Fix | 'Buses don't need contiguous spots.' | Thank them, update: 'Thanks—that simplifies allocation. I'll treat buses as simply needing larger individual spots.' |
| Priority Shift | 'Focus more on the scheduling algorithm.' | Acknowledge, adjust: 'Noted—I'll spend more design time on spot selection strategies and less on entity structure.' |
| Entity Addition | 'What about parking attendants?' | Incorporate: 'Good point—I'll add ParkingAttendant with responsibilities for manual overrides and customer assistance.' |
The Correction Response Pattern:
When an interviewer corrects your understanding, they're not criticizing—they're helping. Responding gracefully shows adaptability. Saying 'That's even better—it simplifies X' or 'Great catch—I'll incorporate that' demonstrates positive collaboration.
Confirmation isn't just about what you say—it's also about what you show. Visual confirmation reinforces verbal alignment and catches misunderstandings that words alone might miss.
Visual Confirmation Techniques:
Example: Visual Confirmation Sketch
╔═══════════════════════════════════════════════════════════════════╗║ PARKING LOT SYSTEM - Confirmation Sketch ║╠═══════════════════════════════════════════════════════════════════╣║ ║║ CORE ENTITIES: ASSUMPTIONS: ║║ ┌───────────┐ ┌───────────┐ A1: Multi-threaded ✓ ║║ │ParkingLot │ │ Vehicle │ A2: Hourly pricing ✓ ║║ └───────────┘ └─────┬─────┘ A3: Full = reject ✓ ║║ │ │ A4: In-memory ✓ ║║ ┌─────┴─────┐ ┌────┴────┐ A5: Contiguous bus (updated)║║ │Level│Spot│ │Car│Bus│MC│ ║║ └───────────┘ └─────────┘ SCOPE: ║║ ┌───────────┐ ✓ Entry/Exit ║║ │ Ticket │ ✓ Spot Allocation ║║ └───────────┘ ✓ Payment (Strategy) ║║ ┌───────────┐ ✓ Availability ║║ │ Payment │ ◄── Strategy ─ Reservations (defer) ║║ └───────────┘ ─ Multi-location (defer) ║║ ║║ FLOW: Enter → Allocate → Ticket → Park → ... → Pay → Exit ║║ ║║ NOTES: + Add proximity pricing (interviewer request) ║╚═══════════════════════════════════════════════════════════════════╝A quick sketch during confirmation catches misunderstandings faster than words alone. If the interviewer sees your entity sketch and says 'Where's the Attendant?', you've caught a gap immediately rather than discovering it mid-design.
Before moving to design, mentally run through this checklist. Every 'no' represents a potential misalignment waiting to derail your design.
If any checklist item is a clear 'no', do not proceed to design. Ask the specific question needed to resolve it: 'I'm unclear on whether concurrency is expected—should I design for thread safety?' The few seconds spent asking beats the minutes wasted on misaligned design.
Confirmation should happen at a natural transition point in the interview. Timing it correctly maximizes its value.
The Interview Flow:
| Phase | Duration | Activities |
|---|---|---|
| Problem Introduction | 1-2 min | Interviewer presents the problem |
| Clarifying Questions | 3-5 min | You ask essential questions |
| Scoping Discussion | 1-2 min | You define and confirm scope |
| Confirmation Statement | 2 min | Synthesize everything; get agreement |
| Design Phase | 25-35 min | Core design work with ongoing dialogue |
| Code/Implementation | 5-10 min | If required, show key implementations |
| Discussion/Q&A | 5 min | Answer follow-up questions, discuss extensions |
Transition Phrases:
Use clear verbal markers to signal you're transitioning to confirmation and then to design:
Always end confirmation with an explicit question seeking approval: 'Does this sound right?' / 'Shall I proceed?' / 'Any adjustments before I dive in?' This creates a clear permission point and ensures the interviewer has explicitly blessed your direction.
Knowing what to avoid is as important as knowing what to do. Here are frequent confirmation mistakes and how to prevent them:
Different LLD problems have different confirmation emphases. Adapt your confirmation statement to the problem type:
Elevator System Confirmation Emphasis:
Problem: 'I'm designing a system to efficiently move passengers between floors using a bank of elevators, focusing on state management and request scheduling.'
Key Points to Emphasize:
Critical Assumptions to Confirm:
Entities to Preview: Elevator, Floor, Request, ElevatorController, ButtonPanel, SchedulingStrategy
Confirmation is the bridge between understanding and action. It transforms gathered requirements into shared understanding, providing a stable foundation for design.
You have now mastered the complete requirements clarification cycle: essential questions to ask, scoping the problem, documenting assumptions, and confirming understanding. These four skills form the foundation of every successful LLD interview. You're ready to move from requirements to design with confidence.
Module Summary:
This module has equipped you with the skills to transform vague problem statements into actionable design specifications:
With these skills, you'll never again design for the wrong problem. You'll enter every design phase with clarity, confidence, and interviewer alignment.