OOP Interview Questions and Answers

OOP interviews test whether you can model problems as objects with clear responsibilities—not whether you can recite "four pillars" without context.

Procedural code is fine for scripts and small tools—see shell scripting interviews. OOP shines when many developers share a long-lived codebase with changing requirements.

Experienced loops expect you to connect pillars, SOLID, and patterns to real class design—not recite definitions alone.

Draw UML-style boxes on paper—interviewers reward clear entity relationships.

Java oops interview questions focus on modifiers and interfaces. Python interviews stress duck typing—see Python interviews. C++ adds multiple inheritance and vtables—see C and C++ interviews.

The pillars work together: encapsulation protects state, abstraction simplifies usage, inheritance shares structure, polymorphism lets callers depend on supertypes.

A strong answer is:

I name all four and immediately ground each in code—private fields for encapsulation, an interface for abstraction, extends for inheritance, and overriding draw() for polymorphism.

class Dog {
    String name;
    void bark() { System.out.println("woof"); }
}

Dog rex = new Dog();  // rex is an object (instance) of class Dog

One class → many objects (new Dog() twice yields two instances with separate state).

A strong answer is:

A class is the template; an object is a concrete instance at runtime with its own field values—one Car class, many Car objects in a fleet.

Encapsulation binds data and methods that operate on that data into one unit (usually a class) and restricts direct access to internal state.

Benefits:

• Invariant protection — balance cannot go negative if withdraw validates
• Refactoring freedom — change internal representation without breaking callers
• Security — sensitive fields not public

public class BankAccount {
    private int balance;

    public void deposit(int amount) {
        if (amount > 0) balance += amount;
    }

    public int getBalance() { return balance; }
}

A strong answer is:

Encapsulation keeps state private and exposes behavior through methods so invariants stay enforced—I never let callers set balance directly if rules matter.

Abstraction hides implementation complexity and shows only essential behavior—the "what" without the "how."

Driving a car: you use accelerate()—not spark-plug timing. That is abstraction at the human level; in code, List abstracts whether backing store is array or linked nodes.

A strong answer is:

Abstraction is the simplified surface—an interface or abstract API—so callers depend on capabilities like charge() without knowing Stripe vs PayPal wiring.

You can encapsulate without strong abstraction (public getters for everything). You can abstract without strict encapsulation (leaky interface returning internals).

A strong answer is:

Encapsulation guards state with access control; abstraction hides how work is done behind a simpler contract—I need both, but they answer different design questions.

Data hiding restricts visibility of fields using access modifiers (private, protected).

Encapsulation can exist with public fields (weak hiding). Production code should hide data and expose behavior.

A strong answer is:

Data hiding is the access-modifier part of encapsulation—I use private fields so internal representation can change without breaking every caller.

Inheritance lets a child class acquire fields and methods from a parent class—an IS-A relationship.

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

class Dog extends Animal {
    void bark() { System.out.println("woof"); }
}

Benefits: reuse, polymorphism (treat Dog as Animal). Risks: tight coupling, fragile base class, deep trees—often replaced by composition for HAS-A.

A strong answer is:

Inheritance models IS-A reuse and enables overriding; I avoid deep trees and prefer composition when behavior is shared but not a true subtype relationship.

Polymorphism ("many forms") lets one interface or superclass reference invoke different implementations depending on the actual object type.

Two forms in Java:

interface Notifier {
    String send(String message);
}

class EmailNotifier implements Notifier {
    public String send(String message) { return "email:" + message; }
}

class SmsNotifier implements Notifier {
    public String send(String message) { return "sms:" + message; }
}

public class PolymorphismDemo {
    static String notifyUser(Notifier n, String msg) {
        return n.send(msg);
    }

    public static void main(String[] args) {
        System.out.println(notifyUser(new EmailNotifier(), "hello"));
        System.out.println(notifyUser(new SmsNotifier(), "hello"));
    }
}

The same notifyUser method accepts any Notifier; runtime dispatch picks email: vs sms: output.

