OOPs Interview Questions

There are many reasons why OOPs is mostly preferred, but the most important among them are: 

• OOPs helps users to understand the software easily, although they don’t know the actual implementation.
• With OOPs, the readability, understandability, and maintainability of the code increase multifold.
• Even very big software can be easily written and managed easily using OOPs.

OOPs refers to Object-Oriented Programming. It is the programming paradigm that is defined using objects. Objects can be considered as real-world instances of entities like class, that have some characteristics and behaviors.

The programming languages that use and follow the Object-Oriented Programming paradigm or OOPs, are known as Object-Oriented Programming languages. Some of the major Object-Oriented Programming languages include:

• Java
• C++
• Javascript
• Python
• PHP

And many more.

Programming paradigms refers to the method of classification of programming languages based on their features. There are mainly two types of Programming Paradigms:

• Imperative Programming Paradigm
• Declarative Programming Paradigm

Now, these paradigms can be further classified based:

1. Imperative Programming Paradigm: Imperative programming focuses on HOW to execute program logic and defines control flow as statements that change a program state. This can be further classified as:
a) Procedural Programming Paradigm: Procedural programming specifies the steps a program must take to reach the desired state, usually read in order from top to bottom.
b) Object-Oriented Programming or OOP: Object-oriented programming (OOP) organizes programs as objects, that contain some data and have some behavior.
c) Parallel Programming: Parallel programming paradigm breaks a task into subtasks and focuses on executing them simultaneously at the same time.

2. Declarative Programming Paradigm: Declarative programming focuses on WHAT to execute and defines program logic, but not a detailed control flow. Declarative paradigm can be further classified into:
a) Logical Programming Paradigm: Logical programming paradigm is based on formal logic, which refers to a set of sentences expressing facts and rules about how to solve a problem
b) Functional Programming Paradigm: Functional programming is a programming paradigm where programs are constructed by applying and composing functions.
c) Database Programming Paradigm: Database programming model is used to manage data and information structured as fields, records, and files.

Structured Programming refers to the method of programming which consists of a completely structured control flow. Here structure refers to a block, which contains a set of rules, and has a definitive control flow, such as (if/then/else), (while and for), block structures, and subroutines.

Nearly all programming paradigms include Structured programming, including the OOPs model.

OOPs or Object Oriented Programming mainly comprises of the below four features, and make sure you don't miss any of these:

• Inheritance
• Encapsulation
• Polymorphism
• Data Abstraction
   

• OOPs is very helpful in solving very complex level of problems.
• Highly complex programs can be created, handled, and maintained easily using object-oriented programming.
• OOPs, promote code reuse, thereby reducing redundancy.
• OOPs also helps to hide the unnecessary details with the help of Data Abstraction.
• OOPs, are based on a bottom-up approach, unlike the Structural programming paradigm, which uses a top-down approach.
• Polymorphism offers a lot of flexibility in OOPs.

OOPs programming paradigm is considered as a better style of programming. Not only it helps in writing a complex piece of code easily, but it also allows users to handle and maintain them easily as well. Not only that, the main pillar of OOPs - Data Abstraction, Encapsulation, Inheritance, and Polymorphism, makes it easy for programmers to solve complex scenarios. As a result of these, OOPs is so popular.

Access specifiers, as the name suggests, are a special type of keywords, which are used to control or specify the accessibility of entities like classes, methods, etc. Some of the access specifiers or access modifiers include “private”, “public”, etc. These access specifiers also play a very vital role in achieving Encapsulation - one of the major features of OOPs.

Yes, with more powers comes more complications. Inheritance is a very powerful feature in OOPs, but it has some limitations too. Inheritance needs more time to process, as it needs to navigate through multiple classes for its implementation. Also, the classes involved in Inheritance - the base class and the child class, are very tightly coupled together. So if one needs to make some changes, they might need to do nested changes in both classes. Inheritance might be complex for implementation, as well. So if not correctly implemented, this might lead to unexpected errors or incorrect outputs.

The various types of inheritance include:

• Single inheritance
• Multiple inheritances
• Multi-level inheritance
• Hierarchical inheritance
• Hybrid inheritance

