Study Notes
Spring Boot learning path

Spring mock round 1 — core backend fundamentals

A 30-minute mock interview covering core Spring concepts, debugging, and an API design trade-off.

2 min read·verified Spring Boot 4.x·reviewed 2026-08-29

Assumes you know

After this you should be able to

  • Structure a concise Spring explanation
  • Debug an API failure aloud
  • Defend a backend design trade-off
Mock interviewSpring coreBackend

Back to Spring roadmap

Mock round 1 · core backend fundamentals

Timebox: 30 minutes — 8 minutes explain, 9 minutes debug, 10 minutes design, 3 minutes follow-ups. Speak your answers before opening the framework.

Learning goal

Prompts#

  1. Explain: A junior developer asks why a Spring controller should receive a service through constructor injection. Give a 90-second answer that connects IoC, testability, and a concrete dependency replacement.
  2. Debug: POST /tasks now returns 500 after the team added validation. Narrate the first evidence you would collect, the boundary you would inspect, and how you would prevent the regression.
  3. Design / trade-off: Design a read endpoint for a user’s tasks. Decide where filtering, DTO mapping, error handling, and authorization belong. Defend one choice against a tempting shortcut.

Follow-up: What changes if an admin may see all tasks but a regular user may see only their own?

Follow-up: Which part would you unit test and which part would you exercise through HTTP?

Stop point#

Do not read below until your timer ends. Record one phrase you would improve and one missing trade-off from your answer.

Completion evidence#

Save a voice note or written outline for all three answers. Mark Interview ready only when you made each answer concrete, checked your claims against code or notes, and can answer both follow-ups without restarting.

Current status: Weak

Answer frameworks and rubric#

For each answer: state the boundary, trace one concrete request or dependency, name the benefit, then state the cost or condition. Avoid reciting annotations without a consequence.

  • Accuracy: terms and request flow are technically sound.
  • Reasoning: the answer explains why the boundary exists.
  • Evidence: uses a test, log, or observable HTTP result to ground the claim.
  • Communication: structured answer fits the allotted time and handles a follow-up.