For about eight years I ran the same interview. The candidate brought code they’d written, my team read it, and we talked about it. No live coding. No puzzles. If they understood their own code, it came out in the conversation. If they didn’t, that came out too.
It worked. People I hired told me afterward it was the least stressful interview they’d been through, and I was proud of that.
Then it stopped working.
I’ve been on both sides of the table for a long time. Twenty years as an engineer, the last eight leading teams. I’ve coded live on problems that look nothing like the actual job. I’ve been asked how I’d escape a blender after a wizard shrank me to three inches. Really?
So when I became a manager and hiring became part of the job, I decided I wasn’t going to do any of that. No one on the spot, no riddles. I wanted a conversation about real code, because that’s what the job is. Someone shares a repo, we read it, we ask why they made the choices they made, and we get a pretty clear picture of whether they can handle the role.
Looking back, I’d say we thought we got a clear picture. Most of the time we did. But I never stopped to ask what the interview was actually measuring.
Fast-forward to 2026.
I’m at a startup now, and this year the hiring plan landed on my desk. The difference this time was AI. A candidate can spin up a repository of good-looking code, or at least passable code, in an afternoon. Then they can hand the same assistant the job description and get coached on how to talk about it.
That’s what broke. My interview was never really about the code. The code was a proxy for understanding, and the conversation was how I checked the proxy. Now both halves can be manufactured, and the check reads the same for a strong candidate and a weak one.
We spent a few weeks scrambling over this. How do you gauge someone’s skills when the thing you used to look at can be generated?
The answer we landed on was to stop fighting it. The language matters less than it did. The framework matters less. Whether their hand-written code is pretty matters a lot less. What I need to know is whether they understand the fundamentals of building software, because that’s the part the assistant can’t supply on their behalf.
So the questions changed. What does a clean API endpoint look like, and why? How should errors propagate through a service? What’s a consistent response envelope and what goes wrong when you don’t have one? What do you do when one endpoint suddenly gets ten times the traffic? Walk me through a query that started timing out last week.
These are the problems they’ll hit on a Tuesday. They don’t have a single right answer, and that’s the point. You can ask an assistant any of them before the interview. You can’t ask it in the middle of a conversation where I’m pushing on your last answer and changing the constraints. Watching someone reason through the second and third question is where the signal is now.
The other thing we ask about is whether they’re comfortable working with AI, because the job now includes directing it. The way I think about it, an assistant is a junior engineer that never sleeps. Everything it produces needs review, and you can’t review what you don’t understand. An engineer who doesn’t know what good error handling looks like can’t tell when the assistant got it wrong. That’s the whole case for fundamentals in one sentence.
I don’t share the fear I see in a lot of posts and videos, the ones saying AI took the art out of coding or cost someone their job. My read, and it’s only a read, is that the people hit hardest built their value on a specific thing. A language, a framework, a niche. That’s a real loss and I don’t want to be glib about it. But it’s also why I hire the way I do now. An engineer with strong fundamentals can pick up a language with some guidance and ship faster than anyone I’ve worked with in twenty years. The fundamentals transfer. The niche doesn’t.
We used to look at the code to judge the engineer. That was always indirect. Now it’s just wrong. The code is cheap. Knowing how it works, why it’s built that way, and what happens when it breaks is what I’m hiring for.