Your interview loop is testing a skill that no longer exists

I was the Bar Raiser at Marshmallow — the person the founders made responsible for the hiring standard — while engineering went from under ten people to over sixty. I ran more than fifty interviews in six months at the peak of that, and then rebuilt a hiring process from scratch again at Vita Mojo. I mention it only so you know this is not a think-piece. It is what I would do on Monday.

Almost every interview loop I see was designed to answer the question “can this person produce working code?” That question has become close to worthless, because the answer for nearly every candidate is now yes.

Every signal you had has been degraded

• —The take-home is dead. It measures whether someone can prompt an assistant and tidy the output. You are not learning nothing, but you are not learning what you think.
• —Live coding with AI banned tests a skill the person will never use again, and tells the candidate you have not thought about the job you are hiring for. Good engineers notice.
• —Live coding with AI allowed is better — but if you have not decided what you are watching for, you will sit there for an hour and come away with an impression rather than evidence.
• —Algorithm puzzles were always a weak proxy. They are now a proxy for nothing at all.

Most teams know this. What they have done about it, in my experience, is nothing — they have kept the loop and quietly stopped believing its output, which is the worst of both worlds. You still spend the hours; you just discount the result and hire on gut feel afterwards.

Stop testing production. Test judgement.

The reframe is straightforward. You are no longer hiring someone to type the code. You are hiring someone to decide whether code is right, and to be accountable for it when it is not. So the loop should put candidates in the position of deciding, and make them defend it.

The question is no longer “can you write this?” It is “here is something that was written. Would you merge it, and what happens if you are wrong?”

The loop I would build

Four stages. The second one is the change that matters, and if you only adopt one thing from this piece, adopt that.

1. Screen, largely unchanged. Thirty minutes on what they have built and what they own. The only addition worth making is a direct question about how AI has changed their working week — the answers separate people who have thought about it from people who are performing enthusiasm, and the split is stark.

2. A code review exercise, and this is now the highest-signal hour in the loop. Hand them a substantial diff — genuinely AI-generated, in your stack, solving a plausible ticket — with three or four planted problems of deliberately different classes: one subtle correctness bug, one security issue, one over-engineered abstraction that will cost you in a year, and one thing that is simply wrong for your context in a way only a careful reader would catch. Ask what they would merge, what they would change, what they would reject outright, and why.

It is astonishingly discriminating. Weak candidates comment on formatting and variable names. Strong ones find the correctness bug, and the very strong ones tell you what they would need to know about the system before they would be willing to approve it at all. You can run it in an hour, it is fair to prepare for, and it maps exactly onto what the job now is.

3. Bring-your-own-tools pairing. A real ticket, in something close to a real codebase, with whatever assistant they normally use. You are not watching them produce a solution — you are watching how they direct the tool, whether they verify what comes back, whether they notice the moment it is confidently wrong, and whether they can explain code they accepted ninety seconds ago. Provide the tooling and a licence, incidentally; making candidates use their own paid subscriptions quietly selects for people who can afford them.

4. Debugging, not greenfield. Give them something broken in a system they did not write. Greenfield problems flatter the tools; debugging exposes whether someone can build a mental model of code they are meeting for the first time, which is now most of what senior engineering consists of.

You need someone who owns the bar

None of the above survives contact with a hiring push unless a specific person owns the standard, and it cannot be the hiring manager. A manager who is three months behind on headcount is not a neutral judge of whether a candidate clears the bar; that is not a character flaw, it is the incentive.

The Amazon Bar Raiser model solves this cheaply: someone from outside the hiring team, trained, with a veto, whose only job in the loop is to protect the standard. At Marshmallow this was the difference between scaling fast and scaling badly — engineering grew sixfold in under two years and the bar held, because someone was accountable for it holding.

It works at ten people too. It does not require a programme. It requires one person with a veto and the standing to use it.

Write the bar down

The reason most teams cannot tell you whether a candidate met their bar is that nobody has written it down. What does a mid-level engineer do that a junior does not? What must someone demonstrate to be hired as senior here — not at Google, here, in this codebase, with this team?

Until that exists on a page, every offer is a judgement call made under time pressure by people who are tired, and your bar is exactly as high as the last person you were desperate to hire. Scorecards, a written levelling framework, and debriefs where evidence beats impressions. It is unglamorous and it is most of the work.

What to stop doing on Monday

• —Take-homes used as a filter. Either drop them or make them AI-allowed and interrogate the result in person.
• —“No AI” rules. Unenforceable, and they tell your best candidates you have not understood the job.
• —Algorithm puzzles.
• —Any stage where nobody can articulate, in advance, what a pass looks like.

The teams that get this right over the next two years will not be the ones paying the most. They will be the ones who worked out what they are actually assessing while everyone else was still arguing about whether candidates should be allowed to use the tools they will use every day of the job.