Sample mock interview report
This is what you get after every mock interview
A hire-bar verdict, your competency profile, and per-answer coaching: what you covered, what a strong answer includes, where you lost points, and how you sounded. Click through the questions below. It's the same report you'll see in the app.
Sample data from a fictional mid-level candidate interviewing for a Backend Engineer (Java / Spring Boot) role. Your report is generated from your own recorded answers, whiteboard, and code.
Borderline
Close, but not consistently above bar. Targeted practice recommended.
You: 66% · Bar: 70% · -4 vs bar
Competency profile
Six axes used in real panel evaluations. Dashed line is the hire bar.
- Technical72%
- Problem Solving70%
- Structure58%, needs work
- Tradeoffs54%, needs work
- Communication68%
- Pacing74%
Areas to strengthen
- System design trade-offs52%
- Spring transaction internals58%
- Behavioral: quantifying impact55%
In the app, these feed your readiness dashboard and revision queue automatically.
Personalized coaching from your session
Solid Java fundamentals and a correct coding solution, but answers often stop at "what" without the "why". In system design you reached a working architecture quickly and then didn't defend it: no capacity numbers, and the Redis failure mode only came up when prompted.
Calibrated for a mid-level backend role at a product company: interviewers expect you to drive the design and raise trade-offs unprompted.
Communication avg
65%
Session pace
148 WPM
Total fillers
23
Hire signal read
A panel would likely split. Coding and Spring basics clear the bar; design depth and the incident story are what keep this at borderline rather than lean hire.
Biggest lift available: name a trade-off for every decision you make, out loud, before the interviewer asks.
Pace is comfortable. Fillers cluster at the start of answers ("so basically"); a two-second pause to plan would remove most of them.
Questions (4)
Question 1
How does @Transactional work in Spring, and when does it silently not apply?
Rubric coverage
63%
Avg score
64%
Answer comparison
You correctly identified proxy-based AOP and the self-invocation trap, which is what most interviewers are fishing for. You missed checked exceptions (no rollback by default) and didn't explain why REQUIRES_NEW matters, for example for audit logs that must persist even when the outer transaction rolls back.
Your answer
So basically @Transactional wraps the method in a transaction. Spring creates a proxy around the bean and when you call the method it begins a transaction, and if there's a runtime exception it rolls back, otherwise it commits. One case where it doesn't work is if you call the method from inside the same class, because then you're not going through the proxy. Also I think it only works on public methods. You can set propagation like REQUIRED or REQUIRES_NEW depending on whether you want a new transaction.
Expected answer (SME bar)
Interview question: How does @Transactional work in Spring, and when does it silently not apply?
- Spring wraps the bean in a proxy (JDK dynamic or CGLIB) and a TransactionInterceptor begins/commits around the call
- Self-invocation bypasses the proxy, so the annotation is ignored
- Only unchecked exceptions trigger rollback by default; use rollbackFor for checked ones
- Non-public methods are not intercepted with proxy-based AOP
- Propagation (REQUIRED vs REQUIRES_NEW) with a concrete use case
- The transaction is bound to the thread, so work on @Async or other threads runs outside it
Model interview answer
Start with the mechanism (proxy + interceptor + thread-bound transaction), then list the failure modes as a crisp set: self-invocation, non-public methods, checked exceptions, and other threads. Close with propagation and one real example where REQUIRES_NEW is the right call.
Gap analysis
- Didn't mention that checked exceptions commit by default, which is the most common production surprise.
- Propagation was named but not motivated with a scenario.
- No mention of thread-bound transactions (@Async, CompletableFuture).
How to improve
- Structure as mechanism → failure modes → configuration. It signals depth immediately.
- Keep one concrete REQUIRES_NEW story ready, e.g. writing an audit row that must survive a rollback.
- Replace "I think it only works on public methods" with the reason: proxies can't intercept non-public calls.
Speech & delivery
Clear once you got going. The opening sentence restated the question instead of answering it.
Points arrived in recall order rather than a structure an interviewer can follow.
Want this for your next interview?
Paste the job description, add your resume, and run the rounds that role will actually ask for.