Java OOP Interview Questions — The $23K @Override Bug

If you're interviewing for a Java role — junior, mid, or senior — OOP questions are guaranteed to show up. Not because interviewers love theory, but because the way you answer reveals how you actually design software. A candidate who can recite four pillars from memory is forgettable. A candidate who explains WHY encapsulation prevents bugs in a multi-team codebase gets the offer.

The problem is that most resources teach OOP as a list of definitions. That leaves you able to parrot answers but unable to handle the natural follow-up: 'Can you give me a real-world example?' or 'How does that differ from an abstract class?' Those follow-ups are where interviews are actually won or lost.

After working through this article, you'll be able to explain every major OOP concept with a concrete analogy, write runnable code that demonstrates each idea, spot the three classic mistakes candidates make, and handle the tricky follow-up questions interviewers use to separate the memorisers from the thinkers.

What Java OOP Interview Questions Actually Test

Java OOP interview questions assess whether you understand the four pillars—encapsulation, inheritance, polymorphism, and abstraction—not as textbook definitions, but as design tools that prevent production bugs. The core mechanic is that each pillar enforces a contract between components: encapsulation hides state behind methods, inheritance shares behavior across a hierarchy, polymorphism lets one interface serve multiple implementations, and abstraction separates what a system does from how it does it.

In practice, these principles interact in ways that matter at scale. For example, polymorphism via method overriding is O(1) at dispatch but can introduce subtle failures when a subclass changes behavior that a parent class's internal methods rely on. The infamous $23K bug occurred when a developer overrode a method without understanding that the parent class called it internally during initialization, causing a NullPointerException in production. This is why interviewers probe beyond syntax—they want to see if you grasp the runtime implications of each OOP choice.

Use OOP principles when you need to manage complexity across a team or over time. Encapsulation reduces ripple effects from refactoring; inheritance should be used only for true "is-a" relationships, not code reuse (prefer composition). Polymorphism enables pluggable architectures like strategy or observer patterns. In real systems, failing to apply these correctly leads to fragile code that breaks when extended, costing hours of debugging and, in extreme cases, revenue loss.

The Four Pillars — What They Are and Why Each One Exists

Every Java OOP interview starts here. The four pillars are Encapsulation, Abstraction, Inheritance, and Polymorphism. But interviewers don't want a dictionary. They want to know you understand the problem each pillar solves.

Encapsulation solves the 'who changed my data?' problem. By bundling data with the methods that operate on it and hiding the internals, you prevent other parts of the system from putting an object into an invalid state. Think of a bank account — you never want external code to set the balance directly to a negative number.

Abstraction solves the 'I don't need to know how' problem. You expose only what's necessary and hide everything else. This is why you can call list.sort() without understanding TimSort.

Inheritance solves the 'don't repeat yourself' problem. Common behaviour lives in a parent class; child classes inherit it and specialise where needed.

Polymorphism solves the 'treat different things uniformly' problem. One interface, many implementations. This is what makes your code extensible without modification — the Open/Closed Principle in action.

package io.thecodeforge.oop;

/**
 * Production-grade Encapsulation Example.
 * We protect the 'balance' invariant from external corruption.
 */
public class BankAccount {
    private double balance;
    private final String accountId;

    public BankAccount(String accountId, double initialDeposit) {
        this.accountId = accountId;
        validateAndSetBalance(initialDeposit);
    }

    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance += amount;
    }

    public void withdraw(double amount) {
        if (amount > balance) {
            throw new IllegalStateException("Insufficient funds for account: " + accountId);
        }
        this.balance -= amount;
    }

    public double getBalance() {
        return balance;
    }

    private void validateAndSetBalance(double amount) {
        if (amount < 0) throw new IllegalArgumentException("Initial balance cannot be negative");
        this.balance = amount;
    }
}

Polymorphism vs Abstraction — The Question That Trips Everyone Up

These two are the most commonly confused pillars, and interviewers exploit that confusion heavily. Here's the clean separation: Abstraction is about DESIGN — hiding complexity behind a simple interface. Polymorphism is about BEHAVIOUR — the same call producing different results depending on the actual object at runtime.

Abstraction is implemented in Java via abstract classes and interfaces. You define WHAT something must do without specifying HOW. Polymorphism is what happens at runtime when Java resolves which overridden method to actually call.

A classic follow-up: 'What's the difference between method overloading and method overriding?' Overloading is compile-time polymorphism — same method name, different parameters, resolved by the compiler. Overriding is runtime polymorphism — same signature in parent and child, resolved by the JVM based on the actual object type.

package io.thecodeforge.oop;

import java.util.List;

// ABSTRACTION: The 'What'
interface Notifier {
    void send(String message);
}

// POLYMORPHISM: The 'How'
class EmailNotifier implements Notifier {
    @Override public void send(String msg) { System.out.println("Emailing: " + msg); }
}

