The Low Level Design (LLD) interview round is one of the most misunderstood rounds in software engineering interviews. Unlike DSA rounds where you're solving algorithmic puzzles, LLD tests how you think about building real software systems. This guide gives you a step-by-step strategy to crack it at Amazon, Flipkart, Swiggy, and other top product companies.
What Is the LLD Round?
In an LLD round, you're given a real-world system to design — like Parking Lot, BookMyShow, or Splitwise — and asked to define classes, relationships, and design patterns. The interviewer is evaluating:
- Object-oriented thinking (entities, relationships, inheritance vs composition)
- SOLID principles application
- Design pattern knowledge (Strategy, Observer, Factory, State, etc.)
- Ability to handle requirements changes ("what if we add surge pricing?")
- Code quality — clean, readable, maintainable
The 5-Step Framework
Follow this framework in every LLD interview:
Step 1: Clarify Requirements (5 minutes)
Never start designing before asking questions. Ask about:
- Scale — how many users, how many requests/sec?
- Edge cases — what happens when capacity is full?
- Extensibility — what features might be added later?
- Constraints — any specific tech requirements?
This shows maturity and prevents you from designing the wrong thing.
Step 2: Identify Core Entities (5 minutes)
List the nouns from your requirements — these become your classes. For a Ride Sharing app: Rider, Driver, Trip, Vehicle, Location, Fare. Don't over-engineer — start with the minimum set.
Step 3: Define Relationships (5 minutes)
For each entity pair, decide the relationship:
- Has-a (composition): Trip has a Rider, Driver, Location
- Is-a (inheritance): Bike, Car, Truck extend Vehicle
- Uses (dependency): TripService uses FareCalculator
Prefer composition over inheritance — this is what interviewers want to see.
Step 4: Apply Design Patterns (10 minutes)
Identify which patterns fit naturally — don't force them. The most common patterns in LLD interviews:
- Strategy — when behavior varies by type (pricing, payment methods, algorithms)
- Observer — when multiple objects need to react to state changes (notifications, real-time updates)
- State — when an object has multiple states with different behaviors (driver states, booking states)
- Factory — when object creation logic is complex or needs to be centralized
- Singleton — when exactly one instance is needed (Logger, Config)
- Decorator — when you need to add behavior dynamically (surge pricing on base fare)
Step 5: Write Clean Code (20 minutes)
Write code that is readable and communicates intent. Use meaningful names, keep methods small, and always implement at least 2-3 core classes fully rather than 10 classes as stubs.
SOLID Principles Cheatsheet for LLD
- SRP: Each class does one thing. ParkingLot manages floors, not pricing.
- OCP: Add new vehicle types without modifying existing classes. Use abstract Vehicle.
- LSP: Any subclass of Vehicle should work wherever Vehicle is expected.
- ISP: Don't force a class to implement methods it doesn't need. Split large interfaces.
- DIP: Depend on abstractions. Trip depends on FareStrategy interface, not HourlyFare directly.
The 3 Things That Differentiate Top Candidates
1. They think about extensibility
When you use Strategy pattern for pricing, you're implicitly saying "this will change." Interviewers love when candidates proactively mention: "I'm using Strategy here so we can add surge pricing or monthly passes later without touching this class."
2. They handle edge cases
What happens when the parking lot is full? When a driver rejects all nearby requests? When two users book the same seat simultaneously? Mentioning these and having a clean answer separates strong candidates.
3. They write actual code, not just diagrams
Many candidates draw boxes and arrows but never write a line of code. Interviewers at top companies want to see working class definitions, method signatures, and at least one complete flow end-to-end.
Common Mistakes That Fail Candidates
- Starting to code without clarifying requirements
- Creating god classes (one class that does everything)
- Using if-else chains instead of polymorphism
- Ignoring thread safety in systems that clearly need it
- Over-engineering (adding microservices, databases) when the question is about OOP design
- Not knowing at least 5 design patterns by name and when to use them
30-Day LLD Preparation Plan
- Week 1: Master OOP fundamentals — encapsulation, inheritance, polymorphism, abstraction
- Week 2: Study SOLID principles with examples. Write violations and fixes.
- Week 3: Learn 8 core design patterns: Strategy, Observer, Factory, State, Command, Decorator, Singleton, Template Method
- Week 4: Practice 10 LLD problems end-to-end with full code. Get AI feedback on your solutions.
The Fastest Way to Improve
Reading about LLD is not enough. You need to actually write code and get feedback. The biggest gap between candidates who pass and those who don't is deliberate practice with real evaluation — not just watching YouTube videos.