A useful PR review interview gives the candidate a small change, an explicit behavioral contract, and enough surrounding code to support a decision. Prepare the answer key before the round. It should identify actual defects, explain their consequences, and name checks that distinguish a repair from a plausible mistake.
Ask for prioritized findings and an approval decision. Record what the candidate points to in the patch and how they explain its impact. A list of possible problems is a starting point; a review finding needs evidence.
Supply a diff that supports the questions
Provide the ticket, before-and-after code, relevant callers, and existing tests. Include permission rules and response contracts when the change depends on them. Keep the patch small enough that the candidate can inspect its important paths within the allotted time.
A summary such as “adds an administrative export and refactors filters” cannot establish either a security defect or a regression. An endpoint name does not establish its access rules. The candidate needs to inspect where authorization happens and how the query selects records.
Use the same artifact and policy for each candidate. State whether the round permits execution, documentation, or other tools. For a written review, ask for proposed checks and record them as proposals. If execution is part of the round, supply the environment and record observed results separately.
Design two defects and one coverage gap
For an illustrative member-export exercise, define this contract: callers may export only their authorized team's members; an explicit inactive-member filter selects inactive members; an authorized empty export still contains the column header. A local variable rename preserves behavior.
Prepare a patch containing two deliberate defects: its record query trusts the requested team identifier without constraining it to the authorized team, and its filter builder discards an explicit false. Keep empty-export behavior correct but omit its test. Verify that the surrounding authorization code does not already prevent the cross-team request.
The private key could contain:
| Target | Evidence in the prepared patch | Required review response |
|---|---|---|
| Team boundary defect | A caller can select another team's identifier and reach an unscoped query | Block approval; require authorized scoping and an adverse access check |
| Inactive filter defect | A truthiness condition drops active=false, changing the selected members |
Block approval; preserve explicit false and check the selected records |
| Missing empty-export test | The contract requires a header for no matches, but no test covers it | Request a concrete coverage addition without inventing an implementation failure |
| Harmless rename | The local binding and its references change consistently | Leave it nonblocking unless another concrete problem is shown |
This is a specification for an interviewer to prepare, not a claim that a runnable patch accompanies the exercise. Check the finished artifact against the key before using it. If another material defect appears, repair the exercise or update the key.
Make every keyed finding inspectable
For each defect, record the file or snippet, trigger, expected behavior, actual behavior, consequence, and acceptable repair boundary. Add the minimum evidence required to resolve the finding. An alternative implementation should receive credit when it preserves the same contract.
For the team boundary, specify a caller authorized for team A requesting team B. The expected outcome is rejection without exposing team B's records. Include a permitted team A export so that denying every request cannot satisfy the checks. Check both access control and record selection; filtering an already-created export in the browser leaves the server boundary unresolved.
For the inactive filter, use a fixture with active and inactive members. State the expected member identifiers for an explicit false filter, then include true and omitted-filter cases under their documented meanings. For each defect, require a check that would fail for the relevant reason before repair and pass after repair. Keep the empty-export coverage request separate from those defect findings.
Protect time for prioritization and a verdict
A practical forty-five-minute written round can reserve five minutes for the contract and questions, twenty for inspection, ten for review comments, and ten for the decision and follow-ups. Announce the transitions so that a candidate does not spend the entire round reading.
Encourage three passes: map the behavioral change and touched files; examine contracts, tests, and adverse cases; then consider maintainability and cleanup. The first pass should identify the highest-risk path. Formatting comments can wait until the behavioral findings and missing test have been addressed.
Ask which comment the candidate would leave publicly. A useful answer names the location, failing condition, consequence, and required proof. For example: “The query accepts the requested team identifier without enforcing the caller's team scope. A team A caller could select team B's records. Constrain selection to the authorized scope and add denied and permitted export cases.”
Score the reasoning behind the findings
Prepare observation criteria alongside the key. Record whether the candidate identifies the intended contract, supports the two defects with code references, separates missing coverage from demonstrated breakage, and reaches a decision with explicit limits.
Do not turn the key into a keyword checklist. “Check authorization” is less specific than a traced access path and an adverse case. A candidate who names a different, well-supported defect has supplied evidence the panel must examine. A candidate who questions the key may have found a missing assumption.
Keep severity tied to consequence and the stated contract. The team boundary is a blocker because it exposes another team's records. The filter regression is a blocker because it exports the wrong selection. The missing test needs a coverage decision; the harmless rename needs no speculative objection.
Close with evidence and remaining work
Require an approve, request-changes, or escalate verdict. For this prepared patch, request changes should identify the two blocking defects, the proposed checks, the coverage gap, and any uncertainty that needs clarification. Do not treat a test plan as proof that a repair works.
After the round, score independently and compare the artifacts behind each judgment. Record disagreements as specific questions about code, contracts, or evidence. Assign any follow-up needed to resolve them before drawing broader conclusions about the candidate.
The Agentic Developer Interview includes cards on PR review rounds with two bugs, one missing test, and one harmless style issue, and on three-pass diff reviews that prioritize behavior, contracts, and tests before cleanup.