class SlackNotifier implements Notifier {
    @Override public void send(String msg) { System.out.println("Slacking: " + msg); }
}

public class NotificationService {
    public void broadcast(List<Notifier> recipients, String message) {
        // Polymorphic call: The service doesn't care about concrete types
        recipients.forEach(n -> n.send(message));
    }
}

Abstract Classes vs Interfaces — When to Use Which

This is arguably the most asked Java OOP question at mid-level interviews. Both enforce a contract. Both support polymorphism. But they're not interchangeable, and using the wrong one reveals a gap in design thinking.

Use an abstract class when you have a true 'is-a' relationship AND shared state or behaviour to inherit. Example: a Vehicle abstract class that stores fuelLevel and has a concrete refuel() method that all vehicles share. Child classes extend this and implement their own accelerate() method.

Use an interface when you're defining a capability that could apply to completely unrelated classes. Serializable, Comparable, and Runnable are capabilities, not identities. A Dog and a BankTransaction can both be Serializable — that doesn't mean they share a parent.

Since Java 8, interfaces can have default and static methods, which blurs the line slightly. The practical rule: if you need instance state (fields) in the shared contract, you need an abstract class. Interfaces can't hold instance state.

package io.thecodeforge.oop;

// Abstract Class: Shared state (identity)
abstract class BaseVehicle {
    protected int fuelLevel;
    public void refuel(int amount) { this.fuelLevel += amount; }
    public abstract void drive();
}

// Interface: Shared capability
interface GPS {
    String getCoordinates();
}

class SmartCar extends BaseVehicle implements GPS {
    @Override public void drive() { fuelLevel -= 5; }
    @Override public String getCoordinates() { return "51.5074 N, 0.1278 W"; }
}

Inheritance Pitfalls and the Liskov Substitution Principle

Inheritance looks clean on paper but is the most misused OOP feature in real codebases. The classic mistake: using inheritance for code reuse when there's no genuine 'is-a' relationship. Stack extending Vector in Java's own standard library is the canonical example of this done badly — a Stack is NOT a Vector, but Java's designers used inheritance for convenience, which meant Stack accidentally exposed methods like add(int index, Object element) that make no logical sense for a stack.

The Liskov Substitution Principle (LSP) is the interview gold standard here. It says: if you replace a parent with any of its subtypes, the program should still behave correctly. A Square extending Rectangle violates LSP — if you set width on a Square it must also change the height, which breaks any code that expects to set width and height independently.

When LSP is in danger, favour composition over inheritance. Instead of Square extending Rectangle, give Square a Dimensions object internally.

package io.thecodeforge.oop;

/**
 * Demonstrating LSP: Any subtype of Payment must be substitutable
 * without breaking the 'process' logic.
 */
public abstract class Payment {
    public abstract void process(double amount);
}

class CreditCardPayment extends Payment {
    @Override
    public void process(double amount) {
        System.out.println("Charging credit card: $" + amount);
    }
}

class RefundablePayment extends Payment {
    @Override
    public void process(double amount) {
        System.out.println("Processing refundable payment: $" + amount);
    }
    
    public void refund(double amount) {
        System.out.println("Refunding: $" + amount);
    }
}

Composition Over Inheritance – A Real-World Refactoring

Many developers default to inheritance when they need to share code. But composition — assembling behaviour from smaller, focused classes — is often a better choice. The rule of thumb: 'Favor composition over inheritance.'

Consider a Bird class that needs to fly. If you create a FlyingBird subclass, you'll soon have NonFlyingBird, SwimmingBird, etc. Adding a new capability (like Sing) explodes the class hierarchy. Instead, compose the bird with a FlyBehavior interface and delegate.

Interviewers love this topic because it tests your ability to design flexible systems. When they ask 'How would you model a bird?' they're not looking for inheritance tree depth; they want to see if you reach for interfaces and delegation.

Here's a clean composition example: an OrderProcessor composed with a DiscountCalculator instead of extending a BaseOrder. This lets you swap discount strategies at runtime without changing the processor.

package io.thecodeforge.oop;

// Discount as a separate responsibility
interface DiscountCalculator {
    double applyDiscount(double total);
}

class NoDiscount implements DiscountCalculator {
    @Override public double applyDiscount(double total) { return total; }
}

class SeasonalDiscount implements DiscountCalculator {
    @Override public double applyDiscount(double total) { return total * 0.9; }
}

public class OrderProcessor {
    private final DiscountCalculator discount;

    public OrderProcessor(DiscountCalculator discount) {
        this.discount = discount;
    }

    public double process(double total) {
        // ... validation, tax calculation etc.
        return discount.applyDiscount(total);
    }
}

Object Creation in Java — The Full Menu

