Java backend interviews cover core language semantics, collections, concurrency, Spring, and how you reason about the JVM. Below are the questions asked most often, each with a model answer. Junior: core theory, definitions, and simple practical cases.
== compares references — whether two variables point at the same object in memory. equals() compares content, if the class overrides it; the default Object.equals falls back to ==. This is why comparing two Strings built at runtime with == returns false while equals() returns true, and it is the single most common Java interview trip-up.
An abstract class can hold state and constructors and describes what something is; a class can extend only one. An interface describes what something can do and a class can implement many. Since Java 8 interfaces can carry default methods, so the practical rule is: shared state means abstract class, shared capability means interface.
Autoboxing is the compiler converting between primitives and their wrappers automatically. It bites in two places: comparing wrappers with == works by accident for small values because of the Integer cache from -128 to 127 and then silently stops working, and unboxing a null Integer throws NullPointerException at a line that looks like plain arithmetic.
They are unrelated despite the names. final makes a variable unassignable, a method unoverridable, or a class unextendable. finally is the block that runs whether or not an exception was thrown, used for cleanup. finalize was a method the garbage collector might call before reclaiming an object; it was unreliable and is deprecated — use try-with-resources instead.
ArrayList wraps a resizable array: access by index is O(1), but inserting in the middle shifts everything after it. LinkedList is a doubly linked list: inserting at a known node is O(1), but reaching index n costs n steps and every element carries pointer overhead. In practice ArrayList wins almost always, because cache locality beats big-O on real hardware.
A static member belongs to the class rather than to any instance, so it exists once no matter how many objects you create and can be used without one. The consequence people forget is that a static field is shared mutable state across the whole application — convenient for constants, a source of hard bugs for anything that changes.
Checked exceptions extend Exception and the compiler forces you to catch or declare them; they describe conditions a caller can reasonably recover from, like a missing file. Unchecked extend RuntimeException and signal programming errors — a null reference, a bad argument. Use unchecked for bugs, and checked sparingly, because forcing every caller to handle something usually produces empty catch blocks.
If two objects are equal they must return the same hash code; the reverse is not required. Break it and a HashMap stops working — you put an object in, look it up with an equal one, and get null, because the lookup went to a different bucket. That is why overriding one without the other is a bug, not a style issue.
Because it is shared. Literals live in the string pool and one instance can be referenced from many places, so a mutable string would let one holder change another's value. Immutability also makes strings thread-safe without synchronisation, lets the hash code be cached, and keeps them safe to use for class loading and connection parameters where a late change would be a security hole.
No — you can only hide it. Overriding is resolved at runtime from the object's type, while a static method is resolved at compile time from the reference type. So a subclass declaring the same static signature does not replace the parent's; which one runs depends on the declared type, not the actual object, which is exactly why calling a static through an instance reference is discouraged.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Junior Java Backend interview →