Inheritance & polymorphism: interview questions & scenarios

Model answer

Overloading is several methods with the same name and different parameter lists, usually in one class. The compiler picks one using the static types of the arguments and writes that exact signature into the bytecode.

Overriding is a subclass replacing an inherited instance method with the same name and parameter types. The JVM picks the implementation at runtime from the class of the receiver object. An override needs a same or covariant return type, equal or wider access, and no new or broader checked exceptions.

Model answer

class Payment {
    String channel = "generic";
    String channel() { return channel; }
    static String gateway() { return "default"; }
}
class UpiPayment extends Payment {
    String channel = "upi";
    @Override String channel() { return channel; }
    static String gateway() { return "npci"; }
}

Payment p = new UpiPayment();
System.out.println(p.channel);     // generic
System.out.println(p.channel());   // upi
System.out.println(p.gateway());   // default

Only the instance method is polymorphic. Field access and static calls are resolved by the compiler from the static type of p, which is Payment. The object actually holds two channel fields, and the override reads its own.

Model answer

No to both. A static method with the same signature in a subclass hides the parent's; the call is bound at compile time to the static type, and @Override on it is a compile error. An instance method can't override a static one or the reverse; both are compile errors.

A private method isn't inherited, so a same-signature method in the subclass is a brand-new, unrelated method. Calls inside the parent to its private method always run the parent's version, whatever the object's class.

Model answer

Because of the diamond problem. With two parent classes that share an ancestor, there's no good answer to "how many copies of the ancestor's fields does the object have?" or "which overridden body runs?". Interfaces have no instance fields, so the state half of the diamond disappears.

Since Java 8 interfaces can carry default methods, so behaviour can still clash. The rules: a class's method always wins over a default, a more specific interface wins over a less specific one, and otherwise the compiler forces you to override and pick with Refundable.super.policy().

Model answer

class Notifier {
    void send(Payment p)     { System.out.println("payment"); }
    void send(CardPayment c) { System.out.println("card"); }
    void send(Object o)      { System.out.println("object"); }
}

Payment p = new CardPayment();
Notifier n = new Notifier();
n.send(p);                   // payment
n.send((CardPayment) p);     // card
n.send(null);                // card

Overload choice uses the static type of the argument. p is declared Payment, so send(Payment) wins even though the object is a CardPayment. The cast changes the static type, so the card overload is chosen. For null, all three apply and the compiler picks the most specific: CardPayment is a subtype of both others.

Model answer

class Payment {
    static { System.out.println("Payment static"); }
    { System.out.println("Payment init"); }
    Payment() { System.out.println("Payment()"); }
}
class CardPayment extends Payment {
    static { System.out.println("CardPayment static"); }
    { System.out.println("CardPayment init"); }
    CardPayment() { System.out.println("CardPayment()"); }
}

new CardPayment();
new CardPayment();

Payment static
CardPayment static
Payment init
Payment()
CardPayment init
CardPayment()
Payment init
Payment()
CardPayment init
CardPayment()

Static blocks run once, parent first, when each class is initialised. For every object, the constructor first calls super() (inserted by javac), then runs its own class's field initializers and instance blocks, then its body. So parent init and constructor finish before any child field is initialised.

Model answer

javac rejects a cast it can prove can never succeed: between unrelated classes such as sibling CardPayment and UpiPayment, or from a final class to an interface it doesn't implement. Everything else compiles.

A downcast like (CardPayment) payment compiles to checkcast, which runs at runtime. null passes, an object whose class is CardPayment or a subtype passes unchanged, and anything else throws ClassCastException. Casts never change the object; they change the type the compiler checks against.

Model answer

false. instanceof returns false for null and never throws, so x != null && x instanceof Order has a redundant null check. If the static type can never be the target, like two sibling classes, it's a compile error.

Since Java 16, if (p instanceof CardPayment card) checks, casts and binds in one step. The binding is in scope wherever the match is proven: on the right of &&, inside the if, and after if (!(p instanceof CardPayment card)) return;. It's not in scope on the right of ||.

Model answer

class Payment {
    Payment() { System.out.println(describe()); }
    String describe() { return "payment"; }
}
class CardPayment extends Payment {
    private final String last4;
    private int retries = 3;
    CardPayment(String last4) { super(); this.last4 = last4; }
    @Override String describe() { return "card *" + last4 + " retries=" + retries; }
}

