What Is a Constructor?

A constructor is a special method whose name matches the class name and whose job is to bring a freshly allocated object into a usable state. It has no return type, not even void, because it does not return anything: the runtime does that for you. Its body is the first code that ever executes for that object.

public class Main {
    public static void main(String[] args) {
        Account a = new Account("Ada", 100.0);
        Account b = new Account("Grace");
        System.out.println(a);
        System.out.println(b);
    }
}

class Account {
    private final String owner;
    private double balance;
    Account(String owner, double balance) {
        this.owner = owner;
        this.balance = balance;
    }
    Account(String owner) {
        this(owner, 0.0);
    }
    void deposit(double amount) { balance += amount; }
    public String toString() { return owner + " " + balance; }
}

What it guarantees is that the object is valid before any other code can see it. Because the constructor runs before the reference escapes to the caller, there is no window in which a half-built object exists. Fields that must be set can be final, so the compiler enforces that every path through the constructor sets them. The second constructor delegates to the first through this, so there is one place where the rules are written rather than two.

Two design points are worth mentioning in an interview. First, keep constructors small and side-effect free; a constructor that sends an email or writes to a database makes object creation unpredictable and hard to test. Second, prefer making invalid states unrepresentable by validating in the constructor, rather than by hoping callers remember to validate afterwards.

The decision is made at compile time by matching the arguments in the new expression against the parameter lists the class declares. It uses the same rules as method overloading: exact matches first, then widening primitive conversions, then boxing, then a widening reference conversion. If nothing matches, the code does not compile, and if more than one matches equally well, the compiler reports an ambiguous call rather than guessing.

public class Main {
    public static void main(String[] args) {
        Point a = new Point(3, 4);
        Point b = new Point(6, 8);
        Point c = new Point(9);
        System.out.println(a);
        System.out.println(b);
        System.out.println(c);
        System.out.println(a.distanceTo(b));
    }
}

class Point {
    private final int x;
    private final int y;
    Point(int x, int y) { this.x = x; this.y = y; }
    Point(int x) { this(x, 0); }
    double distanceTo(Point other) {
        int dx = x - other.x;
        int dy = y - other.y;
        return Math.sqrt(dx * dx + dy * dy);
    }
    public String toString() { return "(" + x + "," + y + ")"; }
}

The output shows the three cases in action. new Point(3, 4) picks the two-argument constructor, new Point(9) picks the one-argument constructor, and that constructor delegates to the two-argument one with a default y of zero. The distance between the first two points is exactly 5.0, since the differences are 3 and 4.

Two related details round out the answer. First, the compiler records the chosen constructor in the class file, so the selection is resolved once rather than at every call. Second, the argument expressions are evaluated before the constructor body runs, in left to right order, which matters when you pass a call that has a side effect.

The rule exists because a subclass cannot touch its inherited state before that state exists. When a subclass instance is created, the parent part of the object has to be initialised first, and only the parent constructor knows how to do that. Making super the first statement guarantees the inherited fields are in a valid state before the subclass body touches them.

If it were allowed later, a whole class of bugs would appear. A subclass constructor could read an inherited final field before it was assigned, or call an inherited method that depends on that field, and get a default value where it expected a real one. The compiler would no longer be able to promise that an object's invariants hold from the moment its constructor returns.

The compiler enforces this by making an explicit super call mandatory whenever the parent has no no-argument constructor. If the parent does have one, the call is implicit and happens before the subclass body. You can also write it as this(...) to delegate to another constructor of the same class, and that call must itself come first.

The interviewer is really probing whether you understand the order of object initialisation: memory is allocated, the parent constructor runs, then the subclass body runs, and only then does the reference become usable. Being able to state that sequence cleanly is a good sign that you have read the language rather than only copied code into it.