Default Constructors

The compiler generates a default constructor for you only when the class declares no constructor at all. The generated one takes no arguments and its body does nothing except the implicit super call. Every field is therefore left at the type's zero value: null for references, zero for numbers, false for boolean, and the null character for char.

public class Main {
    public static void main(String[] args) {
        Settings s = new Settings();
        System.out.println(s.name + "|" + s.retries + "|" + s.verbose);
        Reader r = new Reader();
        System.out.println(r.title + "|" + r.pages);
    }
}

class Settings {
    String name;
    int retries;
    boolean verbose;
}

class Reader {
    final String title;
    final int pages;
    Reader() {
        title = "untitled";
        pages = 0;
    }
}

The output makes the consequence visible. The settings object prints null|0|false, which is legal but rarely what the designer intended. A name field that starts as null tends to produce a null pointer exception far from the constructor that caused it. The reader class avoids the problem by declaring its own constructor and setting sensible defaults, so the object is never null-named or ambiguous.

One subtlety: if any superclass lacks a no-argument constructor, the compiler-generated default constructor in the subclass is invalid, and you must write your own that calls the available super constructor explicitly.

The practical advice for an interview is to treat the implicit default constructor as a design smell in domain classes. If a class can only sensibly exist with certain values, require them in a constructor, and the compiler will then enforce that every caller supplies them.

It disappears. The compiler only supplies the implicit no-argument constructor when a class declares no constructors whatsoever. As soon as you write one, the compiler stops generating anything, and any caller that wants an argument-free instance must be given a constructor that takes no arguments.

public class Main {
    public static void main(String[] args) {
        Config withArgs = new Config("prod");
        System.out.println(withArgs);
        // new Config();  // will not compile: no matching constructor
    }
}

class Config {
    private final String env;
    Config(String env) { this.env = env; }
    public String toString() { return "env=" + env; }
}

The commented line in the code is the point. new Config() would not compile, because the class declares only the one-argument version. This is a feature rather than a bug. It means you can make required information genuinely required: if a configuration object is meaningless without an environment name, you cannot accidentally create one that lacks it.

If you genuinely want both forms, declare both explicitly, or have the convenience constructor delegate to the fuller one. What you should not do is rely on the implicit constructor surviving a later edit, because the moment somebody adds a parameterised constructor, every argument-free call site in the codebase stops compiling.

A good interview summary: the implicit default constructor is a convenience for simple value holders, and adding any constructor of your own takes away that convenience on purpose.