SOLID Principles interview questions and answers

Question 1

What does SOLID stand for, and where did it come from?

Accepted Answer

SOLID is a memory aid for five design principles for writing object-oriented code that is easy to change. The five are: S, Single Responsibility Principle: a class should have one job. O, Open/Closed Principle: you should be able to add new behaviour without editing existing code. L, Liskov Substitution Principle: a subclass must be usable anywhere its parent is expected, without surprises. I, Interface Segregation Principle: keep interfaces small, so a class is not forced to implement methods it does not use. D, Dependency Inversion Principle: code should depend on interfaces, not on concrete classes. The principles were collected by Robert C. Martin ("Uncle Bob") around 2000; the SOLID acronym itself was coined a few years later by Michael Feathers. They are guidelines, not laws. Analogy: a checklist a builder keeps in their pocket. Not a legal code, just five reminders that stop you building a house where moving one wall means rebuilding the kitchen. In an interview: SOLID is five principles for keeping object-oriented code flexible. I would name each one in a sentence, then say the common thread: every one of them is about isolating change, so that a new requirement touches as little existing code as possible.

Question 2

Why do we need SOLID? What problem does it actually solve?

Accepted Answer

Software changes constantly, new features, new rules, bug fixes. The cost of a codebase is not writing it once, it is changing it for years. Code that ignores these principles tends to become rigid (one change forces many others), fragile (a change in one place breaks something unrelated), and immobile (you cannot reuse a piece without dragging half the system with it). SOLID is a set of habits that keep the pieces loosely connected, so a change stays local and you can test each piece on its own. Analogy: wiring a house with plugs and sockets instead of soldering every appliance directly to the wall. When you want a new lamp, you plug it in. You do not call an electrician and cut the power to the whole street. In an interview: The problem SOLID solves is the cost of change. Most of a system's life is maintenance, and badly structured code makes every change risky and slow. SOLID keeps modules loosely coupled and highly cohesive so changes stay contained.

Question 3

Are SOLID principles rules you must always follow?

Accepted Answer

No. They are heuristics, rules of thumb that are usually right. Applied blindly they cause harm: you can split code into so many tiny classes and interfaces that nobody can follow the flow, which is its own kind of unmaintainable. The skill is judgement: apply a principle when you can see or reasonably predict the change it protects against. For a small script or a throwaway prototype, most of SOLID is not worth the ceremony. Analogy: seasoning while cooking. Salt usually improves a dish, but 'salt is good' does not mean empty the jar. You taste, then adjust. In an interview: I treat them as guidelines, not laws. They point at real problems, coupling, ripple effects, hard-to-test code, but the goal is maintainability, not a high principle score. If following a principle makes the code harder to understand with no real benefit, that is a signal to stop.

Question 4

How does SOLID relate to coupling, cohesion, and design patterns?

Accepted Answer

Two older ideas sit underneath all of SOLID. Coupling is how much one piece of code depends on another, you want it low. Cohesion is how strongly the things inside one class belong together, you want it high. SRP and ISP push cohesion up; OCP and DIP push coupling down; LSP keeps inheritance safe so the other four hold. Design patterns (Strategy, Factory, Adapter, Observer, and so on) are named, reusable solutions that put these principles into practice, for example, Strategy is the usual way to satisfy OCP. Analogy: SOLID is the nutritional guidance ('less sugar, more fibre'); design patterns are the specific recipes that follow it. In an interview: SOLID is really a modern restatement of 'low coupling, high cohesion' with concrete guidance for OO code. Design patterns are the vocabulary for the solutions, when I say 'I'd use Strategy here', I'm really saying 'I want this open for extension and depending on an abstraction'.

Question 5

What is the Single Responsibility Principle?

Accepted Answer

A class should have one responsibility, one well-defined job, and therefore only one reason to change. If a class formats a report, saves it to a database, and emails it, that is three jobs. A change to the email system, the database, or the report layout all force you back into the same class, and a mistake in one area can break the others. Splitting it into three focused classes means each one changes for its own reason only. Analogy: a Swiss Army knife versus a proper toolbox. The knife is clever but the screwdriver is bad, the scissors are worse, and sharpening the blade risks bending everything else. A toolbox has one good tool per job. In an interview: SRP says group together only the things that change for the same reason, and separate the things that change for different reasons. One class, one job, one reason to change.

Question 6

What does “one reason to change” really mean? Isn't every class changed for many reasons?

Accepted Answer