A strong answer is:

Polymorphism lets me code to Notifier or Shape supertypes and plug in Email or Circle implementations—compile-time overloading for convenience, runtime overriding for extensibility.

Java classes: single inheritance of classes, multiple interface implementation.

A strong answer is:

Java gives single class inheritance and multiple interfaces—I describe multilevel and hierarchical with Animal examples and mention C++ for true multiple inheritance contrast.

class Engine {
    String start() { return "vroom"; }
}

class Car {
    private final Engine engine = new Engine();
    String drive() { return engine.start(); }
}

public class CompositionDemo {
    public static void main(String[] args) {
        System.out.println(new Car().drive());
    }
}

Favor composition when behavior varies or lifetime is HAS-A. Use inheritance for genuine taxonomic subtyping and shared interface contracts.

A strong answer is:

I default to composition for reusable behavior—Car has Engine—and reserve inheritance for true IS-A subtypes where Liskov substitution holds.

Example: Professor associated with University; Department aggregates Professor (professor can transfer); House composes Room (no house, no those rooms as part of that house).

A strong answer is:

Composition is strict ownership—engine with car; aggregation is looser—students with university; association is mere usage—a doctor and hospital.

Interview trap: modeling Stack extends ArrayList IS-A wrong for behavior—Stack HAS-A list (composition) avoids LSP violations.

A strong answer is:

IS-A for subtype polymorphism; HAS-A when one object contains or uses another—I rejected Stack extends ArrayList because a stack is not an array list behaviorally.

When class D inherits B and C, and both B and C inherit A and override the same method, D faces ambiguous which override to use:

A
   / \
  B   C
   \ /
    D

Java avoids multiple class inheritance to prevent this. C++ allows it with virtual inheritance. Java uses interfaces + explicit default-method resolution.

A strong answer is:

Diamond ambiguity is why Java disallows extending two classes—I use interfaces and, if two defaults collide, override explicitly in the implementing class.

A class may:

class PaymentService implements Auditable, Retryable, MetricsAware { }

Interfaces define contracts; a class implements many. Since Java 8, default methods on interfaces share implementation—but conflicting defaults require an override in the class.

A strong answer is:

Java gives multiple inheritance of type through interfaces, not multiple class extension—default methods add shared code with explicit conflict rules.

class Calc {
    int add(int a, int b) { return a + b; }
    double add(double a, double b) { return a + b; }  // overload
}

class Parent { String greet() { return "hi"; } }
class Child extends Parent {
    @Override String greet() { return "hello"; }     // override
}

A strong answer is:

Overloading is same method name, different parameters, resolved at compile time; overriding is subclass replacing parent behavior, resolved at runtime via dynamic dispatch.

Achieved through method overloading and operator overloading (C++, not Java).

Compiler picks the method at compile time based on argument types:

class Printer {
    void print(int x) { System.out.println("int:" + x); }
    void print(String s) { System.out.println("str:" + s); }
}

public class StaticPoly {
    public static void main(String[] args) {
        Printer p = new Printer();
        p.print(42);
        p.print("hi");
    }
}

Running prints int:42 then str:hi—the compiler bound each call statically.

A strong answer is:

Compile-time polymorphism is overloading—the compiler selects the method signature before the program runs; Java doesn't overload operators like C++.

Achieved through method overriding: reference type is superclass/interface; actual object type decides which method runs.

JVM uses virtual method tables (vtables) for instance methods. final, static, and private methods do not participate in runtime override dispatch the same way.

A strong answer is:

Runtime polymorphism is overriding—a variable typed as Animal holding a Dog calls Dog's speak() at runtime because dispatch uses the object's actual class.

Animal a = new Dog();           // upcast (implicit)
Dog d = (Dog) a;                // downcast — ClassCastException if wrong
if (a instanceof Dog dog) {     // Java 16+ pattern matching
    dog.bark();
}

Always instanceof before downcasting in production code.

A strong answer is:

Upcast to general types for polymorphism; downcast only after instanceof check—otherwise I risk ClassCastException when the object isn't really that subtype.

