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. Senior: architecture, trade-offs, mentoring, and decision-making.
Confirm it is a leak first: watch heap after full GC over hours, since a sawtooth that returns to baseline is not a leak. Then take a heap dump and open it in MAT, which names the dominator tree — the objects holding the most retained memory and who references them. The usual answers are an unbounded cache, a ThreadLocal never cleared on a pooled thread, or listeners that register and never unregister.
Almost always, because two-phase commit needs every participant to support it and holds locks across the network, which couples availability of all services to the slowest. A Saga sequences local transactions with compensating actions, so each service commits independently and failure triggers an undo. The cost is that you have to design the compensations, and there are states where an outsider can observe partial completion.
Virtual threads make blocking cheap: a thread parked on IO no longer holds an OS thread, so the thread-per-request model scales without reactive plumbing. The practical consequence is that CompletableFuture chains and reactive stacks adopted purely to avoid blocking lose their reason to exist. What does not change is that synchronized blocks can pin a virtual thread, and thread pools sized for OS threads become the wrong abstraction.
Measure allocation rate first. If the application allocates gigabytes per second, no collector setting will save it and the fix is in the code — object churn in a hot loop, boxing, defensive copies. GC tuning is the right lever when allocation is reasonable but pauses miss your latency target, and then the choice is usually G1 with a pause goal, or ZGC when the heap is large enough that even G1 cannot keep up.
What problem it solves that a module boundary cannot. Independent deploys and independent scaling are real answers; "microservices are modern" is not. Then whether they can run distributed data — no cross-service joins, eventual consistency, and a Saga for anything that used to be one transaction. And whether ops can support it, because ten services with one pipeline and no tracing is worse than the monolith.
Keep dependencies close to current continuously rather than in a big-bang project — the cost grows superlinearly with how far behind you are. Avoid reflection into JDK internals, since that is what breaks under module encapsulation. Have a test suite you trust enough to believe a green run, and upgrade on a branch that builds against both versions so the migration is reviewable rather than a cliff.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Java Backend interview →