"Reason to change" means a source of change, a group of people or a concern that would ask for a different behaviour. Uncle Bob's sharper phrasing is: a class should have one reason to change, meaning it should answer to one stakeholder or actor. A payroll class that calculates pay (finance's rules), formats a payslip (HR's layout), and writes to the ledger (accounting's format) has three actors. When finance changes a tax rule you do not want to risk HR's payslip. Same code, different reasons, so split it. Analogy: a document that needs sign-off from three different departments. Every edit means three review meetings. Split it into three documents and each department reviews only its own. In an interview: I read 'reason to change' as 'a person or role who could request a change'. If two behaviours in a class serve two different roles, those behaviours will evolve independently, and keeping them together means every change risks the other. That is the smell SRP is pointing at.

Question 7

Walk through a class that violates SRP and how you would fix it.

Accepted Answer

Take a UserService that validates input, hashes the password, saves the user, and sends a welcome email. Four responsibilities. If the hashing algorithm changes, or the email provider changes, or validation rules change, you are editing and re-testing this same class every time, and the tests are hard to write because you cannot check validation without also touching the database and the mail server. The fix: pull each concern into its own class and have UserService coordinate them through interfaces. Analogy: a restaurant where one person takes the order, cooks it, washes up, and does the accounts. Hire a waiter, a chef, a dishwasher, and a bookkeeper, now each can be trained, replaced, or improved without stopping the kitchen. In an interview: I would name the responsibilities out loud first, validation, hashing, persistence, notification, then extract each into a collaborator behind an interface. UserService keeps only the orchestration. Now each piece is independently testable and independently replaceable.

Question 8

How do you know when a class is doing too much?

Accepted Answer

Practical signs: you struggle to name the class without using "and" or "Manager" or "Util"; the class has fields that are only used by some methods and not others; you frequently change the class for unrelated reasons (check the git history); the unit tests need a lot of unrelated setup (a mock database and a mock mailer for the same test); or the class is simply very long. None of these alone is proof, but two or three together usually mean there is a smaller class trying to get out. Analogy: a kitchen drawer that has become the 'everything drawer', batteries, tape, takeaway menus, a screwdriver. You know it is wrong because you cannot describe what the drawer is for. In an interview: I look at cohesion: do all the methods use all the fields, and would all of them change for the same reason? If the class splits cleanly into groups of methods that touch different fields, that is the seam. The git log is a great tell, if one file shows up in commits about totally different features, it is doing too much.

Question 9

What is the Open/Closed Principle?

Accepted Answer

Software entities (classes, modules, functions) should be open for extension but closed for modification. In plain terms: you should be able to add new behaviour by adding new code, not by editing code that already works. Every time you edit a tested, working class you risk breaking it and you have to re-test it. If new requirements mostly mean new classes, the existing ones stay stable. Analogy: a power strip. To add another device you plug in a new one (extension). You do not rewire the strip itself (modification) every time. In an interview: OCP says: design so that new requirements are satisfied by adding new code, not by opening up old code. The mechanism is almost always polymorphism, depend on an interface, and let new implementations carry the new behaviour.

Question 10

How can a class be “closed for modification” and still do new things?

Accepted Answer

Through polymorphism. The class depends on an abstraction (an interface or abstract class), not on concrete types. New behaviour arrives as a new class that implements that abstraction. The original class calls the interface method and does not care which implementation it got, so its code never needs to change. The 'closed' part is the stable class; the 'open' part is the growing family of implementations behind the interface. Analogy: a universal remote that talks 'infrared'. It was built once. New TVs work with it because they also speak infrared, the remote's insides never changed. In an interview: The trick is that the stable class only knows the interface. Behaviour is injected from outside as different implementations. Adding a payment type is a new file and a wiring change, Checkout is never reopened, so it never regresses.

Question 11

Show an OCP violation and the polymorphic fix.

Accepted Answer

The classic violation is a method full of if/else or a switch on a type code. Every new type means editing that method. The fix is to replace the branching with a call to a method on an interface, and move each branch's logic into an implementation of that interface. Analogy: a receptionist with a giant laminated sheet of 'if the caller says X, do Y'. Every new department means reprinting the sheet. Better: give each department its own phone line and just transfer the call. In an interview: When I see a switch on a type, I read it as an OCP violation waiting to bite. The refactor is 'replace conditional with polymorphism': one interface method, one implementation per former branch, and the calling code collapses to a single call.

Question 12

Doesn't OCP just lead to interface explosion and over-engineering?

Accepted Answer

