101
0/246
Loading content...
Every design is built on two foundations: explicit requirements and implicit assumptions. You've gathered requirements through questions and defined scope through boundary-setting. But between what's explicitly stated and what you design, there's a vast space filled with assumptions.
These assumptions are invisible—until they're wrong. When an interviewer says, 'But that doesn't handle concurrent access!' and you thought single-threaded was implied, your design crumbles. When they expect your parking lot to support motorcycles but you assumed cars-only, you've built on quicksand.
Documenting assumptions transforms the invisible into the visible, the debatable into the agreed-upon.
By the end of this page, you will understand how to identify implicit assumptions, categorize them effectively, document them for interviewer alignment, and protect your design from assumption-based attacks. This practice elevates your interview performance from reactive to proactive, from defensive to confident.
Assumptions are the beliefs you hold about the problem that influence your design but weren't explicitly stated. They fill the gaps between vague requirements and concrete implementation decisions.
Consider this problem statement: "Design a library management system."
This statement doesn't specify:
You must make decisions about these matters to design a system. Those decisions are assumptions.
When you don't document assumptions, you can't defend them. If an interviewer challenges an aspect of your design based on an assumption you made silently, you appear thoughtless. If you documented that assumption and they disagree, you appear thoughtful—you just had different information.
Not all assumptions are equal. Organizing them into categories helps you identify gaps systematically and communicate them clearly.
| Category | Description | Examples |
|---|---|---|
| Business Logic | Assumptions about how the business operates | Loan period is 14 days; fines are $0.25/day; max 5 active loans per member |
| Data Characteristics | Assumptions about data volume, format, and nature | Book catalog size ~100K; ISBN is unique; titles can be up to 500 characters |
| Technical Environment | Assumptions about the technical context | Single-threaded; in-memory storage; language-agnostic design |
| User Behavior | Assumptions about how actors interact with the system | Users don't intentionally provide malformed inputs; one user per session |
| Edge Case Handling | Assumptions about boundary conditions | Full parking lot rejects new entries; damaged books are removed from circulation |
| External Dependencies | Assumptions about systems not being designed | Payment processing is handled externally; authentication is pre-verified |
Using Categories for Systematic Discovery:
When documenting assumptions, walk through each category and ask: "What am I assuming about [category] that I haven't confirmed?" This systematic approach catches assumptions you might otherwise miss.
Technical environment and edge case assumptions are highest risk. If you assume single-threaded but the interviewer expects thread-safety, your entire synchronization model is wrong. If you assume 'full means rejection' but they expect queuing, your state machine needs redesign. Clarify these early.
Assumptions are often invisible because they feel obvious. Use these techniques to surface them:
Example: Discovering Assumptions in Elevator Design
Design Decision: "I'll use a single ElevatorController to manage all elevators" WHY THIS WAY?→ Because I'm assuming centralized control is acceptable→ Because I'm assuming latency of centralized dispatch is tolerable→ Because I'm assuming no need for distributed redundancy WHAT IF?→ What if each elevator needed autonomous operation? → Assumption: Elevators depend on controller availability→ What if we had 100 elevators instead of 4? → Assumption: Controller can handle scheduling for 4 elevators efficiently NEWCOMER QUESTIONS:→ "Why not let each elevator decide for itself?" → Assumption: Centralized coordination is more efficient→ "What happens if the controller fails?" → Assumption: Controller failure isn't in scope (but should document!) DOCUMENTED ASSUMPTIONS (from this analysis):1. Centralized elevator control is acceptable (single controller)2. Controller is highly available (failure handling out of scope)3. Number of elevators is small enough for centralized scheduling (~10 or fewer)4. Elevator-to-controller communication latency is negligibleHow you document assumptions matters. A good format makes assumptions easy to communicate, verify, and reference during design discussion.
The Effective Assumption Statement:
Each documented assumption should include:
| Component | Purpose | Example |
|---|---|---|
| Assumption | What you believe to be true | 'All vehicles have license plates' |
| Category | Type classification | Business Logic |
| Design Impact | What changes based on this | 'License plate is used as unique vehicle identifier' |
| If Different | How design would adapt | 'Would need alternative vehicle identification (ticket-only or RFID)' |
Example: Documented Assumptions for Parking Lot
## Documented Assumptions: Parking Lot System ### Business Logic Assumptions: A1. VEHICLE TYPES: System supports three vehicle types: Motorcycle, Car, Bus. - Impact: VehicleType enum with three values; spot sizing based on these - If Different: Need additional vehicle types; abstract factory for extensibility A2. SPOT ALLOCATION: A bus requires 5 contiguous car spots; motorcycles get motorcycle spots only - Impact: SpotAllocationStrategy must check contiguous availability for buses - If Different: Different spot requirements would change allocation logic A3. PRICING: Parking is charged hourly with rates varying by vehicle type - Impact: PricingStrategy calculates (exit_time - entry_time) * hourly_rate[type] - If Different: Flat rate or tiered pricing would change strategy implementation ### Technical Environment Assumptions: A4. CONCURRENCY: Multiple entry/exit points operate simultaneously (multi-threaded) - Impact: Spot allocation and availability tracking require thread-safety - If Different: Single-threaded would simplify; remove synchronization overhead A5. PERSISTENCE: In-memory storage acceptable; no database required - Impact: Collections used directly; no repository abstraction for persistence - If Different: Would add Repository pattern for database abstraction A6. SCALE: Single parking lot with up to 1000 spots across 3-5 levels - Impact: Linear search acceptable for available spots; no sharding needed - If Different: Larger scale might require indexed lookups or distributed design ### Edge Case Assumptions: A7. FULL LOT: When parking lot is full, new vehicles are rejected (no queue) - Impact: parkVehicle() returns null when no spots available - If Different: Would need WaitingQueue and NotificationService A8. LOST TICKETS: Out of scope for MVP; operator manually resolves - Impact: No alternative identification flow needed - If Different: Would need vehicle-to-ticket lookup, potentially via license plateNumber your assumptions (A1, A2, A3...). During design discussion, you can say 'Based on assumption A4 about concurrency, I'm using locks here.' This creates a shared vocabulary between you and the interviewer.
Timing and presentation matter. Dump all assumptions at once and you'll bore the interviewer. Never mention them and you lose their protective value.
The Strategic Presentation Approach:
Example: Contextual Assumption Presentation
[After requirements clarification, before design] Candidate: "Before I start designing, let me share key assumptions I'm making: For business logic:- I'll support Motorcycle, Car, and Bus vehicle types. Buses need 5 contiguous spots.- Pricing is hourly per vehicle type. For technical environment:- I'm assuming we need thread-safety since multiple gates operate concurrently.- I'll design in-memory for now, but with interfaces that allow adding persistence. For edge cases:- A full lot rejects new entries; no waitlist functionality.- Lost tickets are handled manually by operators—out of scope. Shall I adjust any of these before I proceed?" Interviewer: "Actually, let's add motorcycles can also use car spots if motorcycles spots are full." Candidate: "Great catch—I'll update assumption A1. This means spot allocation needs to check motorcycle spots first, then fall back to car spots. I'll use a Chain of Responsibility or Strategy with fallback. Thanks for the clarification." [Later, during design] Candidate: "I'm using a ReentrantLock on the spot allocation because of A4—our concurrency assumption. If we were single-threaded, I could simplify this, but I want to ensure correctness under concurrent entry attempts."Well-presented assumptions invite productive dialogue. Instead of the interviewer saying 'You forgot about X!' they'll say 'What if assumption A3 were different?' This shifts the dynamic from critique to collaboration.
Interviewers will challenge your assumptions—that's part of the evaluation. How you respond matters as much as the assumptions themselves.
Common Challenge Types and Responses:
| Challenge Type | Example | Strong Response |
|---|---|---|
| Wrong Assumption | 'Actually, buses don't need 5 spots' | 'Thanks for the correction. Let me update A2. This simplifies my allocation logic—I can treat buses like large vehicles rather than multi-spot allocations.' |
| Missing Assumption | 'What about electric vehicles needing charging spots?' | 'Good point—I hadn't assumed that. Let me add A9: EV charging is out of scope, but I'll design SpotType as extensible. If we add ChargingSpot, the type hierarchy supports it.' |
| Assumption Too Simple | 'Real parking lots have more complex pricing' | 'Agreed. My assumption A3 is intentionally simplified for MVP. The Strategy pattern I'm using for pricing could accommodate dynamic pricing, surge pricing, or validation-based pricing with new strategy implementations.' |
| Assumption About Edge Cases | 'What if someone enters but never exits?' | 'I assumed no abandoned vehicles for MVP—that's edge case A7. For a production system, I'd add a cleanup service that flags long-stay vehicles after 72 hours. The Ticket already has entry_time, so detecting this is straightforward.' |
The Challenge Response Framework:
When an assumption is challenged, it's an opportunity to demonstrate extensibility. If your assumption was 'hourly pricing' and the interviewer wants 'dynamic pricing,' show how your Strategy pattern accommodates this. 'My assumption A3 would change, but the design handles it—we'd add DynamicPricingStrategy to the existing abstraction.'
Knowing common pitfalls helps you avoid them. Here are frequent assumption-related mistakes and how to prevent them:
When asked how your system handles X, answering 'It depends...' without making a decision is weak. Better: 'Based on my assumption A7, I handle it this way. If that assumption changes, I'd adapt by...' Make decisions; don't defer endlessly.
Different problem types have characteristic assumptions. Familiarizing yourself with these accelerates assumption identification during interviews.
Library Management System Assumptions:
Business Logic:
Technical Environment:
Edge Cases:
Design Impacts:
copyNumber for multiple copiesWell-documented assumptions don't just clarify—they drive design decisions. Each significant assumption should be traceable to specific design choices.
The Assumption → Design Decision Chain:
Documenting the Chain:
When presenting your design, make the connection explicit:
"For the ParkingLot class, I'm making it thread-safe with a ReentrantReadWriteLock.This is driven by assumption A4—concurrent operations from multiple entry gates. Specifically:- Read operations (checking availability) acquire read locks—multiple readers allowed- Write operations (allocating/releasing spots) acquire write locks—exclusive access- I'm using ReadWriteLock rather than synchronized blocks because reads vastly outnumber writes in a parking lot scenario If assumption A4 were wrong—single-threaded operation—I'd simplify by removing the locking entirely, which would reduce complexity and improve performance."Being able to trace design decisions to documented assumptions shows that your design is intentional, not accidental. Every choice has a reason. This is the hallmark of senior engineering work.
Assumptions are the invisible scaffolding of every design. Making them visible transforms them from liabilities into assets—foundations you can stand on confidently.
What's Next:
You now understand how to identify, document, and leverage assumptions. The final page in this module covers confirming understanding—the crucial step of verifying that your interpretation of requirements, scope, and assumptions aligns with the interviewer's expectations before you invest heavily in design.
You've mastered assumption documentation. No longer will invisible assumptions undermine your designs—you'll surface them, document them, and build confidently upon them. Next, we'll learn to confirm understanding before diving into detailed design.