I've spent six months running the same engineering role through every major assessment method we could find. Same JD, same seniority level, same skill requirements. We ran candidates through coding platforms, pair programming sessions, take-homes, system design interviews, and even AI-powered video screens.

The results weren't just surprising. They were infuriating.

The hypothesis that failed

I started with what seemed like a reasonable assumption: more assessment = better signal. If one coding test is good, surely a multi-stage process with algorithm challenges, system design, and take-home projects would give us the complete picture.

We hired three people using this comprehensive approach. Two were gone within four months. One couldn't debug a production issue without copying Stack Overflow answers verbatim. The other froze completely when asked to optimize a slow database query they'd theoretically "designed" in their system design interview.

The candidate we rejected for "poor algorithmic performance"? I found out later he was running infrastructure at a company processing 2 billion requests daily.

What each method actually measures

Resume screening and ATS filtering measure keyword optimization skills. I watched our ATS reject a candidate with eight years of distributed systems experience because he wrote "message queues" instead of "Kafka" in three different places.

Timed coding challenges measure pattern recognition and test anxiety management. The correlation between HackerRank scores and actual job performance in our data: 0.23. Barely better than random.

Pair programming and whiteboarding measure how well someone performs under artificial pressure while a stranger watches them type. We had candidates who built elegant solutions go completely silent in pair programming sessions. And we had people who talked brilliantly through whiteboard problems but couldn't ship working code.

System design interviews measure storytelling ability. I can't count how many candidates beautifully described microservices architectures, load balancers, and caching layers, then struggled to write a working API endpoint.

Take-home assignments measure free time and desperation. Our best candidates—the ones currently employed and in-demand—had a 60% drop-off rate on take-homes. We were selecting for people who had nothing better to do on their weekends.

The pattern I kept seeing

None of these methods showed me what I actually needed to know:

• How does this person debug unfamiliar code?

• What's their process when something breaks in production?

• How do they make tradeoffs under constraints?

• Can they explain their reasoning while they work?

• Do they know when to use AI tools and when not to?

Every method tested a proxy. Algorithms instead of problem-solving. Design discussions instead of implementation. Theoretical knowledge instead of practical judgment.

What actually worked

I stopped asking candidates to prove they could code. Everyone can code now—AI made sure of that.

Instead, I started giving 30-minute scenarios that replicated actual work:

"This API endpoint is returning inconsistent results. Here's the codebase, the error logs, and database access. Walk me through how you'd find and fix this."

"We need to add rate limiting to this service. Here's the current implementation. Show me how you'd add it without breaking existing functionality."

"This Docker container is 2GB and taking 10 minutes to deploy. Make it smaller and faster."

Not coding from scratch. Not whiteboarding. Not explaining what they'd do. Actually doing it, with all their normal tools available, including AI.

What changed

The signal-to-noise ratio flipped completely.

I could see candidates who knew how to read logs versus those who just restarted services hoping problems would disappear. I watched people who understood database indexes versus those who just added them randomly. I saw who could use AI as a tool versus who treated it as a magic answer box.

The candidates who excelled in these scenarios had something in common: they'd all been in production fires before. They had pattern recognition from real experience, not LeetCode grinding. They asked about constraints, discussed tradeoffs, and showed their thinking process.

The actual conclusion

Most assessment methods measure how well someone prepares for assessments. The only thing that matters is watching someone do the actual job.

If you can't watch a candidate connect to a real database, optimize a real query, and explain their reasoning—you're guessing. And in my experience, we're not very good at guessing.

The best predictor of whether someone can do the work is watching them do the work. Everything else is theater.