OOPs interview questions — the four concepts everyone lists and almost nobody can defend
Encapsulation, inheritance, polymorphism, abstraction. Every candidate can define them. Almost none can answer the follow-up that actually decides the interview — why does it matter here.
Ask a hundred candidates to define encapsulation and ninety of them will get it right. "Wrapping data and methods together, hiding internal state." Correct, and worth nothing on its own — because the interviewer already knows the definition. What they are actually listening for is the sentence that comes after it.
That is the real shape of an OOPs interview: four concepts everyone has memorised, and one follow-up question per concept that most people have never had to answer out loud before.
Encapsulation
The definition candidates give: bundling data and the methods that operate on it, restricting direct access with access modifiers.
The follow-up that trips people up: "Why not just make every field public and skip the getters and setters?"
The honest answer isn't "it's a best practice" — that's the definition again, wearing a hat. The real answer is about control: a private field with a setter lets you validate, log, or change the internal representation later without breaking every place that touches the object. A public field gives that control to everyone who ever writes object.field = value, including the version of the code six months from now that assumed nobody would set a negative balance.
Inheritance
The definition: a class acquiring properties and behaviour from a parent class.
The follow-up: "Give me a case where inheritance was the wrong choice, and what you'd use instead."
This is where "is-a vs has-a" stops being a slogan from a textbook and becomes a real design decision. A Duck extends Bird is fine until you add a RubberDuck that can't fly, and the whole hierarchy strains to accommodate it. The better answer for most real cases is composition — a Duck has a FlightBehavior, which can be swapped per instance instead of forced through inheritance. Interviewers ask this specifically because "always use inheritance" is the mistake juniors make in their first real project.
Polymorphism
The definition: the same interface behaving differently depending on the actual object type.
The follow-up: "What actually happens at runtime when you call an overridden method through a parent reference?"
This is the question that separates "I read about it" from "I understand it." A good answer touches dynamic dispatch — the object's actual (runtime) type decides which method body runs, not the reference type it's declared as. Say it with an example: Animal a = new Dog(); a.makeSound(); calls Dog's implementation, not Animal's, because the JVM (or whichever runtime) looks up the method on the real object, not the variable's compile-time type.
Abstraction
The definition: exposing only the essential features of an object, hiding implementation detail.
The follow-up: "How is this different from encapsulation? Isn't that the same thing?"
It genuinely confuses people, because both involve hiding something. The distinction worth having ready: encapsulation hides data (implementation state), abstraction hides complexity (what the object does vs. how it does it). An interface with no implementation is pure abstraction with nothing to encapsulate. A private field with a getter is encapsulation that may expose very little abstraction at all. They usually work together, but they're solving different problems.
Why this format of question exists
None of these follow-ups are trick questions. They exist because "recite the definition" is a filter with no signal left in it — every candidate has read the same five articles before the interview. The follow-up is where the interviewer finds out whether the concept was ever applied to a decision, or only ever memorised for one.
The fix isn't more reading. It's saying the answer out loud, once, before the interview does it for you — the "why" comes out differently the first time you have to produce it live than it does on the page.
If you want to practice OOP questions with real follow-ups instead of a static list, we've got role-specific interview practice for Java/Backend and other languages, free to start.