SOLID principles
OOP · 9 interview questions
SOLID is five design principles collected by Robert Martin, and interviewers ask for them because they are a compact way to see whether a candidate thinks about change.
They are best understood as answers to one question: when this system needs to change, how much of it has to be touched? Single responsibility limits the reasons a class changes. Open/closed asks for extension without modification. Liskov keeps subtypes substitutable. Interface segregation stops callers depending on methods they never use. Dependency inversion points dependencies at abstractions rather than concrete classes.
Reciting the five is table stakes. The useful thing is being able to name the specific pain each one prevents.
SOLID principles interview questions
- What does SOLID stand for?
- Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion.
- What is the single responsibility principle?
- A class should have one reason to change. If a class both formats a report and saves it to disk, a change to either concern forces you to touch and retest the same class.
- What is the open/closed principle?
- Software should be open for extension but closed for modification — you should be able to add behaviour without editing existing, tested code. Typically achieved by adding a new implementation of an interface rather than another branch in a switch.
- What is the Liskov substitution principle?
- Objects of a subtype must be usable anywhere the parent type is expected without breaking correctness. A subclass that throws on a method the parent supports violates it, even though it compiles.
- Give the classic Liskov violation.
- Square extending Rectangle. Rectangle promises width and height can be set independently; Square cannot honour that without changing the other. Code written against Rectangle breaks, so the is-a phrasing was true in geometry and false in behaviour.
- Why they ask: The example interviewers expect. It also shows why is-a should be tested by behaviour, not vocabulary.
- What is the interface segregation principle?
- No client should be forced to depend on methods it does not use. Several small focused interfaces beat one large one, because implementers otherwise have to stub methods that make no sense for them.
- What is the dependency inversion principle?
- High-level modules should not depend on low-level modules; both should depend on abstractions. An order service should depend on a PaymentGateway interface, not on a concrete StripeClient.
- Is dependency injection the same as dependency inversion?
- No. Dependency inversion is the principle — depend on abstractions. Dependency injection is one technique for achieving it, by supplying dependencies from outside rather than constructing them internally.
- Why they ask: A precise distinction that many candidates conflate.
- What's the cost of applying SOLID aggressively?
- Indirection. Every abstraction added for future flexibility is another hop to follow when reading the code, and flexibility that is never used is pure cost. The principles are tools for managing likely change, not goals in themselves.
- Why they ask: Answering this well signals judgement rather than dogma.
You'll forget most of this by next week
That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.
Start free for 7 days