Every Java developer knows 'new'. But if you're debugging a memory leak or designing a library that needs to control instantiation, you need the full picture. Here's what you can actually do: the new keyword (for normal objects), Class.forName().newInstance() (reflection, still used in legacy frameworks), Constructor.newInstance() (reflection with parameter access, preferred for modern reflective code), clone() (shallow copy — no constructor called, watch for shared mutable state), and deserialization (reads the object from a byte stream, also skips the constructor). Why does this matter? Because two of these mechanisms bypass constructor validation entirely. If your constructor sets invariants (e.g., 'age must be positive'), a cloned or deserialized object can violate them silently. The rule: never rely on a constructor alone for security. Validate invariants in setters or use a factory method that controls the entire creation path.

// io.thecodeforge
public class User {
    private final String name;
    private final int age;

    public User(String name, int age) {
        if (age < 0) throw new IllegalArgumentException("Age cannot be negative");
        this.name = name;
        this.age = age;
    }

    // Clone bypasses constructor!
    @Override
    public User clone() {
        return (User) super.clone(); // age could be -1
    }
}

// Usage in production:
User original = new User("Alice", 30);
User clone = original.clone(); // no validation here

Access Modifiers — The Gatekeepers You Can't Ignore

Access modifiers are not a syntax quiz. They are your contract with the rest of the codebase. private means 'implementation detail — change at will'. public means 'other teams depend on this; break it and you get paged at 3 AM'. Here's the real-world breakdown: public — visible everywhere. Use only for API endpoints or stable library interfaces. protected — visible to subclasses and same package. This is the most abused modifier. Why? Because people use 'protected' for fields, thinking it's safe. It's not. It couples you to every subclass ever written. default (no modifier) — visible to package. Good for internal helpers you don't want to leak. private — only the class. Getters and setters should never be the default. Ask: 'does this state need to be exposed?' If not, keep it private. A senior move: use private for everything, then relax to default or protected only when you have a concrete use case. Never start with public.

// io.thecodeforge
public class PaymentService {
    private double rate;   // OK — internal state
    protected int timeout; // BAD — now every subclass inherits this field
    public String name;    // WORST — anyone can mutate your identity

    public PaymentService(double rate, int timeout, String name) {
        this.rate = rate;
        this.timeout = timeout;
        this.name = name;
    }
}

// After refactoring — defensive:
public class BetterPaymentService {
    private final double rate;
    private final int timeout;
    private String name;

    public BetterPaymentService(double rate, int timeout, String name) {
        this.rate = rate;
        this.timeout = timeout;
        this.name = name;
    }

    protected int getTimeout() { return timeout; } // controlled access
}

OOP Design Interview in Java: Parking Lot, Chess, Vending Machine

Object-oriented design interviews test your ability to model real-world systems using OOP principles. Common problems include designing a parking lot, a chess game, or a vending machine. The key is to identify classes, their relationships, and behaviors.

Parking Lot Design: Start with ParkingLot containing multiple Levels, each with ParkingSpots. Spots can be for different vehicle types (e.g., compact, large). Use inheritance: Vehicle abstract class with subclasses Car, Truck, Motorcycle. Implement parkVehicle(), removeVehicle(), and isFull(). Use enums for VehicleSize and SpotType. Ensure thread safety for concurrent access.

Chess Game: Model Board as an 8x8 grid of Piece objects. Piece is abstract with isValidMove() implemented by subclasses like King, Queen, Rook. Use enums for Color (WHITE, BLACK). Game class manages turns, check/checkmate logic. Consider using the Strategy pattern for move validation.

Vending Machine: States (Idle, Selecting, Dispensing) can be modeled with the State pattern. VendingMachine holds inventory (Map of Product to quantity) and a Payment interface (Cash, Card). Handle edge cases like insufficient change or sold-out items.

Focus on extensibility, encapsulation, and single responsibility. Interviewers look for clear class hierarchies, appropriate use of interfaces, and handling of edge cases.

public enum VehicleSize { COMPACT, LARGE, MOTORCYCLE }

public abstract class Vehicle {
    protected String licensePlate;
    protected VehicleSize size;
    public abstract boolean canFitInSpot(ParkingSpot spot);
}

public class Car extends Vehicle {
    public Car(String license) {
        licensePlate = license;
        size = VehicleSize.COMPACT;
    }
    @Override
    public boolean canFitInSpot(ParkingSpot spot) {
        return spot.getSize() == VehicleSize.COMPACT || spot.getSize() == VehicleSize.LARGE;
    }
}

public class ParkingSpot {
    private VehicleSize size;
    private Vehicle currentVehicle;