It can, if you apply it everywhere up front. The honest guidance is: do not build the abstraction until you have a real second case or a well-founded expectation of one. The first time you write the shape calculation, a simple version is fine. The second time a new type shows up, that is the signal to introduce the interface, you now know the axis of change. Predicting every future extension point and building interfaces for all of them is speculative and usually wrong. Analogy: building doorways in a field before you know where the rooms go. Wait until the walls exist, then put the door where people actually walk. In an interview: I apply OCP reactively, not speculatively. 'Rule of three' works well: the first time, just write it; the second time, notice the duplication; the third time, abstract it. By then the right abstraction is obvious instead of guessed.

Question 13

What is the Liskov Substitution Principle?

Accepted Answer

If your code works with a base type, it must keep working when you hand it any subtype, no surprises, no special-casing. A subclass must honour the promises (the contract) of its parent: accept the same inputs, return compatible outputs, throw no unexpected exceptions, and not weaken any guarantee the parent made. If you find yourself writing "if the object is actually a PenguinBird, skip the fly() call", the hierarchy is broken. Analogy: a rental car company. You book "a car". Whatever they give you, sedan, hatchback, estate, the pedals, wheel and gearstick work the way you expect. If one 'car' needed you to steer with your feet, it should not be in the 'car' category. In an interview: LSP is about substitutability. Extending a class is a promise that instances of the subclass can stand in for the parent everywhere. If callers have to know the concrete type to use it safely, inheritance is being misused.

Question 14

What is the classic Rectangle / Square problem?

Accepted Answer

Mathematically a square is a rectangle, so it seems natural to write class Square extends Rectangle. But Rectangle lets you set width and height independently. Square cannot, setting width must also set height. So Square either breaks the parent's behaviour (setWidth quietly changes height too) or throws. Any code that expects a Rectangle and does "set width to 5, set height to 4, assert area is 20" will fail when given a Square. The IS-A of geometry is not the IS-A of behaviour. Analogy: a real square peg genuinely is a kind of rectangular peg in shape, but a machine built to adjust a rectangular peg's width and height separately jams when you feed it a square one. Same shape, different behaviour under the tools that use it. In an interview: It shows that 'is-a' in the real world does not guarantee 'is-a' in code, what matters is whether the subtype keeps every behavioural promise. The usual fix is to not inherit at all: make Shape an interface with an area() method, or make both types immutable so the setter conflict disappears.

Question 15

What are the specific rules a subclass must follow to be substitutable?

Accepted Answer

Four behavioural rules. 1) Preconditions cannot be strengthened: the subclass must not demand more from callers than the parent did (if the parent accepts any integer, the subclass cannot reject negatives). 2) Postconditions cannot be weakened: the subclass must deliver at least what the parent promised. 3) Invariants must be preserved: anything the parent guaranteed stays true must still be true. 4) No new exceptions: the subclass must not throw checked exceptions the caller was not told to expect, and history constraints must hold (it must not allow a state change the parent forbade). Analogy: a stand-in actor. They must say at least all the lines the role requires (postconditions), not demand a bigger trailer than the part allows (preconditions), stay in character (invariants), and not suddenly start improvising a fight scene (no new exceptions). In an interview: I summarise it as: require no more, promise no less, keep the invariants, and surprise no one. If a subclass has to break any of those to work, it is not really a subtype and composition is the better tool.

Question 16

How does LSP connect to the 'favour composition over inheritance' advice?

Accepted Answer

LSP is the reason that advice exists. Inheritance is only safe when the subclass genuinely satisfies the parent's contract in every case, and that is rarer than it looks. When it does not hold, you get the Ostrich and Square problems. Composition sidesteps this: instead of ReadOnlyStore extends FileStore, you have ReadOnlyStore hold a FileStore privately and expose only the read methods. You are no longer promising substitutability you cannot keep. Analogy: inheritance is marrying into a family and taking on every obligation. Composition is hiring the family's plumber when you need plumbing. Far fewer promises to break. In an interview: If I cannot say honestly 'every instance of the child can be used anywhere the parent is expected', I do not use inheritance. Composition lets me reuse the behaviour I want and expose only the contract I can actually keep.

Question 17

What is the Interface Segregation Principle?

Accepted Answer

No client should be forced to depend on methods it does not use. Prefer several small, focused interfaces over one large general-purpose one. When an interface is 'fat', every class that implements it must provide all the methods, even the irrelevant ones, usually by throwing an exception or leaving an empty body, and every class that uses it is coupled to parts it does not care about, so unrelated changes still ripple outward. Analogy: a job description. 'Software engineer' is a useful, focused role. 'Software engineer who also does the accounts, drives the delivery van, and caters lunch' forces every hire to fake three skills. Split the roles. In an interview: ISP says keep interfaces small and role-specific. If implementers keep stubbing out methods they cannot support, or callers only ever touch two methods of a ten-method interface, the interface is doing too much.

