Low-Level Design Interview Guide 2026 (with Java)

Plenty of candidates who can solve a LeetCode hard in 25 minutes still stumble when the interviewer says, “Design a parking lot. Show me the classes.” That is the low-level design (LLD) interview, also called the object-oriented design or machine coding round. In 2026 it shows up at Amazon, Microsoft, Uber, Flipkart, Atlassian, most fintechs, and a growing number of startups that want proof you can write code a team can maintain.

This guide explains what interviewers actually score, gives you a repeatable 6-step framework, walks through a Java example, and ends with a two-week practice plan.

What Is a Low-Level Design Interview?

A high-level system design round asks how services, databases, caches, and queues fit together. A low-level design round zooms in on a single component and asks how you would structure the code: classes, interfaces, relationships, method signatures, and the design patterns that keep it extensible.

You will usually see one of two formats:

• Whiteboard / discussion LLD (45–60 min): You gather requirements, draw a class diagram, and write the core methods in pseudocode or a real language.
• Machine coding round (60–120 min): You write working, runnable code for a scoped problem (Splitwise, a rate limiter, a snake-and-ladder game), and then extend it when the interviewer adds a new requirement.

Commonly Asked LLD Problems in 2026

• Parking lot, elevator system, vending machine
• LRU / LFU cache with thread safety
• Rate limiter (token bucket, sliding window)
• Splitwise / expense sharing, BookMyShow-style ticket booking
• Logger framework, notification service, pub-sub queue
• Chess, tic-tac-toe, snake and ladder

What Interviewers Score in an LLD Round

The rubric is remarkably consistent across companies. Here is what the interviewer is writing down:

1. Requirement clarity: Did you scope the problem before drawing boxes?
2. Entity modeling: Are your classes the right nouns, with clear responsibilities?
3. SOLID principles: Especially Single Responsibility, Open/Closed, and Dependency Inversion.
4. Appropriate patterns: Strategy, Factory, Observer, State, Singleton, and Builder used where they solve a real problem, not sprinkled for decoration.
5. Extensibility: When a new requirement arrives, how much existing code do you have to touch?
6. Code quality: Naming, encapsulation, immutability, and error handling.
7. Concurrency awareness: For senior roles, can you spot race conditions and fix them?

A 6-Step Framework for Any LLD Question

Step 1: Clarify Requirements (5 minutes)

List functional requirements and explicitly mark what is out of scope. For a parking lot: multiple floors? Vehicle types? Pricing by hour or flat? Payment in scope? Writing these down prevents the classic failure of building features nobody asked for.

Step 2: Identify Core Entities

Extract nouns from the requirements: ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, PricingStrategy. Drop anything that is just a data attribute.

Step 3: Define Relationships

Decide composition vs. aggregation vs. inheritance. A ParkingLot has floors (composition). A Car is a Vehicle (inheritance). Favor composition when behavior varies; that is where patterns like Strategy come from.

Step 4: Define Interfaces and Key Methods

Write method signatures before bodies: Ticket park(Vehicle v), Receipt unpark(String ticketId). Interfaces make your design testable and signal to the interviewer that you think in contracts.

Step 5: Apply Design Patterns Where They Earn Their Place

Pricing that changes by vehicle type or time of day is a textbook Strategy. Spot allocation (nearest, cheapest, EV-first) is another Strategy. Display boards that update when spots change are an Observer. Name the pattern and explain the trade-off in one sentence.

Step 6: Handle Concurrency and Edge Cases

Two cars arriving at the same gate must not get the same spot. Mention locking granularity, atomic operations, or a concurrent queue of free spots. Then cover edge cases: lot full, invalid ticket, lost ticket.

Java Walkthrough: Parking Lot Core

Here is a compact, interview-sized skeleton that demonstrates Strategy for both allocation and pricing, plus thread-safe spot assignment.

public enum VehicleType { BIKE, CAR, TRUCK }

public interface SpotAllocationStrategy {
    Optional<ParkingSpot> findSpot(List<Floor> floors, VehicleType type);
}

public interface PricingStrategy {
    BigDecimal calculate(Ticket ticket, Instant exitTime);
}

public class ParkingSpot {
    private final String id;
    private final VehicleType type;
    private final AtomicBoolean occupied = new AtomicBoolean(false);

    public boolean tryOccupy() { return occupied.compareAndSet(false, true); }
    public void release()      { occupied.set(false); }
    // getters omitted
}

public class ParkingLot {
    private final List<Floor> floors;
    private final SpotAllocationStrategy allocator;
    private final PricingStrategy pricing;
    private final Map<String, Ticket> activeTickets = new ConcurrentHashMap<>();

    public ParkingLot(List<Floor> floors,
                      SpotAllocationStrategy allocator,
                      PricingStrategy pricing) {
        this.floors = List.copyOf(floors);
        this.allocator = allocator;
        this.pricing = pricing;
    }

    public Ticket park(Vehicle vehicle) {
        for (int attempt = 0; attempt < 3; attempt++) {
            ParkingSpot spot = allocator.findSpot(floors, vehicle.getType())
                .orElseThrow(() -> new ParkingFullException(vehicle.getType()));
            if (spot.tryOccupy()) {
                Ticket t = new Ticket(UUID.randomUUID().toString(), vehicle, spot, Instant.now());
                activeTickets.put(t.getId(), t);
                return t;
            }
        }
        throw new ParkingFullException(vehicle.getType());
    }

    public Receipt unpark(String ticketId) {
        Ticket t = Optional.ofNullable(activeTickets.remove(ticketId))
            .orElseThrow(() -> new InvalidTicketException(ticketId));
        t.getSpot().release();
        return new Receipt(t, pricing.calculate(t, Instant.now()));
    }
}

Why This Design Scores Well

• Open/Closed: Adding an EV-first allocator or weekend pricing means a new class, not an edit to ParkingLot.
• Dependency Inversion: ParkingLot depends on interfaces injected through the constructor, so it is trivial to unit test.
• Lock-free safety: compareAndSet ensures only one thread wins a spot; the retry loop handles the race gracefully.
• Immutability: List.copyOf and final fields prevent accidental mutation.

Common Mistakes That Sink LLD Candidates

• Jumping to code: Coding before agreeing on requirements almost always leads to a rewrite at minute 35.
• God classes: A single ParkingLotManager with 20 methods violates SRP and is the first thing interviewers flag.
• Pattern stuffing: Using Singleton, Factory, Visitor, and Decorator in one 45-minute answer signals memorization, not judgment.
• Inheritance overuse: Deep hierarchies like ElectricCompactCar extends CompactCar extends Car collapse under new requirements.
• Ignoring concurrency: For SDE-2 and above, not mentioning thread safety on shared state is a missed signal.
• Silent coding: Explain decisions as you go. The interviewer can only score reasoning they hear.

Handling the “New Requirement” Curveball

Almost every LLD interviewer adds a twist at the end: “Now support reservations,” or “Add a monthly pass.” This is the real test of your design. Respond in three moves: identify which existing abstraction absorbs the change, add a new class or strategy, and point out what did not have to change. If your answer requires editing five classes, say so honestly and propose the refactor. That self-awareness is scored positively.

Two-Week LLD Interview Practice Plan

Days 1–3: Foundations. Review SOLID with a small code example for each principle. Re-implement Strategy, Observer, Factory, State, and Builder from memory in Java.

Days 4–7: Classic problems. One problem per day, timed at 60 minutes: parking lot, LRU cache, vending machine (State pattern), and rate limiter.

Days 8–11: Machine coding. Build runnable versions of Splitwise, a logger framework, a snake-and-ladder game, and an in-memory pub-sub queue. Add unit tests for the core paths.

Days 12–14: Mock interviews. Do at least two timed mocks with a peer who adds a surprise requirement at minute 40. Review what you had to change and why.

Quick Checklist for Interview Day

• Write requirements and out-of-scope items before any class
• Draw the class diagram with relationships labeled
• Program to interfaces; inject dependencies through constructors
• Name each pattern and the problem it solves
• Call out thread safety on shared mutable state
• Cover at least three edge cases out loud
• Leave five minutes to discuss extensions and trade-offs

Start Preparing for Your LLD Interview Today

Low-level design rewards deliberate practice more than raw talent. Pick one problem from the list above, set a 60-minute timer, and design it end to end today, then ask a peer to throw a new requirement at you. Repeat that loop for two weeks and the LLD round will turn from your weakest into one of your strongest. For more structured interview preparation, explore Niraswa AI and keep building your skills one round at a time.