Take-Home Anti-Cheating in the LLM Era

The issue is not AI use. It is false signal

Employers are not only worried that candidates use LLMs. Many engineers use AI tools every day at work, and most hiring teams know it. The deeper concern is false signal: a polished submission that does not represent the candidate's ability to understand, modify, debug or defend the work. A take-home exists to predict how you will perform on the job. If the artefact is strong but the person behind it cannot reason about it, the prediction is broken, and that is what a good interviewer is trying to protect against.

It helps to separate three things that often get blurred together. There is the policy question, which is simply whether AI was allowed and whether you followed the rule. There is the authorship question, which is whether the code reflects decisions you can stand behind. And there is the competence question, which is whether you can actually do the work the submission claims you can. A candidate can pass the policy check and still fail badly on authorship and competence. That is the failure mode hiring teams have started designing around.

That is why take-home reviews are changing. Companies increasingly pair submissions with live walkthroughs, change requests, codebase modifications and policy questions. Public signals include Built In's AI job-interview cheating debate, Wired reporting on AI-assisted interview pilots, CodeSignal's AI-assisted assessments, and Hacker News discussion of take-home follow-up modifications.

The take-home is no longer the assessment. It is the prompt for the assessment. The real test is the conversation that follows.

How employers detect weak or dishonest submissions

Employers do not need perfect AI detection tools, and the serious ones have largely stopped relying on them. Instead of trying to prove how the code was produced, they test whether you own it. Ownership is far cheaper to verify than provenance, and it maps directly to the thing they actually care about.

Common signals that something is off:

• The candidate cannot explain library choices, or names a dependency they clearly have not used before.
• The code contains patterns unrelated to the assignment scope, as if lifted from a different problem.
• There are impressive abstractions but missing basic requirements.
• Tests pass superficially but do not cover core behaviour or any failure path.
• The candidate cannot make a small live change without breaking unrelated parts.
• The README is polished but setup fails on a clean machine.
• The project uses APIs or syntax the candidate cannot discuss in plain language.
• Commit history shows one giant drop with no decision trail.

The table below is roughly how an experienced reviewer reads each of these. None of them is proof on its own. The judgement comes from the pattern.

Automated AI detectors are unreliable for serious hiring decisions, and most teams treat a detector score as noise rather than evidence. Ownership interviews are far more useful. A reviewer can ask, "Why did you choose this state model?" or "Change the validation rule now." If the candidate did not understand the work, the signal collapses within a minute or two, regardless of how the code was originally produced. This is the key point for candidates: you cannot pass the follow-up by guessing how the detector works. You pass it by genuinely understanding what you submitted.

What this looks like by seniority

The same submission is read differently depending on the level you are interviewing for, and aligning your work to the expectation matters as much as the code itself.

• Junior and early-career. Reviewers expect honest, correct, readable code. They are forgiving about missing scale considerations or advanced patterns. The fastest way to fail here is to over-engineer, because a junior who ships a sprawling generated architecture they cannot explain looks worse than one who ships a small thing they clearly built. Aim for "I understand every line."
• Mid-level. Reviewers expect sound judgement about scope and tradeoffs. They will probe why you left something out and whether you knew you were leaving it out. A clean log of decisions matters more than raw output.
• Senior and staff. Reviewers expect you to treat the take-home as a design problem. They will ask about failure modes, operability, and how the design holds up under change. At this level, AI-assisted output that you cannot defend is a serious red flag, because the role is precisely about judgement that survives scrutiny.

How it differs by role

• Backend and platform. Expect change requests around data integrity, error handling, idempotency and concurrency. The follow-up often involves adding a constraint and watching how you reason about consistency. See the kinds of probes in the backend engineer interview questions.
• Frontend. Expect questions about state management, accessibility and edge-case rendering. A common live task is handling an empty or error state the original submission ignored.
• AI and ML engineering. Expect scrutiny of evaluation, not just the model call. Reviewers often ask how you would measure quality, handle a bad response, or bound cost. Ironically, AI-engineering interviews tend to be the most relaxed about using AI to build, and the most demanding about whether you understand its failure modes.

Do honest AI-assisted work

If AI is allowed, the goal is not to use it less. It is to use it in ways you can defend afterwards. The dividing line is simple: did the tool accelerate work you understand, or did it produce work you do not understand and then handed off as your own?

