Interview replay

Full round replay — @Transactional

10 minintermediate2–8 yrs

Timed verbal replay with pass/fail criteria per follow-up.

How to run this

Answer out loud, timed. Do not read the entry first. Then compare against "The Answer" and "Interviewer's Next Move" and mark yourself.

The opener

“How does @Transactional actually work?”

Budget: 45 seconds. Going long here is itself a fail signal.

Follow-ups

  1. 1. “I annotated a method and it is not transactional. Why?”

    Testing: Do they reach for self-invocation first, or start guessing config?

    Scoring

    Pass: Almost certainly self-invocation — another method of the same class called it directly, so the call never crossed the proxy. Also possible: private, final, or a final class.

    Fail: Suggests missing @EnableTransactionManagement or a datasource problem before considering the proxy.

  2. 2. “How would you fix a self-invocation problem?”

    Testing: Design instinct versus reaching for a workaround.

    Scoring

    Pass: Move the method to another bean and inject it — usually the right design anyway. Self-injection or AopContext.currentProxy() work and are a smell.

    Fail: Only knows AopContext, or suggests adding another annotation.

  3. 3. “Which exceptions roll back by default?”

    Testing: The default that surprises nearly everyone.

    Scoring

    Pass: RuntimeException and Error. A checked exception COMMITS. Override with rollbackFor.

    Fail: Says any exception rolls back.

  4. 4. “Why does Spring commit on a checked exception?”

    Testing: Can they explain the reasoning, not just the rule?

    Scoring

    Pass: A checked exception is part of the declared contract, so it is treated as an anticipated outcome rather than a failure. Defensible, and almost never what the author intended.

    Fail: Calls it a bug, or has no explanation.

  5. 5. “What does REQUIRES_NEW actually do?”

    Testing: Whether they know it takes a second connection.

    Scoring

    Pass: Suspends the current transaction and runs in a separate one on another connection. A pool of one deadlocks, and the inner transaction cannot see the outer's uncommitted writes.

    Fail: 'It starts a nested transaction' — that is NESTED, which is a savepoint.

  6. 6. “Should a transactional method call an external HTTP API?”

    Testing: Connection-pool reasoning.

    Scoring

    Pass: No. The transaction spans the whole method, so the connection is held across the network call and the pool drains under load. Move the call outside the boundary.

    Fail: Sees no problem, or mentions only latency.

  7. 7. “A transactional method catches its own exception and logs it. What happens?”

    Testing: The proxy only sees what escapes.

    Scoring

    Pass: It commits — the proxy never saw an exception. And if the transaction was already marked rollback-only, the commit fails later with UnexpectedRollbackException, far from the cause.

    Fail: Expects a rollback.

  8. 8. “Why does none of this produce a warning?”

    Testing: Whether they understand the cost of annotation-driven behaviour.

    Scoring

    Pass: It is an annotation, not a language construct — the compiler cannot know Spring will try to proxy it, and Spring cannot know you meant the call to be intercepted. Only a test that observes behaviour catches it.

    Fail: Assumes the framework validates it.

Score yourself

8/8 — you can defend this under pushback at senior level 6-7 — solid; the rollback and propagation details are where points go 4-5 — you know it is a proxy but not what follows; redo the Challenge 0-3 — run the Warm-up and watch the proxy get bypassed

← Back to How does @Transactional actually work, and when does it silently do nothing?