How do you demonstrate that you understand SOLID principles in an LLD interview?
Fast recall
Quick revision
Core answer
Assessing whether the candidate understands SOLID as practical design heuristics that emerge naturally, not just as acronyms to memorize and recite.
Freshers mention SOLID by name ('I'm using SRP here') without actually showing the problem it solves or the design smell it prevents.
Show a violation first, then fix it: 'This ParkingLotManager is doing too much, let me split out the payment logic' — teaching while designing.
Interview-ready guide
Interview answer
The key to demonstrating SOLID is to apply each principle as a natural part of designing, and only name it after I've made the move — that reads as genuine fluency rather than reciting flashcards. So when I split a class that was doing too much into a FeeCalculator and a ParkingSpot, I'll say I'm separating these so each has a single reason to change — that's Single Responsibility. When I introduce an interface so that adding a new vehicle type doesn't require editing existing code, I'll note that keeps the design open for extension but closed for modification, which is Open/Closed.
For Liskov Substitution, I make sure a subtype like Motorcycle can stand in for Vehicle anywhere without breaking logic — no method that throws unexpectedly — and I'll call that out if it's relevant. For Interface Segregation, I prefer small focused interfaces like Parkable or Payable over one giant IVehicle that forces classes to implement methods they don't need. And for Dependency Inversion, I inject a FeeCalculator interface into the ParkingLot through its constructor, so the high-level class depends on an abstraction rather than a concrete implementation.
The mistake I avoid is announcing up front that I'm going to demonstrate SOLID, or reciting the five principles like a list. Interviewers will probe whether my design actually matches my words, so I let the principles fall out of decisions I'm already explaining, and I only invoke the ones the problem genuinely calls for rather than forcing all five.
How do you demonstrate that you understand SOLID principles in an LLD interview
Direct Answer
Demonstrate SOLID by applying principles naturally during design, not as a checklist. Show SRP by splitting a god class into focused responsibilities. Show OCP by using interfaces so new vehicle types don't modify existing code. Show LSP by ensuring subclasses like Motorcycle can replace Vehicle without breaking logic. Show ISP with small interfaces like Payable instead of one giant IVehicle. Show DIP by depending on abstractions like PaymentProcessor interface, not concrete CreditCardProcessor.
Deep Dive & Architecture
Show one decision for each principle you actually use
In a parking-lot design, ParkingSpot owns occupancy while FeePolicy owns pricing (SRP). Adding WeekendFeePolicy without editing the exit flow demonstrates OCP. Every Vehicle subtype must honour the base contract rather than throw for normal vehicle operations (LSP).
Interface segregation and dependency inversion
Separate capabilities such as ChargeableSpot prevent ordinary spots from implementing charging methods they cannot support (ISP). An ExitService that receives FeePolicy and PaymentGateway interfaces through its constructor depends on abstractions and can be tested with fakes (DIP).
Requirement-change walkthrough
If the interviewer adds weekend pricing, show that one new policy class is enough. If they add electric charging, show that only charging-capable spots implement that contract. This demonstrates SOLID through an evolving model instead of reciting five definitions or forcing an interface onto every class.
Code Example
// ISP: small capability interfaces instead of one fat IVehicle
interface Parkable { boolean park(ParkingSpot s); }
interface Chargeable { void charge(); }
// LSP: every subtype honours the Vehicle contract -- no surprise throws
abstract class Vehicle { abstract SpotSize requiredSize(); }
class Motorcycle extends Vehicle { SpotSize requiredSize() { return SpotSize.COMPACT; } }
// DIP: depend on the abstraction, inject it
class ParkingLot { ParkingLot(FeeCalculator fee) { /* ... */ } }
Each line is a normal design decision that happens to embody a SOLID principle.
Common Mistakes & Pitfalls
- Reciting SOLID as a list — apply it; name it only after the move.
- Announcing patterns/principles upfront — let them emerge from decisions.
- Claiming a principle you didn't apply — interviewers probe; match words to design.
- Forcing all five — use the ones the problem actually calls for.
Check your understanding
Answer these without looking back at the article.
- How do you structure your time in an LLD interview?
- What should you say when you're not sure about a design decision in an LLD interview?
- How do you handle extended or follow-up requirements in an LLD interview?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.