How to Prepare for a Low-Level Design Interview
By Evan King
•
You just learned you have a low-level design interview coming up. There is a good chance you've done 100s of LeetCode problems at this point, but low-level design still feels fuzzy and you're not alone.
LLD interviews trip up a lot of candidates. Not because the concepts are hard, but because there's far less preparation material than for DSA or system design. What does exist is either outdated (UML-heavy approaches from decades past) or too academic (memorizing all 23 Gang of Four patterns). The reality is simpler, but you need to know what's actually being evaluated.
This post distills what actually matters so you can walk in confident.
What is LLD?
Before diving into preparation, it helps to understand what LLD interviews actually assess. Unlike coding interviews that test algorithms, or system design that tests distributed systems thinking, LLD sits somewhere in between. You're designing the internal structure of a single component, not a whole system.
System design defines the architecture of a distributed system. LLD defines the internal structure of a single component within that system.
In a system design interview, you might sketch out services, databases, and message queues for Uber's backend. In an LLD interview, you'd design the Trip class, the PricingCalculator interface, and how these objects actually collaborate within a single service.
Interviewers are evaluating four things.
- How you break down problems into clear entities with well-defined responsibilities
- How your classes interact without becoming a tangled mess
- Whether your design can handle change without requiring a complete rewrite
- How clearly you communicate your reasoning and trade-offs
A good design that you can't explain is indistinguishable from a bad design.
The Three-Part Preparation Plan
Effective LLD prep boils down to just three steps.
- Internalize the fundamentals (not memorize them)
- Learn the delivery framework (so you never feel lost)
- Practice with real problems
1. Internalize the Fundamentals
Most LLD guides dump a list of principles and patterns on you: SOLID, DRY, KISS, Factory, Strategy, Observer, Decorator... the list goes on. There are too many, the definitions are overly complex, and you could spend weeks memorizing them and still bomb the interview because you don't know when to apply them.
The underlying concepts are actually simple. The goal is developing intuition, not memorizing definitions. Here are the ones you actually need to know, in plain English.
Principles That Matter
KISS (Keep It Simple) is the most violated principle in LLD interviews. Candidates over-engineer because they want to show off. They introduce factories, builders, and decorators when a basic class would work. Interviewers notice this, so start simple and add complexity only when simplicity stops working.
Single Responsibility means each class does one thing. If you can't describe what a class does in one sentence without using "and," it's doing too much. A Report class that generates content, formats PDFs, and saves files is three classes pretending to be one.
Separation of Concerns is about keeping layers apart. Your UI code shouldn't contain business logic. Your business logic shouldn't know how data is stored. This is less about individual classes and more about architectural boundaries—presentation, domain, persistence.
The rest of SOLID (Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) matter, but they're more about recognizing when your design is getting awkward than actively applying rules. If you find yourself with a Penguin class that throws an exception when you call fly(), you've violated Liskov Substitution. If adding a new payment method requires modifying existing code in five places, you might want an interface.
Over time, you'll develop a "smell" for good code. Rather than rigidly analyzing every decision, you'll notice when something seems missing or overused. That's the intuition we want to build through practice.
For the full breakdown, see Design Principles.
Patterns That Matter
Don't memorize all 23 Gang of Four patterns. Here are the ones that actually show up in interviews:
Strategy is used when the logic might change. When you see if (type == "credit") or switch (vehicleType), that's a strategy pattern waiting to happen. This is probably the most common pattern in LLD interviews because it directly tests whether you can isolate behavior that varies.
Observer lets objects subscribe to events—especially useful when you don't know who might care up-front. When multiple components need to react to state changes, a stock price update that triggers multiple displays, an order placement that notifies inventory, analytics, and notifications, you're looking at Observer.
State Machine handles objects whose behavior depends on their current state. Vending machines, document workflows, game states. If the word "state" appears multiple times in requirements, think state machine.
Factory centralizes object creation. Instead of new EmailNotification() scattered throughout your code, you call notificationFactory.create(type). When you add SMS, you update the factory. Everything else stays the same.
That's it. These four patterns cover 90% of what you'll encounter. The others (Builder, Singleton, Decorator, Facade) are situational and you can usually design a clean solution without explicitly reaching for them.
Patterns should emerge from your design decisions, not drive them. If you're forcing one in, step back. In most interviews, using one or two patterns (or none) is perfectly fine.
For the full breakdown, see Design Patterns.
OOP Concepts as Tools
You learned encapsulation, abstraction, polymorphism, and inheritance in school. The interview tests whether you can wield them appropriately.
Encapsulation means keeping fields private. Expose behavior through methods. If you're returning references to mutable internal collections, you've broken encapsulation.
Abstraction is about defining interfaces for variations. Multiple payment methods? Different vehicle types? Create an interface. The caller doesn't need to know which implementation they're using.
Polymorphism lets objects handle themselves. No type checking, no switch statements on types. Each object knows how to perform its own operations.
Inheritance is where candidates get into trouble. Modern design favors composition over inheritance. Default to interfaces. Only use inheritance when you genuinely need to share stable implementation across classes. In most LLD interviews, you don't need inheritance at all.
For the full breakdown, see OOP Concepts.
2. Learn the Delivery Framework
What's more difficult than knowing the principles and patterns is applying them under time pressure without getting lost. That's where a delivery framework matters.
Most candidates fail because they're trying to solve everything simultaneously. They see "Design a parking lot system" and immediately start thinking about classes, methods, edge cases, and extensions all at once. This cognitive overload is unnecessary and paralyzing.
The fix is a structured framework that breaks the interview into sequential phases. Each phase builds on the previous one, so by the time you're writing code, the design decisions have already been made. You're just translating what you've already figured out.
Low-Level Design Interview Delivery Framework
We have a full Delivery Framework writeup that goes deeper, but here's the essence.
The Five Phases
1. Requirements (~5 minutes)
Every LLD interview starts with a vague prompt: "Design Tic Tac Toe" or "Design a parking lot system." Your job is to turn that into something concrete before you touch design.
Ask questions around four themes. What operations must this system support? What defines success, failure, or state transitions? How should invalid inputs be handled? What's explicitly in and out of scope?
Write down the answers and formulate them into a clear set of requirements you can design against.
2. Entities and Relationships (~3 minutes)
Now scan your requirements for the meaningful nouns. These are the things that need to exist in your system. Not every noun becomes a class though. Apply a filter:
- Does it maintain changing state or enforce rules? It's probably an entity.
- Is it just information attached to something else? It's probably just a field or an input parameter.
Take the classic Design a Parking Lot problem as an example. Vehicle is external to your system. You don't manage it, you don't care about its state. You just need to know its type (motorcycle, car, large). That's an enum. But Ticket? That's internal state your system creates and manages. That's a class.
Find the orchestrator, the entity that coordinates the workflow. In a parking lot it's ParkingLot. In a chess game it's Game. This is the entry point for external requests.
Sketch quick relationships—which entity owns which, who creates whom. Don't overthink notation.
Skip the UML. It's outdated and rarely used in production—Microsoft removed UML tooling from Visual Studio in 2016 because usage dropped to zero. Engineers at modern companies design in code, not diagrams. Simple boxes, arrows, and labels communicate structure just fine.
3. Class Design (~10-15 minutes)
Now go entity by entity, starting from the entry point of your system. For each one, figure out what state it needs to remember to enforce the requirements and what operations it needs to support.
Tie everything back to your requirements list. If you can't point to a requirement that needs a field or method, you probably don't need it.
Candidates frequently add methods and fields that aren't needed for the requirements they agreed on. This burns precious time and increases design complexity, both of which cost you points. Stick to your requirements. You can always amend them if truly necessary.
By the end of this phase, you have pseudocode class outlines showing fields and method signatures for each entity.
4. Implementation (~10 minutes)
Pick the most interesting methods and implement them. Start with the happy path, then handle edge cases. Most interviewers want pseudocode, not syntactically perfect code.
Your interviewer will usually tell you which methods to implement. If not, pick the ones that show how your classes cooperate and how state transitions occur.
5. Verification (~2-5 minutes)
Trace through a concrete scenario. "A car enters, gets ticket T1, parks in spot B. Later exits with T1, pays the fee." Does your state actually change correctly? This catches bugs before your interviewer finds them.
If there's time, the interviewer might ask extension questions: "How would you add undo?" or "What if we need multiple floors?" These test whether your design can evolve without a rewrite.
3. Practice With Real Problems
LLD is a skill, not a knowledge problem. If you don't practice designing from a blank page, reading won't transfer.
Most candidates skip read breakdowns, watch YouTube videos, nod along, and avoid actually practicing. I don't blame them! Practicing takes work and work sucks. But it's the highest leverage activity for passing the interview. Reading and watching gets you maybe 30% of the way there. You need to struggle with the blank text editor, make design mistakes, and develop your sense of "smell" for good code.
Problems to Practice, In Order
Start with these. They're ordered to build skills progressively:
-
Design Connect Four - Game problems test state machines and win condition checking.
-
Design Amazon Locker - Similar to parking lot but with different constraints, good for seeing how designs differ based on requirements.
-
Design an Elevator System - Introduces scheduling algorithms and more complex state management.
-
Design a Parking Lot - The classic starter problem. Tests entity extraction, state management, and basic orchestration.
-
Design a Rate Limiter - Different flavor of problem, algorithm-focused but still tests class design.
-
Design an Inventory Management System - More complex business logic, multiple entity types.
For each problem, follow the delivery framework from section 2. Set a timer if it helps. The goal is to build muscle memory for the five phases so that in the actual interview, the structure is automatic and you can focus on the problem itself.
After you attempt a problem, compare your solution to the breakdown. Don't just check if you got the "right answer" (there usually isn't one). Ask yourself whether you identified the same entities or over/under-modeled, whether your orchestrator is handling the right responsibilities, where you put state and whether that makes sense, and whether your class APIs are clean or if callers need to know too much.
The goal isn't to match some canonical solution. It's to develop design intuition you can apply to any problem.
The Interview Itself
Preparation gets you ready. But execution in the actual interview requires managing time and communicating clearly.
Follow the Framework
The delivery framework from section 2 is your pacing guide. If you're 15 minutes in and still on requirements, you're in trouble. If you're 20 minutes in without any class design on the board, you need to move faster.
The most common failure mode is spending too long on early phases and running out of time before showing meaningful implementation. Conversely, diving straight into code without establishing structure means you'll likely need to backtrack. The framework exists to prevent both.
Communication Is Half the Battle
Talk through your reasoning. Interviewers can't read your mind, and a silent candidate makes for an anxious interviewer. Explain why you're making design choices. Say things like "I'm making this a separate class because it has its own state to manage" or "I considered putting this logic here, but it makes more sense in the orchestrator because..." or "This could also be implemented using X, but I'm choosing Y because..."
If you're stuck, say so. "I'm thinking about where this responsibility should live" is better than awkward silence. And if the interviewer offers a hint, take it gracefully, that's not a negative signal.
Don't Over-Engineer
The most common mistake is over-engineering. You're not building production software. You're demonstrating design thinking.
If a simple solution works, use it. Don't add Strategy patterns for one implementation. Don't build elaborate factory hierarchies for creating two object types. Don't introduce interfaces where concrete classes would suffice.
When the interviewer asks "how would you extend this?", that's when you explain how the design would evolve. But don't build for extensions upfront.
Final Thoughts
LLD interviews aren't about memorizing patterns or principles. They're about demonstrating that you can take an ambiguous problem and turn it into clean, maintainable code structure. That's a skill you use every day as a software engineer, which is why LLD prep feels more practical than grinding LeetCode.
The good news is that the learning curve is shorter than algorithm prep. After working through 5-6 problems actively, you'll notice the pattern recognition becoming automatic. You'll hear "design a parking lot" and immediately know to look for the orchestrator, identify what's internal state versus external input, and structure your class APIs around clear responsibilities.
The framework gives you a reliable path through any problem. The principles keep your design clean. And the practice builds the intuition to apply both under pressure.
If you want to go deeper, our LLD In A Hurry guide covers everything in this post with more detail and worked examples.
Good luck!
Mark as read
About The Author
Evan, Co-founder of Hello Interview and former Staff engineer at Meta, possesses a unique vantage point having been on both sides of the tech hiring process. With a track record of conducting hundreds of interviews and securing offers from top tech companies himself, he is now on a mission to help others do the same.
Recommended Reading
Hello Interview Premium
Reading Progress
On This Page
What is LLD?
The Three-Part Preparation Plan
1. Internalize the Fundamentals
Principles That Matter
Patterns That Matter
OOP Concepts as Tools
2. Learn the Delivery Framework
The Five Phases
3. Practice With Real Problems
Problems to Practice, In Order
The Interview Itself
Follow the Framework
Communication Is Half the Battle
Don't Over-Engineer
Final Thoughts
Your account is free and you can post anonymously if you choose.