Low-Level Design (LLD) Interviews: A Step-by-Step Approach
Low-level design (LLD) interviews, also called object-oriented design or machine-coding rounds, ask you to turn a fuzzy problem ("design a parking lot") into classes, interfaces and working logic. System design asks which boxes; LLD asks what's inside one box.
Interviewers look for the same things every time: clear entities, small interfaces, sensible use of patterns, and code that would survive the next requirement. Here's an approach that produces all four.
Step 1: Clarify the scope (3–5 minutes)
LLD problems are deliberately vague. Pin down the behaviours you'll actually build.
For a parking lot:
- Vehicle types? (Motorcycle, car, truck.)
- Spot sizes, and can a small vehicle use a bigger spot?
- One entrance or several? (Several means concurrent allocation.)
- Pricing: flat, hourly, by vehicle type?
- Out of scope: payments integration, reservations, the UI.
Write the agreed list down. It becomes your acceptance test.
Step 2: Find the entities
Underline the nouns in your requirements and keep the ones that have state or behaviour:
| Entity | Holds | Does |
|---|---|---|
ParkingLot | floors, entry and exit gates | finds a spot, issues tickets |
Floor | spots | reports free spots by size |
Spot | size, current vehicle | park, vacate |
Vehicle | plate, size | — |
Ticket | vehicle, spot, entry time | — |
PricingStrategy | rates | computes the fee |
Trap: a class for every noun. "Gate" may just be a method call; "Owner" may not exist at all in your scope.
Step 3: Define the interfaces before the internals
Write the public methods first. They are what the interviewer reads.
interface SpotAllocator {
Optional<Spot> allocate(VehicleSize size); // empty if the lot is full
void release(Spot spot);
}
interface PricingStrategy {
Money fee(Ticket ticket, Instant exitTime);
}
Good interfaces are small and named after what callers need, not after how you implement them.
Step 4: Use patterns where they earn their place
Patterns are tools for change. Use one when you can name the change it absorbs:
- Strategy for pricing: hourly, flat-rate and weekend pricing swap without touching
ParkingLot. - Strategy or a policy object for allocation: "nearest to entrance" versus "fill lowest floor first".
- Factory when creating the right
VehicleorSpotsubtype from input. - Observer if a display board must update whenever spots change.
- State for objects with a real lifecycle, such as an OTP (created → sent → verified or expired).
Trap: naming patterns to impress. "I used a Singleton for the lot" invites the question "why, and how do you test it?"
Step 5: Write the core logic
Implement the happy path for the main use case end to end: vehicle arrives, gets a spot, gets a ticket, leaves, pays. Keep methods short and the data structures explicit:
- Free spots per size as a set or queue, so allocation is O(1) instead of scanning every spot.
- A map from ticket ID to ticket for lookups at exit.
Step 6: Handle concurrency and edge cases
This is where many candidates stop too early. With several entrances, two cars can be given the same spot.
- Make
allocateatomic: a lock per floor or per size bucket, or a concurrent queue whose poll is atomic. - Say what happens when the lot is full, when a ticket is lost, and when a car leaves without a valid ticket.
- Clock changes and partial hours: decide and state the rounding rule.
Step 7: Extend on request
Interviewers often add a requirement at the end ("add electric charging spots", "add monthly passes"). If your design is right, this is a new subclass or a new strategy, not an edit to five classes. Say that out loud. It is the point of the exercise.
What interviewers mark you down for
- Starting to code before agreeing on scope.
- God classes:
ParkingLotdoing allocation, pricing, payments and printing. - Public fields and no encapsulation.
- No thought about concurrency when the problem clearly has multiple actors.
- Patterns with no reason behind them.
Practise one step at a time. Prepd's LLD track splits each problem into steps (for example: model the entities, then apply the right pattern) and gives written feedback on each. The first three drills below are free, no sign-up needed.