new CardPayment("4242");   // prints: card *null retries=0

Dispatch already uses the real class while the parent constructor runs, so describe() runs the override. But the child's field initializers and constructor body haven't run yet, so it sees default values. The timeline below shows the five steps.

Fig. 1

Five steps of constructing a CardPayment: allocation with zeroed fields, the CardPayment constructor calling super, the Payment constructor calling describe which reads null and 0, then field initializers and the constructor body setting the real values

Model answer

javac compiles payment.fee() to invokevirtual Payment.fee:()J, which names the method but not the implementation. At runtime the JVM reads the receiver's class pointer, looks up fee at its fixed slot in that class's vtable, and jumps. Each subclass copies its parent's vtable and replaces the slots it overrides. Interface calls use invokeinterface and an itable.

Static calls, constructors and super.m() use instructions that name an exact method with no lookup. The diagram compares the four.

Fig. 1

The four invoke instructions: invokestatic and invokespecial bind to a fixed method, while invokevirtual and invokeinterface read the receiver's class and go through a vtable or itable

Model answer

Spring creates class-based (CGLIB) proxies by subclassing your bean and overriding its methods to wrap them in a transaction. A final method can't be overridden, so the proxy inherits it unchanged. Calls go straight into your code with no transaction, and nothing fails at startup.

The NPE comes from where that code runs. The proxy is a separate instance whose own fields were never injected; the real bean sits behind it. Since the final method runs on the proxy instance itself, it reads the proxy's repository field, which is null.

Model answer

That's the fragile base class problem. Your subclass overrides both add and addAll and counts in each. In the old version, Cart.addAll copied items directly into its list. In the new version, it loops and calls add for each item, which dispatches to your override. Every item is now counted twice: once in your addAll, once in your add.

class AuditedCart extends Cart {
    private int added;
    @Override public void add(String sku) { added++; super.add(sku); }
    @Override public void addAll(Collection<String> skus) { added += skus.size(); super.addAll(skus); }
}

Your code depended on how the parent is implemented, not on what it promises. The fix is composition: wrap a Cart, forward calls, and count in your own methods, so internal self-use can't reach you.

Model answer

long fee(Payment p) {
    if (p instanceof CardPayment c) return c.amountPaise() * 2 / 100;
    if (p instanceof UpiPayment)    return 0;
    throw new IllegalStateException("unknown payment " + p);
}

The problem is that the compiler can't tell you the chain is incomplete. Add WalletPayment and this fails at runtime, in whichever method nobody updated.

If the behaviour belongs to the type, make fee() an abstract method and let each class implement it. If it's an outside concern (reporting, mapping to a DTO), make Payment a sealed interface and use an exhaustive switch with no default. Adding a permitted type then breaks the build at every switch that doesn't handle it.

Model answer

The call payment.fee() in the hot loop was probably bimorphic before: the JIT had seen only CardPayment and UpiPayment, inlined both behind a class check, and then optimised across the inlined code. A third receiver class makes the site megamorphic. If no single class reaches about 90% of calls, C2 stops inlining and emits a real vtable or itable call, which also blocks escape analysis and other optimisations around it.

For small methods that's commonly a 2x to 5x slowdown of that call, which shows up when it sits in a tight loop.

Model answer

The instanceof bytecode has to resolve the class it names before it can compare anything. The JVM does that the first time the instruction runs with a non-null reference. If KafkaEvent isn't on the runtime classpath (an optional dependency that was dropped from this deployment, for example), resolution fails with NoClassDefFoundError, even though the answer would have been false.

It only appears at runtime, only on the first non-null check, and not in tests where the dependency is present.

Model answer

Since Java 5, an override may return a subtype of the parent's return type: Payment copy() can be overridden by CardPayment copy(). Callers holding a CardPayment get a CardPayment back without a cast.

The JVM, though, identifies methods by name and full descriptor, including the return type, so copy()Payment and copy()CardPayment are different methods to it. javac generates a synthetic bridge method Payment copy() in CardPayment that calls the covariant one, so calls through a Payment reference still dispatch correctly. The same trick makes generic overrides like compareTo(Order) work after erasure.