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
}