The Take-Home Coding Assignment Is Failing Everyone Involved

Take-home coding assignments feel like the fair option. They're not.

The pitch: no live coding pressure, no biased interviewer watching. Just the candidate, the problem, and their own judgment. What that actually creates is a time cost that falls unevenly on the people you most want to hire. The format feels principled. The outcomes are not.

The "Fair" Format Has a Hidden Tax

Picture the engineer every company says they can't find. Twelve years of experience. Strong opinions about system design. Good communicator. Currently employed, getting three recruiter messages a week, and almost certainly interviewing at two or three other places simultaneously.

Ask that engineer to do an unpaid take-home, and you've done something interesting. You've created a test that's hardest for the candidates most qualified to skip it.

If you have a full-time job, two kids, or both, a "four-hour assignment" doesn't happen in four hours. It happens across evenings and a weekend morning, in fragments, while you're also prepping for three other companies. The junior engineer who just graduated and cleared their calendar takes the exact same test under completely different conditions.

That's not measuring coding ability. It's measuring who had a free Saturday.

Greenhouse surveyed thousands of job seekers and found half dislike take-home tests. The ones most burdened are experienced engineers who are currently employed. If you're good enough to be interviewing at multiple places, you're good enough to triage. A take-home at company B gets skipped when company A is already at the offer stage. You never find out why. You just lose the candidate.

The format selects against the people it was designed to attract. That's a rough tradeoff to make in the name of reducing pressure.

The Dropout Rate Should Embarrass You

Before Dropbox moved away from take-home assignments, 20% of candidates who received one simply didn't submit. Not because they couldn't. Because they didn't bother.

Sit with that number. One in five candidates looked at the assignment, looked at their schedule, and closed the tab. The company probably assumed they weren't serious, or got busy, or were never that interested. The real explanation was simpler: they had better options and a limited number of evenings to spend on long-shot applications.

That 20% skews toward candidates with options. Junior engineers who are unemployed will grind through anything. They fill in every field, write cover letters, complete every step. They have time and urgency. Senior engineers with four open recruiter threads will not jump through the same hoops. The self-selection isn't filtering bad candidates. It's filtering out the people confident enough to walk.

Take-home completion rates average 60-70% across the industry. Live coding formats run above 95%. That 30-point gap is your strongest candidates quietly exiting your funnel before the real evaluation even starts.

A company that gets excited about "removing live coding bias" while losing 30% of its pipeline before the first real conversation has solved the wrong problem. Thoroughly.

AI Made the Signal Worthless

Take-homes always had a cheating problem. You could pay someone on Fiverr to do the assignment. Most companies chose to trust candidates and live with the ambiguity. Small risk, reasonable tradeoff.

That tradeoff collapsed when AI got good.

Fabric analyzed over 50,000 candidate submissions and found AI-assisted cheating more than doubled in six months, from 15% to 35%. And those are the detectable cases. The ones that pattern-matched to AI output clearly enough to flag. The real number is probably higher.

A four-hour take-home that an honest candidate labors through, a cheating candidate hands to Claude and submits in twenty minutes. The output looks identical or better. You can't tell from code style, can't tell from structure. You find out only when the candidate can't explain their own solution in the follow-up call, and by that point you've wasted everyone's time.

There's a specific irony here. The thing everyone liked about take-homes was that candidates could show their best work without time pressure. AI has flipped that into: candidates can show AI's best work without ever touching a keyboard.

The take-home, as a standalone format, no longer measures what you think it measures.

The honest candidate spent four hours on your take-home. The other one spent four hours debugging what ChatGPT gave them, then submitted anyway.

When a Take-Home Actually Earns Its Place

The format can work. A well-designed take-home can surface architectural thinking that a 45-minute live session can't reach. The problem isn't take-homes. It's take-homes running as standalone gatekeeping checkpoints, unverified and uncompensated.

Three conditions have to be true for it to work.

Scope it to two hours maximum, stated explicitly. "Up to four hours" means the best candidates spend six and the worst spend one. "We expect this to take two hours" is a different contract. You're signaling that you've thought about the candidate's time. That you're not using the assignment to screen for people willing to grind.

Pay for it. Most companies skip this and most candidates let it slide. But asking someone to produce work product as part of an application is a thing reasonable people push back on. Some engineers do push back. They just do it by not submitting. A nominal payment, even $50-100, changes the dynamic. The company has skin in the game. The candidate knows you're serious.

Follow up in person. A 20-minute walkthrough where the candidate explains their decisions is the only way to verify the work and extract actual signal. Why this library? Why this tradeoff? What changes if the dataset grows by a factor of ten? That conversation is the real evaluation. The code was just the setup.

Without the walkthrough, you have a document of unknown provenance. You have no way to know whether the candidate wrote it. No mechanism to find out. The code artifact proves nothing on its own.

What to Use Instead

Pair programming gets the same depth in less time with more information. You see how the candidate asks clarifying questions, handles ambiguity, and thinks out loud under mild pressure. A 60-minute live session on a realistic, scoped problem gives you more signal than most take-homes generate across five hours of combined effort from candidate and reviewer.

The AI objection applies here too, but it's much weaker. It's harder to discretely delegate to AI while narrating your thinking on a live call. The format creates light pressure that surfaces real reasoning.

For senior candidates, portfolio review works well. Ask them to bring code they're proud of and walk through the decisions behind it. You get architectural conversation at the same depth as a take-home review. The candidate picks work they already know cold, so they can go deep without prep. The conversation moves faster because both sides are anchored to something concrete.

The common thread: in both formats, the candidate has to explain themselves in real time. That part doesn't outsource.

If your hiring process is sending 30% of candidates to the exit before the real evaluation starts, the problem is not the candidates.

---

Practicing for live coding interviews, where your reasoning is as visible as your solution, is a different skill than grinding take-homes alone. SpaceComplexity runs voice-based mock interviews with real-time feedback on how you communicate your thinking, not just whether the code compiles.