Agentic Interview Failure Recovery: Stop, Revert, a...

The agent's first patch fails. The second patch makes a different test fail. Now the diff is growing faster than your understanding, and the remaining interview time is shrinking. The worst response is to keep prompting until something turns green.

Recovery is an engineering signal. A strong candidate stops compounding the failure, preserves the evidence, returns to a known-good boundary, and re-plans a smaller experiment. Git documents different tools for restoring working-tree content and reversing committed changes; GitHub documents branches as isolated lines of development. Those mechanics matter only after you understand the state you are trying to recover.

Recognize the Moment to Stop

Failure is not simply a red test. A red test can be useful. The stop signal appears when the current path no longer produces reliable learning.

Stop when the agent changes files outside the stated scope, when each fix creates a new unrelated symptom, when the explanation no longer matches the code, or when the next command could erase the evidence needed to diagnose the problem.

Also stop when the task has silently expanded. A local behavior fix that now requires a schema migration, API contract change, dependency introduction, or external side effect needs a new decision, not another automatic iteration.

The AI debugging framework provides a broad diagnostic method. This guide stays narrowly focused on recovering control after an agent damages the repository state.

Why the Weak Recovery Loop Fails

The weak loop is prompt, patch, fail, prompt again. It feels active, but each iteration changes both the system and the hypothesis. Soon you cannot tell which edit caused which symptom.

Another weak response is immediate cleanup. Candidates delete generated files, discard the diff, clear logs, or replace the test before recording the failure. The screen becomes cleaner, but the most useful evidence disappears.

A third failure is using recovery terms interchangeably. Restoring an uncommitted file, reversing a committed change with a new commit, switching to a clean branch, and discarding all local work have different consequences. Choosing by command familiarity can remove unrelated work or corrupt the history the interviewer wants to inspect.

Finally, weak candidates apologize without updating the plan. “The agent made a mistake” does not show recovery ownership. The interviewer needs to see a new boundary and a testable next step.

Preserve the Failure Signal Before You Move

Capture a small recovery receipt.

Record the exact failing command and its first relevant error.
Inspect the working-tree status and touched files.
Save the focused diff or commit reference that introduced the failure.
State the last known-good behavior and how it was established.
Separate useful diagnosis from generated noise.

Do not collect everything. The goal is enough evidence to explain why the path failed and confirm that recovery returned you to the intended boundary.

If the error could involve environment state, note dependencies, ports, fixtures, generated files, and pre-existing failures. If the action involved network access or an external service, local repository evidence may be incomplete.

The missed-question recovery loop is useful for the communication side: acknowledging the miss, rebuilding the frame, and moving forward without spiraling.

Choose the Recovery Boundary Deliberately

Start by naming the state.

Uncommitted local edits: determine which changes belong to this attempt and which were present before it. Restore only explicit targets after inspecting them. Never assume the whole worktree is disposable.

A committed bad change: a recorded reversal may preserve history and make the recovery reviewable. Whether that is appropriate depends on the interview workflow and repository policy.

A polluted experiment: create or return to a clean branch or known checkpoint, then reapply only the evidence-backed part. Branch isolation can be safer than trying to untangle many speculative edits in place.

An external side effect: a local file recovery does not undo a deployment, message, database write, or leaked secret. Pause and describe the compensating action or escalation that real operations would require.

The correct choice is not the fastest command. It is the smallest recovery that returns the relevant system to a known state without destroying unrelated evidence.

Re-plan as a Smaller Falsifiable Experiment

After recovery, reduce both the hypothesis and the write scope.

Instead of “fix submission,” say: “I believe the duplicate event enters through this pending-state branch. I will add one reproduction around that transition and change only the guard if the reproduction confirms it.”

Before asking the agent to edit again, confirm the entry point from call sites or tests. Limit expected files. Name the first command that should fail before the fix and pass after it. Add a stop condition if the hypothesis is not confirmed.

This makes the second attempt meaningfully different from the first. You are not asking the model to try harder. You are changing the experiment so that the result can disprove your assumption.

Interview AiBox can support preparation by helping you replay where an agentic mock went off course and turn the first missed stop signal into a future checklist. The real recovery still depends on the actual repository state and permitted commands.

What the Interviewer Is Observing

The interviewer watches whether you protect evidence before restoring appearance. A candidate who keeps the exact failure, explains the changed files, and returns to a known boundary is easier to trust than one who produces a clean screen with no causal story.

They watch whether you protect other people's work. In a shared or dirty repository, broad destructive commands are a serious judgment failure even if they remove the agent's patch.

They watch whether the second plan is smaller. Repeating the same broad request with stronger wording is not recovery. A new, falsifiable hypothesis is.

They also watch whether you distinguish repository recovery from incident recovery. A reverted commit cannot retract data that left the machine or undo a remote mutation.

A Concise Spoken Recovery Answer

At the stop point, say:

“The latest patch expanded beyond the behavior I understand and introduced a second failure, so I am stopping before compounding it. I will preserve the failing command and diff, confirm which changes belong to this attempt, and return only those files to the last known-good state. Then I will reproduce the original failure with one focused test and re-plan around the confirmed branch.”

After recovery, say:

“The unrelated changes are removed, the baseline test is back to its prior result, and I preserved the failing output for review. The next experiment touches one guard and one test. If that test does not confirm the hypothesis, I will stop rather than widen the patch.”

The post-interview retrospective guide can help turn this kind of failure into a reusable preparation lesson after the round.

Residual Risk After a Successful Rollback

Returning the repository to green does not prove that every side effect is reversed. Generated files may remain untracked. A process may still be running. A cache, database, or remote service may have changed. A credential exposed in output remains exposed even if the log is deleted.

Inspect status, running effects, external actions, and the exact tests that establish the known-good state. Report any boundary you cannot verify.

There is also a product risk: the original bug remains unresolved. A good rollback prioritizes stability, then creates a safer path to continue. Do not present “we reverted it” as the final solution when the requested behavior still needs work.