Spring Boot and Java interview practice for experienced engineers
What a senior Java loop actually tests
At four to fifteen years of experience, nobody is going to ask you what an annotation is. You will be asked why something behaves the way it does, and you will be asked to write code that works. A typical Java loop has three strands: data structures and algorithms in Java, questions on Java and the JVM itself, and a Spring or backend round that asks you to reason about a real service.
Candidates fail the third strand for an unglamorous reason: they use Spring daily and have never had to explain it. The framework hides its own machinery so well that a question like "what happens when this method is called?" has no answer ready. The practice below is about making the machinery explainable.
Core Java: the parts that keep coming up
- Collections: how HashMap resolves collisions and resizes, why mutable keys break it, when a TreeMap or LinkedHashMap is the right choice, what fail-fast iterators do.
- equals and hashCode: the contract, what breaks when you override one but not the other, and why records help.
- Concurrency: synchronized versus locks, volatile and what it does not guarantee, ConcurrentHashMap semantics, thread pools and how to size them, CompletableFuture composition and its failure modes.
- Memory and the JVM: heap versus stack, garbage collection at the level of "why did this pause", and how to reason about a leak in a long-running service.
- Streams and Optional: when they clarify and when they obscure, and what a stream pipeline costs.
Do not memorise definitions. For each topic, write a ten-line program that demonstrates the behaviour, run it, and predict the output before you do. Being wrong in private is cheap.
Spring: explain the machinery
Pick five questions and be able to answer them without a laptop: how the application context is built and what a bean lifecycle looks like; what a proxy is and why calling a transactional method from another method in the same class does not start a transaction; how auto-configuration decides what to wire; how a request travels from the servlet container through filters and the dispatcher to your controller and back; and how profiles and externalised configuration resolve a value.
The self-invocation proxy question is worth special attention. It is asked constantly because it separates people who have read the docs from people who have only used annotations.
JPA and the database: where production incidents live
Interviewers at this level ask about the failures you have probably debugged: the N+1 select problem and how to see it in a statement log; lazy loading outside a transaction; the difference between merge and persist; optimistic versus pessimistic locking and what a version column does; why fetching an entity to update one field is wasteful; what an index will and will not help with.
A good drill: take one entity with a one-to-many relationship and write down every SQL statement a simple list endpoint would issue. Then change the fetch strategy and write them again. If you cannot predict the count, you do not yet understand the mapping.
REST and transactions: design with trade-offs
Expect to design a small API live. The substance is in the details: the right status code for a missing resource versus a forbidden one; pagination that stays stable while rows are inserted; idempotency keys so a retried create does not duplicate; validation that returns every field error rather than the first; a consistent error body.
On transactions, know the default rollback rule (unchecked exceptions roll back, checked ones do not unless told), what propagation means in practice, and why a long transaction around a remote call is a bug. Be ready to say what you would do when a database write and a message publish must both happen: the outbox pattern is the honest answer, and "publish after commit" is the minimum.
Do not skip the algorithms
Even for a Java-heavy role, the first round is usually a timed coding problem. The Java-specific skill is fluency: you should be able to write a heap with a comparator, a sliding window over an array, and a map of lists without looking anything up. Practise these in Java, under a clock, because switching to a more comfortable language in practice and then using Java in the interview is a self-inflicted handicap.
Problems that feel like backend work are a good fit: Requests in a window, Undo/redo buffer, Peak hour per zone and Live top-k total. They are the shapes of rate limiters, editors, aggregations and leaderboards.
A weekly routine that fits a job
- Two weekday evenings: one timed algorithm problem each, in Java, 25 minutes, no help.
- One weekday evening: one framework topic, written as a short explanation you could say aloud, plus a small exercise that shows you can apply it.
- One weekend session: a mixed set, then a review of everything you got wrong.
Unaided has a Java track built on this split: timed DSA in Java, and framework exercises on request handling, validation, pagination, transactions, caching, retries and authorisation, checked by a runner rather than by anyone’s opinion. It is not an AI interviewer and it will not tell you your answer sounded confident. It tells you whether the code passes. If that is what you want, begin here, look at pricing, or try a problem first.