Skip to main content

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:

  1. Clarify Requirements & Define Scope — Understand what you're building before you design it
  2. Identify Core Objects and Relationships — Discover the entities in the system
  3. Draw UML Diagrams — Formalize the design visually
  4. 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:

  1. Ask the right questions before diving in (Step 1)
  2. Identify the right objects from the requirements (Step 2)
  3. Think visually about structure and interactions (Step 3)
  4. 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 ParkingLot class 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:

StepTimePurpose
Step 1: Clarify Requirements~5 minutesUnderstand scope, agree on constraints
Step 2: Identify Objects~5 minutesDiscover entities, attributes, relationships
Step 3: Draw UML~10 minutesClass diagram + one behavioral diagram
Step 4: Implement~20 minutesCode the core classes with patterns
Review & Discuss~5 minutesWalk 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.

The 4-Step LLD Interview Framework showing Step 1 Clarify Requirements, Step 2 Identify Objects, Step 3 Draw UML, Step 4 Implement with Patterns, with time allocations and key activities for each step
The 4-Step LLD Interview Framework showing Step 1 Clarify Requirements, Step 2 Identify Objects, Step 3 Draw UML, Step 4 Implement with Patterns, with time allocations and key activities for each step

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 StepCourse Sections Used
Step 1: Clarify RequirementsS8 (Domain Modeling) — extracting entities from requirements
Step 2: Identify ObjectsS3-S4 (OOP Fundamentals) — classes, relationships, inheritance hierarchies
Step 3: Draw UMLS5 (UML Diagrams) — class, use case, sequence diagrams
Step 4: ImplementS6-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