Question 18

Show a fat interface and how you would split it.

Accepted Answer

Split the big interface along the lines of the roles clients actually need. A class then implements only the interfaces relevant to it, and a caller depends only on the capability it uses. This also plays well with LSP, no class is forced to implement a method it cannot honour. Analogy: a printer showroom. Instead of one 'all machines do everything' spec sheet, you have separate labels: 'prints', 'scans', 'faxes'. A basic printer wears one label; the big office machine wears all three. In an interview: I break the interface up by client role, so each implementer only takes on what it can actually do, and each consumer only sees the slice it uses. Smaller interfaces mean fewer reasons for anything to change.

Question 19

What is a real-world sign that ISP is being violated?

Accepted Answer

Look for: implementations full of methods that throw UnsupportedOperationException or return null or do nothing; test doubles (mocks/stubs) that have to implement ten methods to test code that calls one; an interface whose name is vague ('IService', 'Manager', 'Handler'); or a change to one method of an interface forcing recompilation and retesting of classes that never call it. In frameworks, 'adapter' base classes with empty method bodies (like the old Java AWT listener adapters) exist precisely because a fat interface forced implementers to stub everything. Analogy: a TV remote with 60 buttons where you use 4. The other 56 are not just clutter, every firmware update has to account for all of them, and so do you when something breaks. In an interview: The clearest tells for me are stub-and-throw implementations and painful mocks. If testing a class that uses one method means implementing a dozen, the interface is not segregated and the consumer is coupled to things it does not use.

Question 20

What is the Dependency Inversion Principle?

Accepted Answer

Two parts: high-level modules (business logic) should not depend on low-level modules (database, email, file system); both should depend on abstractions. And abstractions should not depend on details; details should depend on abstractions. In practice: your business class should talk to an interface it defines, and the concrete database/email class should implement that interface. The dependency arrow that normally points from business code down to infrastructure gets 'inverted' to point at an interface in the middle that the business code owns. Analogy: a wall socket. Your laptop (high-level) does not depend on the power station (low-level). Both depend on the socket standard (the abstraction). The power company builds to the socket; your laptop plugs into the socket. In an interview: DIP says the important code, the business rules, should not know about databases or frameworks. It should depend on an abstraction, and the messy infrastructure should conform to that abstraction. That is what keeps the core of a system testable and portable.

Question 21

What does “depend on abstractions, not concretions” mean in day-to-day code?

Accepted Answer

It means: declare your fields, parameters, and return types as interfaces whenever there is more than one plausible implementation or you want to swap one in tests. Instead of 'private FileLogger logger', write 'private Logger logger'. Instead of 'new PostgresUserRepo()' inside a class, accept a 'UserRepository' in the constructor. The concrete class is chosen once, at the outer edge of the application (the 'main' method or a DI container), and passed inward. Analogy: hiring for a skill, not a person. You need 'someone who can drive', not 'Dave'. Dave might quit; the requirement 'can drive' does not. In an interview: Day to day it looks like: program to interfaces, and never call 'new' on a dependency inside the class that uses it. Push object creation to the edges and inject the finished collaborators.

Question 22

How is Dependency Inversion different from Dependency Injection?

Accepted Answer

Dependency Inversion is the principle: depend on abstractions, and keep high-level policy independent of low-level detail. Dependency Injection is one technique for achieving it: instead of a class creating its own dependencies, they are passed in, usually through the constructor. Inversion of Control is the broader idea that the framework or wiring code, not your class, decides what gets plugged in. You can follow DIP with plain constructor injection and no framework at all; a DI container (Spring, Guice) just automates the wiring. Analogy: DIP is the rule 'kitchens should be built to a standard so appliances are swappable'. DI is the delivery van that actually brings the specific fridge and plugs it in. One is the policy; the other is the mechanism. In an interview: I keep them straight like this: Dependency Inversion is the goal, Dependency Injection is the most common way to reach it, and Inversion of Control is the general principle that wiring decisions move out of the class. You do not need a framework to do DIP, you need constructor parameters and discipline about not calling 'new'.

Question 23

Show a DIP violation and the fix, and name the payoff.

Accepted Answer

