Backend Code Review Interview: API, Database & Security Exercises

Backend code review interviews are useful when the role touches APIs, data access, permissions, or reliability. Instead of asking a candidate to implement a greenfield algorithm from scratch, give them a small change and ask what they would approve, block, or refactor.

What This Format Measures

• •Data and boundary thinking: Does the candidate understand queries, ownership, input validation, and failure paths?
• •Security judgment: Does the candidate notice authorization, exposure, and unsafe defaults?
• •Reliability: Can they reason about timeouts, retries, concurrency, partial failure, and observability?
• •Prioritization: Can they separate a release blocker from a style preference and explain the impact?
• •Communication: Can they give actionable feedback without pretending that every issue has equal importance?

Four Scenarios to Include

1. API Handler and Data Access

Start with Inefficient API Implementation. Ask the candidate what the endpoint is trying to do, which inputs cross a trust boundary, and which query or response behavior is most expensive.

A strong answer does not jump straight to a framework recommendation. It first identifies missing pagination, over-fetching, unnecessary work, and the data that must be validated before it reaches the client.

2. N+1 Queries and Connection Pressure

Use N+1 Database Queries to test whether the candidate can trace the number of roundtrips as data grows. Ask them to compare batching, joining, and caching instead of prescribing one solution before understanding the workload.

3. Authorization Boundaries

Use Authorization & Security Bug to see whether the candidate distinguishes resource existence from resource ownership. Follow up with: where should the check live, and what should the logs contain without exposing sensitive data?

4. Async Reliability and Back-Pressure

Use Promise Concurrency Exhaustion or Async Error Handling. The useful signal is whether the candidate identifies uncontrolled concurrency, floating promises, swallowed errors, and the policy for partial failure.

A Focused 45-Minute Structure

1. Context — 5 minutes: Give the user story, constraints, and what the change is meant to protect.
2. First read — 10 minutes: Ask what the candidate would verify before editing.
3. Findings — 15 minutes: Have them rank three to five issues and explain the risk.
4. Focused fix — 10 minutes: Request one small change that addresses the highest-value issue.
5. Debrief — 5 minutes: Ask what belongs in CI, what belongs in review, and what needs an owner.

A Simple Rubric

Score each dimension from one to five:

• •Correctness: Identifies behavior that can fail, lose data, or violate an access boundary.
• •Risk prioritization: Separates blockers from suggestions and explains impact.
• •Design judgment: Proposes a focused change without unnecessary abstraction.
• •Communication: Asks clarifying questions and gives feedback the author can act on.

A candidate does not need to find every planted flaw. A well-reasoned first finding is more useful than a long list of guesses.

Common Failure Modes to Avoid

• •Do not hide the entire product context; a mysterious snippet rewards pattern matching.
• •Do not mix five unrelated bugs into one exercise; prioritization becomes impossible to interpret.
• •Do not treat formatting preferences as equivalent to a security or data-loss issue.
• •Do not ask for a complete rewrite; the goal is evidence of judgment, not endurance.

Run a Backend Review Live

Use the code review exercise library for the full scenario set, or create a Pairlet interview room with a custom task. For the broader interviewer framework, read Code Review Interviews: How to Run One and What to Evaluate.