The subclass is a part of Inheritance. The subclass is an entity, which inherits from another class. It is also known as the child class.

Superclass is also a part of Inheritance. The superclass is an entity, which allows subclasses or child classes to inherit from itself.

An interface refers to a special type of class, which contains methods, but not their definition. Only the declaration of methods is allowed inside an interface. To use an interface, you cannot create objects. Instead, you need to implement that interface and define the methods for their implementation. 

Static Polymorphism is commonly known as the Compile time polymorphism. Static polymorphism is the feature by which an object is linked with the respective function or operator based on the values during the compile time. Static or Compile time Polymorphism can be achieved through Method overloading or operator overloading.

Dynamic Polymorphism or Runtime polymorphism refers to the type of Polymorphism in OOPs, by which the actual implementation of the function is decided during the runtime or execution. The dynamic or runtime polymorphism can be achieved with the help of method overriding.

Overloading is a compile-time polymorphism feature in which an entity has multiple implementations with the same name. For example, Method overloading and Operator overloading.

Whereas Overriding is a runtime polymorphism feature in which an entity has the same name, but its implementation changes during execution. For example, Method overriding.
Image

Data abstraction is accomplished with the help of abstract methods or abstract classes.

An abstract class is a special class containing abstract methods. The significance of abstract class is that the abstract methods inside it are not implemented and only declared. So as a result, when a subclass inherits the abstract class and needs to use its abstract methods, they need to define and implement them.

Interface and abstract classes both are special types of classes that contain only the methods declaration and not their implementation. But the interface is entirely different from an abstract class. The main difference between the two is that when an interface is implemented, the subclass must define all its methods and provide its implementation. Whereas in object-oriented programming, when a subclass inherits from an abstract class with abstract methods, the subclass is generally required to provide concrete implementations for all of those abstract methods in the abstract class unless the subclass itself is declared as abstract.

Also, an abstract class can contain abstract methods as well as non-abstract methods.

An exception can be considered as a special event, which is raised during the execution of a program at runtime, that brings the execution to a halt. The reason for the exception is mainly due to a position in the program, where the user wants to do something for which the program is not specified, like undesirable input.

No one wants its software to fail or crash. Exceptions are the major reason for software failure. The exceptions can be handled in the program beforehand and prevent the execution from stopping. This is known as exception handling.
So exception handling is the mechanism for identifying the undesirable states that the program can reach and specifying the desirable outcomes of such states.
Try-catch is the most common method used for handling exceptions in the program.

Object-oriented programming revolves around entities like objects. Each object consumes memory and there can be multiple objects of a class. So if these objects and their memories are not handled properly, then it might lead to certain memory-related errors and the system might fail.

Garbage collection refers to this mechanism of handling the memory in the program. Through garbage collection, the unwanted memory is freed up by removing the objects that are no longer needed.

No. Java applications are based on Object-oriented programming models or OOPs concept, and hence they cannot be implemented without it.

However, on the other hand, C++ can be implemented without OOPs, as it also supports the C-like structural programming model.

No, class and structure are not the same. Though they appear to be similar, they have differences that make them apart. For example, the structure is saved in the stack memory, whereas the class is saved in the heap memory. Also, Data Abstraction cannot be achieved with the help of structure, but with class, Abstraction is majorly used.

A class can be understood as a template or a blueprint, which contains some values, known as member data or member, and some set of rules, known as behaviors or functions. So when an object is created, it automatically takes the data and functions that are defined in the class.
Therefore the class is basically a template or blueprint for objects. Also one can create as many objects as they want based on a class.

For example, first, a car’s template is created. Then multiple units of car are created based on that template.

An object refers to the instance of the class, which contains the instance of the members and behaviors defined in the class template. In the real world, an object is an actual entity to which a user interacts, whereas class is just the blueprint for that object. So the objects consume space and have some characteristic behavior.
For example, a specific car.

One can visualize Encapsulation as the method of putting everything that is required to do the job, inside a capsule and presenting that capsule to the user. What it means is that by Encapsulation, all the necessary data and methods are bind together and all the unnecessary details are hidden to the normal user. So Encapsulation is the process of binding data members and methods of a program together to do a specific job, without revealing unnecessary details.

