Top 50 OOP Interview Questions with Answers (2026): Fresher to OOP Expert

💡 Why Interviewers Ask This: The first OOP question in every interview. They need to confirm you know the definition and can immediately name all four pillars.

A Class is a blueprint or template that defines the structure (attributes) and behavior (methods) of objects. A class does not consume memory on its own — memory is allocated only when an object (instance) is created from it. Think of a class as a cookie cutter; objects are the actual cookies.

💡 Why Interviewers Ask This: Foundational. They expect the blueprint analogy and the clarification that a class itself has no memory — only instances do.

An Object is an instance of a class — a concrete entity created at runtime that occupies memory. Each object has its own copy of the instance variables defined in the class. When you write Dog d = new Dog();, d is an object (instance) of the Dog class. An object has three characteristics: State (attributes/fields), Behavior (methods), and Identity (unique memory address).

💡 Why Interviewers Ask This: Distinguishing class from object is the most basic OOP check. Always mention state, behavior, and identity.

💡 Why Interviewers Ask This: If you can't name all four and give a one-line definition of each, the interview ends here. Memorize this list.

💡 Why Interviewers Ask This: They want to confirm you understand why OOP was invented — to tackle complexity in large-scale software that procedural code couldn't manage.

Encapsulation is the OOP mechanism of wrapping an object's data (attributes) and the operations on that data (methods) into a single unit (the class), and controlling access to internal state via access modifiers. Example: a BankAccount class keeps the balance field private. External code cannot directly say account.balance = -1000. Instead, it must call deposit() and withdraw() methods that enforce business rules. This is encapsulation — the data is hidden behind a controlled interface.

💡 Why Interviewers Ask This: A classic. The bank account example is the universally expected answer. Always include how the access modifier enforces the control.

Abstraction hides the internal implementation details of an object and exposes only the actions it can perform. The user knows what the object does, not how. Real-world example: when you call list.sort() you don't need to know whether it uses Timsort or Quicksort internally — that complexity is abstracted away. In Java/C++, abstraction is achieved through abstract classes and interfaces.

💡 Why Interviewers Ask This: They want the "what vs how" framing and a concrete code-level example. Mention that abstract classes and interfaces are the implementation mechanisms.

💡 Why Interviewers Ask This: This is the most commonly confused OOP pair. The protection vs simplification distinction is the key differentiator interviewers check for.

An Abstract Class is a class declared with the abstract keyword that cannot be instantiated directly. It may contain: (1) Abstract methods — declared without a body, which subclasses must override; and (2) Concrete methods — fully implemented shared logic. An abstract class gives a partial blueprint — it declares the contract (what subclasses must do) while optionally providing common behavior (how shared tasks are done). Example: an abstract Shape class with an abstract area() method — Circle and Rectangle subclasses provide their own implementations.

💡 Why Interviewers Ask This: They check whether you know the two key rules: cannot instantiate, and can mix abstract + concrete methods.

An Interface is a pure contract that specifies what methods a class must implement, without dictating how. Before Java 8, all interface methods were implicitly abstract and public with no implementation. Java 8+ added default and static methods. A class can implement multiple interfaces, enabling a form of multiple inheritance while avoiding the Diamond Problem. Think of an interface as a job description — it lists requirements, but the employee (implementing class) decides how to fulfil them.

💡 Why Interviewers Ask This: Key to Java design. They expect you to mention that interfaces enable multiple inheritance of type and that Java 8 changed the rules with default methods.

💡 Why Interviewers Ask This: The most asked comparison in Java interviews. Know all five differences — the "when to use" differentiation is what separates good answers from great ones.

Inheritance is the OOP mechanism by which a child class (subclass/derived class) acquires the properties and behaviors of a parent class (superclass/base class). It promotes code reuse — common logic lives in the parent and is shared by all children. It establishes an IS-A relationship: a Dog IS-A Animal. The child class can extend the parent (add new fields/methods) or override inherited methods to change behavior.

💡 Why Interviewers Ask This: They check that you associate inheritance with IS-A and can distinguish it from Composition (HAS-A). Always mention code reuse and IS-A.

