We opened three senior backend positions last quarter. We received 180 applications. We sent take-home assignments to 42 candidates. Reviewing them took 217 hours of combined engineering time.

Here's what actually happened—and why we stopped using them.

The Numbers Tell Half the Story

Out of 42 take-homes sent:

• 19 candidates never submitted (45% drop-off rate)

• 23 completed submissions

• Average review time per submission: 9.4 hours

• Engineers involved: 4 (pulling them from sprint work)

• Candidates who made it to final round: 6

• Hires: 1

That's 217 hours to hire one person. And the person we hired? They weren't even in our top 3 ranked submissions.

What Take-Homes Actually Measure

We thought we were measuring real-world engineering ability. We weren't.

We measured free time. The candidates with the most polished submissions were either unemployed or had extremely flexible schedules. Our best submission came from someone who spent an estimated 18 hours on a "4-hour assignment." They over-engineered everything—multiple design patterns, extensive documentation, CI/CD pipeline, the works.

In the job, they couldn't ship features. They got stuck in analysis paralysis on every ticket.

We measured performance anxiety, not performance. Three candidates who submitted working, pragmatic solutions apologized in their README files for "not having enough time to make it perfect." One wrote: "Sorry this isn't production-ready, I have a full-time job and two kids."

That candidate's code was clean, well-tested, and showed excellent judgment about trade-offs. We advanced them. They withdrew because they'd already accepted another offer—one that didn't require 8 hours of unpaid work.

We measured nothing about debugging. Every take-home was a greenfield problem. Build a REST API. Implement a cache. Design a URL shortener.

Real backend work isn't building from scratch. It's inheriting a 4-year-old codebase with inconsistent patterns, mysterious performance issues, and breaking prod at 2 AM because of a database lock you didn't anticipate.

Not one submission told us if a candidate could read unfamiliar code, trace a bug through three services, or make a pragmatic fix under pressure.

The Hidden Costs

Engineering time evaporated. Our tech lead spent 6-8 hours per week reviewing submissions. That's nearly 25% of his time. He wasn't writing code, wasn't unblocking the team, wasn't doing architecture reviews. He was reading someone's implementation of a rate limiter for the fifth time that week.

We built resentment, not rapport. By the time candidates reached the on-site interview, they'd already invested 6-10 hours. If we asked them to whiteboard or pair program, they got defensive: "I already proved I can code. What more do you want?"

They weren't wrong. But we still didn't know if they could work with our stack, debug our kind of problems, or make decisions under ambiguity.

We optimized for the wrong signal. The candidate we hired had a mediocre submission—decent code, nothing fancy, one or two minor bugs. But in the follow-up interview, when we asked them to walk through their choices, they were exceptional.

They explained why they didn't add caching ("You didn't specify scale requirements, and premature optimization would obscure the core logic"). They pointed out an edge case in our requirements ("What happens if two users try to claim the same resource simultaneously?"). They showed judgment.

The submission didn't matter. The conversation did.

What We Changed

We stopped sending take-homes for initial screening. Not entirely—we still use them in final rounds for 2-3 finalists, with a tight scope and a 90-minute time limit.

For initial technical screening, we switched to 30-minute practical sessions: here's a broken service in a live environment, here are the logs and monitoring dashboards, walk us through how you'd approach this.

We watch them work. We see how they ask questions, prioritize what to investigate first, and use the tools available to them—including AI, stack overflow, documentation, whatever.

Three months in, our engineering time spent on hiring dropped by 68%. Our offer acceptance rate went up because candidates aren't burned out by the process. And the quality of hires? We brought on four engineers this quarter. All four are still here, all four are productive.

The uncomfortable part? We were using take-homes because they felt rigorous. They felt fair. They felt like we were being thorough.

We were actually just offloading our decision-making onto candidates' free time and calling it "assessment."