Interview guide
A Java and Spring interview study plan
This plan is for backend engineers who write Java services and need to explain correctness, not just Spring annotations. Work in a real module: one entity, one repository, one service, one controller. Interviews reward people who can follow a request across those layers.
Language contracts you must say out loud
equals and hashCode fail together. If two objects are equal, they must hash the same; if you mutate a field used in either method while the object sits in a HashSet, you can lose it. Be ready to write both methods for an entity with a generated id and explain why using a business key can be safer before the row is saved.
String, Integer, and other value types have well-known equality. Your domain types do not. Do not wave at Lombok in an interview without describing what you included and excluded.
Collections and complexity
Know when ArrayList, LinkedList, HashMap, and ConcurrentHashMap are the wrong default. Interviewers often ask what happens under concurrent modification, and whether iterator fail-fast behavior is a feature or a foot-gun.
Practice one in-place algorithm (two pointers or a sliding window) and one heap problem. The Java is the easy part; naming the complexity without stalling is the interview skill.
Dependency injection without magic
Constructor injection makes dependencies visible and testable. Field injection hides them. Be able to sketch a Spring bean lifecycle: construct, inject, post-construct, use, destroy.
If you use @Transactional on a self-invocation through this, the proxy never runs. That bug is a classic Spring interview question because it looks like the annotation is ignored.
Transactions and data correctness
State isolation level, rollback rules, and which exceptions mark a transaction rollback-only. Then describe a money-move or inventory decrement that must not double-apply.
Prefer idempotent writes for handlers that can retry. If you cannot make the write idempotent, you need a dedupe key the database can enforce.
Web APIs and errors
Map one endpoint end to end: validation, authz, service call, status codes. 400 for a bad body, 404 for a missing resource, 409 for a conflict you can name, 500 only when you failed unexpectedly.
Do not return a stack trace. Do log a correlation id. Be ready to say how you would find one failed request in production logs.
Tests and a closing exercise
Write a slice test for the service with a fake repository, and one web test that asserts JSON and status. If your only test boots the whole context, say so and name what that leaves untested.
Exercise: accept a POST that transfers units between two accounts. Discuss locking, uniqueness, and what happens if the process dies after debit and before credit. Do not skip the failure path.