Thirty minutes: explain, debug, and design

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.

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.