If you've ever aced a LeetCode round and then frozen when someone said "design a parking lot, with classes", this lesson is for you. Low-Level Design (LLD) is its own game with its own rules, and the first step to winning it is knowing exactly what game you're playing.
The three games interviewers play
Tech interviews test design at three different altitudes. Confusing them is the most common reason strong candidates fail.
DSA asks: can you make one function correct and fast? The unit of thought is the algorithm. HLD asks: can you make many machines cooperate at scale? The unit of thought is the component: load balancers, caches, queues, shards. LLD sits exactly in between: one process, one codebase, and the question is whether you can organize classes and their relationships so the code survives changing requirements.
What interviewers actually grade
The dirty secret of LLD rounds: the final UML rarely matters as much as how you got there. Interviewers are pattern-matching your process against how strong engineers work.
Requirement clarification
You ask which operations matter (park, unpark, query), what's out of scope, and
what will likely change. Jumping straight to classes is the #1 red flag.
Entity discovery
You name the nouns (ParkingLot, Floor, Spot, Vehicle, Ticket) and, more
importantly, defend why each deserves to exist.
Relationship design
Composition vs aggregation vs inheritance. Interfaces where behavior varies. This is where SOLID stops being trivia and starts being a tool.
The extensibility test
"Now add EV charging spots. Now add dynamic pricing." If your answer is "new class,
plug it in" you pass. If it's "let me rewrite ParkingLot" you don't.
Does LLD need code, or just diagrams?
It depends on the company, and you should ask upfront. Some loops want compilable-ish skeletons; others want boxes and arrows plus sharp reasoning. The safe default is a class skeleton: signatures, not bodies.
public class ParkingLot {
private final List<Floor> floors;
private final SpotAssignmentStrategy strategy; // behavior we expect to vary
public Ticket park(Vehicle vehicle) { /* ... */ }
public Receipt unpark(Ticket ticket) { /* ... */ }
}
public interface SpotAssignmentStrategy {
Optional<Spot> findSpot(List<Floor> floors, Vehicle vehicle);
}Notice the design choice hiding in five lines: spot assignment is an interface, not an
if-else ladder, because "nearest spot" today becomes "cheapest spot" tomorrow. That
single decision signals more design maturity than three pages of UML.
✎ Check yourself
The interviewer says: 'Design a parking lot.' What's the strongest first move?
Next up: the five SOLID principles, not as definitions to recite but as the reasons behind every relationship you'll draw in this course.