The Low-Level Design Interview: The Round Nobody Tells You to Prep

You drilled system design for a month. URL shortener, news feed, rate limiter - you can sketch the boxes in your sleep.

Then the interviewer says: "Design a parking lot. I want to see your classes."

And you realize you have no idea where to start.

This is the low-level design round - LLD, sometimes called object-oriented design (OOD). It sits between coding and system design, and it's the round candidates prep for the least. Which is exactly why prepping for it is one of the highest-leverage things you can do.

What LLD Actually Tests

High-level system design asks: how do the services talk to each other across a network? Low-level design asks: how would you structure the code inside one of those services?

The interviewer wants to see whether you can:

• Translate a vague requirement into a clean set of classes and responsibilities
• Pick the right relationships between objects (composition over inheritance, usually)
• Apply design patterns where they fit - and resist forcing them where they don't
• Write code that's extensible without being over-engineered

It's not about memorizing the Gang of Four. It's about modeling a small domain cleanly and explaining your tradeoffs out loud.

The 5-Step Framework

Run every LLD problem through the same five steps. The structure is the whole game - it stops you from diving into code before you understand the problem.

1. Clarify requirements and scope.
Ask what's in and what's out. For a parking lot: do we handle multiple vehicle sizes? Multiple floors? Payment? Reservations? Pin the scope before you write a single class. Most candidates skip this and design the wrong thing beautifully.

2. Identify the core entities.
Pull the nouns out of the problem. Parking lot, level, spot, vehicle, ticket, payment. These become your classes. Don't worry about getting it perfect - you'll refine.

3. Define relationships and responsibilities.
A ParkingLot has Levels. A Level has ParkingSpots. A Vehicle is assigned a Spot via a Ticket. Decide what each class owns and what it delegates. This is where you say "I'll favor composition here" out loud.

4. Sketch the interfaces and key methods.
What's the public API? parkVehicle(vehicle) -> Ticket, unpark(ticket) -> Fee. Define the signatures before bodies. Identify where polymorphism helps - different Vehicle subtypes (or a size enum) mapping to different SpotTypes.

5. Apply patterns and handle edge cases.
Now, and only now, reach for patterns. A Strategy for pricing. A Factory for creating vehicles. A Singleton for the lot itself (mention the tradeoffs - singletons are often a smell). Then walk the edges: lot full, invalid ticket, concurrent parking.

The Composition vs Inheritance Moment

Almost every LLD interview has a fork where you choose between inheritance and composition. The interviewer is watching for it.

The classic trap: modeling vehicle types as a deep inheritance tree.

"I'll have a Vehicle base class, then Car extends Vehicle, Truck extends Vehicle, Motorcycle extends Vehicle, and ElectricCar extends Car, and LuxuryElectricCar extends ElectricCar..."

Stop. You've built a brittle hierarchy. What happens when you need an electric truck? Or a luxury motorcycle?

The cleaner answer: keep Vehicle simple, model variable behavior with composition or enums. A vehicle has a size, has a fuelType, has a pricingStrategy. You compose behavior instead of inheriting it. Saying this explicitly - "I'm avoiding a deep inheritance tree because requirements like 'electric truck' would force diamond problems" - is the single line that separates a senior answer from a junior one.

The Questions You'll Actually Get

LLD problems are a small, well-known set. Prep these and you've covered most of the surface area:

• Parking lot - the canonical one; entities, spot allocation, pricing
• Elevator system - state machines, scheduling, request queues
• Vending machine - the State pattern's home turf
• Library management - CRUD-heavy, relationships, search
• Tic-tac-toe / chess - board state, move validation, win detection
• Splitwise / expense sharing - graph of balances, settlement
• Rate limiter - token bucket vs sliding window as classes
• Notification service - Strategy + Observer for channels
• Logging framework - chain of responsibility for log levels
• Cache (LRU) - the bridge between LLD and a coding question

Notice how many map to a specific pattern. Vending machine is State. Notification is Strategy plus Observer. Logger is Chain of Responsibility. Half the prep is learning which pattern lives where.

How to Talk While You Design

LLD is a thinking-out-loud round even more than coding is. Narrate the decisions, not just the result:

• "I'll make SpotType an enum rather than subclasses because the behavior difference is just size and price."
• "I'm pulling pricing into a PricingStrategy interface so we can add weekend rates without touching ParkingLot."
• "I'll keep Ticket immutable after creation - it's a record of a transaction."

Each of these is a tradeoff stated as a tradeoff. That's the signal interviewers grade on. Silence while you write perfect code reads worse than messy code with sharp commentary.

Common Mistakes That Tank the Round

• Jumping straight to code. No clarifying questions, no entity list. You'll design something impressive and wrong.
• Pattern soup. Forcing five design patterns into a problem that needs one. Over-engineering is as bad as under-engineering.
• Ignoring extensibility. The interviewer almost always adds a requirement near the end ("now support monthly passes"). If your design needs a rewrite to absorb it, you lose points. If you add one class, you win.
• Forgetting it's still code. You'll often be asked to actually implement one method. Your parkVehicle should compile.

A 10-Day Prep Plan

You don't need a month for LLD. You need focused reps:

• Days 1-2: Learn the 6-8 patterns that show up most - Strategy, Factory, State, Observer, Singleton, Decorator. Know the problem each solves, not just the diagram.
• Days 3-7: One problem a day from the list above. Run the 5-step framework end to end. Write real code for one method each.
• Days 8-9: Do two timed mock LLD sessions, out loud, ideally with a peer or an AI interviewer. The talking is the part you can't fake.
• Day 10: Review your weakest two problems. Re-sketch from memory.

The reason LLD feels scary is that it's the round between two rounds you've already drilled. It rewards structure, and structure is learnable in days, not months. Run the five steps every time and the parking lot stops being a trap.

Want to practice LLD and full system design with feedback that catches the composition-vs-inheritance moment before a real interviewer does? gitGood's system design and AI mock interview tracks are built for exactly this - drill the patterns, get graded on the tradeoffs, walk in warm.