Encapsulation can also be defined in two different ways:

1) Data hiding: Encapsulation is the process of hiding unwanted information, such as restricting access to any member of an object.

2) Data binding: Encapsulation is the process of binding the data members and the methods together as a whole, as a class.

Polymorphism is composed of two words - “poly” which means “many”, and “morph” which means “shapes”. Therefore Polymorphism refers to something that has many shapes.

In OOPs, Polymorphism refers to the process by which some code, data, method, or object behaves differently under different circumstances or contexts. Compile-time polymorphism and Run time polymorphism are the two types of polymorphisms in OOPs languages.

C++ is an Object-oriented programming language and it supports Polymorphism as well:

• Compile Time Polymorphism: C++ supports compile-time polymorphism with the help of features like templates, function overloading, and default arguments.
• Runtime Polymorphism: C++ supports Runtime polymorphism with the help of features like virtual functions. Virtual functions take the shape of the functions based on the type of object in reference and are resolved at runtime.

Compile Time Polymorphism: Compile time polymorphism, also known as Static Polymorphism, refers to the type of Polymorphism that happens at compile time. What it means is that the compiler decides what shape or value has to be taken by the entity in the picture.

Example:

// In this program, we will see how multiple functions are created with the same name, 
// but the compiler decides which function to call easily at the compile time itself.
class CompileTimePolymorphism{
   // 1st method with name add
   public int add(int x, int y){ 
   return x+y;
   }
   // 2nd method with name add
   public int add(int x, int y, int z){
   return x+y+z;
   }
   // 3rd method with name add
   public int add(double x, int y){ 
   return (int)x+y;
   }
   // 4th method with name add
   public int add(int x, double y){ 
   return x+(int)y;
   }
}
class Test{
   public static void main(String[] args){
   CompileTimePolymorphism demo=new CompileTimePolymorphism();
   // In the below statement, the Compiler looks at the argument types and decides to call method 1
   System.out.println(demo.add(2,3));
   // Similarly, in the below statement, the compiler calls method 2
   System.out.println(demo.add(2,3,4));
   // Similarly, in the below statement, the compiler calls method 4
   System.out.println(demo.add(2,3.4));
   // Similarly, in the below statement, the compiler calls method 3
   System.out.println(demo.add(2.5,3)); 
   }
}

In the above example, there are four versions of add methods. The first method takes two parameters while the second one takes three. For the third and fourth methods, there is a change of order of parameters. The compiler looks at the method signature and decides which method to invoke for a particular method call at compile time.

Runtime Polymorphism: Runtime polymorphism, also known as Dynamic Polymorphism, refers to the type of Polymorphism that happens at the run time. What it means is it can't be decided by the compiler. Therefore what shape or value has to be taken depends upon the execution. Hence the name Runtime Polymorphism.

Example:

class AnyVehicle{
   public void move(){
   System.out.println(“Any vehicle should move!!”);
   }
}
class Bike extends AnyVehicle{
   public void move(){
   System.out.println(“Bike can move too!!”);
   }
}
class Test{
   public static void main(String[] args){
   AnyVehicle vehicle = new Bike();
   // In the above statement, as you can see, the object vehicle is of type AnyVehicle
   // But the output of the below statement will be “Bike can move too!!”, 
   // because the actual implementation of object ‘vehicle’ is decided during runtime vehicle.move();
   vehicle = new AnyVehicle();
   // Now, the output of the below statement will be “Any vehicle should move!!”, 
   vehicle.move();
   }
}

As the method to call is determined at runtime, as shown in the above code, this is called runtime polymorphism. 

Inheritance is one of the major features of object-oriented programming, by which an entity inherits some characteristics and behaviors of some other entity and makes them their own. Inheritance helps to improve and facilitate code reuse.

Let me explain to you with a common example. Let's take three different vehicles - a car, truck, or bus. These three are entirely different from one another with their own specific characteristics and behavior. But. in all three, you will find some common elements, like steering wheel, accelerator, clutch, brakes, etc. Though these elements are used in different vehicles, still they have their own features which are common among all vehicles. This is achieved with inheritance. The car, the truck, and the bus have all inherited the features like steering wheel, accelerator, clutch, brakes, etc, and used them as their own. Due to this, they did not have to create these components from scratch, thereby facilitating code reuse.

