Why Good Engineers Still Fail the Low-Level Design Round

We see this pattern a lot in mock interview sessions tagged System Design on LastRound AI: a candidate nails the class hierarchy for a parking lot problem in under ten minutes, then goes quiet the moment the interviewer asks what happens when two cars try to claim the same spot at the same instant. The design wasn't wrong. Nobody had asked about concurrency until it was too late to fix cleanly. That's most of what a low-level design round is actually checking: not whether you can draw boxes, but whether your boxes survive contact with a follow-up question.

Low-level design interview questions get lumped in with system design prep, and then treated like a smaller, easier version of the same thing. It isn't. System design is about services talking to each other over a network. LLD is about what happens inside one of those services: the classes, the interfaces, who owns what data, and whether the whole thing can survive a requirement change without a rewrite.

What a low-level design round is actually testing

Strip away the whiteboard and an LLD interview is an object-oriented design exam with a story attached. The interviewer wants to see whether you can take a vague, real-world system (a parking garage, an elevator bank, a library) and turn it into classes with clear responsibilities, sane relationships, and enough flexibility to absorb the follow-up questions that are coming whether you like it or not.

High-level design and low-level design get asked back to back at plenty of companies, and they're testing different muscles. HLD wants to know if you understand load balancers, caching layers, database sharding, and how services fail gracefully across a network. LLD wants to know if you understand encapsulation, composition versus inheritance, and whether your class diagram would actually compile into something maintainable. Amazon runs these as two separate rounds at the SDE-2 level for exactly this reason, and its LLD prompts skew hard toward object-oriented design questions like a parking lot or a rate limiter, according to our own breakdown of the Amazon SDE-2 interview loop, the kind of loop our Auto-Apply tool can help you get more shots at landing in the first place.

The uncomfortable part: a candidate can be strong at system design and still stumble here, because LLD punishes hand-waving in a way HLD sometimes lets slide. "We'd add a cache" works fine in a system design round. "We'd handle that with some logic" does not work in an LLD round. The interviewer wants the class, the method signature, the interface, exactly the kind of on-the-spot detail LastRoundAI's AI Interview Copilot is designed to help you produce live, in the actual room.

How to run the room: a four-step approach that works on almost any prompt

Most classic LLD prompts (parking lot, elevator, library, rate limiter, vending machine, tic-tac-toe) fall into the same four-step shape. Memorizing the shape matters more than memorizing any single design, because the prompt itself is just a costume the same underlying skill wears each time.

1. Clarify requirements before you draw anything. Ask what's in scope and, just as importantly, what isn't. For a parking lot: does it need to handle payment? Multiple vehicle types? Multiple levels? A five-minute clarifying conversation up front saves you from designing a system for a problem the interviewer never asked about. Weak candidates start drawing boxes at second twelve. Strong ones spend two or three minutes asking questions first, even when it feels slow.

2. Pull the nouns out of the problem and turn them into classes. Parking lot, level, spot, vehicle, ticket. Elevator, floor, request, controller. This sounds almost too simple to say out loud, but it's the step people skip when they're nervous, and skipping it is how you end up with one giant ParkingLot class doing everything itself.

