25 Java Interview Questions for 2026: From JVM to Spring Boot

Java interviews are unapologetically old-school in one respect: they test whether you understand the platform, not just the language. The JVM, the memory model, the collections framework — these are fair game at every level, and candidates who treat Java as "just syntax" get caught out fast.

The core idea: Java's interview questions revolve around contracts. equals/hashCode is a contract. The Java Memory Model is a contract. Interfaces are contracts. Interviewers are checking whether you honour them.

The question taxonomy

• Core language. String immutability, final, autoboxing pitfalls, generics and type erasure.
• Collections. HashMap internals, ArrayList vs LinkedList, ConcurrentHashMap, fail-fast iterators.
• JVM and memory. Heap vs stack, garbage collection basics, class loading.
• Concurrency. synchronized vs locks, volatile, thread pools, the happens-before relationship.
• Modern Java. Streams, lambdas, Optional, records, virtual threads.

Worked example: the equals/hashCode contract

"Why must you override hashCode when you override equals?" Show, don't tell:

class Employee {
    private final String id;
    Employee(String id) { this.id = id; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Employee)) return false;
        Employee other = (Employee) o;
        return id.equals(other.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

Then the explanation: a HashMap first uses hashCode to pick a bucket, then equals within the bucket. If two equal objects return different hash codes, the map looks in the wrong bucket and your key "disappears" — lookups fail on objects you know are there. Walk through that scenario out loud and you've answered the question the way a senior would.

How answers get scored

Expect grading on precision (do you say "it depends" in the right places — ArrayList vs LinkedList is workload-dependent), on concurrency correctness (no hand-waving "synchronized fixes it"), and on knowing the modern features well enough to not write Java 7 in 2026. Streams questions reward readability over cleverness.

Common mistakes

• Comparing strings with == instead of equals.
• Overriding equals but forgetting hashCode — the classic.
• Claiming volatile makes compound actions like i++ atomic. It doesn't; it only guarantees visibility.
• Modifying a collection while iterating and being surprised by ConcurrentModificationException.

The questions that expose shallow prep

A few questions reliably separate readers from practitioners. "How does a HashMap handle collisions?" — chaining versus treeification, and why the threshold exists. "Why is String immutable?" — security, caching, thread safety, the string pool. "What's the difference between Comparable and Comparator?" — one belongs to the class, the other to the caller. None of these are hard if you've written Java professionally; all of them are brutal if you've only skimmed a cheat sheet. The defence is simple: when you practise, implement the thing once. Write a tiny hash map with buckets and linked entries. Write a thread-safe counter three ways — synchronized, AtomicInteger, explicit lock — and say out loud when each is appropriate. Twenty minutes of implementation buys you more interview credibility than hours of re-reading definitions ever will.

One more habit pays off disproportionately: learn to read stack traces out loud, frame by frame, naming the line where you'd look first and why. Interviewers who hand you a broken snippet or a logged exception are testing exactly that reflex, and it's surprising how many strong coders freeze when the output isn't an IDE hint. Practise on deliberately broken code — a null here, a wrong generic there — until a trace reads like a story instead of noise.

FAQ

How deep on the JVM do I need to go? For most roles: heap/stack, GC generations at a high level, and when you'd profile. JVM tuning internals are for platform and performance-specific roles.

Are data structure questions asked in Java? Yes — you'll implement them in Java, so generics and collections fluency matter. See the software engineer interview guide for that side.

Want to pressure-test your answers out loud? Run timed sessions with Aissence practice, and use the coding copilot when you're mid-implementation.