Software Development

OOP Questions You Should Master for Technical Interviews

OOP Interview Questions You Should Master

Many programmers lose interviews not because they can't code, but because they can't clearly explain concepts they use every day. Object-Oriented Programming (OOP) is one of the most tested topics, yet many candidates stumble when asked to explain the difference between abstraction and encapsulation or when to use an interface instead of an abstract class.

This guide compiles the most common OOP interview questions, organized from fundamentals to design principles, so you can answer with clarity and confidence.

Fundamentals

What is Object-Oriented Programming?

Simple explanation: OOP is a programming paradigm that organizes code around "objects" -- entities that combine data (attributes) and behavior (methods). Instead of writing long procedural scripts, you model real-world concepts as objects that interact with each other.

Interview answer: "OOP is a paradigm that structures software around objects, which encapsulate state and behavior. It promotes reuse, modularity, and maintainability through its four pillars: encapsulation, abstraction, inheritance, and polymorphism."

Example: A Car object has attributes like color and speed, and methods like accelerate() and brake().

What is a class?

Simple explanation: A class is a blueprint or template that defines the structure and behavior that objects of that type will have. It does not hold actual data -- it describes what data and methods an object will contain.

Interview answer: "A class is a blueprint that defines the attributes and methods an object will have. It acts as a template from which instances (objects) are created."

Example: The class Dog defines that every dog has a name and can bark(), but it is not a specific dog until you create an instance.

What is an object?

Simple explanation: An object is a concrete instance of a class. It is the actual entity that lives in memory with real values assigned to the attributes defined by its class.

Interview answer: "An object is an instance of a class that holds actual state and can execute the behaviors defined in its class."

Example: myDog = new Dog("Rex") -- here myDog is an object of the class Dog with the name "Rex".

What is the difference between a class and an object?

Simple explanation: A class is the recipe; an object is the dish you cook from it. The class defines the structure; the object is the concrete instance with real values.

Interview answer: "A class is the definition or template, while an object is a living instance of that class in memory. You can create multiple objects from a single class, each with different state."

Example: Car is the class. myCar = new Car("red") and yourCar = new Car("blue") are two different objects.

The 4 Pillars of OOP

What is Encapsulation?

Simple explanation: Encapsulation means hiding an object's internal data and exposing only what is necessary through public methods. It protects the internal state from unwanted external modifications.

Interview answer: "Encapsulation restricts direct access to an object's internal state and provides controlled access through public methods (getters/setters). This protects data integrity and reduces coupling."

Example: A BankAccount class has a private attribute balance. You cannot modify it directly -- you must use the deposit() or withdraw() methods, which validate the operation before changing the balance.

What is Abstraction?

Simple explanation: Abstraction means showing only the essential features of an object and hiding the complex implementation details. The user knows what an object does, but not how it does it internally.

Interview answer: "Abstraction exposes only the relevant behavior of an object while hiding its internal complexity. It simplifies interaction by providing a clear interface without revealing implementation details."

Example: When you call emailService.send(email), you don't need to know how the SMTP connection, authentication, or message formatting works internally.

What is Inheritance?

Simple explanation: Inheritance allows a class to inherit attributes and methods from another class (the parent). It promotes code reuse by letting child classes extend or specialize the behavior of parent classes.

Interview answer: "Inheritance is a mechanism where a child class acquires the properties and behaviors of a parent class. It enables code reuse and establishes an 'is-a' relationship between types."

Example: Dog and Cat both extend Animal. They inherit the eat() method but can override makeSound() with their own implementation.

What is Polymorphism?

Simple explanation: Polymorphism means that the same method can behave differently depending on which object calls it. It allows you to write code that works with a general type but executes the specific behavior of each subtype.

Interview answer: "Polymorphism allows objects of different classes to respond to the same method call in their own way. It enables writing flexible code that works with base types while executing subtype-specific behavior at runtime."

Example: A method makeSound() on an Animal reference will produce "Woof" if the object is a Dog and "Meow" if it is a Cat.

What is the difference between Abstraction and Encapsulation?