Defensible uses:

• Ask for edge cases, then decide which ones matter and why.
• Generate test ideas, then keep the ones that actually exercise behaviour.
• Explain unfamiliar docs, then verify the claim against the real API.
• Scaffold boilerplate that you would have written the same way by hand.
• Review the README for clarity once you have written the substance.
• Compare two implementation approaches, then make the call yourself.

Indefensible uses, the ones that blow up in the follow-up:

• Generating an architecture you could not have designed and cannot now explain.
• Accepting code that uses an API you have never read.
• Letting the tool make scope decisions for you so the project balloons past what you can defend.
• Pasting in tests that assert behaviour you do not understand.

Keep a short work log. It is not a confession of every keystroke. It is a record that lets you answer policy and ownership questions calmly.

## Work log

- Read the assignment and wrote down my assumptions.
- Sketched the data model and chose a single-table design for simplicity.
- Used an AI assistant to brainstorm edge cases for validation, kept three.
- Implemented the parser and its tests by hand.
- Used AI to review README clarity after writing it myself.
- Ran the suite, found a setup gap, fixed the install step.

This log does two jobs at once. It keeps you honest with yourself about what you actually did, and it gives you a script for the conversation. When the interviewer asks "what did AI help with," you have a precise, unembarrassed answer ready instead of a vague one.

Make the submission easy to challenge

This sounds backwards, but a good take-home should be easy to review and modify. If you hide behind complexity, the follow-up will hurt, because every layer you cannot explain is a question you cannot answer. Simplicity is not a weakness in a take-home. It is the property that lets you survive the live change request.

Use:

• Small functions with a single clear job.
• Domain names that match how the assignment talks about the problem.
• Focused tests that document behaviour.
• A README that states tradeoffs and what you deliberately left out.
• Minimal dependencies you can each justify.
• A setup that runs in one or two commands.

Avoid:

• Frameworks you do not know well enough to debug under pressure.
• Generated architecture you cannot explain line by line.
• Clever abstractions introduced before there were two real use cases.
• Unused files and dead code that invite questions you cannot answer.
• Fake production polish, such as elaborate config you never exercise.

Here is a small, reviewable function. It is deliberately unimpressive, which is the point.

export type Priority = "low" | "medium" | "high";

export function classifyPriority(hoursUntilDeadline: number): Priority {
  if (hoursUntilDeadline <= 4) {
    return "high";
  }

  if (hoursUntilDeadline <= 24) {
    return "medium";
  }

  return "low";
}

And tests that document the boundaries rather than just the happy path:

import { describe, expect, it } from "vitest";
import { classifyPriority } from "./classify-priority";

describe("classifyPriority", () => {
  it("classifies urgent deadlines as high priority", () => {
    expect(classifyPriority(4)).toBe("high");
  });

  it("classifies same-day deadlines as medium priority", () => {
    expect(classifyPriority(12)).toBe("medium");
  });

  it("classifies later deadlines as low priority", () => {
    expect(classifyPriority(72)).toBe("low");
  });

  it("treats negative hours as already overdue and high", () => {
    expect(classifyPriority(-3)).toBe("high");
  });
});

This is not impressive by itself. It is reviewable, testable and easy to change, which is often exactly what the interviewer needs in order to give you a fair signal. When they say "make overdue items their own category," you know precisely where the rule lives and you can change it in front of them without flinching.

A worked example: the live change request

Here is how the follow-up actually plays out, so you can rehearse the shape of it. Imagine a reviewer has your task-priority project open and starts the screen share.

Reviewer: Walk me through where the core rule lives.

Candidate: It is in classifyPriority. Everything upstream computes hoursUntilDeadline, then this one function maps it to a band. I kept the policy in a single place so it is easy to change.

Reviewer: Good. Add a fourth band: anything overdue should be "critical," separate from "high." Do it now.

Candidate: Sure. I will add the type, add the branch at the top so it takes precedence, then add a test for the boundary.

A confident candidate makes this change live in under two minutes:

export type Priority = "critical" | "low" | "medium" | "high";

export function classifyPriority(hoursUntilDeadline: number): Priority {
  if (hoursUntilDeadline < 0) {
    return "critical";
  }

  if (hoursUntilDeadline <= 4) {
    return "high";
  }

  if (hoursUntilDeadline <= 24) {
    return "medium";
  }

  return "low";
}

