Object-oriented programming (OOPs) questions are asked in almost every fresher and software engineer interview, whatever the language. These OOPs interview questions cover classes, objects and the four pillars for beginners, then SOLID principles, composition vs inheritance, design patterns and real-world design for experienced developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Object-oriented programming organises software around objects, which combine data (attributes) and behaviour (methods).
A class is a blueprint, and an object is an instance of it, for example a Car class and individual car objects.
OOP makes code easier to model on real-world concepts, reuse and maintain.
Java, C++, C# and Python all support it.
Encapsulation bundles data and methods together and hides internal details behind a public interface.
Abstraction shows only essential features and hides complexity.
Inheritance lets a class reuse and extend another class.
Polymorphism lets the same interface behave differently depending on the object, such as a draw() method on different shapes.
A class is a template that defines the attributes and methods its objects will have; it does not occupy memory for data by itself. An object is a concrete instance of a class created at runtime with its own values, for example a class Student and objects for Riya and Arjun, each with their own name and marks.
A constructor is a special method that runs when an object is created and sets its initial state.
A default constructor takes no arguments, a parameterised constructor takes values to initialise fields, and a copy constructor (in C++) creates an object from another object of the same class.
Constructors can be overloaded and can call each other (constructor chaining).
A destructor runs when an object is destroyed and releases resources it holds, such as memory, files or network connections.
In C++ destructors run automatically when objects go out of scope, which makes RAII possible.
Garbage-collected languages such as Java and C# have no deterministic destructors, so they use try-with-resources, using statements or close methods instead.
this (self in Python) refers to the current object, used to access its fields when a parameter has the same name, to call another constructor, or to pass the object to another method. super refers to the parent class, used to call the parent's constructor or an overridden parent method from a subclass.
Static members belong to the class rather than to any object.
A static field is shared by all instances, such as a counter of created objects, and a static method can be called without creating an object, such as a utility function.
Static methods cannot access instance fields directly, and heavy use of static state makes code harder to test.
Single (one parent), multilevel (a chain of parents), hierarchical (many children of one parent), multiple (several parents) and hybrid (a mix).
The diamond problem occurs with multiple inheritance when two parents inherit from the same grandparent, making it unclear which version of a method to use.
Java and C# avoid it by allowing only single class inheritance; C++ uses virtual inheritance.
A BankAccount class keeps its balance field private and exposes deposit and withdraw methods that validate amounts, for example rejecting negative deposits or withdrawals above the balance. Code outside the class cannot set the balance directly, so the object can never enter an invalid state, and the internal implementation can change without affecting callers.
Abstraction is about design: showing only what an object does and hiding how, for example a Payment interface with a pay() method, regardless of whether it uses UPI or a card.
Encapsulation is about implementation: bundling data and methods and restricting direct access to the data with access modifiers.
Abstraction hides complexity; encapsulation protects data.
A notification system has a Notifier interface with a send(message) method, implemented by EmailNotifier, SmsNotifier and WhatsAppNotifier.
The code that sends alerts loops over a list of notifiers and calls send on each without knowing their types; each object behaves in its own way.
Adding a new channel requires a new class, not changes to the sending code.
Applied problems, trade-offs and questions about your own projects.
Overloading means several methods in the same class with the same name but different parameters, resolved at compile time (compile-time polymorphism). Overriding means a subclass provides its own implementation of a method defined in its parent with the same signature, resolved at runtime based on the actual object (runtime polymorphism).
An abstract class can have state, constructors and both implemented and abstract methods, and represents an "is-a" relationship with shared base behaviour; a class can extend only one in Java and C#.
An interface defines a contract of methods a class promises to implement, representing a capability, and a class can implement many.
I use interfaces to decouple code and abstract classes to share common code.
Inheritance creates tight coupling: changes in a parent class can break subclasses, and deep hierarchies become rigid.
Composition builds objects from other objects ("has-a"), such as a Car having an Engine, so behaviour can be swapped and combined at runtime.
Inheritance is still right for genuine "is-a" relationships where the subclass can fully replace the parent.
Access modifiers control visibility.
In Java: private is visible only within the class, default (package-private) within the package, protected within the package and subclasses, and public everywhere.
Using the most restrictive level that works enforces encapsulation, so internal details can change without breaking other code.
Association is any relationship between classes, such as a teacher and a student.
Aggregation is a "has-a" relationship where the part can exist independently, such as a department and its professors.
Composition is a stronger "owns-a" relationship where the part cannot exist without the whole, such as a house and its rooms: destroying the house destroys the rooms.
Coupling is how much classes depend on each other; low coupling means a change in one class rarely forces changes in others.
Cohesion is how closely related the responsibilities inside one class are; high cohesion means a class does one focused job.
Good design aims for low coupling and high cohesion, achieved with interfaces, dependency injection and small, focused classes.
An immutable object cannot change after it is created; any "change" produces a new object, like String in Java.
Immutable objects are thread-safe without locks, safe to share and cache, safe as keys in hash maps, and easier to reason about because their state never changes unexpectedly.
Records and data classes make them easy to write.
Dependency injection means a class receives the objects it depends on, usually through its constructor, instead of creating them itself.
For example, an OrderService receives a PaymentGateway interface rather than creating a specific gateway.
This reduces coupling, lets you swap implementations, and makes testing easy because fakes or mocks can be injected.
Frameworks such as Spring automate it.
Overriding applies to instance methods: the subclass method replaces the parent's, and the version called depends on the actual object at runtime.
Hiding applies to static methods: a subclass static method with the same signature hides the parent's, and the version called depends on the reference type at compile time.
Calling static methods through the class name avoids confusion.
The classic example is making Square a subclass of Rectangle.
Code that sets a rectangle's width and then its height expects the area to be width times height, but a Square that keeps both sides equal breaks that expectation.
A subclass must be usable wherever its parent is expected without surprises; here a shared Shape interface is a better design.
Code that depends on an interface, such as List or PaymentGateway, rather than a concrete class, can work with any implementation. You can switch implementations, add new ones and use mocks in tests without changing the calling code, which supports the open/closed and dependency inversion principles and keeps modules loosely coupled.
System design, deep internals, leadership and tough follow-ups.
Single responsibility: a class should have one reason to change.
Open/closed: open for extension but closed for modification.
Liskov substitution: subclasses must be usable wherever their parent is expected.
Interface segregation: many small, specific interfaces are better than one large one.
Dependency inversion: depend on abstractions, not concrete classes.
Together they produce code that is easier to change and test.
Singleton for one shared instance such as configuration (used carefully because it hides dependencies), Factory to create objects without exposing the concrete class, Builder for objects with many optional parameters, Strategy to swap algorithms such as payment methods, Observer for event notifications, Adapter to make incompatible interfaces work together, and Decorator to add behaviour without changing a class.
I would identify the main objects: ParkingLot containing Levels, each with ParkingSpots of types such as compact, large and electric; Vehicle as an abstract class with Car, Bike and Truck; Ticket recording vehicle, spot and entry time; and a PaymentStrategy for fee calculation.
ParkingLot finds a free spot for a vehicle type, issues tickets and frees spots on exit.
I would discuss concurrency for spot allocation and how to add new vehicle types without changing existing code.
Main classes: Book (title, author, ISBN) and BookCopy (a physical copy with a status), Member with a membership type that sets borrowing limits, Librarian, Loan (copy, member, issue date, due date), Reservation, and Fine calculated by a FineStrategy.
A Library or LoanService issues and returns copies, checks limits and reservations, and notifies members of due dates through a notification interface.
I would discuss concurrency when two members reserve the same copy.
DRY (don't repeat yourself): keep each piece of knowledge in one place.
KISS (keep it simple): prefer the simplest solution that works.
YAGNI (you aren't gonna need it): do not build features until they are needed.
The Law of Demeter: an object should talk only to its close collaborators, avoiding chains like order.getCustomer().getAddress().getCity(), which couple code to internal structures.
OOP models software as objects that combine state and behaviour, which suits systems with many entities and clear responsibilities.
Functional programming builds software from pure functions and immutable data, which makes code easier to test, reason about and run in parallel.
Modern languages mix both: immutable value objects, lambdas and streams inside an object-oriented structure.
A class diagram shows classes with their attributes and methods (with visibility symbols such as + for public and − for private) and the relationships between them: inheritance (a hollow triangle arrow), interface implementation (a dashed line with a triangle), association (a line, with multiplicities such as 1..*), aggregation (a hollow diamond) and composition (a filled diamond). It is used to discuss designs before coding.
First add tests around its current behaviour.
Then identify its separate responsibilities, such as validation, persistence, formatting and notifications, and extract each into its own class with a clear interface, injecting them back as dependencies.
Move methods next to the data they use, replace long conditionals with polymorphism or strategies, and refactor in small steps, running tests after each one.
See all Software Engineer interview questions, covering Data Structures, Algorithms, OOP, System Design, Operating Systems and more.