An abstract class cannot be instantiated; it may contain abstract methods (no body) and concrete methods.

abstract class Shape {
    abstract double area();
    void label() { System.out.println("shape"); }
}

Use when subtypes share common state or implementation but need specialized behavior.

A strong answer is:

Abstract classes are partial blueprints—I share code and fields in Shape while forcing Circle to implement area().

An interface defines a contract—method signatures that implementing classes must provide.

interface Persistable {
    void save();
    void delete();
}

class User implements Persistable {
    public void save() { /* ... */ }
    public void delete() { /* ... */ }
}

Java 8+ allows default and static methods on interfaces. Interfaces support multiple implementation per class.

A strong answer is:

Interfaces define what a type can do without dictating inheritance tree—I implement several on one service class for cross-cutting contracts.

Java 8+ blurs the line with default methods—still prefer interface for roles, abstract class for shared base implementation.

A strong answer is:

Interface for capabilities (Comparable, Runnable); abstract class when subclasses share fields and helper methods—I don't use abstract class just to block instantiation; use private constructor instead.

Interview tip: protected exposes to subclasses even across packages—can leak API surface; prefer private + public methods.

A strong answer is:

I default to private fields, public behavior methods, and protected only when subclasses genuinely need hooks—package-private for internal module APIs.

String is final—security and immutability. Use final on method parameters and local variables when values should not be reassigned (readability).

A strong answer is:

final class blocks inheritance—String uses that; final method freezes behavior; final field means one assignment for references, which helps immutability when the object itself is immutable.

Static methods cannot access instance fields directly. Overuse of static hurts testability and OOP boundaries—see also Java part 1 static questions.

A strong answer is:

Instance members carry per-object state; static belongs to the class—I avoid static mutable state because it breaks encapsulation and makes tests order-dependent.

Rules: if any constructor is defined, default is not auto-generated. Subclass must call super(...) if parent has no no-arg constructor.

A strong answer is:

I use parameterized constructors for required fields and add explicit no-arg only when frameworks need it—remembering Java removes the default once I define any constructor.

class Employee extends Person {
    Employee(String name, int id) {
        super(name);
        this.id = id;
    }
}

A strong answer is:

this is the current instance; super reaches the parent—constructor chaining must put super() or this() first line in constructors.

interface Logger {
    void log(String msg);
    default void logInfo(String msg) { log("INFO: " + msg); }
}

Allows evolving interfaces without breaking every implementor—implementors inherit default unless they override.

Conflict rule: if two interfaces provide the same default, the class must override and choose.

A strong answer is:

Default methods let me add behavior to interfaces without forcing every implementor to update—if two defaults clash, I override explicitly in the class.

High cohesion + low coupling = easier tests and refactors. OOP tools: interfaces, composition, package-private boundaries.

A strong answer is:

I want high cohesion inside a class and loose coupling between classes—depending on PaymentGateway interface, not StripeClient concrete type.

SOLID guides maintainable OOP—common in mid/senior loops and Spring Boot design discussions.

A strong answer is:

SOLID keeps classes focused, extensible without edits, substitutable, interface-small, and wired to abstractions—I cite one real refactor per letter when pressed.

A class should have only one reason to change—one axis of responsibility.

Bad: Invoice generates PDF, sends email, and calculates tax.
Better: Invoice, PdfRenderer, Mailer, TaxCalculator collaborate.

SRP improves testability—mock mailer without touching tax math.

A strong answer is:

SRP means one job per class—if email templates and tax rules change for different reasons, they belong in different classes, not one InvoiceGod.

Software entities should be open for extension, closed for modification—add behavior without editing stable code.

Pattern: Strategy — new DiscountStrategy class instead of editing checkout() switch:

interface DiscountStrategy { int apply(int total); }
class TenPercent implements DiscountStrategy {
    public int apply(int total) { return total * 90 / 100; }
}

A strong answer is:

OCP means I extend with new strategy or handler classes instead of patching a growing if-else in the core checkout method every time marketing adds a promo.

