I've hired 47 engineers across three startups. The fastest hire took 11 days. The slowest took 127. The average? 73 days. For years, I blamed recruiters, candidates, and "the market." Then I realized: I was measuring the wrong thing. The bottleneck wasn't time-to-hire. It was time-to-confidence.

We're optimizing for speed when we should be optimizing for signal

Every CTO I know complains about hiring timelines. We all say the same thing: "It shouldn't take three months to hire a mid-level backend engineer." So we throw solutions at it. Better job posts. Faster ATS filters. More recruiters. Tighter interview loops.

None of it works. Because the problem isn't process efficiency. It's signal clarity.

Here's what actually happens: You get 150 applications. Your ATS filters it to 70 based on keywords. You phone screen 20. You bring 8 onsite. You make an offer to 2. One declines. You start over.

The entire pipeline is designed to eliminate candidates, not identify the right one. And because you're never confident in your signal, you add more steps. More rounds. More people. More time.

The false comfort of consensus

After my second bad hire in year three, I added a fourth interview round. Then a fifth. I convinced myself that more interviewers meant better decisions. It didn't. It meant more calendar Tetris and slower decisions.

Here's the uncomfortable pattern: The more people involved in hiring, the longer it takes, but the quality doesn't improve. In fact, it often gets worse. Because now you're hiring for consensus, not capability.

I once passed on a phenomenal engineer because one interviewer "didn't feel confident" after a 45-minute whiteboarding session where the candidate was nervous. That engineer joined our competitor and shipped their core infrastructure rewrite in four months.

We optimized for comfort, not signal.

The real reason it takes 73 days

Let me break down where the time actually goes:

Week 1-2: Job posted, applications trickle in, you're busy with sprints, you don't look at resumes.

Week 3-4: HR sends you 30 "qualified" candidates. You skim resumes during lunch. 80% are irrelevant. You schedule phone screens for 8 people over the next two weeks because calendars.

Week 5-6: Phone screens happen. 3 out of 8 are decent. You send them a HackerRank test. 2 complete it. 1 ghosts you.

Week 7-8: You schedule technical rounds. Candidate #1 fails your system design round. Candidate #2 passes but wants $40k more than your range.

Week 9-10: You're back to square one. Start over. Post on LinkedIn. Ask for referrals. Repeat.

The cycle isn't slow because of process overhead. It's slow because you don't have confidence until week 7, and by then, the good candidates are gone.

What I changed after hire #32

I stopped treating hiring like a funnel and started treating it like a detection problem. The question shifted from "How do I eliminate bad candidates faster?" to "How do I identify good candidates earlier?"

Here's what that meant in practice:

I stopped reading resumes first. Resumes tell you what someone says they did. I needed to see what they could actually do.

I stopped doing phone screens before technical evals. If someone can't solve real problems, their communication skills don't matter yet.

I stopped using coding puzzles that had nothing to do with our stack. No one on my team writes algorithms to reverse binary trees. They debug API latency and refactor messy codebases.

The 30-minute rule

The best hires I ever made, I knew within 30 minutes. Not from a culture fit chat. From watching them work.

I'd give them a real problem: "This API is throwing 500 errors for 12% of requests. Here's the repo, the logs, and access to staging. Walk me through how you'd debug this."

The signal was immediate. Not whether they solved it, but how they approached it. Did they read the logs first or jump into code? Did they ask about monitoring tools? Did they consider database load, race conditions, or input validation?

I could tell in 18 minutes whether someone thought like a senior engineer or a bootcamp grad following a tutorial.

The problem? I couldn't give 150 candidates this test. I didn't have the infrastructure, the time, or the variations to prevent cheating.

The hidden cost no one talks about

Here's what really broke me in year six: I calculated that our engineering team spent 34% of Q2 in interview loops. Not coding. Not shipping. Interviewing.

That's not a hiring problem. That's a productivity crisis.

And the worst part? We still made bad hires. Because interviews don't predict performance. They predict interview performance.

What confidence actually looks like

The fastest hire I ever made—11 days—happened because I had signal on day two. A friend sent me a GitHub link to a candidate who'd contributed to an open-source project we used. I could see six months of commits, code reviews, architecture decisions, and how they handled feedback.

I didn't need four rounds. I needed evidence. And I had it.

That's when it clicked: Time-to-hire is a lagging indicator of signal quality. If you don't have confidence early, you'll keep adding steps, and it'll keep taking longer.

The actual breakthrough

After 47 hires, here's what I know for certain: Hiring takes so damn long because we've built a system that delays confidence instead of accelerating it.

We spend weeks filtering resumes when we should spend 30 minutes watching people work. We do five interviews when one real task would tell us everything. We optimize for consensus when we should optimize for evidence.

The companies that fix this won't hire faster by speeding up their process. They'll hire faster by getting better signal earlier. And the moment you see someone actually solve a real problem in a real environment with real constraints, the decision becomes obvious.

That's not a faster process. That's a better one.