Yesterday I interviewed ten developers. Didn't hire any of them
Six solved the live-coding task perfectly. Four of those six couldn't explain their own code ten minutes later. How I run interviews now — and why the old filter doesn't filter anymore.
Yesterday I interviewed ten developers. Didn't hire any of them.
This was one of those projects where the client asks me to "help with hiring" and I end up sitting six hours in Zoom watching senior backends go by, one more ideal than the next. To keep things from grinding to a halt, I ran a format of "three meetings in the morning with a coffee break, three more for lunch." By Thursday evening I had ten meetings, ten filled-in Airtable forms, and a stubborn sense that I was doing something wrong.
Six out of ten solved the live-coding perfectly. Four of those six, ten minutes later, couldn't explain their own code. "Well… because that's how it's done" — direct quote. As a justification for why he'd picked that particular data structure.
I closed the last call. Logged "no" in the tracker. Wrote HR that we were continuing the search. And then stared at my coffee, which, I noticed only then, had been cold for about two hours.
(A separate thought — why in 2026, when AI handles my email, my calendar, and occasionally replies to sales on my behalf, I still don't have a solution for "coffee must stay hot for four hours of interviews." Apparently one of those problems that look silly at first glance and get much sillier when you try to think through them properly.)
Five years ago an interview for a developer was simple. A mid-difficulty algorithm (something with graphs, say — everyone always loved graph algorithms). An architecture case. Questions on SQL, caching, the difference between a CTE and a subquery (which, honestly, I google every time). Forty minutes in, you had an approximate picture.
The filter worked on mechanical knowledge. Does the person remember how a B-tree is laid out. Can they build a priority queue in ten minutes. Can they explain two-phase commit without saying, in a wounded voice, "well that's a very deep question."
In 2026 that filter is broken. Not because developers got worse. Because everyone has claude.ai open in the next tab. Any second-year student, with two clicks, solves a mid-difficulty algorithm in eight minutes. Not because they know — because they know how to ask. And the model gives them not only the code but ready-to-go commentary — as if those were their own thoughts.
This isn't fraud. At least not in the sense that a plagiarised diploma was fraud in 1998. The same person, very likely, will use the model at work too. That's fine — I work the same way.
The problem isn't that they use the tool. The problem is I'd been filtering for the wrong skill.
The second and third interviews that day ran for me in "I don't understand what's happening" mode. The candidate solved the task in twelve minutes, and the solution was… good. Honestly good. Right data structure, neat edge-case handling, readable variable names. I've written worse in my practice.
At the fourth I switched tactics. The candidate wrote a solution. I closed the IDE. We talked about something else for five minutes — I remember we discussed whether Lisbon was now cheaper than Barcelona (spoiler: not anymore). Came back to the code. Asked:
— Why did you pick this particular collection type?
— Um… because… that's standard.
— What if N were ten million?
— Well, works the same.
— What would change if you swapped this line for this one?
A pause. A long one.
That pause is now the most honest signal I can collect in forty minutes. Because explanation isn't recall. You can't google it in another tab while I'm talking. Either you see it or you don't.
A model can write code. It can't explain that code as your own if there's no "your own."
From that point I rebuilt the whole format. It looks roughly like this.
I still give a task. But not LeetCode. I now pick something from a real problem I was grinding on a month ago — with context, constraints, a hint of trade-off. Something like: "here are three architectural options, pick one and explain." Not "implement a priority queue." Because real work is trade-offs, not LeetCode.
Models can reason about trade-offs too. But they average. They pick "what the industry does," "best practice." A strong candidate picks differently, because they see the nuance. A weak candidate plus a model picks by the book. And when I toss a stone into the water mid-discussion — "what if we care less about write speed and more about read speed at hour X when everyone syncs?" — the weak one stalls, the strong one rebuilds.
Harder to fake through the side tab, because I break the rhythm. I add a constraint, clarify the context, change the question. Every clarification has to land in the answer. A candidate with a model in the second tab can't keep up.
I also added a question about mistakes. Not abstract "tell me about a weakness" — concrete. "Tell me about a technical decision you made and regretted. What did you take away?" A strong employee remembers specifics: that project, that database, that story about how they spent three days chasing a memory leak that turned out to be one unfortunate library nobody suspected. A weak one — answers in generalities. Or paraphrases a story from Medium I've already read.
Finally, I stopped doing pure live-coding. I almost never use "write from scratch" any more. Instead — "here's some existing code, let's improve it together." Much harder to fake through AI in the second tab, because I set the pace, I set the focus, and clarifications arrive in real time. The candidate has to think, not generate.
What's stopped being important — I'll say it plainly.
Code-writing speed doesn't filter. It's now level for everyone, because speed is a property of the model. Certificates — "I watched 20 minutes of video and pressed a button," it's 2026 already. GitHub portfolios — not a guarantee either, because half the commits are generated, and the rest, honestly, too.
What became more expensive:
Problem framing. Half the work is translating "I want it to work" into a spec. In the AI era that skill matters more than code. Without it, a person with a model produces a pile of pretty non-working.
Architectural taste. The model offers three options. A strong person knows which one fits here, and why. That doesn't fit in a prompt, because it's built from years of "we tried it that way and this is what went wrong in month three."
Business context. "Why we do X and not Y." The part the model won't pick up even with RAG, because it's not in any public source. It's in the heads of people who've watched the same deal fall over at the same point six times personally.
On Friday I delivered the report to the client. Hired nobody. Recommended reshaping the format — not looking for a senior who solves the algorithm perfectly, but for someone who can walk through someone else's code step by step. That, strangely, is a rare and noticeably more expensive skill in 2026.
The client agreed. We rewrote the job description. The very first interview after the reshape — a woman who didn't rush, asked back, once openly said "I don't know," then went and figured it out on Google in "show me your mess and I'll untangle it" mode. We hired her. She's been there three months, and the project is diagnostically, measurably better for it.
Good 2026 candidates aren't the ones who remember APIs by heart — they're the ones who think systemically and work the tool. Filtering by "can they write code" is now like interviewing a carpenter for whether they can pick up a hammer. Of course they can. Everyone can. Hammers are for sale in every supermarket.
Ask what they're going to build with it.