Loading learning content...
You're forty minutes into an LLD interview. Your parking lot design is solid—clean class model, appropriate patterns, well-reasoned trade-offs. Then the interviewer leans forward:
"What if we need to support electric vehicle charging stations? How would your design handle that?"
This is the curveball moment—an intentional disruption to test how you respond when requirements change. It happens in almost every senior-level interview, and the way you handle it reveals more about your engineering maturity than anything else in the session.
Average candidates panic. They either defensively insist their design already handles everything, or they spiral into confusion trying to retrofit an incompatible extension. Senior engineers do something different: they embrace the change as an opportunity to demonstrate adaptability, structured thinking, and design resilience.
By the end of this page, you will master techniques for gracefully adapting designs to new requirements, learn frameworks for evaluating the impact of requirement changes, develop skills in communicating evolution paths clearly, and understand how to turn curveballs into opportunities to demonstrate senior-level thinking.
Understanding the interviewer's motivation helps you respond appropriately. Requirement changes are introduced to test several capabilities:
| Evaluation Goal | What They're Looking For | Red Flag Responses |
|---|---|---|
| Design Flexibility | Can your design accommodate change without major rewrite? | "We'd need to start over" or "That doesn't fit my model" |
| Pattern Application | Do you recognize which patterns support extensibility? | Forcing inappropriate patterns; ignoring extension-friendly ones |
| Impact Assessment | Can you systematically evaluate what changes? | Vague answers; missing obvious impacts; overestimating difficulty |
| Communication | Can you explain evolution paths clearly? | Mumbling through changes; disorganized thought process |
| Resilience | Do you stay calm and structured under pressure? | Visible panic; defensive reactions; shutting down |
| Senior Judgment | Do you know when to push back on requirements? | Accepting everything blindly; never questioning scope |
Requirement changes typically fall into predictable categories:
Additive Requirements: New entities, behaviors, or relationships
Modifying Requirements: Changes to existing behaviors
Cross-cutting Requirements: New concerns that span multiple classes
Constraint Tightening: Performance, scale, or correctness constraints
Recognizing the category helps you select the appropriate response strategy.
Reframe curveballs mentally: they're not attacks on your design—they're invitations to demonstrate deeper thinking. A well-designed system should accommodate reasonable change. Showing how it does (or gracefully admitting where it doesn't) demonstrates exactly the senior judgment interviewers seek.
When a new requirement lands, don't immediately start redesigning. Use the ADAPT Framework to structure your response:
| Step | Action | Purpose | Time Allocation |
|---|---|---|---|
| Acknowledge | Repeat and clarify the requirement | Ensure understanding; buy thinking time | 30 seconds |
| Diagnose | Assess impact on existing design | Identify what changes vs. what stays stable | 1-2 minutes |
| Articulate | Explain the evolution path | Show how design accommodates change | 2-3 minutes |
| Prioritize | Discuss trade-offs and phasing | Demonstrate pragmatic implementation thinking | 1 minute |
| Transition | Move forward or seek confirmation | Return to progress, not endless discussion | 30 seconds |
Curveball: "What if we need to support electric vehicle charging stations where vehicles can park and charge for a duration?"
A - Acknowledge:
"Interesting extension. So we need charging stations as a special type of parking spot, with time-based charging and potentially different pricing?"
(Clarifies scope; buys time; invites interviewer correction)
D - Diagnose:
*"Let me think through what this touches in my current design...
- Spot hierarchy: ChargingStation extends ParkingSpot, or composition with ChargingCapability
- Vehicle: needs hasElectricCapability flag or ElectricVehicle subtype
- Pricing: duration-based charging fees alongside parking fees
- Ticket: needs to track charging session state
- Availability: charging spots have different availability logic (in-use but not blocked for parking)"*
(Systematic impact analysis; shows comprehensive thinking)
A - Articulate:
*"The evolution path I see:
- SpotType enum gains CHARGING value, or we introduce ChargingSpot subclass
- ChargingSession entity tracks plug-in time, energy delivered
- PricingStrategy interface already supports new strategies—we'd add ChargingPricingStrategy
- Ticket composition includes optional ChargingSession
The Strategy pattern for pricing and the abstract Spot model both pay off here—they were designed for exactly this kind of extension."*
(Shows design was extension-ready; connects patterns to benefit)
P - Prioritize:
"If implementing incrementally, I'd start with ChargingSpot as a spot subtype and basic session tracking—that's the minimal viable path. Premium features like dynamic pricing based on energy demand would follow."
(Pragmatic phasing; MVP thinking)
T - Transition:
"Should I sketch out the ChargingSession class, or is this level of analysis sufficient for the scope discussion?"
(Returns initiative to interviewer; ready to dig deeper or move on)
Jumping straight to solutions before clarifying the requirement is a common mistake. The Acknowledge step serves double duty: it ensures you're solving the right problem AND buys you 30 crucial seconds to organize your thoughts.
The Diagnose step of ADAPT requires systematic impact analysis. Here are techniques for rapidly assessing how requirement changes affect your design:
Visualize impact as ripples from a stone dropped in water:
Circle 1 (Core Impact): Which class/entity is most directly affected?
Circle 2 (Direct Dependencies): What directly uses or creates the affected entity?
Circle 3 (Transitive Effects): What depends on Circle 2 components?
Example: Adding "spot reservation" to parking lot
| Circle | Impact |
|---|---|
| Core | New Reservation entity with spot, time window, user |
| Direct | ParkingLot.findAvailableSpot() must consider reservations; SpotAssigner needs reservation awareness |
| Transitive | Ticket creation must check reservation validity; pricing may include reservation fees |
Trace from the new requirement to existing entities:
Example: "Customers can earn and redeem loyalty points"
For each affected class, ask:
Under-analysis misses important impacts ('Oh wait, that also affects...'). Over-analysis paralyzes the conversation. Aim for 60-90 seconds of structured analysis covering the core impact and key transitive effects, then move to articulation.
Certain patterns inherently support easier adaptation. When you've used these patterns in your design, curveballs become easier to handle because the extension points are built-in:
| Pattern | How It Enables Change | Requirement Changes It Handles Well |
|---|---|---|
| Strategy | Swap algorithms without changing context | New pricing rules, different sorting logic, varied authentication methods |
| Factory | Create objects without specifying concrete class | New entity types (vehicle, user, product variants) |
| Observer | Add subscribers without modifying publisher | New notification channels, additional event consumers |
| Decorator | Layer behaviors without modifying core | Optional features, logging, caching, validation |
| Command | Encapsulate operations as objects | Undo/redo, queuing, scheduling, audit logging |
| Composite | Treat individual and composed objects uniformly | Hierarchical structures (menu items, organizational units) |
| Template Method | Define skeleton with customizable steps | Workflow variations, document processing, notification formatting |
When a curveball lands, explicitly connect it to your pattern choices:
"This is exactly why I used the Strategy pattern for pricing. Adding time-based dynamic pricing means implementing a new
TimeBasedPricingStrategyand injecting it into the pricing context. No changes to existing code needed—just a new strategy class."
"The Observer pattern for inventory updates pays off here. Adding SMS notifications alongside email is just registering a new
SmsNotificationObserver. The InventoryManager doesn't change at all."
"I used Factory for vehicle creation, which means supporting electric vehicles is straightforward: extend the factory to produce
ElectricVehicleinstances based on input parameters."
Sometimes the curveball reveals a rigidity. Acknowledge it honestly:
"My current design hardcoded vehicle types in an enum, optimizing for simplicity. This charging station requirement would need a refactor to type composition. The good news: the refactor is localized to the Vehicle class hierarchy—SpotAssignment and Ticket remain stable because they depend on the Vehicle abstraction, not concrete types."
This demonstrates maturity: you see the limitation, you can articulate the fix, and you can scope its impact.
When choosing patterns initially, mention that they support future extension. Then, when the curveball comes, you can say: 'As I mentioned, I chose Strategy specifically because pricing requirements often evolve. Here's that foresight paying off.'
Not every requirement should be accepted uncritically. Senior engineers push back when requirements are unclear, contradictory, or disproportionately expensive. This is a vital skill—interviewers respect thoughtful pushback.
Pushback must be collaborative, not confrontational:
Structure: Acknowledge → Concern → Question
"That's an interesting direction [Acknowledge]. The challenge I see is that it would require fundamentally redesigning the payment flow, which we've already detailed [Concern]. Is this a must-have for the core design, or could we treat it as a known extension point for v2? [Question]"
"I can see why that would be valuable [Acknowledge]. My concern is that 'real-time sync' could mean many things—from eventual consistency with short delays to strict ACID guarantees [Concern]. What's the tolerance for lag in this use case? [Question]"
Sometimes interviewers pose unreasonable requirements specifically to see if you'll push back:
Thoughtful pushback on these demonstrates exactly the senior judgment they're evaluating.
There's a fine line between healthy pushback and defensive resistance. Pushback seeks clarification and proposes alternatives. Defensiveness rejects without alternatives. Always accompany pushback with 'here's what I'd need to know' or 'here's a reduced scope that might work.'
When your design needs to evolve, how you communicate the path matters as much as the technical details. Use structured communication techniques:
Structure:
Example: Adding reservation support
"Before: ParkingSpot has isOccupied boolean, set when vehicle parks.
"After: ParkingSpot has occupancy status enum including AVAILABLE, OCCUPIED, and RESERVED. New Reservation entity links spot, timeWindow, and customer.
"Migration: We'd add the Reservation class and update Spot's availability logic to check active reservations. Existing 'isOccupied' callers would work through a compatibility method during transition, then be migrated to the new status check."
Explain changes in layers of increasing detail:
Layer 1 (Conceptual): "At a high level, we're adding a reservation concept that sits between customers and spots."
Layer 2 (Structural): "This means a new Reservation class with relationships to Customer, Spot, and TimeWindow. The Spot availability logic gains reservation awareness."
Layer 3 (Behavioral): "SpotFinder.findAvailable() now filters spots with conflicting reservations. ReservationService.create() validates no conflicts exist."
Layer 4 (Implementation): "Reservation likely needs createdAt, status (PENDING/CONFIRMED/CANCELLED), and methods like isActiveAt(time)."
In an interview, usually layers 1-3 are sufficient. Layer 4 is for when asked for implementation details.
When possible, update your diagram:
"Let me add to my class diagram. [Draws Reservation box] This connects to Customer, Spot, and introduces a time dimension. [Adds arrows] The key new relationship is Spot checks Reservation when determining availability."
Visual updates are more memorable than verbal explanations.
An often overlooked communication technique: explicitly state what remains stable. 'Ticket, Payment, and Vehicle classes don't change at all—the impact is localized to the Spot and availability subsystem.' This demonstrates design isolation and change containment.
Not all requirement changes are equal. Your response should scale with the magnitude of the change:
| Magnitude | Characteristics | Appropriate Response | Example |
|---|---|---|---|
| Trivial | Fits existing structure perfectly | "Great, we already support this via [mechanism]" | "Support a new vehicle type" when using type composition |
| Minor | Requires new code but no design changes | Quick explanation of addition | "Add email notification" when Observer pattern is in place |
| Moderate | Requires localized design changes | Impact analysis + evolution path | "Add reservation" requires new entity and relationship |
| Major | Requires significant restructuring | Acknowledge scope, propose phased approach | "Add multi-tenancy" affects most system components |
| Fundamental | Contradicts core design assumptions | Pushback and clarify; may need redesign discussion | "Change from in-memory to distributed architecture" |
For Trivial/Minor Changes: Confidence and brevity
"Perfect, this is exactly what Strategy pattern enables. New strategy class, inject it, done."
For Moderate Changes: Structured analysis
"This is meaningful but manageable. Let me walk through the impact: [ADAPT framework]..."
For Major Changes: Scope and phase
"This is a significant addition that touches several components. Let me first outline what changes and what stays stable, then we can discuss phasing..."
For Fundamental Changes: Collaborative redesign
"This changes a core assumption of the design—we assumed X but now need Y. Rather than retrofitting, let me discuss what a redesigned approach would look like..."
Treating trivial changes as major signals lack of confidence in your design. If you've built well, some changes really are easy. Own that: 'This is straightforward because [design decision].'
Certain curveballs appear frequently across LLD interviews. Preparing for these common scenarios builds fluency:
| System Type | Common Curveball | Response Approach |
|---|---|---|
| Parking Lot | Electric vehicle charging stations | SpotType extension, ChargingSession entity, time-based pricing strategy |
| Parking Lot | Multiple entrance/exit points | Gateway entity per entrance, distributed counter or centralized capacity manager |
| Library | eBooks and digital lending | Book abstraction (PhysicalBook vs DigitalBook), LendingPolicy strategy per type |
| Library | Fine amount variations by member type | FineCalculator strategy, MemberType privilege tiers |
| Elevator | Express/service elevator distinction | ElevatorType with different routing strategies, separate request queues |
| Elevator | Maintenance mode | Elevator state machine gains MAINTENANCE state, dispatch ignores unavailable elevators |
| Chess | Game replay/playback | Command pattern for moves enables complete history, replay is command re-execution |
| Chess | Undo last move | Command with undo(), maintain move stack, verify game state restoration |
| Ride Share | Carpooling/shared rides | Trip composition with multiple Riders, split payment, pickup sequencing strategy |
| Ride Share | Driver ratings and feedback | Rating entity linking Trip, Driver, Rider; aggregate rating Calculator |
"How would you add audit logging?"
"What if we need to support multiple currencies?"
"How would you add undo functionality?"
"What about supporting this at 100x the users?"
"How would you test this?"
After practicing each case study, explicitly list the likely curveballs and your response strategies. This mental preparation means you won't be caught off guard in actual interviews—you'll recognize familiar patterns in unfamiliar questions.
The ability to adapt designs to changing requirements is perhaps the most valued skill in senior engineering. Let's consolidate the key principles:
Module Complete:
You've completed the Handling Constraints & Trade-offs module. You now possess the frameworks, techniques, and language for navigating the most challenging aspects of LLD interviews:
These capabilities distinguish senior engineers from those who simply write code. You can now design, defend, evolve, and communicate at the level expected in staff-plus roles.
You have mastered the art of handling constraints and trade-offs in LLD interviews. This module covered discussing alternatives, making justified decisions, acknowledging limitations transparently, and adapting gracefully to new requirements. Together, these skills constitute the behavioral signature of senior engineering practice.