Most LLD prep jumps straight to "design a parking lot" or "design a vending machine" without stopping to ask: what is the interviewer actually grading while you draw those classes? The answer is almost always object-oriented design principles — and if you can't name why a design follows them, the classes on the whiteboard don't matter much.
Here's a breakdown of the principles that come up constantly, and what interviewers are actually listening for when they ask about them.
Encapsulation: more than "make fields private"
Most candidates know encapsulation means hiding internal state. Fewer can explain why it matters in a specific design. If your Order class exposes a public items list that anyone can mutate directly, you've lost control over invariants like "an order can't be empty" or "total must match the sum of item prices." Encapsulation isn't a style rule — it's how you protect the rules your system depends on.
What interviewers listen for: can you point to a specific invariant your encapsulation is protecting, not just say "it's good practice."
Abstraction: hiding complexity, not hiding classes
Abstraction gets confused with encapsulation constantly. Abstraction is about exposing a simple interface while hiding how the work actually happens. A PaymentProcessor interface with a charge(amount) method is abstraction — the caller doesn't need to know if it's calling Stripe, Razorpay, or a mock in tests.
What interviewers listen for: whether your abstractions are stable. If adding a new payment provider means changing code all over your system instead of just adding one new class, the abstraction was drawn in the wrong place.
The Single Responsibility Principle, applied honestly
Everyone can recite "a class should have one reason to change." Almost nobody applies it under interview pressure, because the honest version requires you to notice when you're about to violate it — usually while you're mid-design and it's tempting to just add one more method to a class that already does too much.
A classic tell: a User class that handles authentication, sends emails, and calculates loyalty points. Three reasons to change, three responsibilities, three future bugs waiting to happen when one gets modified and breaks the others.
Open/Closed: designing for the extension you haven't been asked for yet
This is the principle candidates struggle with most, because it requires anticipating change without over-engineering for hypothetical futures that never arrive. The skill isn't "add every extension point possible" — it's identifying the one or two axes your interviewer's problem is actually likely to extend along.
For a parking lot problem, vehicle types are an obvious extension axis (cars, motorcycles, trucks). Pricing strategies are another. If your class hierarchy makes adding a new vehicle type require editing five existing classes, that's a real signal, not a nitpick.
Liskov Substitution: the one that silently breaks systems
This principle rarely gets asked about directly, but it gets violated constantly, and interviewers notice. If a subclass changes the behavior a caller expects from the parent class — a Square that extends Rectangle but breaks setWidth/setHeight independence — you've created a class that's technically a subtype but functionally a landmine.
What interviewers listen for: whether you catch this yourself when sketching an inheritance hierarchy, without being prompted.
Composition over inheritance: knowing when to reach for which
Interviewers love asking "would you use inheritance or composition here?" because there's rarely one right answer -there's a right answer for the specific constraints of the problem. Inheritance models a true "is-a" relationship with shared behavior. Composition models "has-a" and tends to age better when requirements shift, because you're not locked into a rigid hierarchy.
A Car "is-a" Vehicle -inheritance is reasonable. A Car "has-a" Engine -composition, not inheritance, because a car doesn't behave like an engine, it uses one.
Why reading these definitions doesn't make them stick
You can memorize every principle above and still freeze the first time you're asked to design something from scratch, because recognizing a principle in a textbook example and applying it correctly to a novel problem, live, are different skills. The gap only closes with repetition-designing schemas and class hierarchies yourself, getting told specifically where a principle was violated, and doing it again.
That loop is what ScaleDojo's LLD Schema Design Lab is built around progressive missions on an interactive canvas where you apply these principles to real problems and get scored, specific feedback instead of a vague pass/fail.
If OOD principles have been the part of your LLD prep you've been reading about instead of practicing, that's usually the highest-leverage gap to close before your next interview.
Comments
Join the discussionWorth reading!
