Spring Boot Interview Questions
Spring Boot interviews reward understanding one mechanism properly: the proxy. Transactions, caching, async execution, security and retries are all implemented by wrapping your bean, and nearly every surprising Spring bug is the proxy not being involved where you assumed it was. A candidate who understands proxying can derive most of the answers; a candidate who has memorised annotations cannot.
The classic demonstration is the self-invoked transactional method. A public method annotated `@Transactional`, called from another method inside the same bean, runs with no transaction at all — silently, with no error, until data is left half-written. It is asked constantly because it is both common in real codebases and impossible to answer from annotation recall.
Written and reviewed by Sahil Srivastav
What the bar actually is
You should be able to say where a transaction begins and ends, what happens on an unchecked versus a checked exception, and why calling an external service inside the boundary is a defect — the transaction stays open for the whole round trip, holding a connection and a snapshot, and never closes if the remote call hangs without a timeout.
On the container, you are expected to understand bean scope as a correctness concern rather than a performance setting. Singleton beans holding mutable request state is the most common Spring concurrency bug, and it passes every single-user test. Interviewers probe this by asking what happens when two requests hit the same bean simultaneously.
How the rounds are structured
Machine coding in Spring Boot
A small REST service with persistence. Transaction boundaries and validation placement are scored, not just whether the endpoints work.
Transaction and proxy mechanics
Propagation, rollback rules, self-invocation, and why `@Transactional` on a private method does nothing. The deciding round for Spring roles.
JPA and query behaviour
Lazy loading and where it explodes, the N+1 problem, the difference between `getReference` and `findById`, and what the persistence context actually caches.
Configuration and container questions
Bean scope, conditional configuration, profiles, and how auto-configuration decides what to create.
What this interview bar tests
Proxy awareness
Self-invocation bypasses the proxy, so transactions, caching, async and retries silently do not apply. Deriving this from the mechanism is the signal.
Transaction boundary discipline
Short, database-only, and ending before any network call. The boundary wrapped around an entire request handler is the source of most idle-in-transaction incidents.
Rollback semantics
By default rollback happens on unchecked exceptions only — a caught or checked exception commits. This default surprises people in production.
Lazy loading and the N+1 problem
Where the ORM hides query count, and why each query being fast does not make the endpoint fast.
A preparation plan that works
- 1Write the self-invocation bug yourself and observe that no transaction starts. Then fix it three ways — extract to another bean, inject self, use programmatic transactions — and be able to say which you would choose and why.
- 2Build an endpoint with a lazy relationship and watch the query count with SQL logging on. Then fix it with a fetch join or an entity graph. One real observation makes the N+1 answer concrete.
- 3Deliberately put a `RestTemplate` or `WebClient` call inside a `@Transactional` method and look at the connection and transaction age under load. The idle-in-transaction consequence becomes obvious.
- 4Give a singleton bean a mutable field and hit it concurrently. The resulting corruption is the clearest possible lesson about bean scope.
Questions you should expect
Why does this `@Transactional` method not open a transaction?
Because it is being called from another method inside the same bean, so the call does not pass through the proxy that would start the transaction. The annotation is honoured only on calls arriving from outside the bean. Fixes: move the method to a separate bean, self-inject, or use `TransactionTemplate`. A private or final method is a related case — the proxy cannot intercept it at all.
You catch an exception inside a transactional method. Does it roll back?
No. Rollback is triggered by an unchecked exception propagating out of the boundary. Catching it, or throwing a checked exception, commits by default — which is how partially applied writes get persisted with no error anywhere. Use `rollbackFor` or rethrow unchecked if that is not what you want.
Is it safe to store request data in a singleton service?
No. A singleton is shared across every concurrent request, so mutable instance state is a data race that single-user testing never reveals. Pass state as parameters, or use a request-scoped bean if it genuinely must be held — and remember a request-scoped bean injected into a singleton needs a proxy to work at all.
Why is this endpoint slow when every query in the log is fast?
Query count rather than query cost — the N+1 pattern, where a lazy relationship is accessed per row in a loop. A hundred one-millisecond queries plus round-trip overhead is a slow endpoint made of fast queries. Fix with a fetch join, an entity graph, or `selectinload`-style batching depending on the stack.
What gets candidates rejected
- Not knowing that self-invocation bypasses the proxy, which disables transactions, caching and async silently
- Assuming a caught or checked exception triggers a rollback
- Making an HTTP call inside a transactional boundary
- Mutable state on singleton beans
- Wrapping an entire request handler in one transaction
- Treating N+1 as acceptable because each individual query is fast
- Reciting annotations without being able to explain what creates the behaviour
What to practise, in order
Database connection pool exhaustion
The consequence of long or leaked transactions, with pool and database evidence. A bigger pool does not make the tests pass.
Transactional outbox implementation
The correct answer to "I need a database write and a remote call to be consistent", which is the real fix for a network call inside a transaction.
Database overload under a traffic spike
N+1 plus a missing index plus an unbounded fetch, with tests asserting statements executed per request.
Java backend interview coding problems
Repository challenges in Java where the service layer is wrong in ways the bundled test suite exposes immediately.
FAQ
How much Spring internals do I need?
Enough to derive behaviour from proxying and the bean lifecycle rather than recalling annotation semantics. If you understand that AOP features are implemented by wrapping the bean, you can answer most Spring questions you have never seen before — which is exactly what interviewers are testing.
Is JPA or JDBC preferred in interviews?
Neither as a matter of taste, but you should know JPA's failure modes because they are what get asked: lazy loading outside a session, N+1, the persistence context caching more than you expected. Candidates who prefer JDBC should be able to say what JPA would have cost them.
Do I need WebFlux?
Only if the role names it. Most Indian Spring roles are servlet-stack, and reactive knowledge is a bonus rather than a baseline. Claiming it without having operated it is risky because the follow-ups get specific about backpressure quickly.
How are configuration questions usually asked?
Through a problem rather than a definition: this bean is not being created, this property is not taking effect, this profile behaves differently in production. Understanding resolution order and conditional auto-configuration answers all three.