OOP
Object-Oriented Programming Interview Questions
Object-oriented programming (OOP) questions appear in almost every software engineering interview, from fresh-grad roles to senior positions. Interviewers use these questions to probe how deeply you understand software design — not just syntax, but why OOP concepts exist and when they genuinely help.
The four pillars (encapsulation, inheritance, polymorphism, abstraction) are the vocabulary; the SOLID principles are the judgement. Knowing both lets you reason out loud about trade-offs, which is exactly what interviewers want to hear.
Key Concepts
Encapsulation
Bundle data and the methods that operate on it inside a class, and hide implementation details behind a public interface. This means marking fields private and exposing only what callers need. The payoff: you can change the internals without breaking any code that depends on the class.
Inheritance
A subclass inherits the state and behaviour of its parent, then extends or overrides it. Inheritance models 'is-a' relationships. Overuse causes fragile hierarchies — if the parent changes, every subclass breaks. Prefer composition ('has-a') over deep inheritance chains.
Polymorphism
The same interface, multiple implementations. At runtime, the correct method is dispatched based on the object's actual type (dynamic dispatch). This is what makes code open to extension without modification — you can add a new subclass and existing code just works.
Abstraction
Expose what something does, hide how it does it. Abstract classes and interfaces define contracts. Callers depend on the abstraction, not the concrete implementation. This is the mechanism behind dependency inversion and what makes testing and swapping implementations easy.
SOLID Principles
Single Responsibility: a class should have one reason to change. Open/Closed: open for extension, closed for modification. Liskov Substitution: subtypes must be substitutable for their base type. Interface Segregation: many specific interfaces beat one fat interface. Dependency Inversion: depend on abstractions, not concretions. Violations of these principles are a common interview discussion topic.
Composition vs Inheritance
Composition (giving a class a field of another type) is usually more flexible than inheritance. It avoids tight coupling between parent and child, makes unit testing easier (you can inject fakes), and sidesteps the fragile base-class problem. A common interview follow-up: 'When would you still choose inheritance?'
Sample Interview Questions
What is the difference between an abstract class and an interface?
Answer: An abstract class can contain state and method implementations; an interface defines only a contract (method signatures). A class can implement multiple interfaces but typically only extend one abstract class.
Why it matters: Use an abstract class when there is shared implementation to reuse. Use an interface when you want to define a capability that unrelated classes can share.
Explain the Liskov Substitution Principle with an example.
Answer: If S is a subtype of T, objects of type S must be usable wherever objects of type T are expected without altering correctness. Classic violation: a Square class that extends Rectangle but overrides setWidth to also set height — code that holds a Rectangle and calls setWidth(5); setHeight(3) gets unexpected behaviour.
Why it matters: LSP violations break polymorphism. If you can't safely swap a subtype, the inheritance hierarchy is wrong — rethink the design.
Why is 'favour composition over inheritance' good advice?
Answer: Composition keeps classes loosely coupled. You can change a composed object's behaviour at runtime by swapping the injected dependency. Inheritance fixes the relationship at compile time and can force brittle changes across a whole hierarchy.
Why it matters: This is a design judgement question. Demonstrate you understand the trade-offs rather than treating it as an absolute rule.
Ready to test yourself?
Apply what you've read with a timed 10-question quiz on OOP.
Start OOP Quiz →