I have been involved in the hiring process pretty consistently over the past years, across data, engineering and consulting roles. The interview process for all of them has stayed close to the same, and I think the reason why matter more than ever.

For as long as I've been interviewing for these roles, I've cared less about whether a candidate can write clean code or knows the "best" library for the job. I've cared about how they think. Can they approach an ambiguous problem in a structured way? Do they reach for a framework, or do they just start typing and hope something works?

Instead, I give candidates a real problem from our world, something like: "We need to predict when cashflows actually happen. Here's some sample data. How would you approach this?" Then we talk it through.

That single exercise tells me almost everything. It shows whether they're diligent and structured, or whether they jump straight to the first idea that comes to mind. It shows whether they understand the technical side, what transformations the data needs, which models might fit, what to watch out for, and whether they can reason about the business side too: which variables might be correlated, which might actually be causal. Especially the ability to reason from a technical and business perspective, even if not always right, is one of the best indicators of future success for me.

I ran live-coding and algorithm tests once or twice, early on, and dropped them fast. They ate hours of everyone's time and told me almost nothing about how someone actually worked. I landed on the case-conversation approach a long time ago, well before agentic tools existed, because it was simply better at predicting who'd be good on the job. The fact that Claude Code can now do most of what those tests were checking for is a coincidence that happens to prove the point twice over.

Take-home exercises fared no better. Mostly they told me how much free time a candidate had that week, or whether a friend helped. This approach takes more effort than either. A proper conversation about a real problem takes longer to run than a scored online test. But it tells you far more than a pass or fail, and that trade-off has never felt like a bad one.

What it never told me much about is syntax/ language-specific knowledge, and that is because I do not really care about that. The "right" way to do something is almost always situational, and it usually only comes with years of experience, not something I'd expect from a grad anyway. Teaching someone a library or a best practice is easy. It happens on the job, fast. Teaching someone how to think is hard, and it's usually already baked in by the time they walk into an interview.

The syntax gap was already narrowing before Claude Code arrived. Tools like ruff and ty, in the Python ecosystem, have been quietly nudging people toward the "right" way of writing something for a while now. Claude Code just finished the job. The gap between a strong grad and a weak one has basically disappeared. What's left exposed is the thing I was always actually testing for: judgment, structure, and the ability to reason through a messy problem before touching a keyboard.

I didn't change my hiring approach because of AI. AI just made it obvious that I'd been optimising for the right thing all along.

🤖 Blog post was co-edited with the help of AI 🤖