I've interviewed a lot of engineers over the past two years, and the whiteboard syntax test has quietly become the least useful part of the process. Hiring engineers in the AI era means screening for a different skill set, because the thing that used to differentiate a good engineer from a mediocre one, the ability to write correct code quickly from memory, is no longer the bottleneck. AI writes that code now. What it can't do reliably is decide whether the code it wrote is actually right, or whether it solved the right problem in the first place.
This isn't a theoretical shift for me. On our Fleet and Collecta teams, engineers use AI-assisted coding daily. The ones who are genuinely productive aren't the ones who type fastest. They're the ones who can specify a problem precisely, catch a subtly wrong AI suggestion in code review, and reason about how a change ripples through a system. Those are learnable skills, but they're not what most interview processes test for.
If your hiring pipeline still centers on algorithm puzzles and syntax recall, you're optimizing for a skill that's rapidly depreciating while ignoring the ones that now separate strong engineers from weak ones.
What changed and why it matters for hiring engineers ai era style
Three years ago, an engineer who could write a correct binary search from memory under pressure was demonstrating something real: fluency, precision, discipline. Today an AI assistant produces that same binary search in two seconds, correctly, most of the time. The scarce skill moved a layer up the stack.
What's scarce now:
- Problem specification. Turning a vague business request into a precise, testable spec that an AI (or a junior engineer) can execute against without producing the wrong thing confidently.
- Critical review. Reading AI-generated code and knowing which 10% is subtly wrong, because it always looks plausible even when it's broken.
- System thinking. Understanding how a change in one service affects three others, something no autocomplete tool reasons about.
- Debugging under ambiguity. When AI-assisted code fails in production, the failure often isn't a syntax error, it's a wrong assumption baked in three layers deep.
None of these show up in a "reverse this linked list in 20 minutes" interview.
How interviews need to change
I've restructured how we screen for Syntax's engineering hires around three exercise types, replacing the traditional algorithm round entirely.
1. Code review exercises, not code writing exercises
Give the candidate a pull request, real or synthetic, that looks correct on the surface but has a subtle bug: an off-by-one in a pagination query, a race condition in a payment callback, a missing null check on an optional field from an external API. Watch how they find it and how they explain the fix. This tests exactly the muscle they'll use daily reviewing AI output.
2. AI-collaboration tasks
Sit the candidate down with an AI coding assistant and a real, moderately ambiguous ticket. Don't test whether they can use the tool, test whether they push back on it. Do they accept the first suggestion, or do they catch that the AI missed an edge case the ticket implied but didn't state? This is the single best predictor I've found for on-the-job performance with AI-assisted teams.
3. Specification writing
Ask the candidate to turn a messy, two-paragraph feature request (write it the way a non-technical stakeholder actually would) into a spec with defined inputs, outputs, edge cases, and acceptance criteria. Engineers who can't do this will produce AI-assisted code that solves the wrong problem quickly, which is worse than solving it slowly.
What to explicitly stop screening for
| Old signal | Why it's weaker now |
|---|---|
| Memorized algorithm implementations | AI produces these instantly and correctly |
| Syntax fluency in a specific language | AI translates between languages trivially |
| Speed of typing correct code | Speed bottleneck moved to review and judgment |
| "Have they used X framework before" | Ramp-up time with AI assistance dropped sharply |
I'm not saying fundamentals don't matter, an engineer who can't reason about complexity or data structures at all will still struggle to catch AI's mistakes in those areas. But testing for the ability to recite them from memory under interview pressure is testing for the wrong thing.
Building the team around this, not just the interview
This shift also changes what a healthy team ratio looks like. I've seen why software estimates are always wrong get worse, not better, with AI-assisted teams that hired for the old skill set, because velocity on writing code went up while velocity on reviewing and specifying stayed flat, creating a bottleneck nobody planned for. If you hire five fast typists and no strong reviewers, you'll ship bugs faster, not features.
Practical rule I use: for every two engineers hired primarily for build speed, hire one for review and system-design strength explicitly, even if their raw coding output looks slower on paper.
The practical takeaway
Stop testing for what AI already does well. Redesign your interview loop around code review, AI-collaboration exercises, and specification writing, because those are the skills that now determine whether your team ships correct software or confidently ships broken software faster than before. The engineers worth hiring in this era aren't the ones who can out-code the AI. They're the ones who can catch it when it's wrong.