Violation: a high-level NotificationService that constructs a concrete SmtpEmailClient itself. It cannot be tested without a mail server, cannot switch to SMS without editing, and drags the mail library into every build that touches business logic. Fix: define a MessageSender interface next to the service, depend on that, and implement it with SmtpMessageSender in the infrastructure layer. Payoff: the service is unit-testable with a fake, new channels are new classes, and the business code no longer imports the mail library. Analogy: a chef who insists on personally growing the vegetables. Give them a 'supplier' they can call instead, now they can cook in any kitchen, and you can change farms without retraining the chef. In an interview: The violation is 'new SmtpEmailClient()' inside the business class. The fix is an interface owned by the business layer plus constructor injection. The payoff I would emphasise is testability and the fact that infrastructure changes stop reaching into the core.

Question 24

How do the five principles reinforce each other?

Accepted Answer

They overlap heavily. SRP splits code into small focused classes, which naturally produces the small interfaces ISP wants. Those interfaces are the abstractions DIP tells you to depend on. Depending on abstractions is exactly what lets you satisfy OCP, because new behaviour becomes a new implementation instead of an edit. And LSP is the safety rule that keeps all of this working: it guarantees that swapping one implementation for another (which OCP and DIP rely on) does not break the caller. Do SRP and DIP well and you tend to get the other three almost for free. Analogy: five habits of a tidy workshop. Label your drawers (SRP), keep tools on standard hooks (DIP/ISP), so you can add a new tool without rearranging (OCP), and trust that any tool on the 'screwdriver' hook actually works like a screwdriver (LSP). Each habit makes the others easier. In an interview: I see SRP and DIP as the engines and the other three as consequences. Small responsibilities give you small interfaces; depending on those interfaces gives you extensibility; LSP is the contract that makes the substitution safe.

Question 25

What are the most common mistakes people make applying SOLID?

Accepted Answer

1) Premature abstraction, adding interfaces with a single implementation everywhere 'just in case', which adds indirection with no payoff. 2) Anaemic over-splitting, cutting classes so small that following a single use case means opening fifteen files. 3) Treating the principles as a checklist to maximise rather than a means to an end (maintainability). 4) Interfaces that mirror one class exactly (IFooService with only FooServiceImpl), that is not DIP, it is ceremony. 5) Forcing inheritance to satisfy 'reuse' and breaking LSP. The fix for all of them is to let a real, observed need for change drive the abstraction. Analogy: learning chess openings by rote and playing them even when the board says otherwise. The principles are patterns that usually help, not moves to make regardless of position. In an interview: The big one is abstracting before you have a reason to. I wait for a second implementation, a testing pain point, or a genuine volatility in requirements. Abstraction has a real cost in indirection, so it should buy something concrete.

Question 26

How would you introduce SOLID into a messy existing codebase?

Accepted Answer

Incrementally, driven by the work you are already doing. Do not stop to 'SOLID-ify' everything. When you need to change a class, first add characterization tests so you know its current behaviour. Then apply the smallest relevant refactor: extract a method, then a class (SRP); introduce an interface at the exact seam you need for testing (DIP); replace one switch with polymorphism when a new case arrives (OCP). Each change leaves the area a little better. Over months the hot spots, the files that change most often, get most of the cleanup, which is exactly where it pays off. Analogy: renovating a house you live in. You do not demolish it. You fix the room you are using this month, and over a few years the whole place is sound. In an interview: I let the changes I am already making pull the refactoring along. Add tests to lock behaviour, refactor the smallest useful amount at the seam I need, and concentrate effort on the files that change most. Big-bang rewrites in the name of SOLID usually fail.

Question 27

Can you give one small example that uses all five principles?

Accepted Answer

A checkout that calculates an order total with a pluggable discount and a pluggable receipt output. Checkout has one job, produce a total and a receipt (SRP). It depends on DiscountPolicy and ReceiptWriter interfaces (DIP), each tiny and role-specific (ISP). New discounts or output formats are new classes; Checkout is never edited (OCP). Every DiscountPolicy honours the same contract, take a total, return a valid discounted total, so any of them can be dropped in safely (LSP). Analogy: a coffee machine with swappable pods and a swappable cup size. The machine's job is fixed; the pod and the cup are chosen at use time; any valid pod works. In an interview: I would build exactly this on a whiteboard: one class with a single job, two small injected interfaces, new behaviour added as new implementations, and a note that every implementation must keep the interface's contract. That one example touches all five without feeling forced.

SOLID principles

What SOLID is

S, Single Responsibility

O, Open/Closed

L, Liskov Substitution

I, Interface Segregation

D, Dependency Inversion

Applying SOLID