Explain Polymorphism.

Hook: Polymorphism is like one universal remote controlling a TV, speaker, and AC: the button is the same, but each device responds in its own way.

Question: Explain polymorphism in Java.

Answer: Polymorphism means one thing can take many forms. In Java, it usually means a parent type can refer to different child objects, and when you call an overridden method, Java runs the child version at runtime. This makes code flexible because you can add new classes without rewriting the code that uses them.

Interview-Ready Answer: I think of polymorphism as “one interface, many behaviors.” In Java, I can store different subclasses in a parent reference or interface reference, and when I call an overridden method, the JVM picks the actual object’s version at runtime. That is why a PaymentMethod variable can represent card, UPI, or wallet payments without the caller knowing the concrete class.

What polymorphism really means

Polymorphism is a core OOP idea where code talks to a general type, but the actual object decides what behavior happens. The word sounds fancy, but the mental model is simple: same call, different result.

1. You define a common parent type, usually an interface or an abstract class (a class that cannot be created directly and is meant to be extended).
2. Each subclass provides its own version of the same method by override (replace inherited behavior with a new one).
3. You store the objects in a parent reference like PaymentMethod or Shape.
4. When you call the method, Java does not pick based on the variable’s declared type alone; it uses the actual object type.
5. This selection is called dynamic dispatch (runtime method selection by the JVM).

Two common kinds in Java

Interviewers often expect you to know that Java supports polymorphism in two ways:

Compile-time polymorphism is usually method overloading. The compiler chooses the method based on the parameter list. Runtime polymorphism is method overriding. The JVM chooses the implementation based on the real object.

How it works under the hood

1. You create a child object, such as a CardPayment, but store it in a parent reference like PaymentMethod method = new CardPayment(...).
2. The reference type tells the compiler which methods are allowed to be called.
3. At runtime, the JVM looks at the object sitting behind the reference.
4. If the method is overridden, the JVM calls the child class version.
5. This decision is very fast: the call is effectively O(1) per method call, and the memory cost is still O(1). In a loop over 10,000 objects, the total cost is O(n) because you still visit each object once, but the dispatch itself is tiny compared with a database call or network request.

When and why to use it

Use polymorphism when you want to write code against a stable contract instead of a concrete class. That is ideal for payments, notifications, report generation, rendering, logging, and plugin systems.

• Extensibility: add a new subclass without changing the caller.
• Testability: you can swap in a fake implementation in tests.
• Readability: the caller stays small because behavior lives inside each class.

Important gotchas

• Fields are not polymorphic. If a child hides a field with the same name, field access uses the reference type, not runtime dispatch.
• Static methods are not polymorphic. They are hidden, not overridden.
• Private methods are not overridden. A subclass can define a same-named method, but it is a new method, not an override.
• Final methods cannot be overridden. That means no runtime polymorphism for that method.
• Overloading is not runtime polymorphism. The compiler chooses the overload from the parameter types it sees, which can surprise people with null or upcasting.

What interviewers listen for

A strong answer says: polymorphism is about calling a method through a parent type and getting child-specific behavior at runtime. A stronger answer adds the difference between overloading and overriding, plus one limitation such as static or final methods.

Real-world story

Imagine an e-commerce checkout service with multiple payment types: card, UPI, and wallet. The service keeps a List<PaymentMethod> and calls pay() on each item, so the checkout flow does not care which payment type is used.

Now picture a production bug: a new WalletPayment class was added, but the team accidentally copied an old pattern with a base class method that did nothing. Orders reached the UI as “paid,” but no money was captured. Symptoms included reconciliation mismatches, customer support tickets, and logs like Payment failed: Insufficient wallet balance or, worse, no gateway call at all because the wrong method was being used.

This is exactly why polymorphism matters: the checkout service should depend on the contract, not on a giant if/else chain. If the implementation is correct, adding a new payment type means adding a new class, not rewriting the checkout logic.

Follow-up & Tricky Questions:

• What is the difference between polymorphism, overloading, and overriding? Polymorphism is the big idea; overloading is same method name with different parameters, while overriding is a subclass replacing a parent method. Overloading is chosen at compile time, but overriding is chosen at runtime.
• Why is polymorphism useful in real systems? It lets you write code against a stable interface and swap implementations without changing the caller. That is a huge win for extensibility, testing, and clean design.
• Can interfaces support polymorphism? Yes. An interface reference can point to any class that implements it, and calling the interface method triggers the concrete class’s version.
• How does Java decide which overridden method to call? It uses the actual object at runtime, not just the variable type. The declared type controls what methods are allowed; the real object controls which override runs.
• Why do developers prefer polymorphism over big if/else chains? Because it moves behavior into classes instead of spreading conditionals throughout the code. That makes the code easier to extend and less risky to change.
• Is method overloading polymorphism or not? Yes, but it is compile-time polymorphism. It is a different mechanism from runtime polymorphism through overriding, and interviewers usually want you to explain both.
• Can static methods be overridden? No. Static methods are hidden, not overridden, so they do not use runtime polymorphism.
• Can constructors be polymorphic? No. Constructors are not inherited, so they cannot be overridden.
• Are fields polymorphic? No. Field access depends on the reference type, which is a common gotcha.

• Gotcha: Is a private method overridden? No. A private method is not visible to subclasses, so a same-named method in a child class is unrelated.
• Gotcha: Does final allow overriding? No. A final method cannot be overridden, so it cannot participate in runtime polymorphism.
• Gotcha: Does overloading pick the runtime object? No. The compiler chooses the overload based on the reference and parameter types it can see, which is why null and upcasting can surprise people.

Common Mistakes:

• Confusing polymorphism with inheritance. Inheritance is the mechanism; polymorphism is the behavior you get when the same call works on different subclasses.
• Thinking overloading is runtime dispatch. Overloading is chosen by the compiler, so it is compile-time polymorphism, not runtime polymorphism.
• Assuming fields behave like methods. Methods can be overridden, but fields are resolved by the reference type, so they are not polymorphic.
• Forgetting that static, final, and private methods do not override. If a method cannot be overridden, it cannot demonstrate runtime polymorphism.

Memory Hook: Think “one remote, many devices”: the same button press goes through one interface, but each device reacts in its own way.

Cheat Sheet:

• Polymorphism = one interface, many behaviors.
• Overriding gives runtime polymorphism.
• Overloading gives compile-time polymorphism.
• Use parent or interface references to stay flexible.
• Fields are not polymorphic; methods are.
• static, final, and private methods do not override.

Practice Tasks:

• Create a Shape interface with Circle and Rectangle, then call area() through a List<Shape>.
• Add a new subclass to the payment example, such as CashPayment, without changing the loop that processes payments.
• Write one overloaded method and one overridden method, then observe which one the compiler chooses and which one the JVM chooses.