We Hire People to Ship Features, Then Test Them Like They're Entering a Math Olympiad

The Job You're Interviewing For Doesn't Exist

Here's a fun exercise: ask any working senior engineer what they did last Tuesday. I promise you the answer is not "hand-implemented Dijkstra's algorithm from memory." It's more like "read three PRs, sat through a planning meeting that should've been an email, debugged a flaky CI pipeline, and spent forty minutes figuring out why accounting's CSV export has a trailing comma."

Yet the standard interview loop — the one used everywhere from Bay Area giants to mid-size companies in Columbus — still hinges on solving abstract algorithm puzzles, live, on a whiteboard or a shared editor with no autocomplete, while three people watch you sweat.

We're not testing the job. We're testing a ritual.

The Leaky Abstraction of Technical Interviews

The original logic wasn't crazy. Algorithm puzzles were a proxy: if you could break down an unfamiliar problem under pressure, maybe you could break down unfamiliar problems at work. It was always a rough proxy, but at scale it was cheap, and tech companies love cheap and scalable.

The problem is the proxy has rotted. Consider what the job actually looks like in 2025:

• Most production work is gluing systems together, not inventing them
• The hardest part is rarely the code — it's the requirements, the legacy constraints, the politics
• An AI assistant can produce a working BFS traversal in four seconds

That last point is the kicker. If a candidate can get the answer from a tool they'll have open all day at work, what exactly are we measuring when we ban the tool? Composure? Handwriting?

We've built a hiring process that filters for a skill the role stopped requiring years ago, and we keep running it because everyone else does and changing feels risky.

The False-Negative Machine

The real cost isn't just that the process is silly. It's who it quietly rejects.

Great engineers who freeze under performance conditions. People with deep domain judgment who haven't crammed graph theory since college. Career changers who learned to build real things — actual deployed software — instead of grinding NeetCode for six months.

And who sails through? People who optimized for the test. Interview prep is now a whole industry, which means the signal you're measuring is increasingly just "did this person spend 200 hours on LeetCode." That's a signal about free time and test-taking, not engineering judgment.

Meanwhile, the false positives sail in too. Anyone who's watched a puzzle ace struggle to write a migration plan or give honest code review feedback knows the gauntlet doesn't predict on-the-job performance well. Google famously found its own brainteasers nearly worthless years ago. The industry shrugged and kept going.

What a Realistic Loop Could Look Like

I'm not arguing for vibe-based hiring or take-homes that eat a weekend — unpaid labor is its own problem. But there's a middle path, and some shops are already walking it:

Work-sample interviews with the tools you'd actually use. Give candidates a small, realistic codebase and a bug or a feature request. Let them use their IDE, their AI assistant, Stack Overflow, all of it — because that's the job. Then talk through their decisions. What they did matters less than why, and whether they can reason about trade-offs out loud.

AI-inclusive exercises, judged on verification. If a candidate uses a copilot to scaffold a solution, great. Can they spot when it's wrong? Can they explain what the generated code does? The skill of the next decade isn't writing code from scratch — it's reviewing and correcting code at speed. Test that.

Design conversations over puzzle hazing. "How would you approach adding offline support to this app?" has no single answer, which is the point. It surfaces judgment, curiosity, and the ability to say "it depends" and then actually explain what it depends on.

Follow-up questions that reward honesty. The best interviews I've been in were the ones where saying "I don't know, but here's how I'd find out" was treated as the correct answer. Because it is.

The Uncomfortable Part

None of this is a secret. Every engineering leader complaining about the gauntlet knows the fix. The obstacle is that a better process takes more interviewer time per candidate, requires calibration, and can't be fully automated.

But here's the thing: a broken hiring filter is just technical debt with a calendar attached. You pay for it in missed hires, in homogeneous teams, in the slow drip of great candidates who took an offer from the company that interviewed them like a human.

The gauntlet is broken. We know how to fix it. The only question left is whether the industry is willing to spend a little more effort to hire people for the job they'll actually do — not the one we pretend they're applying for.