The interviewer says: "Design a Parking Lot."
That's it. No class names, no hints, no starting point.
You take a breath. What do you write first — ParkingLot? Vehicle? ParkingSpot? Or do you just start typing code and hope classes appear along the way?
Actually — none of them. Before a single class exists, you need to answer one question: what is this system actually expected to do? Everything in this course — SOLID, patterns, UML, the six systems we design end to end — is really just different tools for answering that one question well.
What LLD interviews really test
Here is the trap most self-taught candidates fall into: they read about Singleton, Factory, Strategy, Observer and Adapter, memorise each definition, and walk into the interview expecting to "spot the pattern and name it."
That gets you partway. But an interviewer's actual follow-up is almost never "what pattern is this?" It's "why did you design it that way, and what would you change if I added this new requirement?" LLD interviews score your reasoning, not your vocabulary. Two candidates can both say the word "Strategy" — only one of them can explain what breaks without it.
HLD vs LLD — same problem, different zoom level
You may have also heard of High-Level Design (HLD) — the system design interview where you draw boxes for services, load balancers, databases and caches, and talk about how a URL shortener scales to a crore requests a day.
LLD zooms in. Take that same URL shortener's "shortening service" box from the HLD diagram, and ask: inside that one box, what classes exist, and how do they collaborate? That is LLD — often called machine coding or object-oriented design (OOD) in job descriptions. HLD asks "which components, and how do they talk over the network?" LLD asks "which classes, and how do they call each other?"
Classes are responsibilities, not just nouns
Let's try the noun trick on a real requirement:
"A customer can place an order. An order contains multiple products. The customer pays using a payment method."
Underline every noun and you get a first rough list:
- Customer
- Order
- Product
- PaymentMethod
Not bad as a first pass — but not every noun deserves to become a class, and this list alone tells you nothing about how these four things relate. The question that actually matters for each one is:
"What job does this class own?"
Order owns the list of products and the total. It does not own sending a confirmation email, generating an invoice PDF, or talking to a payment gateway — those are different jobs, likely to change for different reasons, so they belong to different classes (NotificationService, InvoiceGenerator, PaymentService). Put all of them inside Order and you get exactly the kind of class that makes an interviewer's eyebrow go up:
Order knows how to calculate its total, send an email, generate an invoice, and talk to a payment gateway. Four unrelated reasons this one class could change — a classic "God class," and the single most common LLD interview mistake.A useful second question, once you have a rough class in mind, is the opposite one: "What happens if I delete this class?" If deleting InvoiceGenerator just means invoice logic moves back into Order — and that move clearly makes Order worse — you've just proven InvoiceGenerator earns its place.
A repeatable design process
Every problem in this course — and almost every LLD interview question you'll ever get — is worked through the same ladder. Each step answers the very next question sitting in your head, so you never have to jump levels or guess what to do next:
- Clarify requirements. Confirm scope — what must this system support, what can you assume away for now?
- Find the objects and their responsibilities. Read the requirement like a designer: which nouns matter, and what job does each one own?
- Define relationships. Who needs to know about whom? Composition, aggregation, or inheritance?
- Find what changes frequently. Which piece of behaviour is most likely to grow a new variant next month?
- Introduce an abstraction — only where change justifies it. An interface exists because something behind it is expected to vary, never by default.
- Apply SOLID. A set of five questions you ask your own design (the next lesson).
- Reach for a pattern — only if it solves a real, stated pain. Singleton, Factory, Strategy, Observer, Adapter — each earns its place the same way
InvoiceGeneratordid above. - Draw the UML. Class diagram for structure, sequence diagram for "who calls whom."
- Write the core code. Interview-sized — enough to prove the design works, not a production codebase.
- Handle "what if the interviewer changes this?" Extend the design out loud: a new vehicle type, a new payment method, thread safety.
You will see this exact ladder — clarify → objects → relationships → changing behaviour → abstraction → SOLID → pattern → UML → code → extend — repeat in every remaining lesson of this course, especially the six systems we design end to end later on.
Why not just start coding and refactor later?
You genuinely can, for a five-minute toy problem. The reason this process matters in an interview is that you're being watched build something you can't fully see yet. An interviewer who has run this problem fifty times knows exactly which requirement is about to arrive ("now add a new pricing rule," "now make it thread-safe"), and is checking whether your first design absorbs that change gracefully or requires a rewrite. Following the process above is what makes your first design already resilient to the second requirement, instead of getting lucky.
This also means: a design is never "the correct one." It's reasonable given the requirements you clarified. Say so out loud — "given that pricing rarely changes for this use case, I'd keep it simple; if you expect frequent new pricing rules, I'd pull it behind an interface instead" — and you sound like an engineer making a trade-off, not someone reciting a memorised diagram.
Common mistakes
- Naming a pattern before stating the pain it solves ("I hear 'notify', so: Observer" — without explaining what breaks without it).
- Turning every noun in the requirement into a class without asking what job each one owns.
- Building a God class that owns unrelated jobs (business logic + persistence + notification + payment).
- Adding interfaces and patterns nothing in the requirements actually justifies — overengineering reads just as badly as underengineering.
- Presenting the first design as the only correct one instead of a reasonable choice given stated assumptions.
Quick recap
| Idea | One-liner |
|---|---|
| LLD vs HLD | HLD = which services, over the network. LLD = which classes, inside one service. |
| Class | Not just a noun — a noun with a clear, ownable job. |
| Design process | Clarify → objects → relationships → changing behaviour → abstraction → SOLID → pattern → UML → code → extend. |
| Pattern | Earned by a stated pain, never named on a keyword match. |
| "Correct" design | Doesn't exist — only a reasonable one given stated assumptions. |
One thing to remember
Find responsibilities → isolate what's likely to change → keep classes focused → reach for an abstraction only where that change justifies it. That sentence is the whole of LLD. Every lesson after this one is just that sentence applied to a new problem.
Practice Zone
Five MCQs on how to think about a fresh LLD problem, then three reasoning questions to attempt before revealing the answer.
An interviewer says 'Design a Parking Lot' and nothing else. What should you do first?
Asked in
What is the main difference between HLD and LLD?
Asked in
A ParkingLot class validates tickets, calculates the fee, charges the card, and emails a receipt. What's the main design problem here?
Asked in
Requirement: 'A customer places an order containing products, and pays using a payment method.' Which of these is NOT automatically a good candidate for its own class, just from being a noun?
Asked in
Which of these is the most reasonable order to work through an LLD interview problem?
Asked in
Think it through, then reveal:
Why shouldn't you name a design pattern the moment you hear a familiar-sounding requirement (e.g. hear "notify" and immediately say "I'll use Observer")?
Asked in
What question should you ask about every class you're tempted to add to a design?
Asked in
A requirement says: "The parking lot should support multiple pricing rules, and we may add more in the future." What should this sentence make you suspicious of?
Asked in
FAQ
Is LLD the same as OOD (object-oriented design)?
Yes, in almost all job descriptions and interview loops the two names refer to the same round — sometimes also called "machine coding." It means: design the classes, interfaces and their interactions for one part of a system, usually with working code by the end.
Do I need to memorise all 23 Gang-of-Four patterns for SDE-I/II interviews?
No. This course deliberately covers five — Singleton, Factory, Strategy, Observer, Adapter — because they are the ones that actually recur as real solutions in LLD interview rounds. Knowing five patterns deeply, and reasoning about when not to use them, easily beats a shallow list of twenty.
How long should an LLD interview design take?
Most rounds are 45–60 minutes and expect you to reach working, reasonably clean code — not a finished production system. A good rhythm: a few minutes clarifying, most of the time on classes/relationships/code, and the last few minutes on "what if you added X?" follow-ups.
What if I don't know which pattern to use?
Say what's changing and why a plain if/else or direct dependency feels uncomfortable, out loud. Often the right abstraction becomes obvious once you've named the pain — and if it doesn't, a plain, simple design with no pattern is a completely acceptable answer for a stable requirement.
Next, we turn "what job does this class own?" into five sharper questions you can ask any design — Lesson 2: SOLID Principles →