How to Approach an LLD Round

Big idea

A low-level design (LLD) round asks you to turn a one-line prompt — "design a parking lot" — into classes, relationships, and working code for the core flows. Interviewers grade the process as much as the result: did you pin down scope, find the right entities, keep responsibilities clean, and leave room for the extensions they'll push on? A fixed method keeps you from freezing or over-building.

The problem it solves

Without a method, candidates either start typing a ParkingLot class immediately and paint themselves into a corner, or spend 30 minutes drawing a UML diagram of 25 classes and never write code that runs. Both fail the same way: the interviewer can't see good judgement.

Think of it like

An architect designing a house extension. First a conversation — how many bedrooms, what budget, is there a planning limit? Then a list of rooms, then a floor plan, then a walk-through ("you come in here, the kitchen's on the left"), then the build. And they leave the wall where a future conservatory could go.

The six steps

1. Requirements (5 min). Ask, then write down: actors, the 3–5 core use cases, and what's out of scope. Confirm numbers that change the design (one building or many? concurrency?).
2. Entities (5 min). Underline the nouns in your requirements: they're candidate classes. Verbs become methods. Drop nouns that are just attributes (a "colour" isn't a class).
3. Class diagram (10 min). Relationships (has-a, is-a), multiplicities, and who owns which rule. Put an interface wherever variation is likely (pricing, strategies, notification channels).
4. Key flows (5 min). A sequence diagram or a numbered walk-through of the 1–2 most important use cases. This catches missing responsibilities before you code.
5. Code the core (20 min). Runnable code for the main flow, with a tiny demo. Enums for fixed sets, small classes, no frameworks. Name things clearly.
6. Extensions and trade-offs (5 min). Show how a new requirement plugs in (new vehicle type, new pricing) and what you'd do about concurrency, persistence, and scale.

In code: nouns and verbs to a skeleton

# Requirements: customers earn 1 stamp per drink; 9 stamps = a free drink;
# stamps expire after a year (out of scope today, noted as an extension).
# Nouns: customer, card, stamp, drink, reward.  Verbs: buy, earn, redeem.
from dataclasses import dataclass, field

@dataclass
class LoyaltyCard:                      # owns the stamp rule
    stamps: int = 0
    FREE_AT = 9
    def earn(self):
        self.stamps += 1
    def can_redeem(self):
        return self.stamps >= self.FREE_AT
    def redeem(self):
        if not self.can_redeem():
            raise ValueError("not enough stamps")
        self.stamps -= self.FREE_AT

@dataclass
class Customer:
    name: str
    card: LoyaltyCard = field(default_factory=LoyaltyCard)

class Till:                             # orchestrates a purchase
    def buy(self, customer, drink, use_reward=False):
        if use_reward:
            customer.card.redeem()
            return f"{customer.name}: free {drink}"
        customer.card.earn()
        return f"{customer.name}: {drink}, stamps={customer.card.stamps}"

till, ana = Till(), Customer("Ana")
for _ in range(9):
    last = till.buy(ana, "flat white")
print(last)
print(till.buy(ana, "flat white", use_reward=ana.card.can_redeem()))
print("stamps left:", ana.card.stamps)

output
Ana: flat white, stamps=9
Ana: free flat white
stamps left: 0

Even this toy shows the method: rules sit with the data they guard (LoyaltyCard), orchestration is separate (Till), and the extension (expiry) is named up front.

Watch it

What interviewers look for

• Clear responsibilities — each class has one job (Single Responsibility); rules live with data (Encapsulation).
• Extension points where change is likely — a PricingStrategy, not a hard-coded rate (Open/Closed, Strategy).
• Patterns by need, not by name-dropping — State for lifecycles, Observer for notifications, Factory for creation.
• Concurrency awareness — two people booking the same seat; two cars taking the same spot.
• Code that runs, even if small.

The case studies

Parking lot · Elevator · Vending machine · LRU cache · Rate limiter · Library management · Chess · Expense splitter · Movie ticket booking · Logging framework

Key terms

• Low-level design (LLD) — Designing the classes, interfaces, and interactions inside one component or service.
• Use case — One thing an actor wants to do with the system, such as "park a car".
• Entity — A domain concept that becomes a class, usually found among the requirement's nouns.
• Extension point — An interface or hook placed where requirements are likely to change.