Method overloading vs overriding interview questions, with answers

The questions, with answers

1. 1.What is the difference between method overloading and method overriding?

   Overloading is several methods in the same class with the same name and different parameter lists; the compiler chooses between them from the argument types at compile time. Overriding is a subclass providing its own version of a method it inherits, with the same signature; the JVM chooses the version from the object's actual class at run time. So overloading is compile-time (static) polymorphism and overriding is run-time (dynamic) polymorphism.

   The practical tell: overloads differ in what you pass, overrides differ in what the object is. print(int) and print(String) are overloads; Dog.speak() replacing Animal.speak() is an override.

   class Animal { String speak() { return "..."; } }
   class Dog extends Animal { @Override String speak() { return "Woof"; } }   // override
   
   class Printer {
       void print(int n)    { System.out.println("int " + n); }        // overloads
       void print(String s) { System.out.println("text " + s); }
   }

2. 2.Can you overload a method by changing only the return type?

   No. In Java, C# and C++ the return type is not part of the method signature, so two methods that differ only in return type are a duplicate definition and the code will not compile. The reason is that a call is resolved from the name and the arguments, and the return value may be discarded entirely — with int f() and double f() the statement f(); would be ambiguous. Return type does matter in one place: an overriding method may narrow it to a subtype (covariant return), and it must not change it to an unrelated type. Overloads may have different return types as long as their parameter lists differ.

3. 3.What are the rules for a valid method override in Java?

   Same name and the same parameter types in the same order. A return type that is the same or a subtype of the original. Access that is the same or wider — a public method cannot be overridden as private. Checked exceptions that are the same, narrower or absent; a broader checked exception is a compile error, while unchecked exceptions are unrestricted. Methods marked final or private cannot be overridden, static methods are hidden rather than overridden, and constructors are never overridden. Put @Override on every override: it costs nothing and turns a typo in the parameter list — which would silently create an overload — into a compile error.

4. 4.Which overload does the compiler pick when an argument could match several?

   The most specific one, found in phases. First it tries exact matches and primitive widening without boxing: print(5) prefers print(long) over print(Integer), because widening int to long beats boxing to Integer. Only if that fails does it consider boxing and unboxing, and only after that varargs. Among candidates in the same phase it picks the most specific type, so print(null) chooses print(String) over print(Object), because String is more specific. If two candidates are equally specific — print(String) and print(Integer) both offered null — the call is ambiguous and does not compile, and you must cast the argument to say which you mean.

5. 5.Is an overloaded call resolved by the variable's declared type or the object's runtime type?

   By the declared type of the argument expression, decided at compile time. If a method has overloads describe(Object) and describe(String), then Object o = "hello"; describe(o); calls describe(Object), even though the object is a String at run time — the compiler only knows o as an Object. This is the mirror image of overriding, where o.toString() would run String's version because dispatch on the receiver is dynamic. The two-line summary interviewers want: the method name and overload are fixed by the static types of the arguments; the implementation that runs is chosen by the dynamic type of the receiver.

   static void describe(Object o) { System.out.println("object"); }
   static void describe(String s) { System.out.println("string"); }
   
   Object o = "hello";
   describe(o);              // prints "object" — chosen from the declared type
   describe((String) o);     // prints "string"

6. 6.Can static methods be overridden?

   No — they are hidden, not overridden. A static method belongs to the class, not to any object, so there is no receiver whose runtime class could drive dispatch. If a subclass declares a static method with the same signature, both exist, and which one runs depends on the static type of the reference used to call it: Animal.info() and Dog.info() are two unrelated methods, and calling info() through a variable declared as Animal runs Animal's version even when it holds a Dog. Writing @Override above a static method is a compile error, which is the quickest way to prove the point. The same is true of fields: they are hidden, never overridden.

7. 7.What is a covariant return type?

   An override that returns a subtype of what the overridden method returns. If Animal declares Animal reproduce(), Dog may override it as Dog reproduce(): every Dog is an Animal, so callers who expected an Animal are still satisfied, while callers who know they have a Dog get the more precise type without a cast. Java has allowed it since Java 5; C++ allows it for pointer and reference return types. The clone() method is the standard example — Object.clone() returns Object, and a well-written override returns the class's own type. Parameter types, by contrast, cannot vary in an override; changing one creates an overload instead.

8. 8.Can a constructor be overloaded or overridden?

   Overloaded, yes; overridden, no. A class can declare several constructors with different parameter lists, and one may call another with this(...) to avoid duplicated initialisation. Overriding is impossible because constructors are not inherited: a subclass has its own constructors, and each of them begins by calling a superclass constructor with super(...) — implicitly super() if you write nothing. That call must come first, so the parent part of the object is initialised before the child part touches it. Rules that follow from this: if the parent has no no-argument constructor, every child constructor must call super with arguments explicitly, and a class whose constructors are all private cannot be subclassed from outside it.

How the diagnostic asks it

One question from the OOP bank, exactly as a sitting would show it. The bank has 3 on method overloading vs overriding and 60 across OOP.

class Calculator {
    void show(int a) {
        System.out.println("int: " + a);
    }
    void show(double a) {
        System.out.println("double: " + a);
    }
}

public class Main {
    public static void main(String[] args) {
        Calculator c = new Calculator();
        c.show(5);
    }
}