The Hiring Crisis Nobody Saw Coming
AI coding tools broke technical interviews. Here's how to see depth before a production incident does.
A candidate submits a take-home that looks like it was written by a senior architect. Clean code, optimized algorithms, thoughtful abstractions. You bring them in for a live round, ask one question about trade-offs, and watch them freeze. Blank stares. Frantic typing in another tab. They can’t explain the decisions in code they supposedly wrote.
You’ve probably seen the scene twice this quarter. Gergely Orosz at The Pragmatic Engineer has documented a version of it all year: candidates sailing through take-homes and collapsing the moment an interviewer asks them to explain a single line. Simon Willison has written repeatedly about how fluent AI-generated code looks to someone who can’t evaluate it, and how fast that fluency evaporates under questioning. The tools we use daily to ship faster have broken how we evaluate the people we’d hand them to.
The Standard Loop Stopped Working
The interview loop was built on a simple premise. If someone can produce working code under observation, and do it again on their own time, they’re probably a competent engineer. Take-homes tested problem-solving. Live rounds verified thinking. Neither test survives contact with Claude Code or Cursor.
Take-homes are unreliable now because the floor moved. A candidate with minimal technical knowledge can prompt an AI to generate production-quality code and submit it as their own. The code is often excellent, and it tells you almost nothing about the person who submitted it. Live rounds are harder to game in the moment, but nobody ships code in a vacuum anymore, and asking someone to implement a binary tree on a whiteboard tells you less than it did five years ago. It didn’t tell you much then.
Both halves of the loop leak signal. The format that survives, a clean artifact plus a confident walk-through, is exactly what AI now produces for anyone. So the candidates who look best in your process are no longer the ones you most want.
Fluency Is Cheap Now
We use these tools. Our teams use them. We want candidates who use them well: an engineer who accelerates with AI in the loop beats one who can’t. Charity Majors has written about this shift toward judgment as the scarce skill, where the work that matters is review, decision, and debugging, not typing.
The candidates aren’t cheating. Fluency has simply gotten cheap. Anyone can discuss distributed systems without having debugged one, open a PR without understanding the codebase, narrate an architecture they couldn’t rebuild from first principles, and sound right doing it. A standard loop can’t separate an engineer using AI as a force multiplier from someone using it to stay afloat, because on the surface the two ship the same artifact.
Call it surface tension. It’s a property of calm, undisturbed surfaces, and it holds right up until something heavy lands. An engineer who understands what they built can trace the call path, predict how it fails, and say what they’d change under load. Someone floating on fluency ships the same convincing artifact with nothing underneath it. Interviews that never put weight on the surface can’t tell the two apart.
“AI gives anyone enough fluency to float. The surface holds until something heavy lands on it.”
Here’s the cost when the surface breaks on your side of the offer. A new manager, strong pedigree, confident in every meeting, opens a PR using an AI coding tool. The tests assert that 3 == 3. An hour of explanation later, he still can’t say why that’s wrong. He isn’t playing dumb, he genuinely doesn’t know. The loop never caught it because it rewarded the exact fluency that got him through. What finally exposed the gap was a 2am production incident, on a system his team shipped fluently and couldn’t trace.
What Actually Produces Signal Now
Across our experience building engineering teams at ToolWatch (now AlignOps), Oxen.ai, and a labor marketplace spanning all 50 states, the practices that still produce signal have one thing in common: they put weight on the surface. They test evaluation, not generation.
- Replace code-from-scratch with code review
The most reliable change we’ve made. Hand the candidate AI-generated code with deliberate flaws, a subtle race condition, a performance cliff, an abstraction that collapses at 10x scale, and ask them to walk you through it. Code review is no longer “does this work.” It’s “does this person understand why it works.” Strong engineers find the flaws and name them in their own words. Weak ones praise the structure and miss the bug.
- Architectural reasoning under constraint
Skip the generic system-design puzzle and use a real scenario from your codebase: the 10x traffic problem you had last quarter, the migration you’re about to attempt. Then push past the diagram: “Walk me through what happens if this fails.” Strong candidates get specific about failure modes. Weak ones pivot to another high-level concept. Will Larson’s work at staffeng.com on what senior engineers actually do makes it concrete: the job is judgment under ambiguity, and ambiguity is what scripted interviews engineer out.
- Pair program on a real problem
This beats coding puzzles every time. Give the candidate an actual bug or a small feature, let them use whatever tools they normally use, including AI, and watch them work. When the AI hands them a plausible-but-wrong suggestion, do they catch it? An hour of that mirrors the job better than any take-home. You can’t float your way through a race condition you don’t understand.
- Deep-dive the real work history
The easiest and most underused move: have your most experienced engineers run a deep dive on the candidate’s actual work. “Tell me about a system you designed that failed. What would you do differently?” Real experience has a texture fabricated stories don’t. Camille Fournier’s writing on reference-as-interview names it well, the specifics people choose to remember reveal what they actually learned.
What You’re Actually Screening For
This hiring problem is the visible edge of something larger: AI moved what engineering competence means. Five years ago, a strong engineer wrote clean, efficient code under pressure. That’s still valuable, but no longer scarce. What’s scarce is judgment: architecting systems that solve real problems, making trade-offs under uncertainty, debugging distributed systems whose state you can’t hold in your head. Google Cloud’s DORA research has spent years showing that the teams shipping reliably have strong judgment at the architectural and operational layers, not the fastest typists.
So the real question isn’t who passes your loop. It’s who on your team can navigate an unfamiliar codebase under pressure, without a prompt, and reason through failure modes in real time. That’s your load-bearing engineering capacity, and it may be much smaller than your headcount suggests. Every hire your loop waves through on fluency alone shrinks it, because a leader who manages by AI output rather than judgment hires and promotes in the same pattern. If your pipeline feels dry, your filter may be the problem: the candidates failing your algorithm challenges might be the ones who’d carry your fastest-moving team, and the ones passing might crumble in the first real incident.
If your interviews aren’t producing strong hires anymore, you’re not the only one. The playbook most teams are still running was written for a constraint that stopped binding the day fluency got cheap.
Your hiring loop is still screening for typing speed.
We audit hiring loops before the cost of a bad hire does it for you, rebuilding them to surface judgment instead of plausible artifacts. It’s one piece of a bigger job: helping any company retool its technology, its people, and its business for a world AI is rewriting faster than most teams can adapt.
Not ready to talk? Stay sharp anyway.
We send insights like this to technical leaders every week or two. The thinking we bring to our engagements, no fluff, no spam.
You're in. Check your inbox to confirm, and for what we sent.
