Explain a tool-assisted patch through the decisions you made: the behavior you intended to change, the boundaries you set, the suggestions you rejected, the review you performed, and the evidence behind your approval. Make the resulting code and your judgment easy to inspect.
Prepare a short opening, then keep the diff and relevant evidence ready for follow-up questions. An interviewer should be able to move from your explanation to a specific changed branch, acceptance case, or unresolved risk. A chronological account of every interaction rarely provides that structure.
Open with the goal and the risk
State the user-visible problem and the most consequential way the repair could go wrong. Name your responsibility precisely: setting the brief, editing the patch, reviewing it, authorizing the merge, or some combination. Distinguish your decisions from decisions another person owned.
Consider a hypothetical address editor where clearing optional delivery instructions appears to save, but the previous note returns after reload. For this example, define the contract explicitly: an omitted field preserves the stored note, an empty string clears it, and nonempty text replaces it. Other address fields keep their existing behavior.
That contract gives your explanation a concrete starting point. The risk is losing the distinction between an intentional clear and a partial update that leaves the field untouched.
Explain the boundary of the delegated work
Describe what you asked the tool to investigate or change, the relevant context you supplied, and the files or behaviors outside scope. Explain why you chose that boundary.
In the address example, the assignment could cover the form submission, request mapping, and focused address tests. Rewriting validation for every address field would require a separate justification. If inspection reveals that the behavior depends on a shared update contract, explain when you stopped to resolve that dependency.
Keep the account consistent with the diff. If a shared utility changed, be ready to show its other callers and explain the compatibility review. Saying the task was narrow does not establish that the resulting patch stayed narrow.
Show a rejected option and its consequence
Choose an alternative that reveals an engineering decision. Describe what it would change, why it was tempting, and which requirement made you reject it.
For the hypothetical editor, hiding the old note after save could improve the immediate display while leaving stored data unchanged. Changing a shared mapper to retain every empty value might address the symptom while altering unrelated updates. A narrower repair would need to preserve the agreed delivery-instructions contract without silently redefining other fields.
Connect the rejection to behavior, compatibility, maintenance, or scope. If you accepted the first proposal, explain how you challenged it during review. Inventing a rejected suggestion adds nothing useful to the account.
Walk through the review path
Show how you followed the affected value from the interface to storage and back. Identify where omitted and empty values must remain distinct. Inspect both the change and its callers, including any defaulting expression that could discard an intentional empty string.
Name the highest-risk hunk and explain it in ordinary language. Then connect each relevant test to a plausible mistake. A check of the immediate form display would leave the reload behavior unresolved; a check of a helper call alone could leave persistence unresolved.
When discussing completed work, point to the actual review artifact where one exists. If your review missed a dependency, state that directly and explain what further inspection is needed.
Separate expected behavior from observed evidence
Use a small evidence table when several cases matter. For the illustrative contract, prepare these checks:
| Case | Expected behavior | Evidence to inspect |
|---|---|---|
| Clear an existing note | Stored value becomes empty; reload stays empty | Submitted request, persisted state, and reloaded form |
| Omit the field in a partial update | Existing note remains unchanged | Request without the field and stored value afterward |
| Replace the note | New text persists | Submitted text and reloaded value |
| Change another address field | Existing field rules remain intact | Relevant compatibility checks |
These are proposed checks for the example. In an account of real work, distinguish checks you ran, results you inspected from another source, and checks still pending. Name the patch revision and relevant conditions so the evidence can be matched to the code under discussion.
A successful command needs context: which cases it selected, what assertions mattered, and what remained outside its coverage. Explain any unavailable integration check and who must complete it before approval.
Finish with a decision and remaining risk
State whether you would approve the patch, request a specific change, or pause for clarification. Tie that decision to the evidence you can show.
For the address example, a focused test might leave uncertainty about older clients that omit the field. Identify that compatibility gap and the check needed to resolve it. If release behavior matters, name the owner, the condition that would stop the rollout, and the recovery action appropriate to the change.
Give the next person a usable handoff. “Check compatibility” becomes actionable when it identifies the caller, expected behavior, evidence required, and accountable owner.
Explain a regression through the approval decision
If the patch caused a regression, identify what you approved and the exact missed signal: a changed branch, an untested caller, a skipped check, or an approval given before required evidence arrived. Explain contributing causes accurately while keeping responsibility for your own decision clear.
Then describe the review or test change adopted afterward. Be specific about what it catches and who reviewed the repair. If the change is only proposed, say so. A prevention measure needs verification through a regression check, a rehearsal, or subsequent ordinary review before you can describe its effectiveness.
Prepare for three follow-ups: What would you decide differently with the same diff? How did you communicate the regression? What evidence did the reviewer of the fix require? Keep the answers anchored to decisions and inspectable work.
The Agentic Developer Interview includes cards on owning merge decisions after regressions, identifying missing evidence, explaining rejected options, and assessing review, verification, and ownership.