How to verify a take-home assignment is the candidate's own work

Employers verify a take-home assignment by testing the person, not the file: a 20 to 30 minute walkthrough where the candidate explains their choices, answers "why not the alternative?" questions and makes a small change to the work live. Nothing in the submission itself proves authorship. Git lets anyone set a commit's author and date, document version history can be deleted, and AI text detectors are too unreliable to act on (OpenAI withdrew its own detector in July 2023 for low accuracy). The fair version tells candidates in the brief what help is allowed and that a walkthrough will follow.

This page covers authorship only. For grading the work itself, rubrics and pay, see how to evaluate a take-home assignment; for the email that sends the brief, see the take-home assignment email template.

Can you prove who wrote a take-home assignment?

Not from the artifact. A take-home is done unsupervised, on the candidate's own machine, over hours or days. Anyone could have helped: a friend, a paid service, an AI tool, a previous candidate's answer posted online. What you can establish is narrower and more useful: whether the candidate understands the work well enough to defend it, change it and extend it. That is also the thing you are hiring for. A candidate who used help but can reason about every line has shown you something real; a candidate who cannot explain their own submission has shown you something too.

So reframe the question your process answers. Not "did they write it?" but "can they do this work, as shown by this submission plus a conversation about it?"

What should you decide before you send the brief?

Most authorship disputes start with a brief that never said what was allowed. Settle these before the first candidate receives it, and give every candidate the same text.

1. What help is allowed. Documentation and search, almost always. Libraries and starter code, usually. AI assistants: allowed, allowed with disclosure, or not allowed. Another person: almost never.
2. What disclosure you want. "List any tools you used and what you used them for" is easy to follow and gives you something concrete to discuss.
3. That a walkthrough follows. Saying so up front is fair warning, and it deters outsourcing more than any detector does.
4. How accommodations work. Extra time is a common request. The EEOC's page on job applicants and the ADA explains that reasonable accommodation covers changes to the application process itself.

A paragraph you can paste into the brief:

HELP AND TOOLS
You may use documentation, search and open-source libraries.
AI assistants: [allowed / allowed if you tell us how you used them /
not allowed for this exercise].
Please do the work yourself; do not have another person write it.
At the end of your submission, list the tools you used and what for.

WHAT HAPPENS NEXT
If you move forward, we will spend 20-30 minutes with you going through
your submission: your choices, what you would change, and one small
change made together on the call. There is nothing extra to prepare.

How do you design an assignment that is easier to verify?

Some briefs are almost impossible to verify because any competent answer looks like any other. A few design choices give the walkthrough more to work with.

• Build in a judgment call. Leave one requirement deliberately open ("the data has duplicates; decide what to do") and ask the candidate to state their assumption. The reasoning behind a judgment call is hard to borrow.
• Ask for a short decision log. Five bullet points: what they tried first, what they dropped and why, what they would do with more time. It is cheap to write if you did the work.
• Use your own data or scenario. A sanitized internal problem is less likely to have a public answer than a classic exercise that has been posted many times.
• Rotate variants. Two or three versions of the brief with different datasets or constraints make a circulated answer less useful.
• Keep it short. A three-hour assignment is easier for a candidate to do honestly than a weekend project, and easier for you to discuss in depth.

How do you run the take-home walkthrough?

The walkthrough is the verification. Run it the same way for every candidate who reaches it, with the same interviewer or a calibrated pair, and score it against the same competencies as the assignment.

1. Open with the candidate's summary (3 minutes). "Talk me through what you built and the one decision you would defend hardest."
2. Go to the decisions (10 minutes). Pick two or three places where there was a real choice and ask why. Pick them in advance from the submission, not on the fly.
3. Ask about what is not there (5 minutes). "What did you try that did not work?" "What did you leave out on purpose?"
4. Make a change live (10 minutes). Add a requirement, change an input, or introduce a small bug and ask them to find it. Watching someone work in their own submission is the strongest evidence you will get.
5. Close with their questions. Then score immediately, before you compare notes with anyone.

Questions for code

• "Why this data structure here rather than the obvious alternative?"
• "What happens if this input is empty, or ten times larger?"
• "Walk me through this function line by line. What would you rename?"
• "Here is a new requirement. Where would you change the code, and what would break?"