Then they add the test, run the suite, and narrate the tradeoff: ordering the overdue check first so it cannot be masked by the four-hour branch. The whole exchange takes a few minutes and tells the reviewer everything they need.

Now contrast the weak version. A candidate who outsourced the design opens the project, hunts for the rule across several files, edits the wrong layer, breaks a test they did not know existed, and cannot explain why the overdue check needs to come first. The code may have been excellent. The signal is now negative, because the role is about changing systems under pressure, and that is exactly what just failed in front of the reviewer.

Prepare for the ownership interview

Before the follow-up, be ready to answer the questions an interviewer almost always reaches for:

• What was the hardest tradeoff, and what did you give up?
• What did you intentionally leave out, and why was that the right call for the time box?
• Where would this fail in production?
• How would you change it for ten times the traffic?
• Which part would you refactor first, and what is the risk of leaving it?
• What did AI help with, if anything?
• Show me where the core business rule lives.
• Add one new validation rule, right now.

Do a twenty-minute rehearsal a day or two before. Open the project cold, run the tests, explain the architecture out loud as if someone is listening, and make one small change you did not plan. If any part of that makes you hesitate, that hesitation will be ten times worse on the call. The fix is not more polish. It is to simplify the project until you understand all of it, or to study your own code until you do.

A useful drill is to write the three sentences you would say about the project before anyone asks. One sentence on what it does, one on the main tradeoff, one on what you would do next. If you cannot write those three sentences cleanly, the work is not yet yours.

If AI is banned

If the company bans AI for the assignment, follow the policy exactly. You can still use normal references when they are allowed: official language documentation, framework docs and package docs. If the rule is ambiguous about whether docs or search are permitted, ask. A short clarifying email reads as professional, not as weakness.

Do not use AI secretly and hope detection fails. The risk is not only being caught by a detector, which is the smaller risk. It is being unable to defend the work in the follow-up, where the gap shows immediately and no detector is involved. The professional downside, including a withdrawn offer or a burned reference, is far larger than the short-term benefit of a slightly shinier submission.

If the assignment is genuinely too large to finish honestly within the stated time box, say so rather than overproducing:

I can complete this within the stated time box without AI, but I will need to keep scope focused. I will document the tradeoffs and what I would add with more time.

That message is a better signal than a sprawling submission, because it shows judgement about scope, which is most of senior engineering. Reviewers respect a focused, honest deliverable with a clear note on what was deferred far more than an over-built one with broken setup.

Common mistakes to avoid

• Over-engineering to look senior. A large generated architecture you cannot defend is worse than a small one you built. Match the complexity to the brief.
• Polishing the README before the code is real. A glossy README over broken setup is the single most common tell.
• One giant commit. Even if you work in one sitting, commit in stages. The decision trail is part of the signal.
• Ignoring failure paths. Tests that only cover the happy path read as incomplete at every level above junior.
• Bluffing in the follow-up. If you do not know, say so and reason out loud. Reviewers forgive gaps far more readily than confident nonsense.
• Hiding AI use that was allowed. If the policy permitted it, being cagey about it looks worse than the use itself.

FAQ

Will using AI get my take-home rejected? Not if it was allowed and you can defend the result. The rejection risk comes from breaking a stated policy or from submitting work you cannot explain, not from the tool itself.

Should I volunteer that I used AI? If it was allowed, yes, briefly and specifically. A one-line note in the README and a clear answer in the interview reads as mature. Concealment of permitted use is the worse look.

Do AI detectors actually work on code? Not reliably enough for a hiring decision, and most serious teams know it. They test ownership through live change requests instead, which is why your understanding matters more than any detector.

What if I genuinely cannot finish in the time box? Submit a focused, working subset and document what you deferred and why. A smaller honest deliverable with a clear scope note beats an over-built one that breaks on setup.

Is a take-home even worth doing given the cost in hours? That is a fair personal calculation, and you can negotiate the format. But if you do it, treat the follow-up conversation as the real assessment and prepare for that, not just the artefact.

Continue your prep

Take-home integrity is part of broader interview readiness:

• Backend engineer interview questions
• Backend engineer salary guide
• Backend engineer resume template