Twelve questions senior Java interviews return to, from HashMap and the memory model to GC choice and virtual threads, with what strong answers cover.
Core Java interview questions for 10 years experience cover collections, concurrency, the JVM and modern language features; at this level the follow-up questions go deeper. Nobody expects a decade-long Java developer to define a HashMap. They expect you to explain why one returned null for a key you just put in, when volatile is not enough, which garbage collector you would pick and why, and what you have actually used since Java 8. Below are the twelve questions that do that work, grouped by area, each with what the interviewer is testing and an outline of a strong answer. The answers draw on the Java Language Specification, the JDK documentation and the JEPs, all linked in Sources.
Senior Java loops usually add system design and a behavioral round to these questions, and our overview of how software engineer interviews change by level shows what to expect from each stage.
How to read this list
Each question has a "first answer" that any experienced developer gives and a second layer that separates senior candidates. Plan for the second layer. A good habit is to end each technical answer with one sentence of trade-off ("this costs X, so I would not use it when Y") and, where you have one, a short production example of your own. The example outlines below are illustrative: swap in your own systems and numbers, because the interviewer will ask about them.
The Java version matters too. Oracle lists Java 8, 11, 17, 21 and 25 as long-term-support releases, with Java 29 planned as the next one in September 2027. In New Relic's 2024 report, Java 17 ran in 35% of the applications it monitored, up from about 9% a year earlier. If the job posting mentions Java 17 or 21, expect at least one question on features from those releases.
Collections and the object contract
1. How does HashMap work, and what changed in Java 8?
What it tests: whether you know the structure well enough to reason about its failure modes.
Strong answer: keys are hashed into buckets; colliding entries share a bucket and are compared with equals. Since Java 8 (JEP 180), a bucket that grows past a threshold switches from a linked list to a balanced tree, which improves worst-case lookup from O(n) to O(log n) under heavy collisions. The second layer: the JEP describes the gain for key types that implement Comparable, and a tree bucket only softens a bad hash function rather than fixing it.
2. What goes wrong if you override equals but not hashCode?
What it tests: the Object contract, which senior developers are expected to enforce in code review.
Strong answer: the hashCode contract says equal objects must return the same hash code, and the equals documentation says you generally need to override both. Break it and hash-based collections stop finding your keys:
class Key {
final int id;
Key(int id) { this.id = id; }
@Override public boolean equals(Object o) {
return o instanceof Key k && k.id == id;
}
// hashCode not overridden: falls back to identity
}
Map<Key, String> m = new HashMap<>();
m.put(new Key(1), "a");
m.get(new Key(1)); // usually null: the two keys land in different bucketsThen add the related trap: a key whose fields change after insertion can become unreachable, which is a reason to prefer immutable keys. A record generates equals and hashCode from its components (JEP 395), which removes this class of bug for simple value types.
3. When would you use ConcurrentHashMap instead of a synchronized map?
What it tests: whether you know what the class does and does not promise.
Strong answer: retrievals generally do not block and can overlap with updates, so it scales better than a map behind one lock. The second layer comes straight from its documentation: it rejects null keys and values, its iterators are weakly consistent and never throw ConcurrentModificationException, and size() is typically only meaningful when no other thread is updating the map, so do not branch on it. For compound updates, use the atomic methods rather than get-then-put:
ConcurrentHashMap<String, LongAdder> freqs = new ConcurrentHashMap<>();
freqs.computeIfAbsent(key, k -> new LongAdder()).increment();The documentation warns that other updates may block while the mapping function runs, so keep it short.
Concurrency
4. What does volatile guarantee, and what doesn't it?
What it tests: the Java Memory Model, which is where many experienced candidates go vague.
Strong answer: the JLS defines happens-before: a write to a volatile field happens-before every subsequent read of it, and an unlock of a monitor happens-before every subsequent lock of it. So volatile gives visibility and ordering. It does not make compound actions atomic:
private volatile int count;
void hit() { count++; } // read, add, write: two threads can read the same value and lose an updateUse AtomicInteger, or LongAdder for a counter that many threads hit; its documentation says throughput under high contention is significantly higher than AtomicLong, at the cost of more memory.
5. Is double-checked locking safe in Java? How would you write a singleton?
What it tests: a memory-model question disguised as a design-pattern question.
Strong answer: the classic version was broken, because another thread could see a non-null reference to a partly constructed object. Since JDK 5 it works if the field is volatile. For a static singleton there are simpler options: a holder class (the JVM does not initialize the nested class until it is first used) or an enum.
class Config {
private Config() {}
private static class Holder { static final Config INSTANCE = new Config(); }
static Config get() { return Holder.INSTANCE; }
}
enum Registry { INSTANCE } // JLS: no clones, no reflective instantiation, no duplicates on deserializationThe second layer is to question the singleton itself: global state makes testing harder, and dependency injection usually does the job better.
6. synchronized or ReentrantLock?
What it tests: choosing a tool for a reason.
Strong answer: ReentrantLock has the same basic semantics as an intrinsic lock, plus tryLock with a timeout, interruptible acquisition, multiple Conditions and an optional fairness policy. Its documentation notes that fair locks can be much slower. The cost is that you must release it yourself:
if (lock.tryLock(2, TimeUnit.SECONDS)) {
try {
// critical section
} finally {
lock.unlock();
}
} else {
// fail fast: log, back off, retry later
}A current second layer: JEP 444 advised replacing long-held synchronized blocks with ReentrantLock when using virtual threads, because blocking inside synchronized pinned the carrier thread. JEP 491 in JDK 24 removed nearly all of that pinning. Saying which JDK your team runs shows you know the advice changed.
7. A service hangs in production. How do you find a deadlock?
What it tests: diagnosis, not definitions.
Strong answer: take a thread dump. Oracle's troubleshooting guide suggests jcmd <pid> Thread.print over the older jstack. Sending the process a quit signal (kill -QUIT <pid> on Linux, Control+Break on Windows) prints a dump and runs deadlock detection; when it finds a cycle, it adds a "Found one Java-level deadlock" section naming each thread and the lock it waits for. With jstack, the -l option also reports java.util.concurrent locks rather than only monitors. Then explain the fix: a consistent global lock order, or tryLock with a timeout so a thread backs off instead of waiting forever.
8. When do virtual threads help, and when don't they?
What it tests: whether you read past the headline of Java 21.
Strong answer: JEP 444 finalized them in JDK 21 and is explicit that they provide scale (higher throughput), not speed (lower latency). They help when there are many concurrent tasks, typically more than a few thousand, and the work is not CPU-bound, such as request handlers waiting on I/O. They should never be pooled; create one per task and limit concurrency with a semaphore if a downstream system needs protecting. A CPU-heavy batch job gains nothing.
9. How do CompletableFuture chains run, and how do errors surface?
What it tests: asynchronous code you have debugged, not just written.
Strong answer: the ...Async methods without an executor argument run on ForkJoinPool.commonPool(), so blocking I/O there can starve unrelated work; pass your own executor. Failures propagate down the chain: exceptionally and handle let you recover, and join() throws an unchecked CompletionException with the original exception as its cause, while get() throws a checked ExecutionException. Logging the cause, not the wrapper, is the detail that shows experience.
The JVM and memory
10. How do you choose a garbage collector?
What it tests: whether you tune from evidence or from folklore.
Strong answer: Oracle's tuning guide says to start with the collector the VM selects, adjust heap size, and only then switch. G1 has been the default on server-class configurations since JDK 9 (JEP 248). The guide's rule of thumb: Parallel when peak throughput matters and long pauses are acceptable, G1 when pauses must be kept shorter, ZGC when response time is a high priority. Since JDK 23, ZGC runs in generational mode by default (JEP 474). A strong answer ends with how you would measure: GC logs or a Flight Recorder recording before and after, compared against a latency target.
11. Walk me through an OutOfMemoryError in production.
What it tests: a structured incident response.
Strong answer: read the detail message first, because they mean different things. Oracle's guide says "Java heap space" means an allocation failed and does not necessarily mean a leak; "GC overhead limit exceeded" means the collector is running most of the time with little progress; "Metaspace" means class metadata in native memory exceeded the configured limit. Then gather evidence: run with -XX:+HeapDumpOnOutOfMemoryError, take a heap dump or class histogram with jcmd, and if the leak is slow, keep Flight Recorder running, since the guide notes it must be recording when the leak happens. Only after that do you change heap size or code. Raising -Xmx without first reading the detail message and gathering a heap dump or histogram can hide a leak rather than diagnose it, so show that you gather evidence first.
Modern Java
12. What have you used since Java 8, and where?
What it tests: whether your Java has kept moving. Java 8 features (lambdas, streams, Optional) are a common starting point, so be ready to say where you would not use them. A good line on Optional: its documentation says it is intended mainly as a method return type for "no result", and an Optional variable should never itself be null.
Strong answer: name features you shipped, not a release-notes list. Records (final in JDK 16), sealed classes (JDK 17) and pattern matching for switch (JDK 21) work well together:
sealed interface Payment permits Card, BankTransfer {}
record Card(String last4) implements Payment {}
record BankTransfer(String iban) implements Payment {}
String describe(Payment p) {
return switch (p) {
case Card c -> "card ending " + c.last4();
case BankTransfer b -> "transfer from " + b.iban();
}; // no default needed: the compiler checks every permitted type is covered
}The second layer is the trade-off: adding a new permitted type breaks every exhaustive switch at compile time, which is the point. Also, a switch without case null still throws NullPointerException on a null selector (JEP 441).
A ten-day preparation plan
- Days 1 to 2: pick two incidents or performance problems from your own work and write each as situation, evidence, fix, result. They will anchor questions 7, 10 and 11.
- Days 3 to 4: reread the HashMap, ConcurrentHashMap and Object documentation and JLS section 17.4.5 on happens-before. Explain each out loud in under two minutes.
- Days 5 to 6: write the snippets on this page from memory, then break them on purpose: remove volatile, drop hashCode, add a type to the sealed interface.
- Days 7 to 8: on a local service, take a thread dump and a heap dump with jcmd and start a Flight Recorder recording, so the commands are familiar rather than memorized.
- Days 9 to 10: do a mock round with a colleague who will ask "why?" twice after every answer. For design rounds, see our Java architect interview questions; for coding rounds, our Java coding interview questions.
If you want help during the interview itself, Verve AI's Interview Copilot for Java interviews listens to the conversation and shows suggestions only you can see. Upload your resume and job details, and add your incident write-ups to its Knowledge Base, so its suggestions draw on your own examples.
Sources
- Java SE LTS releases (8, 11, 17, 21, 25) and Java 29 as the next planned LTS in September 2027: https://www.oracle.com/java/technologies/java-se-support-roadmap.html
- Java 17 in 35% of monitored applications in 2024, up from about 9% in 2023: https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem
- HashMap buckets switching to balanced trees, O(n) to O(log n), Comparable keys, Java 8: https://openjdk.org/jeps/180
- hashCode contract and overriding equals with hashCode: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html
- Records finalized in JDK 16 with generated fields, accessors, constructor, equals, hashCode and toString: https://openjdk.org/jeps/395
- ConcurrentHashMap non-blocking retrievals, no nulls, weakly consistent iterators, size under concurrent updates, atomic computeIfAbsent and the LongAdder example: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html
- Happens-before rules for volatile and monitors: https://docs.oracle.com/javase/specs/jls/se21/html/jls-17.html
- LongAdder versus AtomicLong under contention: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/atomic/LongAdder.html
- Double-checked locking broken, fixed with volatile from JDK 5, static holder approach: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
- Enum classes: no cloning, no reflective instantiation, no duplicate instances from deserialization (JLS 8.9): https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html
- ReentrantLock semantics, fairness cost, tryLock, unlock in finally: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html
- Virtual threads final in JDK 21, scale not speed, workloads that benefit, never pool, pinning in synchronized: https://openjdk.org/jeps/444
- JDK 24 removes nearly all synchronized pinning: https://openjdk.org/jeps/491
- jcmd preferred over jstack, Thread.print, "Found one Java-level deadlock", jstack -l for java.util.concurrent locks: https://docs.oracle.com/en/java/javase/21/troubleshoot/diagnostic-tools.html
- CompletableFuture default commonPool, CompletionException and ExecutionException behavior: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/CompletableFuture.html
- Collector selection guidance: https://docs.oracle.com/en/java/javase/21/gctuning/available-collectors.html
- G1 default on server configurations since JDK 9: https://openjdk.org/jeps/248
- Generational ZGC default since JDK 23: https://openjdk.org/jeps/474
- OutOfMemoryError detail messages, heap dumps, HeapDumpOnOutOfMemoryError, jcmd, Flight Recorder: https://docs.oracle.com/en/java/javase/21/troubleshoot/troubleshooting-memory-leaks.html
- Optional intended as a return type; Optional variables should never be null: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html
- Sealed classes final in JDK 17: https://openjdk.org/jeps/409
- Pattern matching for switch final in JDK 21, exhaustiveness and null handling: https://openjdk.org/jeps/441
- Verve Interview Copilot (suggestions visible only to the user): https://docs.vervecopilot.com/features/interview-copilot
- Verve personas and Knowledge Base: https://docs.vervecopilot.com/features/create-first-persona, https://docs.vervecopilot.com/features/knowledge-base
Ryan
CEO of Verve AI