Questions for writing, analysis and design work

• "Without the document in front of you, what is your recommendation and the main reason for it?"
• "Which number in your analysis, if it were wrong, would change your conclusion?"
• "Who disagrees with this recommendation, and what would you say to them?"
• "Show me the version you threw away. Why did you abandon it?"

For more probes that separate understanding from a rehearsed or generated answer, see interview questions that expose AI-assisted answers.

Which authorship checks are reliable, and which are not?

The checks people reach for first are mostly the weakest. This table ranks them by what they can actually establish; the tool documentation it cites was checked as of October 2026.

Why AI detectors are not evidence

OpenAI reported that its own classifier correctly identified 26% of AI-written text as "likely AI-written" and wrongly labeled human-written text as AI-written 9% of the time; it withdrew the classifier on July 20, 2023, citing its low rate of accuracy. A 2023 Stanford study, "GPT detectors are biased against non-native English writers", found that widely used detectors consistently misclassified non-native English writing samples as AI-generated, and that simple prompting strategies could bypass them. A screening step that falls harder on candidates by national origin is exactly what a disparate impact analysis looks at. If you run a detector at all, use the result only to choose which parts of the walkthrough to probe. For what commercial detection tools catch and miss in live interviews, see tools to detect AI use in interviews.

What should you do when the walkthrough does not match the submission?

Sometimes a polished submission meets a candidate who cannot explain it. Before you conclude anything, separate the possible explanations.

• Nerves. Some people freeze on camera. Signs: they recover when given a minute, or when asked to type rather than talk. Offer that minute.
• Allowed help, poorly understood. If your policy allowed AI tools, the problem is a skill gap, not dishonesty. Score the understanding you saw.
• Work they did not do. Signs: they cannot explain the decisions, describe an approach that differs from what they submitted, or cannot make even a small change.

Then act on what you observed, the same way for everyone:

1. Ask once, neutrally. "Some of this you explained clearly and some you did not. Can you tell me how you worked on this part?" Do not accuse.
2. Offer a short live exercise on the same skill if the evidence is mixed. Thirty minutes of live work settles most doubts in either direction.
3. Record observations, not conclusions. Write "could not explain the caching logic or change the retry limit when asked" rather than "cheated". A note like the first survives a later review; the second does not.
4. Decide on the competency. If they cannot do the work, they do not meet the bar, whatever the reason. You rarely need to prove misconduct to make a sound decision.

If you find a misrepresentation after an offer, the process in how to handle a candidate who lies in an interview applies, and how to rescind a job offer covers the steps if it comes to that.

Is using AI on a take-home assignment cheating?

Only if your brief said so. Many jobs now involve AI tools, and banning them from a take-home can test a way of working the role does not use. Three workable positions:

• Allowed with disclosure: you learn how the candidate uses the tools, and the walkthrough tests whether they understand the result.
• Not allowed for this exercise: reasonable when the skill itself (writing, core reasoning) is the thing being assessed. Expect to verify mainly through the walkthrough.
• Replace the take-home with live work: a paired session removes most of the authorship question, at the cost of more interviewer time.

Whatever you choose, write it into a team policy so every hiring manager answers the same way; candidates using AI in interviews: how to set a fair policy has text to adapt.

What about agency recruiters?

When the client sets the assignment, the client verifies it. The recruiter's job is to make sure the candidate knows the rules before starting: what help is allowed, that a walkthrough follows, and how long it should take. A candidate who learns about the walkthrough only after submitting has a fair complaint. If you sit in on the walkthrough call, Interview Signal can transcribe it from your own computer, without a bot joining, and its private answer check flags answers that read as AI-written or read out, with a follow-up question to try; the flag never changes a score and never appears in the client submittal.

A short checklist

• The brief states the help and AI policy, the disclosure you want, and that a walkthrough follows.
• The assignment includes at least one judgment call and asks for a short decision log.
• Every finalist gets the same walkthrough: decisions, what was left out, one live change.
• Detector scores, git history and version history are context, never evidence.
• Mismatches get one neutral question and, if needed, a short live exercise.
• Notes record what you observed, and the decision rests on the competency.

For the wider picture of deception in hiring, from proxies to stolen identities, see what is interview fraud.