Contrary to constructors, which initialize objects and specify space for them, Destructors are also special methods. But destructors free up the resources and memory occupied by an object. Destructors are automatically called when an object is being destroyed. 

Copy Constructor is a type of constructor, whose purpose is to copy an object to another. What it means is that a copy constructor will clone an object and its values, into another object, is provided that both the objects are of the same class.

The most common classification of constructors includes:

Default constructor: The default constructor is the constructor which doesn’t take any argument. It has no parameters.

class ABC
{
   int x;
      
   ABC()
   {
       x = 0;
   }
}

Parameterized constructor: The constructors that take some arguments are known as parameterized constructors.

 class ABC
{
   int x;
      
   ABC(int y)
   {
       x = y;
   }
}

Copy constructor: A copy constructor is a member function that initializes an object using another object of the same class.

class ABC
{
   int x;
      
   ABC(int y)
   {
       x = y;
   }
   // Copy constructor
   ABC(ABC abc)
   {
       x = abc.x;
   }
}

Constructors are special methods whose name is the same as the class name. The constructors serve the special purpose of initializing the objects.
For example, suppose there is a class with the name “MyClass”, then when you instantiate this class, you pass the syntax:
MyClass myClassObject = new MyClass();

Now here, the method called after “new” keyword - MyClass(), is the constructor of this class. This will help to instantiate the member data and methods and assign them to the object myClassObject.

No. An object is necessary to be created if the base class has non-static methods. But if the class has static methods, then objects don’t need to be created. You can call the class method directly in this case, using the class name.

Classes do not consume any memory. They are just a blueprint based on which objects are created. Now when objects are created, they actually initialize the class members and methods and therefore consume memory.

If you are a user, and you have a problem statement, you don't want to know how the components of the software work, or how it's made. You only want to know how the software solves your problem. Abstraction is the method of hiding unnecessary details from the necessary ones. It is one of the main features of OOPs. 
For example, consider a car. You only need to know how to run a car, and not how the wires are connected inside it. This is obtained using Abstraction.

The term “inheritance” means “receiving some quality or behavior from a parent to an offspring.” In object-oriented programming, inheritance is the mechanism by which an object or class (referred to as a child) is created using the definition of another object or class (referred to as a parent). Inheritance not only helps to keep the implementation simpler but also helps to facilitate code reuse.

#include<iostream> 
 
using namespace std; 
class BaseClass1 { 
public: 
    BaseClass1() 
    { cout << " BaseClass1 constructor called" << endl;  } 
}; 
 
class BaseClass2 { 
public: 
    BaseClass2() 
    { cout << "BaseClass2 constructor called" << endl;  } 
}; 
 
class DerivedClass: public BaseClass1, public BaseClass2 { 
  public: 
   DerivedClass() 
    {  cout << "DerivedClass constructor called" << endl;  } 
}; 
 
int main() 
{ 
  DerivedClass derived_class; 
  return 0; 
}

Output:

BaseClass1 constructor called
BaseClass2 constructor called
DerivedClass constructor called

Reason:
The above program demonstrates Multiple inheritances. So when the Derived class’s constructor is called, it automatically calls the Base class's constructors from left to right order of inheritance.

class Scaler
{
   static int i;

   static
   {
       System.out.println(“a”);

       i = 100;
   }
}

public class StaticBlock
{
   static
   {
       System.out.println(“b”);
   }

   public static void main(String[] args)
   {
       System.out.println(“c”);

       System.out.println(Scaler.i);
   }
}

Output:

b
c
a
100

Reason:
Firstly the static block inside the main-method calling class will be implemented. Hence ‘b’ will be printed first. Then the main method is called, and now the sequence is kept as expected.

#include<iostream> 
using namespace std; 

class ClassA {  
public: 
   ClassA(int ii = 0) : i(ii) {} 
   void show() { cout << "i = " << i << endl;} 
private: 
   int i; 
}; 

