Take home coding assignment: the zip file is no longer the evidence

A take home coding assignment is a programming task a candidate completes on their own time, away from the interviewer, and then submits for review. It was meant to show how someone works on a realistic problem without the pressure of a live audience. That idea still holds. What broke is the assumption that the submitted code tells you who wrote it.

Our view is simple. The zip file is no longer evidence. The conversation about it is. You can keep the take-home, but only if you move the scoring from the artifact to the walkthrough, or swap it for a format that records how the code was produced.

Key Takeaways

Our position: a take-home now proves something was submitted, not who produced it or how. Score the follow-up conversation, not the zip file.
An AI assistant can finish most short, well-specified take-homes, so a clean submission no longer separates strong candidates from weak ones.
You have three honest options: allow AI openly and score the walkthrough, replace the screening take-home with a timed sandboxed test, or move a small or paid take-home to the final stage.
Keep it short, write the AI policy down, ask for a decision log, and write the rubric before you open a single submission.
Never ask candidates to assign code rights for an interview task.

What a take home coding assignment was meant to prove

The original pitch for the take home coding test was fair. Live coding rounds reward people who think well under a stopwatch, and plenty of good engineers don't. A take-home let candidates work at their own pace, with their own editor, on something closer to real work than a whiteboard puzzle.

It was also meant to show habits a live round can't. How someone names things, whether they write tests, how they structure a small project, and what they leave out on purpose. Those are real signals, and they're the reason many teams still like the format.

The problem is the hidden assumption underneath all of that. The format only works if the person who submits the code is the person who wrote it, and if "wrote it" means what it used to mean.

What changed: the assistant in the next tab

Developers now use AI tools as a normal part of the job. The Stack Overflow 2025 Developer Survey found that 84% of respondents are using or planning to use AI tools in their development process, up from 76% the year before. That isn't cheating. That's the job.

It does change what a take home coding challenge measures. A short, clearly specified task is exactly the kind of thing an assistant handles well. The submission comes back tidy, tested and documented, and it looks the same whether the candidate understood every line or pasted the prompt and walked away.

The same survey has a useful twist. More developers actively distrust the accuracy of AI tools (46%) than trust it (33%). So the skill that matters is judging, fixing and owning what the assistant produced, and a zip file can't show you that.

Practitioners have noticed. In a long Hacker News thread on the best take-home tasks, one commenter put it plainly: a short challenge can be solved with AI, and a month of work gets no takers. That's the squeeze every hiring team running a take home assignment interview is in right now.