💡 Why Interviewers Ask This: Expect this to be followed by the Diamond Problem question. Know all 5 types and flag that Java avoids multiple class inheritance.

Multiple Inheritance allows a class to inherit from more than one parent class simultaneously. It is problematic because of the Diamond Problem: if class C inherits from both A and B, and both A and B inherit from D and override the same method, the compiler cannot determine which version C should use — creating ambiguity. Java prevents this with classes by allowing only single class inheritance. It enables multiple type inheritance through interfaces because interfaces don't have implementation (pre-Java 8). C++ handles the Diamond Problem via virtual inheritance.

💡 Why Interviewers Ask This: The Diamond Problem is one of the most asked OOP follow-ups. Draw the diamond mentally (D at top, A+B in middle, C at bottom) and explain the ambiguity.

💡 Why Interviewers Ask This: They want to know you understand when not to use inheritance. The "favor composition over inheritance" principle is a senior-level design insight.

💡 Why Interviewers Ask This: The lifecycle dependency is the defining differentiator. If the child cannot exist without the parent, it's Composition. If it can, it's Aggregation.

💡 Why Interviewers Ask This: A subtle but important distinction in Java interviews. Static methods cannot be polymorphically overridden — they are hidden, not overridden.

Polymorphism (Greek for “many forms”) is the OOP ability that allows a single interface, method name, or operator to work differently based on the context or the actual type of the object at runtime. There are two types: Compile-Time Polymorphism (also called Static or Early Binding — achieved through Method Overloading) and Run-Time Polymorphism (also called Dynamic or Late Binding — achieved through Method Overriding). Example: draw(Circle), draw(Rectangle), and draw(Triangle) can all be called as draw(shape) — the right version is selected at runtime.

💡 Why Interviewers Ask This: The fourth pillar. Always give both types with their binding mechanism. The shape example is universally recognized.

Compile-Time Polymorphism is resolved by the compiler before the program runs, achieved through Method Overloading. In Method Overloading, multiple methods exist in the same class with the same name but different parameter lists (different number, type, or order of parameters). The compiler inspects the method call, determines which version matches based on the arguments, and binds the call statically. Example: print(int), print(String), and print(double) — the compiler decides which one to call. It is also called Early Binding.

💡 Why Interviewers Ask This: They check whether you use compile-time and method overloading as synonyms. You must also mention that the return type alone cannot be used to overload (the parameter list must differ).

Run-Time Polymorphism is resolved at runtime through Method Overriding, where a subclass provides a new implementation for a method already defined in the parent class with the same signature. The JVM uses a virtual method table (vtable) to decide which version to call based on the actual object type, not the reference type. Example: both Cat and Dog override Animal.makeSound(). When you call animal.makeSound() on a Dog object, the Dog's implementation runs. This is also called Late Binding or Dynamic Dispatch.

💡 Why Interviewers Ask This: The vtable is the underlying mechanism. Mentioning dynamic dispatch and that the object type (not reference type) drives the decision earns you senior-level points.

💡 Why Interviewers Ask This: One of the top 5 most asked OOP questions. Know all constraints for both — especially that static/final/private methods cannot be overridden.

Operator Overloading is redefining the behavior of standard operators (+, -, *, ==, etc.) for user-defined types. In C++, you can overload operators so that vec1 + vec2 calls your custom operator+() function for a Vector class. This is a form of Compile-Time Polymorphism. Java does NOT support operator overloading (except for the + operator which is built-in for String concatenation). Python supports it via dunder methods (__add__, __eq__, etc.).

💡 Why Interviewers Ask This: Language-specific awareness check. For Java interviews: state clearly that Java doesn't support operator overloading (except the String + special case).

A Virtual Function (C++ term) is a member function declared with the virtual keyword in the base class, enabling Run-Time Polymorphism through dynamic dispatch. When a derived class overrides a virtual function and it is called through a base-class pointer or reference, the overridden version in the derived class is executed — not the base class version. The compiler creates a virtual table (vtable) for each class with virtual functions. In Java, all non-static, non-final, non-private instance methods are virtual by default — you don't need a keyword.