class ClassB { 
public: 
   ClassB(int xx) : x(xx) {} 
   operator ClassA() const { return ClassA(x); } 
private: 
   int x; 
}; 

void g(ClassA a) 
{  a.show(); } 

int main() { 
 ClassB b(10); 
 g(b); 
 g(20); 
 getchar(); 
 return 0; 
}  

Output:

i = 10
i = 20

Reason:
ClassA contains a conversion constructor. Due to this, the objects of ClassA can have integer values. So the statement g(20) works. Also, ClassB has a conversion operator overloaded. So the statement g(b) also works.

public class Demo{ 
   public static void main(String[] arr){ 
         System.out.println(“Main1”);
   } 
   public static void main(String arr){  
         System.out.println(“Main2”);
   } 
}

Output:

Main1

Reason:
Here the main() method is overloaded. But JVM only understands the main method which has a String[] argument in its definition. Hence Main1 is printed and the overloaded main method is ignored. 

#include<iostream> 
using namespace std; 
 
class BaseClass{ 
   int arr[10];      
}; 
 
class DerivedBaseClass1: public BaseClass { }; 
 
class DerivedBaseClass2: public BaseClass { }; 
 
class DerivedClass: public DerivedBaseClass1, public DerivedBaseClass2{}; 
 
int main(void) 
{  
 cout<<sizeof(DerivedClass);
 return 0; 
}

Output:

If the size of the integer is 4 bytes, then the output will be 80.

Reason: 
Since DerivedBaseClass1 and DerivedBaseClass2 both inherit from class BaseClass, DerivedClass contains two copies of BaseClass. Hence it results in wastage of space and a large size output. It can be reduced with the help of a virtual base class.

#include<iostream> 
 
using namespace std; 
class A { 
public: 
  void print() 
  { cout <<" Inside A::"; } 
}; 
 
class B : public A { 
public: 
  void print() 
  { cout <<" Inside B"; } 
}; 
 
class C: public B { 
}; 
 
int main(void) 
{ 
 C c; 
 
 c.print(); 
 return 0; 
}

Output:

Inside B

Reason:
The above program implements a Multi-level hierarchy. So the program is linearly searched up until a matching function is found. Here, it is present in both classes A and B. So class B’s print() method is called. 

Useful Resource

Features of OOPS

Method Resolution Order defines how Python determines which method to call when a class hierarchy involves multiple inheritance. It becomes particularly important when more than one parent class defines the same method.

Python uses the C3 linearization algorithm to produce a consistent, predictable lookup order:

class A:
    pass
class B(A):
    pass
class C(A):
    pass
class D(B, C):
    pass

print(D.mro())

Output:
[D, B, C, A, object]

Python searches methods in this exact sequence during execution. MRO guarantees consistent method lookup, avoids duplicate traversal of the same class, and produces predictable inheritance behavior.

Python oops interview questions are becoming increasingly common across all seniority levels because Python is now widely used in backend engineering, machine learning, and data engineering systems.

This is one of the most important memory management questions in advanced oops interview questions for C++ developers. Get this wrong in production code and you have resource leaks that are extremely difficult to track down.

When you delete a derived object using a base class pointer, the base destructor must be virtual. Without it, only the base destructor runs and the derived class destructor is skipped entirely.

Without Virtual Destructor

class Base {
public:
    ~Base() {
        cout << "Base Destructor";
    }
};

class Derived : public Base {
public:
    ~Derived() {
        cout << "Derived Destructor";
    }
};

Deleting through a base pointer here skips the Derived destructor. Any resources allocated in Derived are leaked silently.

Correct Version

class Base {
public:
    virtual ~Base() {
        cout << "Base Destructor";
    }
};

With the virtual keyword in place, the correct destructor chain runs during runtime polymorphism: Derived destructor first, then Base. These advanced oops interview questions for experienced C++ developers are standard in systems programming and low level engineering interviews.

The diamond problem is one of the most common oops interview questions in C++ because C++ actually supports multiple inheritance, which means the problem is real, not hypothetical.

The issue arises when a derived class inherits from two parent classes that both inherit from the same base class:

       A
      / \
     B   C
      \ /
       D

