← Back to Design & Development
Complete Interview Guide

Low-Level Design
Interview Roadmap

A structured approach to cracking LLD rounds — from first principles to mock interviews.

Phase 1

The 7-Step Approach (Use This in Every Interview)

Follow this framework for any LLD question. Interviewers evaluate your thought process, not just the final answer.

Clarify Requirements (2–3 min)

Ask questions to narrow scope. Identify the core use cases (pick 3–5 most important ones). Clarify what's in scope vs. out of scope. This shows maturity — jumping straight to code is a red flag.

Q: "Design a parking lot system" You ask: • How many floors? Single or multi-level? • What vehicle types? (bike, car, truck) • Do we need payment processing? • Real-time availability display needed? • Is there a reservation system? Scope down: "Let's focus on vehicle parking/unparking, spot assignment, and fee calculation."

Identify Core Entities & Their Attributes (3–4 min)

List the nouns from your requirements — these become your classes. Identify what data each entity holds. Think about relationships: has-a, is-a, uses-a.

Entities for Parking Lot: ───────────────────────────────── ParkingLot → name, floors[], entry/exitGates[] ParkingFloor → floorNumber, spots[] ParkingSpot → spotId, spotType, isOccupied, vehicle Vehicle → licensePlate, vehicleType Ticket → ticketId, entryTime, vehicle, spot Payment → amount, paymentMethod, timestamp

Define Relationships & Class Diagram (4–5 min)

Draw a rough class diagram on the whiteboard. Show inheritance (Vehicle → Car, Bike), composition (ParkingLot has ParkingFloors), and associations. Use enums for fixed types.

ParkingLot ├── List<ParkingFloor> (composition) └── List<Gate> ParkingFloor └── List<ParkingSpot> (composition) ParkingSpot └── Vehicle (association) Vehicle (abstract) ├── Car (inheritance) ├── Bike └── Truck VehicleType → ENUM {CAR, BIKE, TRUCK} SpotType → ENUM {COMPACT, REGULAR, LARGE} PaymentMethod → ENUM {CASH, CARD, UPI}

Define Core APIs / Interfaces (3–4 min)

Write the method signatures for key operations. Think about what each entity can DO — these become your methods. Start with interfaces for flexibility.

interface ParkingStrategy { ParkingSpot findSpot(VehicleType type); } interface FeeStrategy { double calculateFee(Ticket ticket); } class ParkingLotService { Ticket parkVehicle(Vehicle v); Payment unparkVehicle(Ticket t); int getAvailableSpots(VehicleType type); }

Apply Design Patterns (3–4 min)

This is where you shine. Identify which patterns fit naturally — don't force them. Explain WHY you're using each pattern.

Strategy Pattern → ParkingStrategy • NearestToEntryStrategy • NearestToElevatorStrategy (Easily swap parking algorithms) Factory Pattern → VehicleFactory • Creates Car/Bike/Truck based on type (Decouples creation from usage) Singleton Pattern → ParkingLotService (Only one parking lot instance) Observer Pattern → SpotAvailabilityNotifier (Notify display boards when spots change)

Write Key Classes with Code (8–10 min)

Write the most critical 3–4 classes with actual code. You don't need to code everything — focus on the classes that demonstrate your design decisions.

public class ParkingLotService { private static ParkingLotService instance; private List<ParkingFloor> floors; private ParkingStrategy strategy; private FeeStrategy feeStrategy; public Ticket parkVehicle(Vehicle vehicle) { ParkingSpot spot = strategy.findSpot( vehicle.getType() ); if (spot == null) throw new ParkingFullException(); spot.assignVehicle(vehicle); return new Ticket(vehicle, spot, LocalDateTime.now()); } public Payment unparkVehicle(Ticket ticket) { double fee = feeStrategy .calculateFee(ticket); ticket.getSpot().removeVehicle(); return new Payment(fee, PaymentMethod.CASH); } }

Discuss Extensibility & Trade-offs (2–3 min)

Talk about how your design handles future requirements. Mention concurrency, thread-safety, and edge cases. This is the finishing touch that separates good from great.

Extensibility: • "Adding a new vehicle type (e.g., EV) only needs a new subclass — no existing code changes (OCP)" • "Swapping fee strategy (hourly → per-minute) is just injecting a new FeeStrategy implementation" Concurrency: • "ParkingSpot.assignVehicle() should be synchronized to prevent two cars getting the same spot" • "Could use ConcurrentHashMap for spot lookup" Edge cases: • What if the lot is full? • What if a ticket is lost? • What about overnight parking fee calculation?
Phase 2

Design Patterns You Must Know

These are the patterns that come up most frequently. Know when and why to use each one.

