Multi-File Agent Tasks in Coding Interviews: How to...

The request sounds small: add one validation rule. The agent returns changes across a handler, service, shared utility, configuration file, test fixture, generated file, and several neighboring tests. A large patch is not automatically wrong, but accepting it before you can explain the blast radius is a visible loss of control.

Multi-file coding-agent interviews reward a candidate who can turn a broad request into a bounded change. GitHub documents coding agents that work in repository context and produce pull requests for human review. That workflow makes a durable principle visible: the agent may explore widely, but the accepted patch should remain tied to the requested behavior and reviewable evidence.

Start with a Behavior Map, Not a File Count

Do not begin by declaring that the task may touch exactly three files. You may not know enough yet. Begin with the behavior path.

For a request such as “reject expired invitations,” trace the likely flow from input to output:

the request enters through a handler or command boundary;
existing validation or domain policy decides whether the invitation is valid;
the caller receives the repository's established error shape;
tests protect the expired and still-valid cases.

Now ask which files own those steps. The initial map may name one handler, one domain module, and one test file. It should also name uncertainty: perhaps expiration is already centralized elsewhere. This map is a hypothesis, not a promise.

The value is that every later file change must answer a concrete question. If the agent wants to modify a global date helper, you can ask whether the helper actually owns invitation expiration or whether the change is only convenient. The technical decision-making interview guide offers a useful way to explain that ownership trade-off without turning the answer into framework trivia.

Set Four Boundaries Before Delegating

A strong instruction gives the agent room to investigate while preventing silent expansion.

Expected files. Name the modules most likely to contain the behavior and the tests that should demonstrate it.

Protected areas. Identify directories or concerns that should not change, such as authentication, billing, generated artifacts, shared configuration, or public API shapes.

Conditional supporting edits. Allow a neighboring helper or fixture only if the agent first explains why the current owner cannot support the behavior cleanly.

Stop condition. Require a pause before changing a public interface, dependency, schema, shared abstraction, or more files than you can review within the remaining time.

This is more useful than “make minimal changes.” Minimal can mean few lines, few files, few concepts, or low operational risk. State which dimension matters here.

For example: “Inspect the invitation handler, domain validation, and existing tests. Propose the smallest behavior change. Do not change shared time utilities, API response shapes, or generated files. Pause if the fix requires a public interface change or a fourth production module.”

Build Through Dependency Checkpoints

The main danger of a multi-file task is not the final number. It is losing the ability to connect each step to the previous one.

Use checkpoints based on dependencies:

Discovery checkpoint: confirm the current call path and three similar implementations.
Behavior checkpoint: change the narrowest owner and inspect that diff before editing callers.
Support checkpoint: update only the directly affected call site, fixture, or type.
Evidence checkpoint: add or update tests that prove the requested behavior and protect one adjacent path.
Final scope checkpoint: review the complete diff by file and remove anything that cannot be defended.

At each checkpoint, ask two questions: what new fact justified this file, and what would break if this edit were removed? If the answer is “the agent preferred it,” the evidence is weak.

GitHub's pull-request review model is useful because it presents the change as a bounded diff rather than a stream of generated activity. The AI coding agent code review guide goes deeper on line-level review. Here, the priority is deciding whether a file belongs in the patch at all.

Detect Scope Drift Before the Patch Becomes Unreviewable

Scope drift usually announces itself through patterns rather than raw size.

One signal is abstraction spread: a local rule suddenly introduces a generic helper used nowhere else. Another is cleanup hitchhiking: renames, formatting, dependency updates, or test reorganization appear beside the requested behavior. A third is ownership migration: logic moves to a shared layer without evidence that other consumers need it. A fourth is test expansion without risk logic: many snapshots change, but no focused case proves the request.

When one signal appears, pause before issuing another broad prompt. Inspect the working tree by file and group changes into necessary behavior, necessary support, useful but optional, and unrelated. Keep the first two groups. Remove or defer the others.

Do not reward the agent for making the diff internally consistent if it solved a larger problem than the interview asked. A coherent overreach is still overreach.

Use a File-by-File Acceptance Pass

Before accepting the patch, review every file with a short test.

Purpose: Can you state in one sentence why this file changed?

Connection: Which requirement or verified dependency requires it?

Risk: What adjacent behavior could this edit affect?

Evidence: Which test, inspection, or build result addresses that risk?

Removal: If the file were restored, would the requested behavior still work?

This pass can reveal that a helper change is unnecessary even when all tests pass. Tests show exercised behavior; they do not prove that every edit was required. Conversely, a six-file patch can be justified when the repository has explicit layer boundaries and each layer needs a narrow, conventional update.

The distributed systems interview mistakes guide is a helpful companion for learning to describe downstream effects instead of treating a local edit as isolated.

Recover from a Twelve-File Surprise

Imagine the agent was asked to add a retry limit to one client. The returned patch changes twelve files: the client, a shared retry utility, two unrelated callers, configuration defaults, documentation strings, and several snapshots.

Do not start reviewing line by line. First classify the file list.

You discover the client already has a local retry policy and only needs a new boundary check plus two tests. The shared utility change was a refactor preference. The other caller changes followed from that unnecessary abstraction. The snapshots changed because error text was rewritten without a requirement.

A disciplined recovery is:

preserve the current diff long enough to understand the agent's reasoning;
restore the unrelated callers, shared utility, configuration, and snapshots;
keep the local client change only if it matches existing patterns;
add the focused retry-limit and normal-path tests;
run the relevant suite and inspect the final two-file or three-file diff.

The lesson is not that twelve files are forbidden. It is that eleven files lacked a necessary connection to the requested behavior.

Explain Scope Control Without Sounding Defensive

Use concise updates at the moments when the boundary changes.

Before delegation:

“The likely path is the handler, domain validation, and focused tests. I will let the agent inspect those areas, but I am protecting shared utilities and public response shapes. If it finds a dependency outside that map, I want the reason before it edits.”

When drift appears:

“The diff expanded through a new shared helper. I do not yet have evidence that other consumers need this abstraction, so I am pausing, restoring the unrelated callers, and keeping the behavior local. Then I will verify the expired and valid invitation paths.”

At completion:

“Three files remain. Each maps to the requested behavior: the policy owner, its caller, and focused tests. The relevant suite is green, and I inspected the diff for public-interface and configuration changes. I did not run the full deployment path, so environment-specific time behavior remains outside my evidence.”

That explanation shows control without pretending that file count alone proves quality.