How to Interview Developers in the AI Era

The first developer you hire this year will spend more time reviewing code than writing it. Most founders are still interviewing like it’s 2021.

The old playbook tested whether someone could produce code from a blank page, which is why interviews were built around whiteboard puzzles, syntax trivia, and take-home feature builds. That skill still matters, but Claude and Copilot write the first draft now, and they write it fast. What you’re actually paying for is judgment: can this person tell when the AI’s output is wrong, and will they catch it before your customers do?

I’ve spent the past two years helping teams standardize AI-assisted development, including writing the instruction files that keep tools like Claude consistent across a codebase. The developers who thrive with these tools aren’t the fastest typists. They’re the ones who read code critically, understand the whole system, and push back when a generated solution looks plausible but isn’t right. Plausible-but-wrong is exactly the failure mode AI produces, and a junior who accepts every suggestion will fill your product with it.

So change the interview. Hand candidates a chunk of AI-generated code with three real problems buried in it and ask what they’d flag. Ask how they decide when to trust a tool’s output. One developer with that judgment will protect your product better than two who type fast.

Founders who’ve hired recently: has AI changed how you run interviews, or are you still testing for skills the tools already have?