# Interview loop

An FDE must frame an unfamiliar business problem, build maintainable integrations, reason about data and permissions, evaluate system behaviour, and make progress with people who hold different authorities. AI-assisted coding changes the implementation part of that job, so the assessment changes with it: this loop makes the candidate's reasoning observable while they use approved coding agents.

Source: article two, "Hire for judgment, then change the assessment for AI-assisted coding".

## Who fills this in, and what it decides

The practice lead designs the loop and names an interviewer for each round. Each interviewer records the "Observed" column for their round during the interview, not afterwards. The loop feeds one hiring decision, recorded in section 5, and it tests one capability: the one the delivery diagnosis showed the enterprise repeatedly lacks. Platform, data, design, product, and control teams supply the rest, so the loop should not test for everything.

The strongest candidate is not the person who types fastest without assistance. It is the person who can decide what should be built, give an agent enough context, inspect the result, design tests that expose failure, and notice when the agent has misunderstood the business.

The exercises below use the article's transaction-screening example. It is hypothetical. Replace the workflow, the conflicting field, and the access restriction with ones from your own diagnosed problem, keeping the same structure: one ambiguity that code generation cannot resolve, and one restriction that must not be worked around.

## Before the loop

- Capability the diagnosed delivery problem repeatedly lacks (from the delivery diagnosis):
- Which existing teams supply the rest (platform, data, design, product, control):
- Approved AI coding tools in the interview environment:
- Repository prepared for the exercises, and who maintains it:
- Interviewer for each round:

## Round 1: agent-assisted build with an unresolvable ambiguity

Setup: a small repository, an incomplete screening workflow, conflicting requirements, and a data-access limitation. The candidate may use the approved tools. Somewhere in the repository, a field called "enterprise value" has different meanings in two source systems. Code generation cannot resolve this; only a question to the method owner can.

The interviewer records what they saw in the last column, in the candidate's own words or actions where possible.

| Observable behaviour | Strong | Weak | Observed |
| --- | --- | --- | --- |
| Inspects the repository before instructing the agent | Reads structure, tests, instructions; states what is unclear | Starts prompting immediately | |
| Clarifies the problem | Asks which source is authoritative; states assumptions in writing | Assumes | |
| Decomposes the work | Separates integration, business rule, and evaluation | One large prompt | |
| Instructs the agent | Supplies context, constraints, and the acceptance test | Vague instruction, accepts output | |
| Reviews generated changes | Reads the diff; finds the permission or entity assumption | Runs it and moves on | |
| Handles the enterprise value conflict | Pauses implementation, records the unresolved interpretation, routes it to the method owner | Normalises both fields into one schema and writes a test that checks only syntax | |
| Handles the access restriction | Proposes a narrower design; does not work around the control | Mocks the data and continues as if access existed | |
| Explains what remains uncertain | Names it without prompting | Declares it done | |

## Round 2: review an agent-generated pull request

Setup: a plausible integration, incomplete tests, and an unsafe permission assumption, all generated by an agent. The task is to review the change, identify the risk, ask the agent for a correction, and decide which checks must stay human-owned. This resembles the practice's real work more closely than a timed algorithm question.

| Observable behaviour | Strong | Weak | Observed |
| --- | --- | --- | --- |
| Identifies the permission risk | Finds it and explains the consequence for the affected team | Comments on style | |
| Identifies the test gap | Names the failure the tests cannot catch | Accepts green tests | |
| Asks the agent for a correction | Precise, with the acceptance condition | "Fix it" | |
| Decides which checks stay human-owned | Names them and why | Delegates everything | |
| Maintainability | Comments on what the next engineer would need | Silent | |

## Round 3: fundamentals without an agent

An architecture discussion with no tools: data models, APIs, identity, state transitions, testing, observability, and system failure. Compare the answers with the candidate's tool-assisted work in round 1. A large gap in either direction is the finding: strong assisted work with weak fundamentals means the candidate cannot check the agent; strong fundamentals with weak assisted work means they cannot yet use it.

- Topic set:
- Observed gap between assisted and unassisted reasoning:

## Round 4: explain it to the business owner

The candidate explains every important design choice from round 1 in plain language to someone playing the business workflow owner. FDE work fails when technical and business explanations cannot meet.

| Observable behaviour | Strong | Weak | Observed |
| --- | --- | --- | --- |
| States what the solution will and will not decide | Clear boundary | Technical detail only | |
| Explains the enterprise value problem to a non-engineer | The owner can restate it | The owner cannot | |
| Handles a pushback about scope | Holds the boundary and explains the cost of moving it | Agrees to everything | |

## 5. Decision

The practice lead records the decision after all four interviewers have reported. The last field matters most: an engagement's success is measured partly by whether the workflow ends up with an owner, so the loop should predict that.

- Recommendation: hire / no hire
- The single strongest signal:
- The single weakest signal:
- Would this person leave a workflow with an owner, on the evidence of rounds 1 and 4:
- Decided by, and date:

## 6. The environment the hire will need

These do not make generated code correct. They make errors easier to find and reduce the human attention spent on routine checks. The practice lead confirms each item exists before the hire's first engagement.

| Item | In place | Owner |
| --- | --- | --- |
| Repository instructions, architecture notes, test commands, data handling rules, and deployment constraints legible to both humans and agents | yes / partly / no | |
| CI, static checks, evaluation cases, and review workflows that produce feedback an agent can use | yes / partly / no | |
| An approved, isolated environment for agentic coding against restricted data | yes / partly / no | |

## 7. Career incentives that match the work

If advancement rewards only launches or lines of code, engineers have little reason to improve repository structure, evaluation, transfer, or the receiving team's capability. Record what the practice recognises, and confirm it with whoever owns the promotion criteria.

- Recognised: sound problem framing, reliable systems, useful shared primitives, clear negative findings, effective use of agents, and leaving a workflow with an owner
- Not recognised on its own: launches, lines of code, or dependence on one exceptional person
- Confirmed with the owner of the promotion criteria, and date: