What are the SOLID principles? Give an example of one you've applied.
Design patternsJunior
In shortFive design rules for code that's easy to change. Single responsibility, open/closed, Liskov substitution, interface segregation and dependency inversion, each best explained with a concrete before and after.
Model answer
SOLID is five rules of thumb for keeping code changeable:
| Principle | In one line | |
|---|---|---|
| S | Single responsibility | A class has one reason to change: one group of people asks for its changes. |
| O | Open/closed | Add new behavior by adding code (a new rule, a new class), not by editing code that works. |
| L | Liskov substitution | A subtype must work everywhere its parent is expected, with no surprises. |
| I | Interface segregation | Small interfaces shaped by what each client needs. |
| D | Dependency inversion | Business code defines the interfaces it needs; databases and vendors implement them. |
An example worth giving: a checkout class created its own payment client, so tests hit the real provider. Introducing a PaymentGateway interface owned by checkout, passed in through the constructor, fixed testing (D) and later made adding a second provider a new class instead of an edit (O).
Close with judgment: the principles pay off where code actually changes. Abstracting a closed, stable set of cases (three order states) adds indirection without benefit.
What they're looking for
All five named correctly with a one-line meaning each, and at least one real example from the candidate's own code. Stronger answers also say when a principle would be overkill.
Common mistakes
- Reciting the five names without an example.
- Defining single responsibility as "one method per class".
- Confusing dependency inversion with dependency injection.
- Claiming every class should follow all five, always.