Without handling this correctly, class D ends up with two separate copies of class A's members, causing ambiguity and unexpected behavior.

C++ Solution Using Virtual Inheritance

class A {};
class B : virtual public A {};
class C : virtual public A {};
class D : public B, public C {};

Virtual inheritance ensures only one shared instance of the base class exists in the hierarchy. Java sidesteps this problem entirely by disallowing multiple class inheritance. This makes the diamond problem one of the most frequently tested C++ oops interview questions in systems programming interviews.

This is one of the most important oops concepts interview questions because candidates frequently conflate these two ideas. They are related, but they solve different problems.

Abstraction is about hiding complexity. It exposes only the essential behavior that a user needs to interact with, while keeping the underlying implementation invisible. An ATM is a great example. You see deposit and withdraw. You do not see the transaction processing logic behind those operations.

Encapsulation is about hiding data. It binds data and methods together within a class and restricts direct access from outside. Here is a clean example:

class BankAccount {
    private double balance;
    public void deposit(double amount) {
        balance += amount;
    }
}

The balance field is private and cannot be touched directly from outside the class. Only the controlled deposit method can modify it. Abstraction handles what is visible. Encapsulation handles what is protected.

These object oriented programming interview questions are foundational. They appear consistently in fresher rounds, backend interviews, and full stack engineering assessments alike.

This is one of the most common oops interview questions for freshers, and it's also a good litmus test for whether a candidate genuinely understands why OOP exists rather than just how it works.

Object oriented programming organizes software around objects that bundle both data and behavior together. Procedural programming organizes software around functions that operate on separate data.

OOP improves modularity, maintainability, and extensibility, which makes it far better suited for large scale enterprise applications where multiple developers work on the same codebase over time.

This is one of the most practical object oriented programming interview questions because it shifts from theory to execution. Interviewers want to see whether you can translate OOP concepts into a working design, not just recite definitions.

Consider a payment processing system that needs to support UPI payments, card payments, and wallet payments.

Step 1: Identify Classes

• Payment
• User
• Transaction
• PaymentProcessor

Step 2: Use Abstraction

Define a PaymentStrategy interface that all payment types must implement:

interface PaymentStrategy {
    void pay(double amount);
}

Step 3: Use Polymorphism

Each payment method implements the interface independently:

class UpiPayment implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Paid using UPI");
    }
}

class CardPayment implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Paid using Card");
    }
}

Step 4: Use Composition

The processor takes any strategy at runtime, without caring which one:

class PaymentProcessor {
    private PaymentStrategy strategy;

