The Code Was Never the Hard Part

I read a post last week that put words to something I've been circling for a year. Sabina Amaricai wrote: "AI didn't break the hiring process. It removed the last excuse for not fixing it." (Read her full piece here, it's worth your time.)

She's right, and I want to build on it with what we actually ask candidates at AssessDev.

The Interview We Kept Running Anyway

Most technical interviews still test the same three things: can you name this design pattern, can you reverse a linked list from memory, can you explain the difference between two classes. That's a closed-book exam, in a field where every book has always been open.

It worked by accident for years. Engineers who drilled syntax hard enough to pass that kind of interview also tended to know their way around a codebase. We weren't testing the right thing. We were getting lucky on the correlation.

AI Took the Overlap Away

AI writes working code now, faster than most engineers, with fewer typos. The thing our interviews were accidentally testing for, fluency in syntax, speed of recall under pressure, is a commodity. The lucky correlation is gone.

Even the biggest employers are rethinking this in public. Meta has started piloting interviews where candidates use an AI assistant on a real, multi-file codebase instead of a whiteboard algorithm problem. A Meta spokesperson told HR Grapevine: "We're obviously focused on using AI to help engineers with their day-to-day work, so it should be no surprise that we're testing how to provide these tools to applicants during interviews."

If Meta no longer trusts a whiteboard round to tell them anything useful, it's worth asking what your own interview is actually measuring.

What a Skilled Engineer Actually Does

Amaricai makes the point with a university exam. The open-book ones were always the hardest, because the professor wasn't checking what you'd memorised. They were checking whether you understood the problem well enough to reason your way to an answer they'd never seen, and they could follow your logic to judge it.

That's what a skilled engineer does when they review AI-generated code. Not "does it run," but "is it solving the right problem." They trace the logic. They catch the edge case the prompt never mentioned. They know the stack well enough to spot where the AI is confidently wrong.

None of that shows up in a linked-list reversal. It shows up before anyone opens an editor, in the question someone asks about a vague requirement.

The Question We Actually Ask

This is the part I'd add to Amaricai's argument: you don't get that signal from a clean, well-specified problem. You get it from a spec with a gap in it, and you watch what the candidate does with the gap.

"A user adds items to their cart, enters their card details, and hits submit. Some users aren't getting a confirmation email. Here's the ticket. What do you do?"

A candidate who starts listing debugging steps knows how to debug. A candidate who asks "is it all users or a subset, is the email service third-party, what do the logs show before the failure" knows how to define the problem before they debug it. In a world where AI can handle the debugging, that second candidate is the one worth hiring.

Try This Instead

• Give every candidate for the role the same scenario, with the same gap, scored against the same rubric.
• Watch whether they ask before they start, not just what they build once they do.
• If you let candidates use AI during the interview, evaluate what they do with the output, not whether they produced any.
• Stop testing recall. The technologies on a CV don't map 1:1 to the role anymore, but how someone used them to solve a problem still transfers.

Build an Interview That Still Works

If your process is still optimised for a world where syntax fluency predicted judgment, here's how we can help.