Simple explanation: Abstraction decides what to show to the outside world (the interface). Encapsulation decides how to protect the internal data (the implementation). Abstraction simplifies; encapsulation protects.

Interview answer: "Abstraction focuses on exposing only the relevant interface and hiding complexity, while encapsulation focuses on restricting access to internal state. Abstraction is about design; encapsulation is about access control. They complement each other."

Example: An abstract class PaymentProcessor defines processPayment() (abstraction). The concrete class StripeProcessor keeps the API key as a private field (encapsulation).

Interfaces and Abstract Classes

What is an Interface?

Simple explanation: An interface is a contract that defines what methods a class must implement, without providing any implementation. It specifies behavior without dictating how it should be done.

Interview answer: "An interface defines a contract of methods that implementing classes must fulfill. It contains no implementation -- only method signatures. It enables polymorphism and decoupling."

Example: An interface Drivable defines accelerate() and brake(). Both Car and Motorcycle implement it, each in their own way.

What is an Abstract Class?

Simple explanation: An abstract class is a class that cannot be instantiated directly. It can contain both implemented methods (shared behavior) and abstract methods (that subclasses must implement). It sits between a regular class and an interface.

Interview answer: "An abstract class provides a partial implementation that subclasses must complete. It can have both concrete methods (shared logic) and abstract methods (forced overrides). Unlike interfaces, it can hold state and constructor logic."

Example: An abstract class Shape implements getColor() (shared) and declares calculateArea() as abstract (each shape calculates it differently).

When should you use an Interface vs. an Abstract Class?

Simple explanation: Use an interface when you want to define a contract that unrelated classes can implement. Use an abstract class when you want to share common code among closely related classes.

Interview answer: "Use an interface when you need a pure contract across unrelated types -- it defines what to do, not how. Use an abstract class when you need shared implementation among related classes. In languages that support single inheritance, interfaces also enable a form of multiple inheritance."

Example: Serializable is an interface -- any class can be serializable. Vehicle is an abstract class -- only vehicle types should extend it and share its startEngine() logic.

SOLID Principles

SOLID is a set of five design principles that help you write maintainable, flexible, and scalable object-oriented code.

S -- Single Responsibility Principle (SRP)

Simple explanation: A class should have only one reason to change. Each class should do one thing and do it well.

Interview answer: "SRP states that a class should have a single responsibility -- one reason to change. This reduces coupling and makes the class easier to test and maintain."

Example: Instead of a User class that handles validation, database persistence, and email sending, split it into UserValidator, UserRepository, and EmailService.

O -- Open/Closed Principle (OCP)

Simple explanation: Classes should be open for extension but closed for modification. You should be able to add new behavior without changing existing code.

Interview answer: "OCP means that a module should allow its behavior to be extended without modifying its source code. This is typically achieved through inheritance, interfaces, or the strategy pattern."

Example: A DiscountCalculator uses a DiscountStrategy interface. To add a new discount type (e.g., BlackFridayDiscount), you create a new class implementing the interface rather than editing the calculator.

L -- Liskov Substitution Principle (LSP)

Simple explanation: A subclass should be usable wherever its parent class is expected, without breaking the program. If it looks like a duck and quacks like a duck, it should behave like a duck.

Interview answer: "LSP states that objects of a superclass should be replaceable with objects of its subclasses without altering the correctness of the program. Subtypes must honor the contract of their base type."

Example: If Rectangle has a method setWidth(), a Square subclass that overrides it to also set the height violates LSP because it changes the expected behavior of setWidth().

I -- Interface Segregation Principle (ISP)

Simple explanation: Don't force a class to implement methods it doesn't need. It's better to have several small, specific interfaces than one large general-purpose interface.

Interview answer: "ISP states that clients should not be forced to depend on interfaces they don't use. Split large interfaces into smaller, role-specific ones so that implementing classes only need to know about the methods that are relevant to them."

Example: Instead of one Worker interface with work(), eat(), and sleep(), create Workable, Eatable, and Sleepable. A Robot implements only Workable.

D -- Dependency Inversion Principle (DIP)

Simple explanation: High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). This makes your system flexible and easy to change.