    PaymentProcessor(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    void process(double amount) {
        strategy.pay(amount);
    }
}

This design demonstrates encapsulation, abstraction, composition, and runtime polymorphism working together in one clean system. Scenario based oops coding interview questions like this are common in SDE 2 and backend engineering rounds precisely because they reveal how candidates think architecturally.

SOLID principles interview questions are among the most valuable advanced oops interview questions because they test real world design judgment, not just textbook knowledge. Candidates who can explain why each principle matters, not just what it means, stand out immediately.

Single Responsibility Principle (SRP)

A class should have only one reason to change. A UserService class that handles both authentication and email sending is doing too much. Split those responsibilities and your code becomes easier to test, change, and understand.

Open Closed Principle (OCP)

Software entities should be open for extension but closed for modification. When new behavior is needed, you extend through interfaces and abstractions rather than editing existing, tested code. This protects stability.

Liskov Substitution Principle (LSP)

A subclass should be fully substitutable for its parent class without breaking the application. If swapping in a subclass causes unexpected behavior, the hierarchy is broken, even if the code compiles.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they do not use. Smaller, focused interfaces are far better than one large, monolithic interface that forces implementing classes to stub out irrelevant methods.

Dependency Inversion Principle (DIP)

High level modules should depend on abstractions, not on concrete implementations. This decouples your business logic from infrastructure details and makes testing and swapping implementations much easier.

Applied together, SOLID principles meaningfully improve maintainability, extensibility, scalability, and testability in large codebases. This is why they remain core oops interview questions for experienced developers at any level.

These three relationship types are foundational in software architecture, which is why they appear so often in object oriented programming interview questions. Getting the distinctions right matters, especially when you're discussing low level system design.

Association is a general relationship between two independent classes. A Student enrolls in a Course. Both objects exist independently. Neither owns the other, and neither's lifecycle is tied to the other.

Aggregation is a weak has a relationship. A Department has Professors. If the department is dissolved, the professors still exist. The child object survives the parent. Ownership is implied but not absolute.

Composition is a strong has a relationship where the child's lifecycle is entirely tied to the parent. An Order contains OrderItems. Delete the order, and its items go with it. The child cannot meaningfully exist without the parent.

These relationship based oops interview questions for experienced engineers appear regularly in backend, Java, and system design interviews because object relationships directly inform architectural decisions.

This is one of the most important oops interview questions for experienced developers, and it comes up constantly, because the choice between these two patterns shapes the scalability and maintainability of an entire codebase.

Inheritance represents an is a relationship. A child class inherits properties and behaviors from a parent class. Composition represents a has a relationship. One class contains another as part of its functionality rather than extending it.

Inheritance makes sense when a subclass is a genuine specialization of its parent. Dog is an Animal is a textbook valid hierarchy. But in most real world systems, composition is the better default because it keeps coupling loose and makes behavior reuse far more flexible.

Think about it this way: a Car has an Engine is composition. The engine is a component the car uses, not a subtype of the car itself. Swapping out the engine or adding a different one later is straightforward. With inheritance, that kind of flexibility is much harder to achieve.

Modern backend systems heavily favor composition precisely because it avoids rigid inheritance chains. This is why the distinction between the two is one of the most frequent oops concepts interview questions in senior developer rounds.

This is one of the most important oops interview questions in Java around inheritance design, and it connects directly to a real compiler level problem: the diamond problem.

If two parent classes define the same method and a child class inherits from both, the compiler has no way to determine which implementation should take precedence.

       A
      / \
     B   C
      \ /
       D

If both B and C override a method from A, class D faces genuine ambiguity. Java resolves this by disallowing multiple inheritance for classes entirely. Instead, it offers:

• Multiple inheritance of type through interfaces
• Explicit resolution for conflicting default methods

Here is how Java handles a conflict between two interface default methods:

interface A {
    default void show() {
        System.out.println("A");
    }
}

interface B {
    default void show() {
        System.out.println("B");
    }
}

class Test implements A, B {
    public void show() {
        A.super.show();
    }
}

The implementing class explicitly picks which default method to use. These oops interview questions in Java are extremely common because they weave together inheritance, interfaces, and polymorphism into one cohesive concept.

This is a classic trick based entry in oops concepts in Java interview questions, and it trips up a lot of candidates who answer instinctively without thinking through the mechanics.

Static methods belong to the class, not to any object instance. They cannot participate in runtime polymorphism. What looks like overriding with static methods is actually method hiding.

class Parent {
    static void display() {
        System.out.println("Parent method");
    }
}

class Child extends Parent {
    static void display() {
        System.out.println("Child method");
    }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        p.display();
    }
}

Output:
Parent method

The method call resolves based on the reference type at compile time, not the actual object. That is method hiding, not overriding. Tricky Java oops interview questions like this appear frequently in experienced Java interviews because they test whether you truly understand how method resolution works.

This is one of the most common oops interview questions in Java, and for good reason. Runtime polymorphism is a core pillar of object oriented programming, and Java's implementation of it is clean and worth understanding deeply.

Java achieves runtime polymorphism through method overriding and dynamic method dispatch. A parent class reference can point to a child class object, and the method executed is determined at runtime based on the actual object type, not the reference type.

class Animal {
    void sound() {
        System.out.println("Animal sound");
    }
}

class Dog extends Animal {
    void sound() {
        System.out.println("Dog barks");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.sound();
    }
}

Output:
Dog barks

Even though the reference type is Animal, the JVM resolves the method call to Dog's implementation at runtime. Static, private, and final methods are excluded from this mechanism because they are resolved at compile time, not runtime. This is one of the highest priority Java polymorphism interview questions in backend engineering interviews.