LLD Interview Framework
A structured approach to LLD interviews: (1) Clarify scope and requirements; (2) Identify actors and core entities; (3) Define relationships and multiplicity; (4) Apply relevant design patterns; (5) Surface trade-offs and extension points.
LLD Interview Framework = building a house. Step 1: ask the client what they want (requirements). Step 2: sketch the rooms (entities). Step 3: draw the hallways (relationships). Step 4: pick materials (patterns). Step 5: warn about the foundation cost (trade-offs). Never start pouring concrete before you have blueprints.
Step 1 — Clarify: Ask about scale (single machine vs distributed?), persistence, concurrency, functional scope. A parking lot: how many floors, how many spot types, pricing strategy, reservation support? Step 2 — Entities: ParkingLot, Floor, Spot, Vehicle, Ticket, Payment. Step 3 — Relationships: ParkingLot has many Floors; Floor has many Spots; Ticket associated with Spot and Vehicle; one-to-many, multiplicity. Step 4 — Patterns: Strategy for pricing, State for spot/ticket lifecycle, Factory for spot type creation, Observer for notifications. Step 5 — Trade-offs: thread-safety of spot allocation, extensibility for new spot types, separation of parking logic from payment.
The LLD interview is an exercise in demonstrating design judgment, not pattern recall. Interviewers look for: (1) Do you ask the right questions before drawing anything? (2) Do you identify the right abstractions — not too many, not too few? (3) Do you apply patterns because they solve a real problem, not because you know their names? (4) Do you proactively surface trade-offs (e.g., 'I'm using a Singleton for the LotManager but in a multi-server deployment this breaks — I'd swap it for a service with a distributed lock')? Common LLD interview systems: parking lot, elevator system, chess, LRU cache, rate limiter, hotel booking, library management, snake and ladder, vending machine. For each: identify the state machine, the primary entity relationships, and the concurrency concerns.
I follow a five-step framework. First, I spend 3-4 minutes on requirements: what are the actors, what are the core use cases, what is explicitly out of scope? Second, I enumerate entities and their attributes without getting into code. Third, I draw relationships: which entities own which, cardinality, which are Entities vs Value Objects. Fourth, I identify one or two patterns that directly solve a specific problem in this system — I name the problem first, then the pattern. Fifth, I call out at least two trade-offs or extension points — this is where senior engineers demonstrate depth. I keep the design at the interface/class level, not implementation. I code only when asked, and I start with the most critical class.
The worst LLD interview mistake is immediately drawing classes without asking questions. Requirements always contain ambiguities that change the design fundamentally. A close second: naming patterns without explaining why they apply to this specific problem.