💡 Why Interviewers Ask This: Critical in C++ interviews. In Java context, know that the language inherently makes all overridable methods virtual. The vtable is the implementation mechanism.

In C++, a Pure Virtual Function is declared with = 0 in the base class: virtual void draw() = 0;. It has no implementation in the base class and must be overridden in every concrete derived class. A class that contains at least one pure virtual function is called an Abstract Class in C++ — it cannot be instantiated. This is C++'s mechanism for enforcing interface contracts, equivalent to Java's abstract methods inside abstract classes or interface methods.

💡 Why Interviewers Ask This: For C++ roles specifically. In Java comparisons, map pure virtual → abstract method. The = 0 syntax is the key C++-specific detail.

💡 Why Interviewers Ask This: Polymorphism fundamentals. The ClassCastException risk of downcasting and the instanceof safety check are what interviewers look for beyond the basic definition.

💡 Why Interviewers Ask This: Key fact: if you define a parameterized constructor in Java, the compiler no longer provides a default constructor — you must explicitly add it if needed.

A Copy Constructor creates a new object as an exact copy of an existing object. In C++, it is called when an object is passed by value, returned from a function, or explicitly copied. The default compiler-provided copy constructor does a shallow copy — copying field values directly. For objects with dynamic memory/pointers, you must write a custom copy constructor to do a deep copy (allocating new memory). In Java, there is no built-in copy constructor — you implement it manually as a constructor taking the same class as a parameter, or use Cloneable.

💡 Why Interviewers Ask This: Shallow copy vs deep copy distinction is the key insight. Shallow copy shares the same memory — modifying one object affects the other.

A Destructor is a special method automatically called when an object is destroyed to perform cleanup — like releasing memory, closing file handles, or freeing network connections. In C++, it is named with a tilde (~ClassName()) and called automatically when an object goes out of scope or is deleted. In Java, there are no explicit destructors — the Garbage Collector (GC) manages memory automatically. Java had a finalize() method but it is deprecated since Java 9 because its invocation timing is unpredictable. Instead, use try-with-resources and the AutoCloseable interface.

💡 Why Interviewers Ask This: For C++: the Rule of Three (if you define destructor, copy constructor, or copy assignment — define all three). For Java: GC + try-with-resources as the modern pattern.

Garbage Collection (GC) is the automatic memory management process that identifies and frees heap memory occupied by objects that are no longer reachable by any reference in the program. Java's GC uses a generational model: Young Generation (newly created objects, frequently collected), Old Generation (long-lived objects), and Metaspace (class metadata). Modern JVMs use the G1 Garbage Collector by default. GC eliminates manual memory management (and the memory leaks/dangling pointers it causes in C/C++) but introduces GC pauses that can affect latency.

💡 Why Interviewers Ask This: Backend engineers must understand GC pauses — they cause "stop-the-world" events. Knowing generational GC shows JVM depth. "GC runs when an object has no more references" is the minimum answer.

Object Cloning creates a copy of an existing object. In Java, a class must implement the Cloneable interface and override the clone() method from Object. Shallow Clone (default): copies primitive fields by value and object references by value — both original and clone point to the same nested objects. Deep Clone: recursively copies nested objects — original and clone are completely independent. For most cases, a copy constructor or a serialization-based deep clone is preferred over implementing Cloneable (which is considered a flawed API).

💡 Why Interviewers Ask This: Shallow vs deep clone is the follow-up they are building toward. Know that modifying a shared nested object in a shallow clone will affect both the original and the clone.

An Object Pool is a design pattern that pre-creates and reuses a set of expensive objects rather than creating and destroying them on demand. When a client needs an object, it borrows one from the pool; when done, it returns it. This avoids the overhead of object allocation and GC for frequently used, costly-to-create objects. Classic examples: Database Connection Pools (JDBC, HikariCP), Thread Pools (ExecutorService), and HTTP Connection Pools. The pool manages a fixed or dynamic maximum number of instances.

💡 Why Interviewers Ask This: Performance design knowledge. Any backend engineer working with databases must understand connection pooling. The key benefit is avoiding per-request connection creation overhead.

