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:

EntityHoldsDoes
ParkingLotfloors, entry and exit gatesfinds a spot, issues tickets
Floorspotsreports free spots by size
Spotsize, current vehiclepark, vacate
Vehicleplate, size—
Ticketvehicle, spot, entry time—
PricingStrategyratescomputes 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 Vehicle or Spot subtype 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 allocate atomic: 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

  1. Starting to code before agreeing on scope.
  2. God classes: ParkingLot doing allocation, pricing, payments and printing.
  3. Public fields and no encapsulation.
  4. No thought about concurrency when the problem clearly has multiple actors.
  5. 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.

Practise it