    public ParkingSpot(VehicleSize size) { this.size = size; }
    public boolean isAvailable() { return currentVehicle == null; }
    public boolean park(Vehicle v) {
        if (!isAvailable() || !v.canFitInSpot(this)) return false;
        currentVehicle = v;
        return true;
    }
    public void removeVehicle() { currentVehicle = null; }
    public VehicleSize getSize() { return size; }
}

public class Level {
    private List<ParkingSpot> spots;
    public Level(int numSpots) {
        spots = new ArrayList<>();
        for (int i = 0; i < numSpots; i++) {
            spots.add(new ParkingSpot(VehicleSize.COMPACT));
        }
    }
    public boolean parkVehicle(Vehicle v) {
        for (ParkingSpot spot : spots) {
            if (spot.park(v)) return true;
        }
        return false;
    }
}

Composition vs Inheritance: Modern Best Practices

Inheritance establishes an "is-a" relationship, while composition establishes a "has-a" relationship. Modern best practices favor composition over inheritance because it offers greater flexibility, lower coupling, and easier testing.

Why Composition Wins: Inheritance exposes subclasses to parent implementation details, breaking encapsulation. Changes in the parent class can ripple through the hierarchy. Composition allows you to swap behaviors at runtime via delegation. For example, a Bird class can have a FlyBehavior interface, with CanFly and CannotFly implementations, instead of subclassing FlyingBird and NonFlyingBird.

When to Use Inheritance: Use inheritance only when there is a genuine hierarchical relationship and the subclass is a true subtype (Liskov Substitution Principle). For example, Square extends Rectangle is problematic because changing width independently violates LSP. Instead, use composition: Square contains a Rectangle or uses a Shape interface.

Example: Instead of Dog extends Animal, use Dog { private Animal animal; } if you need to reuse animal behaviors. Prefer interfaces for defining contracts. Use default methods in interfaces sparingly.

Modern Java: Records and sealed classes provide controlled inheritance. Records are implicitly final, encouraging composition. Sealed classes allow you to restrict which classes can extend them, making hierarchies more predictable.

Testing: Composition makes mocking easier because you can inject dependencies. Inheritance requires testing the entire hierarchy.

// Inheritance approach (fragile)
class Animal {
    void eat() { System.out.println("Eating"); }
}
class Dog extends Animal { }

// Composition approach (flexible)
interface EatBehavior {
    void eat();
}
class CanEat implements EatBehavior {
    public void eat() { System.out.println("Eating"); }
}
class Dog {
    private EatBehavior eatBehavior;
    public Dog(EatBehavior eatBehavior) { this.eatBehavior = eatBehavior; }
    public void eat() { eatBehavior.eat(); }
}

// Usage
Dog dog = new Dog(new CanEat());
dog.eat();

SOLID Principles with Java Code Examples

SOLID is a set of five design principles that make code more maintainable and scalable. Here's how they apply in Java:

Single Responsibility Principle (SRP): A class should have only one reason to change. Example: Employee class should not handle both payroll calculation and database persistence. Separate into Employee, PayrollCalculator, and EmployeeRepository.

Open/Closed Principle (OCP): Classes should be open for extension but closed for modification. Use interfaces or abstract classes. Example: Shape interface with area() method, and Circle, Rectangle implement it. Adding a new shape doesn't modify existing code.

Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. Classic violation: Square extends Rectangle where setting width affects height. Instead, use a common Shape interface.

Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don't use. Split large interfaces into smaller, specific ones. Example: Worker interface with work() and eat(); separate into Workable and Eatable.

Dependency Inversion Principle (DIP): Depend on abstractions, not concretions. High-level modules should not depend on low-level modules. Use dependency injection. Example: NotificationService depends on MessageSender interface, not EmailSender directly.

Applying SOLID leads to testable, decoupled code. Use them as guidelines, not rigid rules.

// SRP: Separate concerns
class Employee {
    private String name;
    // getters/setters
}
class PayrollCalculator {
    public double calculatePay(Employee e) { return 0; }
}

// OCP: Extend without modifying
interface Shape {
    double area();
}
class Circle implements Shape {
    private double radius;
    public double area() { return Math.PI * radius * radius; }
}

// LSP: Square does not extend Rectangle
interface Rectangle {
    void setWidth(int w);
    void setHeight(int h);
    int getArea();
}
class Square implements Rectangle {
    private int side;
    public void setWidth(int w) { side = w; }
    public void setHeight(int h) { side = h; }
    public int getArea() { return side * side; }
}

// ISP: Segregated interfaces
interface Workable { void work(); }
interface Eatable { void eat(); }
class Robot implements Workable {
    public void work() { }
}

// DIP: Depend on abstraction
interface MessageSender {
    void send(String message);
}
class EmailSender implements MessageSender {
    public void send(String message) { }
}
class NotificationService {
    private MessageSender sender;
    public NotificationService(MessageSender sender) { this.sender = sender; }
    public void notify(String msg) { sender.send(msg); }
}