💡 Why Interviewers Ask This: Key OOP encapsulation mechanism. The "protected + subclass in other package" rule for protected is what trips up many candidates.

A Static Method belongs to the class itself, not to any instance. It can be called without creating an object (ClassName.methodName()). It cannot access instance variables or instance methods directly — only other static members. Static methods cannot be overridden (they can only be hidden, as explained in Q17). They are resolved at compile time based on the reference type, not the runtime object type. Common use: utility/helper classes (Math.sqrt(), Collections.sort()).

💡 Why Interviewers Ask This: "Can static methods be overridden?" is a classic Java trick question. The answer is NO — they are hidden, not overridden. Runtime polymorphism doesn't apply to static methods.

A Static Variable (class variable) is a field declared with the static keyword that belongs to the class, not to any individual instance. There is only one copy of a static variable shared across all instances of the class — it lives in the method area (Metaspace) of the JVM, not on the heap. Classic use cases: keeping a count of all objects created (static int objectCount), defining constants (static final double PI = 3.14159). Modifying a static variable from one instance affects what all other instances see.

💡 Why Interviewers Ask This: The "one copy shared by all instances" principle is what they check. The object count example is universally recognized.

💡 Why Interviewers Ask This: All three uses are asked. The constructor chaining use (this()) and the method chaining pattern (returning this) are the senior-level expectations.

💡 Why Interviewers Ask This: Often followed by: "What happens if you don't put super() as the first line?" — Java auto-inserts it, so both constructors run in order: parent first, then child.

Coupling measures the degree of interdependence between classes/modules. High Coupling (bad): a change in one class forces changes in many dependent classes — fragile, hard to test, hard to maintain. Loose Coupling (good): classes interact through well-defined interfaces or abstractions, minimizing dependencies. Loose coupling is achieved through Dependency Injection, programming to interfaces, and following the Dependency Inversion Principle. Example: A NotificationService that directly instantiates EmailSender is tightly coupled. Injecting an INotificationChannel interface is loosely coupled.

💡 Why Interviewers Ask This: Coupling and Cohesion are the two fundamental measures of good OOP design. Always tie this to Dependency Injection as the solution for high coupling.

Cohesion measures how strongly related and focused the responsibilities of a single class/module are. High Cohesion (good): a class has one well-defined, focused purpose — all its methods and fields serve that one purpose. Low Cohesion (bad): a class does too many unrelated things — a "God class". High cohesion is directly embodied by the Single Responsibility Principle. Rule: if you can't describe a class's purpose in one sentence without using "and," it probably violates cohesion.

💡 Why Interviewers Ask This: Goal: low coupling + high cohesion. If you say this combination in your answer, you demonstrate senior-level design thinking.

An Immutable Object is one whose state cannot be changed after it is created. In Java: declare the class as final, make all fields private final, provide no setters, initialize all fields in the constructor, and return defensive copies of mutable objects from getters. Classic Java example: String is immutable. Benefits: thread-safe by design (no synchronization needed), safe to share, ideal for cache keys and Map keys. String, Integer, and all other wrapper classes in Java are immutable.

💡 Why Interviewers Ask This: Thread safety is the primary motivation. The 5-step recipe for making a class immutable in Java is the standard expected answer.

Association is a relationship where one class uses or interacts with another class, but neither owns the other. It is the broadest HAS-A relationship. Types: (1) Unidirectional: A knows about B, but B doesn't know about A. (2) Bidirectional: Both A and B know about each other. Subtypes of Association are Aggregation (weak ownership — independent lifecycle) and Composition (strong ownership — dependent lifecycle). Example: A Student can be associated with a Teacher — neither owns the other, and both exist independently.

💡 Why Interviewers Ask This: Tests knowledge of the UML relationship hierarchy: Association → Aggregation → Composition (most to least loose). Know the ownership and lifecycle implications at each level.

Method Chaining is a programming pattern where each method returns the current object (this), allowing multiple method calls to be chained in a single expression. It creates a Fluent Interface. Example using a QueryBuilder: query.select("*").from("users").where("age > 18").limit(10).build(). Java's StringBuilder uses method chaining. Popular in builder pattern implementations and test frameworks like AssertJ. It improves code readability but can make debugging harder (entire chain appears as one line in a stack trace).

