Beyond the four pillars, interviewers — especially at product companies — probe whether you can design maintainable systems. The SOLID principles are five guidelines for class design, and a few common design patterns show you know proven solutions to recurring problems.
SOLID in one line each
Single Responsibility: a class has one reason to change. Open/Closed: open to extension, closed to modification. Liskov Substitution: a subclass should be usable wherever its parent is. Interface Segregation: many small interfaces beat one fat one. Dependency Inversion: depend on abstractions, not concrete classes.
A few patterns worth naming
| Pattern | Solves |
|---|---|
| Singleton | exactly one shared instance (e.g. a config) |
| Factory | create objects without naming concrete classes |
| Observer | notify many subscribers when state changes |
| Strategy | swap interchangeable algorithms at run time |
⚡ The edge
- You don't need to recite every pattern — but being able to state SOLID and explain one pattern (Singleton or Factory) clearly puts you ahead of most candidates.
- SOLID's through-line is the same as the four pillars taken seriously: low coupling, high cohesion — each class does one thing well and depends on abstractions.
Worked example
'Explain the Single Responsibility Principle.'
- A class should have one, and only one, reason to change — it should do one job.
- If a class handles both, say, business logic and file saving, a change to either reason forces edits to the same class.
- Splitting responsibilities makes each class smaller, easier to test, and less likely to break when requirements shift.
Answer: A class should have a single responsibility — one reason to change — which keeps it cohesive and testable.
Worked example
'What is the Singleton pattern and when is it used?'
- Singleton ensures a class has exactly one instance and provides a global access point to it.
- It's used for shared resources like a configuration object, a logger, or a connection pool.
- The caution: overuse creates hidden global state and makes testing harder, so apply it sparingly.
Answer: Singleton guarantees one shared instance with global access — good for config/loggers, but easy to overuse.
⚠ Watch out
- SOLID is about maintainability, not performance — frame it as managing change.
- Liskov Substitution is violated when a subclass can't safely replace its parent (e.g. a Square that breaks Rectangle's behaviour).
- Patterns are tools, not goals — don't force a pattern where a simple class suffices.