Hiring Developers When the AI Writes the Code

CTOs and engineering managers still hire developers. But the interview CTOs should run today looks nothing like the one I ran for twenty years, because in most of the companies I work with the AI already writes most of the code, in a few of them all of it, and the thing engineering managers used to spend most of the interview testing for stopped being relevant somewhere in the last year.

For two decades the interview process barely moved. You sat a candidate down, took away the internet, and watched them solve a puzzle or a problem on a whiteboard - reverse a linked list, balance a tree, find the duplicate in one pass - or design a search engine, ecommerce site or scale your infrastructure. You also let them write code - and sometime you let them read and explain code (Great!). What you were measuring - in essence - was how many correct lines of code they could pull out of their own head per hour - no really (depending of course of the definition of correct). That was coding, so that was the test (don’t believe me, ask the CEO what she thinks the developers job is (was (looks like LISP now))).

The machine does the coding now. It writes correct (yes it does) code faster than any candidate, it remembers every framework and every standard-library call (with research hallucinations are no problem anymore), and it never blanks on the syntax for a closure at 4pm in a room full of strangers - and if it does it diligently fixes it until it works. 24/7. Screening for that is screening for what developers no longer need to do - so don’t.

What the old bar measured

What people were asking in an interview, differed, but might have been leetcode, syntax recall, language edge cases, framework trivia, the speed of getting boilerplate onto the screen - like writing a string reverser. I ran those interviews for a long time, for years, and I was measuring the wrong thing the whole time (Lucky me changing my interviews to look for motivation, business sense and ownership before it a decade ago).

The signal that predicted who would be useful - can this person open a codebase they did not write, juggle it in their head, and change it without breaking three other things - was what hiring managers were looking for.

Who I hire instead

What AI changes is how much one person can own. When the typing is no longer the bottleneck, and skills (PM, coding) are no longer a constraining factor, one developer can carry an idea from “a customer complained about X” to a feature in production, without multiple handoffs (sales, pm, developer, QA) and three other people in the middle. The developers who do that well many people in our industry have started calling product engineers, and product engineers are who I’d hire for today.

A product engineer owns the complete outcome, from having an idea about a customer need to the thing running in production. They can sit in front of a customer and work out what the customer needs (detirmend by what the customer is doing) as opposed to what they asked for (the two are rarely the same). They point an AI at the work the way a senior used to point four juniors at it in a daily, and they keep the judgment about what is worth building and whether what came back is any good. The coding was never the part that mattered. The deciding was. Build the right things.

Everyone is a manager now. With the problems of accountability, delegation, and trust. What managers struggled with in their jobs is now the same thing developers struggle with when working with an AI. Hire for that.

This is the shift I wrote about in creators and coders: the person with intent and taste, with an AI behind them, gets further than the person who can only translate a ticket someone handed them to source code. AI shrinks the gap between the idea and the working software to almost nothing, and once that gap is gone, one person owns the customer need and the deploy, where it used to take three departments and a queue of tickets in between.

What earns a hire now

What to look out for today? Taste and judgment, ahead of everything. Can they look at three ways to solve a problem and pick the one that won’t hurt in a year. Creativity - can they come up with a product worth building, since the ideas side is where the bottleneck went. Whether they can direct an AI: do they know what to ask for, how to tell when the answer is wrong, and how to steer it back.

Then verification. Do they verify what the AI gives back? - this is responsible engineering. Developers who push code into production without verifying do more damage now than the slow developer ever did. Responsible engineering used to mean writing the test. Now it also means using an AI to find and prevent bugs, checking what the AI wrote for security holes, and going back to the requirement to see whether the code written solves the problem you started with (loop back to the ticket, specs, requirements or idea).

Then product sense, business understanding (which was always important for seniors to make the right tradeoffs, but rarely interviewed for), and the one thing that did not change: do they own the work when no one is checking. It got harder to just fake it, because when you own the outcome there is no team and product pipeline left to hide behind. So at least you detect your mishires sooner than before.

What I stopped testing

Algorithm puzzle and whether the candidates carry one framework in their head down to the method signature and the edge cases. Which languages sit on the CV - I no longer care about programming languages, neither should you. With Claude a senior developer should be able right away on a code base in a language they never saw - the AI is fluent in all of the languages, and so, with the AI, is the candidate. Be careful, you still need someone with fundamentals, so “nobody needs to know how anything works anymore” is going too far - for now. Engineers need to make the right judgements, about the architecture the AI chose, the technology it built on and about the tradeoffs the AI introduced.

How the interview works now

Just give them the Claude. Don’t fight the AI, don’t try to keep it out of the interview. Sit thje candidate down with the tools they would use on the job, hand them something tangled out of your own codebase, and watch how they work.

Looking how they work lets you decide if you want to hire them. Do they hit tab on autocomplete, or do they prompt with intent. Do they know how to keep the AI out of doom loops? Do they know where AIs struggle and prompt accordingly? Do they ask YOU the right questions about what should be build? Does their prompting make sense? When the AI hands back two hundred lines, do they read them or ship them. Do they make the AI explain them, verify them? Do they make the AI hunt for bugs and security problems, unbalanced architecture and inconsistent domain classes? Do they think about the edge case, the thing the requirement forgot to mention. Do they catch the AI doing the wrong thing and pull it back to what you wanted. let them write the code first and sort the rest out second, and judge what they shipped when the hour is up. Can they save tokens? Do they know differences between models?

So hire for taste, for the instinct to build the right product, for responsible engineering, for candidates taking ownership and those being motivated. Mostly what you already wanted but didn’t know.

If you want the developers you already have to get there, bring the AI to them before your CEO gets angry because the company is not moving fast enough.