When a take-home still earns its place (and when it doesn't)

We're not anti-take-home. We're against treating the artifact as proof. Here's how we'd decide.

A take-home still earns its place when:

It's late in the process. Only finalists get it, so you're asking for a few hours from people you're seriously considering.
It's small or paid. One engineer in that HN thread said the best take-homes they'd done were small, paid tasks from the team's real backlog, reviewed together afterward.
It feeds a conversation. The submission is the agenda for the next interview, not the verdict.
AI use is allowed and expected. You're grading judgment, not keystrokes.

It doesn't earn its place when:

It's the first screen. You're asking for unpaid hours before you've invested anything, and candidates with other offers simply skip it.
It's long and unsupervised, and the artifact is the score. That's the version an assistant beats most easily.
Nobody reviews it with the candidate. Then you've collected a file and learned almost nothing about the person.

How to design a take home coding assignment that survives AI

If you keep the format, design it so the signal survives an assistant. Five rules cover most of it.

Keep it short. CodeSubmit's own guide to designing a take-home coding challenge recommends a 2–4 hour limit. Treat that as a vendor view, not a standard. Shorter is kinder, and length doesn't make an assistant any less useful.
Write the AI policy down. Say whether AI tools are allowed, and if they are, ask candidates to note where they used them. Our post on whether you should allow AI in job interviews has a framework for deciding.
Ask for a short decision log. Five or six lines: what they built first, what they changed, what they'd do with another day. It's cheap to write if you did the work and awkward to invent if you didn't.
Write the rubric before you review. Decide what good looks like and how much each part counts before the first submission arrives. Otherwise the most polished file wins, and polish is now free.
Never ask for IP assignment. An interview task that asks candidates to sign over code rights reads as free labor, and good candidates will notice.

None of this makes the submission trustworthy on its own. It makes the follow-up conversation sharper, which is where the real assessment happens.

The follow-up walkthrough: questions that separate an author from a submitter

The technical interview after take-home assignment review is the part to invest in. Book 30 to 45 minutes, share the candidate's own code on screen, and ask questions the author can answer easily and a copier can't.

"Walk me through the structure. Why is it split this way?" Authors explain trade-offs. Submitters describe what the files contain.
"What did you try first that didn't work?" Real work has a dead end in it, and people remember their dead ends.
"Change this constraint. What breaks?" Double the input size, add a second user, or remove a dependency, then ask them to reason about it live.
"Where would this fail in production?" Look for specific failure modes, not a generic list.
"Show me a line you'd rewrite now." People who wrote the code have opinions about it.
"Where did you use AI, and what did you change in what it gave you?" If you allowed AI, this is the most useful question you'll ask.
"Add a small feature right now." Ten minutes of live change shows whether they can move around their own code.

Score the walkthrough against the rubric you wrote in advance. If the answers are vague and the code is excellent, believe the answers.

Take home coding test vs live coding interview vs a timed sandboxed test

The full take home coding test vs live coding interview comparison lives in our guide to coding assessment software. Here's the short version, sorted by stage.

Early screen, high volume: a short, timed, sandboxed coding test. The code actually runs against hidden test cases, so you see what it produced rather than what it claims.
Mid-stage: a live round where the candidate codes and talks, so you hear the reasoning as it happens.
Finalists: a small or paid take-home, followed by the walkthrough above.

The timed sandboxed option is where Expert Hire fits. Our coding tests run the candidate's program in a Piston-backed sandbox and score it on correctness, efficiency and code quality, with a complexity read. There's nothing to download and no submission to package up. It's not a take-home and doesn't take multi-hour projects or repositories, which is the point.

Integrity is handled in the open. When proctoring is on, Expert Hire detects known AI-assistant overlay tools, signs of impersonation and tab switching, and every signal goes to a human reviewer next to the code. A proctoring flag never rejects anyone, and there's no black-box pass/fail. Our post on detecting AI cheating in interviews covers that wider problem.

If you want the conversation layer too, the AI interview has a Coding round type. It's a voice interview with a code editor in the room, so you hear the reasoning as well as see the code. The recruiter guide to running a coding test explains the difference between the two.

What candidates are telling hiring teams about take-homes

Candidates are clear, and it's worth listening. In that HN thread, several engineers say they've stopped doing take-homes, or won't do unpaid work for a hiring process. Others say the ones they remember fondly were reviewed together in the next interview, where the work turned into a real technical conversation.

Two warnings stood out. One engineer described a short take-home that ended in a rejection with no feedback at all, and when another candidate asked about a task that required assigning the code rights, the reply called it a red flag. One hiring manager in Europe described take-homes as routine and uncontroversial, which tells you expectations vary by market.

The common thread is respect for time. If you ask for hours, give a conversation back. If you can't promise that, use a shorter format.

Frequently asked questions

What is a take-home assessment?

A take-home assessment is a task a candidate completes on their own time and submits for review, usually a small coding project or exercise. It's meant to show how someone works without live pressure. Because AI assistants can now complete many short tasks, the follow-up discussion matters more than the submission itself.

How long should a take home coding assignment take?

Short. CodeSubmit, a take-home vendor, recommends 2 to 4 hours, and many candidates will skip anything much longer. A longer task doesn't stop an assistant from helping, it just costs honest candidates more time. Pay for anything that runs past an evening.

Should candidates be allowed to use ChatGPT or Copilot on a take-home?

We'd say yes, as long as you say so in writing and ask candidates to note where they used it. Developers use these tools on the job. Then grade the judgment in the walkthrough: what they kept, what they changed, and why.

Should you pay candidates for take-home assignments?

If the task runs longer than a couple of hours or looks like real product work, yes. One engineer on Hacker News said the best take-homes they'd done were paid tasks from the team's real backlog. Never ask for code rights on an unpaid interview task.

What happens in the technical interview after a take-home assignment?

The interviewer and candidate review the submitted code together. Expect questions about structure, what you tried first, how the code behaves if a constraint changes, and where it would fail. Many teams also ask for a small live change. This conversation is where most of the real assessment happens.

The bottom line on take-home assignments

A take-home still has a place, but the submission isn't the evidence anymore. Keep it small, late and honest about AI, and put your scoring effort into the walkthrough. If your take-home is the first screen, replace it with something that records how the code was made.

If you want an early-stage screen where the code really runs and integrity signals sit next to it for a human to read, see how Expert Hire coding tests work.

By TK, Growth at Expert Hire. Last updated October 13, 2026. Reviewed by Anand Suresh, CPO at Expert Hire.