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.

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);
    }
}