We were asked recently whether coding agents had changed what we look for when hiring engineers. Mostly no. One thing, specifically, yes.
What didn't change
The ability to read a requirement and spot its ambiguity, the discipline to write a test before trusting a change, and the judgement to know when a clever solution is worse than a boring one — all still separate strong candidates from weak ones, exactly as before. None of our interview questions on these fronts needed rewriting.
What moved
The ability to review code quickly and accurately, at volume, without slowing to a hand-written pace, got noticeably more important. When a team is producing more code per week because some of it is generated, the bottleneck shifts from writing to reading, and reading well — fast, sceptical, alert to the specific ways generated code goes subtly wrong — is a skill some strong writers of code have never had much occasion to develop.
How we test for it now
- We give candidates a diff, not a blank page, and ask them to find what's wrong with it, alongside the usual written exercise. Some candidates who write clean code struggle here; some who write average code are excellent at it.
- We ask what they'd check first, not just what's wrong. The order of investigation says as much about judgement as the specific bugs found.
- We include at least one diff that's entirely correct, because knowing when to stop looking and approve something is as much a skill as finding problems, and we've seen candidates invent issues rather than say a diff is fine.
The trait that predicts this skill
Candidates who are good at this tend to describe their own past debugging as "I assumed the obvious thing was true and it wasn't, and it took me two hours to notice" — a specific kind of humility about their own assumptions that seems to transfer directly to reading someone else's, or a model's, work sceptically.
We are not hiring people who can prompt well. We are hiring people who read carefully. Prompting is a skill anyone on the team picks up in a week.
What we stopped asking
Algorithm-heavy whiteboard exercises that had already been on their way out before any of this, now feel even less connected to daily work than they did. Almost nobody on the team spends real time on that kind of problem; almost everyone spends real time deciding whether a diff, generated or not, is safe to merge.
The honest caveat
A year is not a long baseline, and we may be overfitting to our own current process. What we're confident of is narrower: reading has become at least as valuable as writing, and we were previously hiring almost entirely for the latter.