💡 Why Interviewers Ask This: A common Java design pattern. The key is that every method returns this. Be ready to link this to the Builder pattern.

Delegation is a design technique where an object forwards a task to a helper (delegate) object rather than implementing the behavior itself. It is an alternative to inheritance — instead of a class inheriting behavior, it holds a reference to another class that provides the behavior (HAS-A over IS-A). Example: Printer delegates printing to an InkJetEngine or a LaserEngine, allowing the printing technology to change at runtime. This implements the Strategy and Decorator patterns. The key benefit: behaviour can be changed at runtime by swapping the delegate object.

💡 Why Interviewers Ask This: "Favor composition over inheritance" is tested here. Delegation is the mechanism that makes composition work — the delegating class stays unchanged when behaviour is swapped.

A Method Signature is the unique identifier of a method, consisting of the method name and its parameter list (number, type, and order of parameters). In Java, the return type is NOT part of the signature. Two methods with the same name but different parameter lists have different signatures (overloading). Two methods with the same name and same parameter list but different return types do NOT compile — they are considered duplicate signatures. The method signature is what the compiler uses to resolve method overloading at compile time.

💡 Why Interviewers Ask This: "Is return type part of the method signature?" is a classic Java trick question. NO. If you know this, it clarifies why overloading by return type alone doesn't work.

💡 Why Interviewers Ask This: SOLID knowledge separates good engineers from great ones. Know all five, give a one-line definition of each, and have a real-world example ready for LSP and DIP.

💡 Why Interviewers Ask This: You need to know the three GoF categories and at least 2-3 patterns from each. In real interviews, they almost always ask about Singleton, Factory, or Observer next.

The Singleton Pattern ensures that a class has only one instance throughout the application's lifetime and provides a global access point to that instance. Implementation: (1) Make the constructor private. (2) Store the instance in a private static field. (3) Expose it through a public static getInstance() method. Thread-safe implementation: use double-checked locking with volatile or an Enum (Java's recommended Singleton approach). Examples in practice: Database connection pools, logging services, configuration managers.

💡 Why Interviewers Ask This: The most asked design pattern. They always follow up with: "How do you make it thread-safe?" Know double-checked locking AND enum-based Singleton — the enum approach is the Joshua Bloch recommendation.

The Factory Method Pattern defines an interface for creating an object but lets subclasses (or a factory method) decide which class to instantiate. Instead of calling new ConcreteClass() directly, the client calls a factory method that returns the appropriate subtype based on input or configuration. Example: a ShapeFactory.createShape("circle") returns a Circle instance; createShape("square") returns a Square. The client works with the Shape interface — it never knows the concrete type. Benefits: Open/Closed Principle (add new shapes without touching the factory logic), decoupled object creation.

💡 Why Interviewers Ask This: Second most asked pattern after Singleton. Know it implements the Open/Closed Principle — you extend the factory without modifying existing code.

The Observer Pattern defines a one-to-many dependency: when one object (the Subject/Publisher) changes state, all dependent objects (Observers/Subscribers) are notified automatically. The subject maintains a list of observers and calls notify() on all of them when its state changes. Examples: Java's EventListener, React state management, stock price tickers, UI frameworks responding to model changes. This pattern is the foundation of event-driven architecture and the Publish-Subscribe messaging model. Also called the “Hollywood Principle” — “Don't call us, we'll call you.”

💡 Why Interviewers Ask This: Third most asked pattern. The "Hollywood Principle" quote and its real-world connection to event-driven systems / message queues shows engineering depth.

💡 Why Interviewers Ask This: DI is fundamental to Spring and enterprise Java. Know the difference between the principle (DIP) and the implementation technique (DI). Constructor injection is preferred for mandatory dependencies.

💡 Why Interviewers Ask This: Often the final question — they want a senior-perspective wrap-up. Mention modularity, reusability, and the Open/Closed Principle. Connecting OOP to business domains shows systems thinking.