Stop asking whether they can build it.

AGENT ALLOWED
  everybody produces working code
  → measures: prompting speed, and only at the low end
  → discriminates: barely, and mostly on typing

AGENT BANNED
  some produce working code from memory
  → measures: unassisted recall under observation
  → a condition that will never recur in the job you are hiring for

The banned branch feels rigorous, which is why it won. Look at what it selects for: candidates who best simulate a working environment that no longer exists. Because of that, it also selects against people who have already adapted to the one that does. If your team writes code with an agent every day, an interview that forbids one is not a higher bar. It is a different bar, pointed somewhere else.

The fix is not a cleverer puzzle. It is noticing what you wanted all along: whether this person can tell right from plausible. That skill is testable in forty-five minutes, and always was. Nobody bothered because the proxy used to be cheaper.

A take-home now returns a well-structured, tested, documented submission from almost everyone, and the artifact cannot say who understood it. Asking candidates not to use an agent penalises the honest ones. That is bad design in any process, and worse in a process about integrity.

There is a partial rescue that some teams use: let them use anything, then spend thirty minutes interrogating the submission. That works, and is strictly worse than skipping the take-home and spending the same thirty minutes on material you prepared. You lose nothing and you stop asking for six hours of unpaid work whose output you have decided to ignore.

That last row is the honest summary of the whole page. You are hiring a junior for their trajectory, and trajectory is a derivative that no single point can show you. Everything below extracts the best available point estimate. Section 9 covers why the point estimate was never going to be enough.

1. Sent ahead Tell them the format in advance, in writing. Surprise measures composure, not judgment, and you are not hiring for composure under surprise.
2. 0:00 → 0:05 Context: what the program is for, what the ticket asked for, what the business rule is. State the business rule up front. Withholding it tests telepathy.
3. 0:05 → 0:25 They read. Anything goes: run it, test it, ask the agent, ask you. Say out loud that you expect them to use the agent, because half will assume it is a trap.
4. 0:25 → 0:40 The verdict, and the defense. Merge or not, and why. Then you push, once, on whatever they were most confident about.
5. 0:40 → 0:45 Tell them the answer, and what you were watching for. Every candidate leaves knowing something. This costs five minutes and is the reason people speak well of your process.

Choosing the material

• Self-contained, ~60 lines, common language. Offer a choice of two languages. A defect in your stack tests familiarity with your stack, which is not what you are hiring a junior for.
• One defect, from the taxonomy. A policy inversion or a test that cannot fail are the two best for this purpose. Both are invisible to the suite, and neither requires local knowledge once you have stated the business rule.
• About one candidate in four gets a clean diff. And you say nothing about it. Correctly approving a clean change, with reasons, is a full pass and the most informative outcome you can get.

Weight proved above found for a junior. Finding the defect is partly luck at this level. Going and checking before committing to an answer is a disposition, and disposition is what survives training. Take the candidate who misses the defect and says "I am not sure about this line, here is how I would find out". If the method they name is the right one, that beats spotting the defect and not saying why.

1. 25 min · one thing One thing they built or worked on. Not "tell me about it": what would you do differently, and what did you not understand at the time? The second half of that question separates people, and someone whose project was mostly agent-written can answer it without lying.
2. 20 min · ambiguity Hand over a two-sentence spec with a hole in it. Not a puzzle, a genuine omission: what happens to a refund on a cancelled order. Watch for whether they ask or assume. Assuming is not disqualifying; assuming silently is the signal.

That plus the exercise is the loop. Everything else people put in a junior process is measuring something you cannot act on or something you already know. That covers the system design round, the second technical screen, and the culture panel. Cutting them costs you nothing and buys you a candidate pool that has not been ground down before day one.

1. Syntax recall Whiteboard-from-memory API questions. Weak in 2015, worthless now, and negatively correlated with people who have spent their time on harder things.
2. Algorithm puzzles This measures preparation, and preparation is now nearly free and wholly automated. You end up ranking candidates on how recently they ground through a practice set.
3. Build a small app This measures prompting. It works as a warm-up if you enjoy it, but it is not evidence.
4. Side-project portfolio This once proxied for curiosity. Now it proxies for having had unstructured time, since the artifact costs a weekend to produce regardless of understanding. Ask about one project in depth instead of counting them.
5. "Explain this code" as a quiz Asking someone to narrate what a function does tests what the agent does best. Ask what would make it wrong, which is the question the model cannot answer for you.

1. Calibrated doubt "I don't know" followed immediately by how they would find out. The pair is the signal; either half alone is not.
2. Observed vs inferred Do they distinguish "I ran it and saw" from "I think it does"? People who keep that boundary clean under mild pressure are rare and trainable into everything else.
3. Asks about the rule Reaching for the business rule rather than the algorithm: the single most transferable instinct on this list, and the one the agent structurally lacks.
4. Holds, or folds well Under one round of pushback: do they hold with a reason or concede with a reason? Both are fine. Silent capitulation is the thing to note.
5. Notices the hole Spots the missing case in the spec without anyone pointing at it. Cheap to test, hard to fake, and it is most of what a first year of usefulness consists of.

• Familiarity with your stack. Offer two languages, keep the program self-contained, and state the business rule out loud. Anything the candidate has to already know about your domain is measuring prior access, not aptitude.
• Thinking aloud. Fluent narration is a separate skill from close reading, and it is unevenly distributed for reasons unrelated to engineering. Let people work in silence and ask at the end. Read the written verdict, not the monologue.
• Surprise. Send the format in advance. A candidate told what to expect shows you their judgment; one who was not shows you their startle response.
• Your own defect. If you wrote the planted defect and find it obvious, you have lost the ability to judge its difficulty. Have someone else on the team attempt it cold first, and time them.

Every organisation unhappy with its junior hiring lengthens the interview. That does not work, because the variable that decides the outcome is not in the room. How fast does this person improve when told something? No format resolves that from a single sitting, and a sixth round does not get you closer.

What does resolve it is a first month with a gate in it. If a new engineer is doing spoken claims from day one and a weekly rep from week three, day thirty tells you whether feedback lands. And it tells you from evidence rather than impression. That is a far better instrument than any interview, and it is available to anyone willing to run the first month on purpose.

flowchart LR
%% declared bottom-up: the layout engine stacks the later subgraph first,
%% so BETTER is written first and renders under TYPICAL
  subgraph better["BETTER"]
    direction LR
    b1["2-stage loop, 90 minutes · low cost, honest resolution"] -- hire --> b2["a first month with a gate"]
    b2 ~~~ bwhen["problems surface at day 30, cheaply"]
  end
  subgraph typical["TYPICAL"]
    direction LR
    t1["6-stage loop, 6 hours · high cost, low resolution"] -- hire --> t2["unstructured first 90 days"]
    t2 ~~~ twhen["problems surface at month 7"]
  end
  class t2 warn
  class twhen block
  class b2,bwhen pass

None of this argues for a careless interview. It argues that the marginal hour is worth far more after the offer than before it. A team with a real first ninety days can afford a shorter loop. It is no longer asking the interview to do something interviews cannot do.