How to Approach Any LLD Problem — The 4-Step Framework
Introduction
You're 5 minutes into an LLD interview. The interviewer says: "Design a Parking Lot system." Your mind races — should you start coding? Draw a class diagram? Ask questions? You freeze.
This is the most common failure mode in LLD interviews — not a lack of knowledge, but a lack of process. Candidates who know every design pattern and SOLID principle still fail because they don't have a repeatable, structured approach to decompose an open-ended problem.
In this section, we'll give you that process: a 4-Step Framework that works for any LLD problem, from Parking Lot to Elevator System to Chess.
The framework:
- Clarify Requirements & Define Scope — Understand what you're building before you design it
- Identify Core Objects and Relationships — Discover the entities in the system
- Draw UML Diagrams — Formalize the design visually
- Implement with Patterns & Principles — Write clean, extensible code
Across this entire section (S16), we'll apply every step to a single running example: the Parking Lot system — so you see the complete journey from vague prompt to working design. By the end, you'll be able to take any LLD problem and systematically work through it without freezing.
Why You Need a Framework
LLD interviews are deliberately open-ended. "Design a Parking Lot" doesn't tell you:
- How many floors? One level or multi-story?
- What vehicle types? Cars only, or also motorcycles, trucks, buses?
- How is pricing handled? Flat rate, hourly, tiered?
- Is there a reservation system?
- What happens when the lot is full?
The interviewer withholds these details on purpose. They want to see whether you:
- Ask the right questions before diving in (Step 1)
- Identify the right objects from the requirements (Step 2)
- Think visually about structure and interactions (Step 3)
- Apply clean design with the right patterns (Step 4)
Without a framework, candidates make one of two mistakes:
- Too fast: They jump straight to coding, building a monolithic
ParkingLotclass with 30 methods and no separation of concerns. Result: messy, untestable, unextensible. - Too slow: They spend 20 minutes asking clarifying questions and never write any code. Result: the interviewer has no artifact to evaluate.
The framework gives you time discipline. In a typical 45-minute LLD interview:
| Step | Time | Purpose |
|---|---|---|
| Step 1: Clarify Requirements | ~5 minutes | Understand scope, agree on constraints |
| Step 2: Identify Objects | ~5 minutes | Discover entities, attributes, relationships |
| Step 3: Draw UML | ~10 minutes | Class diagram + one behavioral diagram |
| Step 4: Implement | ~20 minutes | Code the core classes with patterns |
| Review & Discuss | ~5 minutes | Walk through design decisions |
Notice: only 20 minutes of the 45 are actual coding. The other 25 minutes are design — and that's where most points are scored.
The 4-Step Framework — Overview
Step 1: Clarify Requirements & Define Scope
Before designing anything, ask questions. Your goal is to turn a vague prompt into a concrete specification:
- What are the functional requirements? (What does the system DO?)
- What's out of scope? (What are we NOT building?)
- What are the constraints? (Single building? Concurrent access?)
- Who are the actors? (Drivers, attendants, admins?)
The interviewer EXPECTS questions. Not asking them signals that you make assumptions — a red flag in engineering.
Step 2: Identify Core Objects and Relationships
Once you know what you're building, discover the entities:
- Nouns in the requirements become candidate classes: Parking Lot, Floor, Spot, Vehicle, Ticket
- Verbs become candidate methods: park, unpark, calculateFee, findAvailableSpot
- Adjectives/types become candidate enums or attributes: SpotType (COMPACT, REGULAR, LARGE), VehicleType (CAR, MOTORCYCLE, TRUCK)
Then define relationships: A ParkingLot has Floors (composition). A Floor has Spots (composition). A Ticket has a Vehicle (association).
Step 3: Draw UML Diagrams
Formalize your mental model into diagrams:
- Class Diagram (always) — shows structure: classes, attributes, methods, relationships
- Use Case Diagram (if asked) — shows who does what
- Sequence Diagram (recommended) — shows how objects interact for a key workflow
You learned all of these in S5 (UML Diagrams). Now you apply them under interview pressure.
Step 4: Implement with Patterns & Principles
Translate your UML into code:
- Apply appropriate design patterns from S10-S12: Strategy for pricing, Factory for vehicle creation, Observer for notifications
- Follow SOLID principles from S6: each class has one responsibility, program to interfaces not implementations
- Write Python + Java code that is clean, testable, and extensible
The pattern selection isn't random — it's driven by the requirements you clarified in Step 1 and the object relationships you identified in Step 2.

Running Example — Parking Lot System
Throughout this section (Tutorials 2-5), we'll apply each step to a Parking Lot system — one of the most classic and frequently asked LLD interview problems.
Why Parking Lot?
- It's universally understood — everyone has parked a car
- It's rich enough to exercise all four steps — multiple entities, various pricing strategies, real-time availability tracking, concurrency concerns
- It's asked at every level — from junior to senior interviews at Amazon, Google, Microsoft, and others
- It's the perfect complexity for learning — not so trivial that it's boring, not so complex that it requires domain expertise
Here's the vague prompt you'd receive in an interview:
"Design a Parking Lot system."
That's it. Six words. The rest is up to you.
In the next four tutorials, we'll take this from a 6-word prompt to a fully designed, coded, and extensible Parking Lot system — applying one step at a time.
Common Mistakes When Approaching LLD Problems
Mistake 1: Coding First, Designing Never
❌ Wrong: "Design a Parking Lot? Let me create a ParkingLot class with a 2D array of spots..." — and 15 minutes later, you have a monolithic class with no patterns, no UML, and no clear structure.
✅ Right: Spend the first 20 minutes on Steps 1-3. The code writes itself when the design is solid.
Mistake 2: Over-Engineering the Scope
❌ Wrong: "I'll add a reservation system, a mobile app, real-time GPS navigation to the spot, dynamic pricing based on demand, electric vehicle charging stations, and a loyalty program."
✅ Right: Start with the core: park a vehicle, unpark a vehicle, calculate the fee. Mention advanced features as future extensions, but don't try to design everything.
Mistake 3: Not Asking Questions
❌ Wrong: Silently assuming the parking lot is a single floor with only car spots.
✅ Right: "Is this a multi-story parking lot? What vehicle types do we need to support? Is pricing flat-rate or hourly?" Questions demonstrate engineering maturity.
Mistake 4: Drawing But Not Explaining
❌ Wrong: Silently sketching a class diagram with 12 boxes and arrows, then looking up expectantly.
✅ Right: Narrate your design decisions as you draw: "I'm separating ParkingSpot from VehicleType because spot size and vehicle size are independent — a compact spot can only hold a motorcycle or a car, but the vehicle itself doesn't care what spot type it's in."
Mistake 5: Ignoring Time Management
❌ Wrong: Spending 25 minutes on requirements and UML, leaving only 15 minutes for code — not enough to show implementation depth.
✅ Right: Watch the clock. 5-5-10-20-5 is the target split. Adjust based on interviewer signals.
How This Section Connects to the Rest of the Course
This framework is the culmination of everything you've learned so far — it pulls together skills from every prior section:
| Framework Step | Course Sections Used |
|---|---|
| Step 1: Clarify Requirements | S8 (Domain Modeling) — extracting entities from requirements |
| Step 2: Identify Objects | S3-S4 (OOP Fundamentals) — classes, relationships, inheritance hierarchies |
| Step 3: Draw UML | S5 (UML Diagrams) — class, use case, sequence diagrams |
| Step 4: Implement | S6-S7 (SOLID & Beyond), S10-S12 (Design Patterns), S13 (DI), S14-S15 (Concurrency) |
After completing this section, you'll be ready for the Design Problems course — where you'll apply this exact framework to 20+ real problems including Elevator System, Chess, Uber, Vending Machine, and more.
The pattern cheat sheets in S53 will help you quickly recall which pattern fits which scenario during Step 4.
Key Takeaways
- LLD interviews test process, not just knowledge — having a repeatable framework prevents freezing under pressure
- The 4-Step Framework: (1) Clarify Requirements, (2) Identify Objects, (3) Draw UML, (4) Implement with Patterns
- Time allocation for a 45-minute interview: 5 min requirements, 5 min objects, 10 min UML, 20 min code, 5 min review
- The most common mistake is coding first — invest 20 minutes in design before writing a single line of code
- Questions are expected in Step 1 — not asking them is a red flag
- This framework integrates skills from the entire course: OOP (S3-S4), UML (S5), SOLID (S6-S7), Domain Modeling (S8), Patterns (S10-S12), and Concurrency (S14-S15)
- We'll apply every step to a Parking Lot system across the next four tutorials