Strategy
Swap algorithms at runtime — pricing, sorting, routing, authentication methods
Very High
Observer
Event notification — stock price alerts, UI updates, notification systems
Very High
Factory / Abstract Factory
Object creation without exposing logic — vehicle types, document parsers
Very High
Singleton
Single instance — DB connection pool, logger, configuration manager
Very High
Decorator
Add behavior dynamically — pizza toppings, I/O streams, middleware
Medium
Chain of Responsibility
Pass request along a chain — log levels, vending machine, ATM dispenser
Medium
State
Object behavior changes with state — vending machine, elevator, order status
Medium
Builder
Step-by-step object construction — complex configs, query builders
Medium
Command
Encapsulate actions — undo/redo, task queues, remote controls
Medium
Adapter
Bridge incompatible interfaces — third-party integrations, legacy wrappers
Low-Medium

Golden Rule for Interviews

Don't memorize patterns — understand the PROBLEM each pattern solves. When an interviewer asks "Why Strategy here?", your answer should be: "Because we need to swap pricing algorithms without modifying existing code, satisfying the Open-Closed Principle."

Phase 3

SOLID Principles — Use Them, Don't Just Recite Them

Interviewers don't ask you to define SOLID. They watch whether your design follows it.

S Single Responsibility

Each class does ONE thing. ParkingSpot doesn't calculate fees. Ticket doesn't manage payment. If you can't describe what a class does in one sentence without using "and", split it.

O Open-Closed Principle

Open for extension, closed for modification. This is WHY you use Strategy, Factory, and Observer. Adding a new vehicle type shouldn't require editing ParkingLotService — just add a new class.

L Liskov Substitution

Subtypes must be substitutable for their base types. If your ElectricCar extends Car, it should work anywhere Car is expected. If it needs special charging logic that breaks the contract, reconsider your hierarchy.

I Interface Segregation

Don't force classes to implement methods they don't need. Instead of one giant VehicleService interface, split into Parkable, Billable, Reservable — each class implements only what's relevant.

D Dependency Inversion

Depend on abstractions, not concretions. ParkingLotService depends on ParkingStrategy (interface), not NearestSpotStrategy (concrete class). This is why your code is testable and flexible.

Phase 4

Must-Practice LLD Problems

Start with easy ones and work your way up. Solve at least 10–12 before your interview.

Parking LotStarter
Tic-Tac-ToeStarter
Library MgmtStarter
Vending MachineStarter
ATM SystemStarter
Snake & LadderMedium
Elevator SystemMedium
BookMyShowMedium
SplitwiseMedium
Chess GameMedium
Hotel BookingMedium
Food DeliveryHard
Ride SharingHard
Stock ExchangeHard
Social Media FeedHard

How to Practice Each Problem

Set a 45-minute timer. Follow the 7-step approach above. Write actual code, not pseudocode. After you're done, compare with 2–3 online solutions and note what you missed. Track which patterns came up in each problem.

Phase 5

4-Week Study Plan

A realistic timeline if you're preparing alongside work or college.

Week 1
Foundations
OOP concepts, SOLID principles, UML basics, 2 easy problems
Week 2
Patterns
Learn top 6 patterns with code, solve 3 easy + 1 medium
Week 3
Practice
Solve 4–5 medium problems, time yourself, review solutions
Week 4
Mock + Polish
2 hard problems, mock interviews with a friend, refine your approach
Final Tips

Interview Day: Do's and Don'ts

✓ Do This

  • Clarify requirements before designing
  • Think out loud — narrate your thought process
  • Start with interfaces, then implement
  • Use meaningful class/method names
  • Draw a quick class diagram first
  • Mention trade-offs of your decisions
  • Handle edge cases and exceptions
  • Show awareness of concurrency concerns
  • Keep classes small and focused
  • Ask for feedback mid-way: "Does this direction look good?"

✗ Avoid This

  • Jumping straight to code without planning
  • Using design patterns just to show off
  • Creating god classes that do everything
  • Ignoring the interviewer's hints or redirections
  • Over-engineering with unnecessary abstractions
  • Using generic names like Manager, Helper, Utils
  • Hardcoding values instead of using enums/configs
  • Spending too long on one part (watch your time)
  • Forgetting access modifiers (everything public)
  • Arguing when the interviewer suggests a change
Resources

Recommended Learning Path

📖 Books

  • Head First Design Patterns (beginner-friendly)
  • Clean Code by Robert C. Martin
  • Design Patterns (Gang of Four) — use as reference

💻 Practice Platforms

  • Workat.tech — LLD problem set with solutions
  • GitHub — search "awesome low level design"
  • LeetCode Discuss — LLD tagged questions

🎥 YouTube Channels

  • Concept && Coding (Hindi + English)
  • Sudocode — clean LLD walkthroughs
  • Tech Dummies — pattern explanations

🧠 Key Mindset

  • LLD ≠ memorizing patterns
  • LLD = breaking problems into clean, extensible objects
  • Practice writing code, not just reading solutions