3. Define relationships, not just entities. Does a ParkingLot own its Levels (composition, the Levels can't exist without it) or just reference them (aggregation)? Should Vehicle be an interface that Car and Motorcycle implement, or a base class they extend? Get this wrong and every later question about extending the system gets harder than it needs to be.

4. Reach for SOLID and design patterns as tools, not as a checklist to recite. The five SOLID principles (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) trace back to Robert C. Martin's 2000 paper on software rot; the acronym was coined later, around 2004, by Michael Feathers, per the SOLID principles reference on Wikipedia. Interviewers rarely ask "what does the S in SOLID stand for." They ask "what happens if we add a new vehicle type," and SRP and OCP are the reason your answer is "I add a class" instead of "I rewrite three existing ones." Our SOLID principles breakdown covers each one with runnable code.

Design patterns work the same way. The original catalog is the 1994 Gang of Four book, Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma, Helm, Johnson, and Vlissides, which documented 23 patterns across three categories: creational, structural, and behavioral, according to its Wikipedia entry. In an interview, three patterns cover most of what comes up: Strategy (swap an algorithm, like pricing or scheduling, without touching the class that uses it), Observer (notify a set of dependents when state changes, like a waitlist), and Factory (centralize how related objects get created). If you catch yourself forcing a pattern in because you memorized it rather than because the problem needs it, stop. Interviewers notice pattern-shoehorning almost immediately, and it reads worse than not knowing the pattern at all. Our design patterns interview questions guide goes deeper on when each one actually earns its place.

Walking one all the way through: the parking lot problem

Parking lot is the most asked LLD prompt there is, partly because it has just enough real-world messiness (multiple vehicle sizes, multiple levels, payment, availability tracking) to force real design decisions without needing domain knowledge nobody has. Here's a class breakdown that would survive a 45-minute round.

Notice what's not in that table: nothing about the database, nothing about a REST endpoint, nothing about how the app talks to a payment gateway over the network. That's the HLD conversation, and a good LLD answer stays out of it unless the interviewer explicitly pulls it in.

The follow-ups are where the round is actually won or lost. "What if motorcycles can share a spot with a car?" tests whether ParkingSpot's occupancy model can hold more than one vehicle reference without a rewrite (Open-Closed Principle as a real constraint, not a trivia question). "What if pricing needs to change to surge pricing?" tests whether PaymentProcessor was cleanly separated in the first place. And the concurrency question from the opening, two cars claiming the same spot, tests whether you'll say "lock" or "atomic" before the interviewer has to drag it out of you. A ParkingSpot.reserve() method that isn't safe under concurrent calls is a real bug, not a nitpick.

Three more prompts you should be able to sketch cold

Parking lot gets the deep treatment because the pattern generalizes. These three show up almost as often, and each one leans on a slightly different part of the same toolkit.

Elevator system. Core classes: Elevator, ElevatorController (or Dispatcher), Request, Floor. The interesting decision isn't the classes, it's the scheduling algorithm the controller uses to pick which elevator answers which call (a direction-based SCAN or LOOK approach is the standard answer, and it's fine to just say so rather than inventing something novel on the spot). A Controller mediating between multiple Elevators and incoming Requests is close to the Mediator pattern, even if nobody says that word out loud. Expect a follow-up about a broken elevator or a fire-alarm override that has to preempt everything else in the queue.

Library system, or a BookMyShow-style seat/ticket booking system. Core classes: Catalog (books or shows), Member or User, and a Reservation or Booking object that sits in a hold state before it's confirmed. The concurrency problem from the parking lot shows up again here, almost word for word: two users trying to reserve the last copy of a book, or the same seat, at the same moment. That's not a coincidence. It's the same design problem (protecting a shared, limited resource from a race condition) wearing a different costume, and once you've solved it once you'll recognize it fast the second time. A State pattern on the Reservation object (held, confirmed, expired, cancelled) plus an Observer that notifies waitlisted members when a copy frees up is a clean answer here.

Rate limiter or a logging framework. These two get asked less often but deserve a mention: they're thinner on class design and heavier on algorithm choice, which trips people who over-invest in diagrams and under-invest in the mechanism. A rate limiter needs a RateLimiter interface, per-key bucket state, and a chosen algorithm (token bucket, sliding window, or leaky bucket); the design is secondary to defending the algorithm and explaining where bucket state lives across multiple servers. A logging framework needs a Logger, an Appender or Handler interface (console, file, network sink) so new destinations plug in without touching existing code, a LogLevel enum, and a Formatter. People reach for Singleton on the Logger by reflex. I'd rather hear a candidate explain why they're avoiding it than use it correctly without knowing why it's a debatable default.

Sample questions interviewers actually ask

What's the real difference between low-level design and system design?

System design covers how services communicate across a network (load balancing, databases, caching, message queues). Low-level design covers what happens inside a single service or module: the classes, their responsibilities, and how they relate to each other so the code stays maintainable as requirements change.

How do you decide between composition and inheritance for two related classes?

Use inheritance when a true "is-a" relationship holds and the subclass genuinely behaves like its parent everywhere the parent is used (violating this is what the Liskov Substitution Principle flags). Use composition when a class needs another class's behavior without wanting to be that class, which is most of the time in practice.

What does the Single Responsibility Principle mean in practice, not textbook language?

It means a class should have one reason to change. If editing your pricing logic also forces you to touch your ParkingSpot class, those two responsibilities got tangled together and should be split apart.

When would you use the Strategy pattern instead of a big if/else chain?

When the behavior needs to swap at runtime or grow over time without editing existing code, like a pricing rule or a spot-assignment rule. A long if/else chain violates the Open-Closed Principle every time you add a new case.

How would your parking lot design change to let a motorcycle share a spot with a car?

It depends on whether ParkingSpot tracks a single occupant or a capacity. A single vehicle reference from the start means a real change; a capacity field with room for smaller vehicles means it's closer to a config change. This follow-up reveals whether your original design was actually extensible or just looked that way.

What's the difference between the Observer pattern and just calling a callback function?

Observer formalizes a one-to-many relationship: a subject maintains a list of observers and notifies all of them on a state change, without knowing what any individual observer does with that notification. A single callback is a one-to-one relationship. Once you have more than one thing that needs to react to the same event, you're already describing Observer whether you name it or not.

Why might Singleton be a questionable default for a logger class?

It creates global, hidden state that's hard to mock in tests and hard to reconfigure per environment. It's not wrong in every case, but a candidate who defends the choice ("here's why global access is actually the right call for this specific case") comes across stronger than one who reaches for it out of habit.

How do you handle two users trying to reserve the same seat or spot at the same moment?

Usually a reservation that moves through an explicit hold-then-confirm state, backed by locking or an atomic check-and-set on the resource, rather than a plain read-then-write that leaves a window for two requests to both succeed. You rarely need to write the locking code itself, but you do need to name the race condition and say where it lives.

What would you change about your design if the interviewer added a new requirement halfway through?

Ideally, not much. That's the entire point of applying SOLID up front: a design where new vehicle types, new payment methods, or new elevator scheduling rules require adding a class rather than editing three existing ones is the signal the interviewer is actually looking for.

The one thing that actually separates hires here

Watching enough of these, my honest read is that most candidates don't fail LLD rounds because they don't know SOLID or the patterns. They fail because they design silently in their head and only narrate the final answer, so the interviewer scores the silence as a gap even when the underlying thinking was fine. I could be wrong about this; I don't have a controlled study, just a lot of sessions.

It's also the one round where saying your assumptions out loud is scoreable in a very literal sense on LastRound AI. Our Technical Interviews mock category is configurable by tech stack and covers system design and architecture depth specifically, and every answer gets scored on six dimensions: relevance, content, structure, specificity, clarity, and conciseness. Structure and specificity are the two that map almost exactly onto an LLD walkthrough. A candidate who narrates "I'm making ParkingSpot an abstract class because I expect subtypes to differ in capacity, not just size" scores higher on both than one who arrives at the identical class diagram in silence. If you want to practice that muscle with a live AI interviewer asking the follow-ups instead of just reading a class diagram off a page, that's what our mock interview practice is built for.

For the wider system design conversation this round sits next to, our system design interview questions post covers the concept side with sample answers. The pattern holds either way: the parking lot, the library, and the elevator are never really the question. What breaks when you push on them is.

How this list was built

Worth being straight about where these questions come from, because plenty of pages in this category are not. The set was compiled from a research pass across official documentation, vendor release notes, published engineering writing and public discussion of hiring processes, then cross-checked against the current version of each technology so nothing here describes behaviour that has since changed.

What that means in practice: these are the questions the material supports as reasonable and current for this role, not a transcript of any one company's loop. We have not sat in on your interview and we are not going to claim we have. Treat the list as well-sourced preparation rather than a leaked question bank, and expect your panel to phrase things their own way.

If you spot something out of date, tell us at contact@lastroundai.com and we will fix it.

Frequently asked questions

Is low-level design still worth learning in 2026?

For interview purposes the question is really whether the teams you are targeting use it, which is worth checking against their actual job postings rather than general popularity rankings. Where it is in use it tends to be deeply embedded and slow to replace.

Should I memorise low-level design syntax for the interview?

Rarely worth it. Most interviewers care that you know what to reach for and why, and will not fail you for forgetting an exact flag. Being confidently wrong about behaviour costs far more than admitting you would check the documentation.

What is the most common mistake in low-level design interviews?

Answering the question that was asked and stopping there. The strongest candidates add the trade-off or the failure mode without being prompted, which is what signals real use rather than revision.

How long does it take to prepare for a low-level design interview?

If you already work with low-level design day to day, a focused week on the areas you avoid in practice is usually enough. Coming in cold, expect three to four weeks. The gap is rarely knowledge; it is being able to explain something you normally just use.

What low-level design topics come up most often?

Interviewers concentrate on the parts that cause production incidents rather than the parts that are pleasant to learn. Expect the fundamentals to be assumed and the follow-up questions to sit one layer below what a tutorial covers.