There is an interview format going around that asks a candidate to sit down with an agent and produce something. Not to write code by hand — that argument was settled — but to prompt, to steer, to show that they can get a result out of a model. It is presented as the modern version of the coding test. It is closer to the old one than anyone wants to admit.
The old test asked you to write a program on a sheet of paper. No editor, no linter, no autocomplete, no documentation, no compiler telling you the obvious. People defended it for years: it shows how you think. What it actually showed was how you perform a task you will never perform again, under conditions that exist nowhere except that room.
The new test does the same thing one level up. On the job there will be a ticket with acceptance criteria. There will be a described system, a branching policy, a review pipeline, a deployment procedure someone wrote down. There will be a corridor. The test removes the corridor and asks you to improvise one from nothing in forty minutes, then grades you on the improvisation.
What the corridor is for
I watched two people this year who are, by temperament, identical. Both young in the role in the sense that matters. Both eager, both full of initiative, both convinced they could make things better and both willing to do the work.
The first one was given a task with a hint of study in it: here are the requirements, here is the documentation, go and learn this. He went away, read, came back, agreed the shape of the task, and only then started generating. He arrived with a diagram and a set of services and an explanation of why the pieces sat where they sat. Nothing about his tooling was remarkable. The sequence was: read, agree, then build.
The second one joined a codebase and, in one evening, reformatted the repository, upgraded a batch of packages, and changed how the thing starts. All of it together, all of it at once, delivered with a flourish: it is done, no need to thank me. Then he looked at the deployment flow — features cherry-picked from the QA branch into production, one branch per environment — and asked why it worked that way, in the tone of someone who has already decided it shouldn’t. He was told there was a feature on QA that was not ready for production yet. He pressed anyway.
The difference between these two is not initiative against passivity. Both have initiative in excess. The difference is one word: proposed against done. A proposal is a contribution even when it is wrong. A fait accompli is a seizure even when it is correct.
And the second man is the interesting case, because he was not only breaking things. In the same stretch he turned on branch protection and made approvals mandatory before a merge. He was building the corridor. He was building exactly the thing this essay is arguing for.
He built it the way he does everything: by reaching for admin rights nobody quite remembers granting him, and installing the rules overnight, and letting everyone find out afterwards. Which means the corridor arrived as another fait accompli, from a man who had appointed himself the person in the room whose judgement decides. The rules he installed may well be the right rules. It no longer matters much. A constraint that appears without agreement is read as an assertion of rank, and it gets fought on those terms, whatever its merits.
That is the trap in the argument, and it is worth naming before anyone rushes off to install gates. The corridor cannot be imposed the way a refactor is imposed. It is a statement about how a group will work, and a statement like that is either agreed or it is resented into the ground.
And here is the part that matters for hiring. Everything the second one did is catchable by a machine. One delta, one branch: that is a rule, and rules can be enforced at the point of merge. A feature that is not ready does not go to production: that is a gate, and gates do not get tired of arguing. None of this requires a senior engineer to notice, feel annoyed, and decide whether today is the day to have the conversation.
Which is exactly what happens when the corridor is missing. The tech lead tolerates it, because from above a big cleanup looks like productivity, and because arguing costs forty minutes and merging costs nothing. Tolerance accumulates. Then one day it runs out, and a person is let go for their character, when the actual defect was architectural: there was nothing in the system that made the behaviour impossible, so it fell to a human being to prevent it by force of personality, and eventually he didn’t.
A rule that lives in someone’s head is a bug with a delay
That is the third reason the tech lead says nothing, and the only one that can be fixed. The rules are probably not written down. The cherry-pick, the ripening of a feature, the size of an acceptable change — folklore, all of it. So in the argument he has nothing to point at except this is how we do it, which loses to a confident newcomer every time. It is a habit wearing the costume of an argument.
I have been applying the inverse of this all week in my own work, and the lesson keeps arriving from directions I did not expect. A default that must be unique gets a partial unique index in the database, not a note asking everyone to be careful. A measurement with no calibrated thresholds classifies nothing at all, and says so, rather than guessing on an unfamiliar scale.
That last gate was built to catch a unit mismatch. What it actually caught was a broken measurement I had written myself and not noticed — a metric whose numbers looked entirely plausible and were noise. The gate did not fire for the reason it was installed. It fired for a reason nobody had anticipated, which is the whole argument for gates in one sentence. You keep the one that stops a failure you did not predict, not the one that stops the failure you designed it around.
What is left to interview for
Follow this through and the hiring question inverts.
Where the corridor exists, the system supplies the discipline. Small changes, ordered deployments, reviewed merges, nothing reaching production before it is ready — none of that needs to be a property of the person any more. It is a property of the pipeline. So do not screen for it. You will get it regardless, from people who have it and people who don’t.
Screen for what the pipeline cannot supply.
Going to read the thing before changing it. Asking why a process is shaped the way it is before announcing it is wrong. Recognising that a confident answer is incorrect — which, now that the confident answers arrive by the dozen and arrive well written, is the rarest of the three, and it gets more valuable every month.
Two shapes of evidence show this, and an interviewer can spot either. One is experience told well: I have done this, and here is the detail we had to account for, and here is what it cost us when we didn’t. The other is appetite, in someone with a year or two behind them: I built this, I turned that over, I configured this thing here to see what would happen. Both are the same signal underneath.
There is a way to test the last one that takes fifteen minutes and needs nothing but a laptop. Have the agent do the task. Then ask the candidate to find what it got wrong and explain why that particular mistake was predictable. A person who can do that has the only skill that does not depreciate, and you will know within two answers whether they have it.
The part nobody says out loud
The shift has a specific cause, not a general one about tools improving. When producing the work was the bottleneck, the scarce thing was people who could produce. Now producing is cheap, and abundant, and available at three in the morning. The bottleneck moved.
What is scarce now is the process. Not restriction for its own sake, but the written sequence: these steps, in this order, with this criterion for the decision at each one, and the reason recorded next to it. Knowing what not to build. Knowing where the machine must stop and a person must look. Knowing which of the forty changes it offered are the three you actually want, and being willing to throw away the other thirty-seven after the work is already done and looks fine.
Junior and senior do not describe it. It is a different axis entirely, and almost nobody is hiring along that axis, because the interview formats were built when the other axis was the one that mattered.
Which points at something uncomfortable about the trade. This work is drifting away from cleverness. The useful faculties now are curiosity, and intuition about where a thing will break, and a kind of caution: running the change forward in your head and asking what could go wrong before touching anything. Judgement rather than intellect, if the two can be separated at all.
So: fewer questions about how someone would build the thing. Fewer live demonstrations of prompting, which will be uniform across every candidate within a year anyway. Build the corridor, make the walls real, put the gates where the expensive mistakes happen, and then hire for curiosity and for the instinct to ask why, because those are the only two things you cannot install.