Low Level Design Interview Questions
A low level design round hands you something familiar — a parking lot, an elevator, a vending machine — and asks you to model it in clean, extensible classes in about forty minutes. It is not an algorithm round; there is rarely a clever trick. It is an object-oriented design round, judged on how you turn a vague prompt into entities, responsibilities and interfaces, how well your design absorbs change, and whether you can defend each boundary when the interviewer pushes.
This guide gives you both halves of low level design interview preparation: the twenty problems that come up most often, organised by difficulty, and a repeatable five-step method that works on any of them — including the one you have not seen. It also covers the design patterns that recur, the follow-ups that decide the round, and why the only way to get good at LLD is to type and defend a design out loud.
What a low level design interview tests
The LLD round tests object-oriented design: can you identify the right classes, give each a single clear responsibility, define clean interfaces between them, and apply the SOLID principles and the appropriate design patterns — then handle the concurrency edge cases the domain throws up? Unlike the high-level design round, you are not sketching distributed systems on a shared canvas; LLD answers are typed out as class skeletons and method signatures. The signal the interviewer is really grading is extensibility: a design that absorbs a new vehicle type or payment method without rewriting existing classes is what separates a senior answer from a junior one.
A five-step method for any LLD prompt
The same sequence turns any prompt into a defensible design inside the time limit.
-
Clarify requirements (≈5 min). Cover four areas: the core actions, how errors are handled, the boundaries of the system, and whether you need to plan for extensions. Turn the vague prompt into a concrete spec. For machine-like systems, ask the senior question up front — "are we building a simulation where I control time with a
step()function, or the real control software?" (it is almost always a simulation). Knowing what to exclude — weight sensors, hardware — saves the fifteen minutes you do not have. - Model the entities as classes (≈10–15 min). The nouns in the spec become classes; give each one responsibility. Every method you add should map to a concrete need in the prompt.
- Map the relationships. Composition, aggregation and inheritance between the classes, and enums for fixed sets of values.
- Define the interfaces and methods. The public API each class exposes to the rest of the system.
- Apply SOLID, patterns and concurrency, then extend. Reach for a design pattern only where it genuinely fits, handle the concurrency race if the domain has one, and finish by showing how the design would extend without restructuring.
Here is the first slice of that for a parking lot — entities, an enum, and a Strategy interface for pricing:
enum VehicleType { CAR, BIKE, TRUCK }
class ParkingLot {
List<Floor> floors;
ParkingTicket park(Vehicle v) { /* find a spot, issue a ticket */ }
double unpark(ParkingTicket t) { /* free the spot, compute the fee */ }
}
interface PricingStrategy { double price(ParkingTicket t); } // swappable pricing
On a live round the interviewer digs into the edges: "What happens to a held slot when the reservation expires mid-pickup?" A clean class diagram does not answer that — reasoning about the state transition and the lock out loud does.
The top 20 LLD problems
Prepare across the difficulty range, but if you do only one, do the parking lot — it is the single most common LLD prompt and the template for the rest.
| Difficulty | Problems |
|---|---|
| Warm-up | Parking Lot, Vending Machine, Tic-Tac-Toe, Snake Game |
| Medium | Elevator System, ATM, LRU Cache, Library Management, Rate Limiter, Car Rental, Meeting Scheduler, Logging Framework |
| Hard | Splitwise (expense sharing), Movie Ticket Booking, Chess, Online Shopping Cart, Food Delivery, Ride-Sharing |
The warm-ups teach the mechanics — entities, enums, a strategy or two. The hard ones add real complexity: Splitwise needs careful balance modelling, movie booking and ride-sharing need concurrency control so two users cannot grab the same seat or driver, and chess needs a clean rule engine. Once the parking lot is automatic, five or six more across the range cover most of what you will be asked.
The design patterns that keep coming up
A handful of patterns solve most LLD prompts. Know where each fits — and apply it in your code, because naming a pattern you never actually use is a well-known red flag.
| Pattern | Where it shows up |
|---|---|
| Strategy | Swappable algorithms — pricing, elevator dispatch, matching |
| Factory | Creating objects by type — vehicles, payments, notifications |
| Observer | Events and notifications — order status, subscriptions |
| State | Lifecycles — vending machine states, order/booking status |
| Singleton | A single manager or configuration object |
| Decorator | Adding behaviour without subclassing — add-ons, toppings |
Underneath the patterns sit the SOLID principles, and one shows up in almost every follow-up: Open/Closed. When the interviewer says "now add a new vehicle type" or "support a second payment method", they are checking whether your design extends without editing existing classes. If it does, you designed it well.
Low-level design
Amazon · Parking Lot · 60 min
Type out a parking-lot design and defend every class, out loud
The follow-ups that decide an LLD round
The initial class diagram rarely decides the round; the follow-ups do, and they are predictable:
- The concurrency race. "Two users book the last seat at the same moment — what prevents a double-booking?" Have an answer: a lock, an atomic reservation, optimistic concurrency with a version check.
- Extensibility. "Add a new vehicle type or payment method without touching existing classes." This is Open/Closed in disguise.
- Trade-offs. "Why immediate dispatch instead of a request queue?" Be ready to weigh both.
- "Why is this a separate class?" Justify each boundary in terms of responsibility and change.
Each maps to the four dimensions a scored round grades — problem solving (the class model and its extensibility), communication (justifying each boundary), technical execution (clean, compiling skeletons and the concurrency fix), and time management (a working design inside the window). Reading a solution teaches you the model; only saying it out loud under these follow-ups prepares you for them.
How to prepare for LLD interviews
- Do the parking lot cold. Entities, enums, a Strategy for pricing, a clean park/unpark flow — until it is automatic. It is the template for everything else.
- Add five or six across the range. Elevator and LRU cache for the mechanics; Splitwise and movie booking for concurrency and harder modelling.
- Drill the five-step method, not memorised solutions. The method is what carries you through a prompt you have not seen.
- Apply patterns only where they fit. Have Strategy, Factory, Observer, State and Singleton ready, and resist forcing them.
- Rehearse out loud. Type the skeleton while narrating why each class exists and how you would extend it.
Low-level design
Amazon · Movie Ticket Booking · 60 min
Handle the booking concurrency race under follow-ups, out loud
Frequently asked questions
What is a low level design interview?
It is an object-oriented design round where you model a concrete system — a parking lot, an elevator, a booking service — as classes with clear responsibilities, clean interfaces and the right design patterns, typically in thirty-five to forty-five minutes. Unlike the high-level system design round, it focuses on code-level structure rather than distributed architecture, and the answer is typed out as class skeletons and method signatures. The round is graded on clean modelling, extensibility and how you handle edge cases like concurrency.
What are the most common LLD interview questions?
The parking lot is the most common by a wide margin and the template for the rest. Other frequent ones include the elevator system, vending machine, ATM, LRU cache, rate limiter, library management and meeting scheduler at the medium level, and Splitwise, movie ticket booking, chess, online shopping cart, food delivery and ride-sharing at the harder end. Preparing the parking lot plus five or six others across the difficulty range covers the vast majority of what you will be asked.
How do I approach an LLD problem I've never seen?
Use a fixed method: clarify the requirements (core actions, error handling, boundaries, extensions), model the entities as classes with single responsibilities, map their relationships, define the interfaces and methods, then apply SOLID principles and design patterns and handle any concurrency. Finish by showing how the design extends without restructuring. Because the method is the same for every prompt, an unfamiliar problem becomes a matter of applying the steps rather than recalling a specific solution.
Which design patterns should I know for LLD?
Strategy (swappable algorithms like pricing or dispatch), Factory (creating objects by type), Observer (events and notifications), State (lifecycles such as a vending machine or an order), Singleton (a single manager or config), and Decorator (adding behaviour without subclassing) cover most prompts. More important than knowing them is applying them only where they genuinely fit — interviewers quickly spot a pattern named but not used. Underneath them, the SOLID principles, especially Open/Closed, drive the extensibility follow-ups.
Do I write real code in an LLD interview?
Usually yes — you type class skeletons, enums, interfaces and the key methods, and often implement the core logic (the elevator's movement, the booking's reservation). It does not need to be fully production-ready in forty minutes, but it should compile in spirit and show clean structure. Start with the simplest working version and offer to make it more sophisticated rather than over-engineering upfront, which signals judgement about scope.
How do I practise LLD out loud?
Typing a class diagram alone will not prepare you for "why is that a separate class?" or "what prevents a double-booking?". On Zynter, the low-level design track lets you type out entities, interfaces and state while a voice interviewer probes the edges — the concurrency race, the extensibility question — and gives you a debrief on problem solving, communication, technical execution and time management. It is a genuine LLD mock interview on demand, and the score is a practice signal, not a hiring decision.
Practise it on Zynter
A clean class diagram isn't the round. The round is defending every boundary out loud.
Pick a low-level design prompt, type out the entities and interfaces, and defend each class to a voice interviewer that keeps asking "why a separate class?" and "what happens when the reservation expires mid-pickup?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies (Sep 2026), including low-level design from parking lots to booking systems — about $8–$12 for a full 60-minute mock, and two free credits to start.
Practise a low-level design round →
Browse all interview tracks
Top comments (0)