We were spending six weeks per engineering hire. Two weeks sourcing, three weeks cycling candidates through four interview rounds, and another week deliberating on someone we'd meet for maybe four hours total. Then they'd start, and within 90 days, we'd realize we'd hired wrong. The person who aced the system design interview couldn't ship a feature. The one who crushed LeetCode couldn't debug a production issue without hand-holding.

The problem wasn't our interviewers. It was that we were testing for the wrong things in the wrong environments.

What We Were Actually Measuring

Traditional technical interviews measure three things: preparation, performance under artificial pressure, and pattern recognition. A candidate who spent three months grinding algorithms will outperform someone who spent three years shipping products. We rewarded memorization over judgment.

Our old process looked like this:

Week 1-2: Resume screening, initial calls

Week 3: Coding challenge (algorithms, data structures)

Week 4: System design round

Week 5: Behavioral + technical deep-dive

Week 6: Final decision, negotiations

Out of 100 applicants, we'd interview 15, bring 5 to final rounds, and hire 1. That one person was a coin flip.

The False Proxies We Trusted

We believed system design interviews showed us who could architect systems. They didn't. They showed us who could draw boxes and talk confidently about CAP theorem. When we asked them to actually implement a caching layer or optimize a slow query, many couldn't.

We thought pair programming revealed problem-solving ability. It actually revealed who performs well with someone watching over their shoulder. Our best backend engineer—the one who reduced our API latency by 60%—bombed his pair programming round. He got hired anyway because the director overruled the process. That was our first clue.

We assumed take-home assignments were realistic. They weren't. Candidates had unlimited time, could copy solutions, and optimized for impressing us rather than solving the actual problem. We'd see beautiful code that used design patterns inappropriately or was over-engineered for the scope.

What Changed: Watching People Work

We stopped asking candidates to perform and started watching them work. Thirty minutes. Real environment. Actual problems from our backlog.

Instead of "explain database indexing strategies," we gave them a slow query, access to our staging database, and said: "This is timing out. Fix it."

Instead of "design a distributed system," we showed them our microservices architecture with a latency spike and asked: "Walk me through how you'd debug this."

Instead of "implement a binary tree," we gave them a bug in our checkout flow that was costing us revenue and said: "Here's the codebase and error logs. What do you see?"

What We Learned in 30 Minutes

You see decision-making immediately. Do they jump to conclusions or gather data first? Do they check logs, monitoring, or just start changing code randomly?

You see how they use tools. Do they know their way around a debugger, a profiler, a database console? Or do they rely purely on print statements and guessing?

You see their relationship with AI. The best candidates used AI to accelerate research or generate boilerplate, then understood and modified the output. Weak candidates copied AI responses verbatim without comprehension.

You see communication. Can they explain their reasoning? Do they ask about constraints? Do they consider trade-offs or just propose the first solution that works?

You see judgment. Not everything needs to be perfect. Strong engineers know when "good enough" is actually good enough and when to dig deeper.

The New Process

Day 1: Job posted

Day 2-3: All applicants get a 30-minute "watch-them-work" assessment

Day 4: Platform ranks candidates by performance on real tasks

Day 5-6: We interview the top 10

Day 7: Hire

We went from six weeks to one week. From 40+ hours of engineering time per hire to about 8. From a 30% mis-hire rate to under 5%.

Why Most Companies Won't Do This

It requires admitting that what you've been doing doesn't work. That's hard when you've built an entire hiring process around LinkedIn profiles and LeetCode scores.

It requires infrastructure. You need environments where candidates can safely deploy, break things, and work with real tools. Most companies don't want to build that.

It requires letting go of credentials. A candidate without a CS degree from a top school might outperform someone with every certification. That makes people uncomfortable.

What We Actually Optimized For

We stopped hiring for "smart" and started hiring for "effective." Smart people can talk about Big O notation. Effective people ship features, fix bugs, and make systems better.

Our 30-minute assessments don't tell us if someone can recite algorithms. They tell us if they can do the job. That's the only signal that matters.

The uncomfortable part? Half our engineering team wouldn't pass our own assessment if we made them take it today. They've been promoted based on tenure, not demonstrated skill. That's a separate problem, but at least now we're hiring people who won't make it worse.