Subtypes must be substitutable for base types without breaking correctness.

Classic violation: Square extends Rectangle—setting width should not break square invariants.

// Anti-pattern: Square changes independent width/height semantics
class Square extends Rectangle {
    void setWidth(int w) { super.setWidth(w); super.setHeight(w); }
}

Callers expecting Rectangle behavior get surprises—favor composition over forced inheritance.

A strong answer is:

LSP means any Rectangle reference should behave as callers expect—Square-as-Rectangle violates that, so I model Square independently or use composition.

ISP: Clients should not depend on methods they do not use.

// Bad: force read-only repo to implement delete()
interface Repository { void save(); void delete(); }

// Better: split
interface Writer { void save(); }
interface Deleter { void delete(); }

DIP: High-level modules depend on abstractions, not concretions.

class OrderService {
    private final PaymentGateway gateway; // interface
    OrderService(PaymentGateway gateway) { this.gateway = gateway; }
}

Spring dependency injection embodies DIP—see Spring Boot interviews.

A strong answer is:

ISP splits fat interfaces so implementors aren't forced to stub unused methods; DIP injects PaymentGateway interfaces into services so tests swap fakes without changing OrderService.

interface Notification { void send(); }
class NotificationFactory {
    static Notification create(String type) {
        return switch (type) {
            case "email" -> new EmailNotification();
            default -> new SmsNotification();
        };
    }
}

A strong answer is:

Factory hides concrete types; Builder assembles complex objects; Singleton only when one instance is truly required—I prefer Spring-scoped beans over hand-rolled Singletons.

Strategy: Encapsulate interchangeable algorithms—payment methods, compression codecs.

Observer: One-to-many notification—UI listeners, domain events.

interface PayStrategy { void pay(int cents); }
class Checkout {
    private PayStrategy strategy;
    void setStrategy(PayStrategy s) { strategy = s; }
    void checkout(int cents) { strategy.pay(cents); }
}

Strategy supports OCP—add CryptoPay without editing Checkout internals.

A strong answer is:

Strategy swaps algorithms at runtime—checkout doesn't care Visa vs UPI; Observer decouples event publishers from subscribers like order-placed emails.

Decorator avoids subclassing every combination of features; Adapter integrates third-party libraries into your OOP boundaries.

A strong answer is:

Adapter makes legacy APIs fit my interface; Decorator layers behavior—Java I/O streams are the textbook Decorator example I cite in interviews.

Entities (interview whiteboard approach):

Use composition: lot HAS floors HAS spots. Use Strategy for pricing. Avoid one ParkingLotManager God class doing payment + SMS + spot math.

A strong answer is:

I'd identify entities, assign SRP, use Strategy for pricing and composition for floor-spot hierarchy, and keep entry/exit flows as methods on ParkingLot delegating to spot allocation—not a single static util class.

Refactor toward small cohesive classes and composition.

A strong answer is:

God classes and deep inheritance hierarchies are red flags—I split responsibilities and inject strategies instead of adding another override layer.

Modern Java blends both—stream().map().filter() is functional style on collections; domain models remain OOP. Neither replaces the other in most enterprise codebases.

A strong answer is:

I use OOP for domain entities with lifecycle and functional style for transformations on immutable data—Java streams don't mean I abandon encapsulation in core models.

Checklist:

• Four pillars with one example each
• Encapsulation vs abstraction and data hiding
• Overloading vs overriding + compile vs runtime poly
• Composition vs inheritance + IS-A vs HAS-A
• Abstract class vs interface decision tree
• Diamond problem and Java interfaces
• Access modifiers table
• SOLID — all five with examples
• Two patterns — Strategy + Factory or Observer
• One OOD scenario — parking lot or library
• Java part 1 for Java-only follow-ups
• C and C++ if systems role

A strong answer is:

I whiteboard pillars and SOLID, run through overloading vs overriding aloud, and walk one OOD scenario with composition and Strategy—then tie answers to code I've actually written.