Interview answer: "DIP states that high-level modules should depend on abstractions, not on concrete implementations. This decouples components and makes the system easier to extend, test, and maintain through dependency injection."

Example: A NotificationService depends on a MessageSender interface, not on EmailSender directly. You can swap EmailSender for SmsSender without changing the service.

Design and Interview Concepts

What is Coupling?

Simple explanation: Coupling measures how much one class depends on another. Low coupling is desirable because it means you can change one class without breaking others.

Interview answer: "Coupling is the degree of interdependence between modules. Low coupling means modules can change independently, which improves maintainability and testability."

Example: If OrderService directly instantiates MySQLDatabase, they are tightly coupled. Using a Database interface instead reduces coupling.

What is Cohesion?

Simple explanation: Cohesion measures how closely related the responsibilities of a class are. High cohesion means every method and attribute in the class serves a single, clear purpose.

Interview answer: "Cohesion measures how focused a class is on a single responsibility. High cohesion means all methods and properties in a class are closely related and work toward the same purpose."

Example: A UserRepository with only database methods (save(), findById(), delete()) has high cohesion. If it also sends emails, cohesion drops.

What is Composition?

Simple explanation: Composition means building complex objects by combining simpler ones. Instead of inheriting behavior, an object contains other objects that provide the desired functionality.

Interview answer: "Composition is a design technique where a class achieves functionality by containing instances of other classes rather than inheriting from them. It models a 'has-a' relationship and is generally preferred over inheritance for flexibility."

Example: A Car class doesn't inherit from Engine -- it has an Engine. You can swap engines without changing the car's class hierarchy.

Inheritance vs. Composition: when to use each?

Simple explanation: Use inheritance when there is a true "is-a" relationship and shared behavior makes sense. Use composition when you want flexibility, reuse without tight coupling, or when the relationship is "has-a".

Interview answer: "Prefer composition over inheritance as a default. Use inheritance only for genuine 'is-a' relationships where the subclass is a true specialization of the parent. Composition provides better flexibility, testability, and avoids the fragile base class problem."

Example: A Dog "is an" Animal (inheritance makes sense). A Car "has an" Engine (composition makes sense). Don't make Car extend Engine.

What is Method Overloading?

Simple explanation: Method overloading means having multiple methods with the same name in the same class but with different parameter lists. The correct version is selected at compile time.

Interview answer: "Method overloading is a form of compile-time (static) polymorphism where multiple methods share the same name but differ in their parameter types, number, or order. The compiler determines which version to call."

Example: add(int a, int b) and add(double a, double b) are overloaded methods. The compiler picks the right one based on the argument types.

What is Method Overriding?

Simple explanation: Method overriding means a subclass provides its own implementation of a method already defined in its parent class. The correct version is selected at runtime based on the actual object type.

Interview answer: "Method overriding is a form of runtime (dynamic) polymorphism where a subclass provides a specific implementation for a method defined in its superclass. The JVM/runtime determines which version to call based on the object's actual type."

Example: Animal defines makeSound(). Dog overrides it to return "Woof". At runtime, calling makeSound() on a Dog reference executes the Dog version.

How to Answer Better in Interviews

Use this 3-part structure to give clear, memorable answers:

  1. Define it in one sentence -- show that you understand the concept.
  2. Explain why it matters -- connect it to maintainability, flexibility, or testability.
  3. Give a concrete example -- prove you can apply it in real code.

Key rule: Don't just recite definitions. Show that you understand the why behind each concept and how it affects the code you write every day.

Quick Checklist Before an Interview

  • Can you explain the 4 pillars of OOP without hesitation?
  • Can you describe each SOLID principle with a real example?
  • Do you know when to use an interface vs. an abstract class?
  • Can you explain the difference between overloading and overriding?
  • Can you articulate why composition is generally preferred over inheritance?
  • Can you define coupling, cohesion, and why they matter?

If you answered yes to all of them, you are ready. If not, revisit the sections above and practice explaining each concept out loud -- that's the real interview skill.

#oop#interviews#solid
Share:

Related Posts