How to Approach an LLD Interview

What LLD interviews test

Deliberately under-specified problem, 45-60 min. Interviewer not checking whether code compiles, whether you remember every GoF pattern, every edge case.

They are checking: how you structure ambiguity, decompose, abstract (interfaces, composition, polymorphism where they earn their keep), reason about change (extensions, evolution hotspots), handle concurrency, communicate.

Strong candidate sounds like a senior engineer thinking out loud, not a textbook reciting principles.

Six-step flow

1. 1
   Clarify requirements (5-7 min)
2. 2
   Identify entities + relationships (5 min)
3. 3
   Class diagram (10 min)
4. 4
   Walk through flows (5 min)
5. 5
   Code critical bits (12-15 min)
6. 6
   Concurrency, extensibility, trade-offs (5 min)

If you spend 30 min on code and never clarified requirements, you've failed before you started.

Step 1 — clarify

Three buckets, in order:

Functional scope: in/out. 'Single lot or multi-floor/location?' 'Reservations or walk-in only?' 'Payment in scope?' 'Multiple vehicle types and sized spots?'

Non-functional / scale: 'Single instance or distributed?' 'Concurrent users?' 'In-memory only, or persist state?'

Out-of-scope confirmation: 'I'll skip auth/billing infra unless you want it modeled.'

Every clarifying question rules out a different class hierarchy. Write agreed scope down at top of whiteboard.

Step 2 — entities and relationships

Nouns from problem: ParkingLot, Floor, Spot, Vehicle, Ticket, EntryGate, ExitGate, PaymentProcessor, RateStrategy.

Verbs (→ methods or use cases): park vehicle, unpark, compute fee, find spot.

Relationships: ParkingLot has many Floors. Floor has many Spots. Spot has zero or one Vehicle. Ticket references Spot + Vehicle + entry time.

Don't model the universe — only what your scope requires.

Step 3 — class diagram

Classes + key fields + key methods. Mermaid or whiteboard.

Heuristics:

• One responsibility per class (SRP)
• Vary-by-policy bits behind interface (Strategy) — fee calculation, spot allocation
• Composition over inheritance (Spot has a SpotType, not CarSpot extends Spot)
• Abstract interfaces named for role (FeeStrategy, SpotAllocator), not implementation (HourlyFeeImpl)
• Identify interfaces / ports before concrete classes

Step 4 — walk through a flow

Pick the most representative flow and walk through:

Vehicle arrives → EntryGate calls parkingLot.park(vehicle) → lot picks a Floor → floor finds available Spot for that vehicle's SpotType via SpotAllocator → spot is assigned to vehicle → Ticket created with entry time + spot reference → returned. On exit: parkingLot.unpark(ticket) → spot released → FeeStrategy.calculate(ticket) runs → receipt returned.

Walk-through validates design (you'll catch missing classes), lets interviewer interject, communicates 'animated' design.

Step 5 — code the critical pieces

Don't write every class. Write:

• Interfaces for strategy / extension points
• 1-2 methods driving the flow — parkingLot.park(), feeStrategy.calculate()
• Enums if they clarify (SpotType, VehicleType, OrderStatus)

Skip getters/setters/constructors/toString/exception bodies. Say 'standard boilerplate' and move on.

Step 6 — concurrency, extensibility, trade-offs

Bring up before interviewer asks.

Concurrency: two vehicles arriving simultaneously — atomic spot reservation. Synchronize spot lookup + assignment, or ConcurrentHashMap with compute() for atomic check-and-set. For multi-floor, partition by floor, lock per floor to reduce contention.

Extensibility: new spot types — add to enum or interface for open polymorphism. Different pricing — FeeStrategy is the extension point. Reservations later — ReservationService that pre-reserves; lot.park() checks held reservations first.

Trade-offs: 'I used Strategy for fees; alternative is a rule engine, but Strategy is simpler for this scope.' 'In-memory state; for persistence we'd add LotRepository and persist on assign/release — but opens consistency questions.'

This separates senior candidates — showing you understand shape of future change.

Common mistakes

• Jumping to code first
• Modeling the universe (50 classes for a parking lot)
• Deep inheritance (Vehicle ← Car ← SedanCar ← LuxurySedanCar)
• God classes (30-method ParkingService)
• Ignoring concurrency
• Naming patterns out loud as a flex
• Refusing to make decisions ('it depends' for everything)
• No interface boundaries (hard-coded HourlyFee — can't mock for tests)
• Skipping the walk-through
• Not asking interviewer for input — it's a conversation

Recommendation

Treat the LLD interview as a structured conversation, not a coding sprint. Spend the first 15 minutes on clarification + entities + class diagram before you write any code. Use composition + interfaces for variability points (Strategy for fees, Allocator for spot finding); avoid deep inheritance and god classes. Code only the critical 1-2 methods and the strategy interfaces — skip boilerplate. Always close with a concurrency analysis, two extension scenarios, and one trade-off you consciously made. Drive the conversation — ask the interviewer for input at every major decision point.