Take-Home Coding Assignments and AI: The 2026 Rules

A take-home coding assignment is unproctored work you complete on your own machine, on your own time, and submit as an artifact. That format has not survived contact with capable coding models intact. It has split into two designs that look identical in your inbox and grade almost nothing in common: one that forbids AI and treats your submission as evidence of unaided skill, and one that expects AI and has moved the real evaluation somewhere the artifact cannot reach. Reading the brief carefully enough to tell which one you were sent is the single highest-value thing you can do before you write a line of code.

This article is about asynchronous, unproctored assignments. If your AI use is happening inside a live, supervised session with a tool the employer provided, the rules are different and what an AI-assisted coding interview actually grades covers that case instead.

The format is still common, and the rule against AI is mostly unenforced

Take-homes have not been abandoned. Karat's engineering interview trends report, published January 7, 2026 from a survey of 400 engineering leaders across the United States, India, and China, puts take-home projects in use at 45% of US organizations, against 20% in China. The same report finds 71% of leaders saying AI has made technical skills harder to assess, and 62% of organizations still prohibiting AI use in interviews. Karat also reports that leaders estimate more than half of candidates use AI despite being instructed not to.

Those two numbers together describe the actual state of the format. A clear majority of employers write a rule against AI. A clear majority of employers believe the rule is being broken. Neither side is operating on good information.

Hiring managers say this openly. Kitty Giraudel, a Berlin-based frontend engineer writing as a hiring manager on May 8, 2026, argued that take-homes are "generally unhelpful" for most engineering roles and that with AI coding agents widespread "they're not actually great at judging code — unless you actively forbid using AI but a) good luck enforcing that" (On Take-Home Coding Assignments). Giraudel's stated remedy is not better detection. It is using the assignment "in a subsequent in-person interview as a conversation starter."

That remedy is the pattern worth planning around, because it is spreading faster than any detection tool.

Design one: AI is prohibited

Read the brief for an explicit instruction. Phrases like "please complete this without AI assistance," "we want to see your own work," or "do not use code generation tools" are the rule, and their unenforceability does not make them optional. If you break a stated rule and it surfaces later — in the walkthrough, in a reference conversation, in your own first weeks on the job — the finding is not a code-quality finding. It is a finding about whether you follow instructions you disagree with, which is a much harder thing to recover from. Our guide to verifying AI rules before a technical interview covers how to get the rule in writing when the brief is vague.

If the brief is genuinely silent, ask. A one-line email — "Is AI assistance permitted on this assignment?" — costs you nothing, and the answer is useful either way. Employers who intended a prohibition will say so. Employers who never thought about it will usually tell you to use whatever you would use at work, and you now have that in writing. Silence in a brief is ambiguity, not permission, and resolving it in your favor without asking is a decision you will have to defend later.

A prohibition also tells you what the assignment is really measuring, which is rarely the code. Under a no-AI rule the submission is a proxy for unaided fluency: can you structure a small system, name things sensibly, handle the obvious edge cases, and stop at a reasonable scope. Scope discipline is scored more heavily than most candidates expect. A restrained, well-tested submission that does exactly what the brief asked usually beats an expansive one.

Design two: AI is permitted, and the problem got harder on purpose

The more interesting design is the assignment that explicitly allows AI. Anthropic's engineering team published a description of one on January 21, 2026, covering how they build performance-engineering evaluations that stay informative as models improve. The post states that on their take-home "candidates can use AI tools (as they would on the job) while still needing to demonstrate their own skills," and frames the underlying design problem directly: "A take-home that distinguishes well between human skill levels today may be trivially solved by models tomorrow" (AI-resistant technical evaluations). Their response, across three iterations of the exercise, was to move toward deliberately unusual constraint-based problems — the kind that sit outside the distribution a model has seen a thousand variations of — and to weight judgment about where to invest effort over raw solution speed.

That is the tell. When an employer permits AI on a take-home, they have almost always changed the problem to compensate. Expect one or more of these:

• A problem with an artificial constraint that makes the standard library answer inapplicable.
• A codebase you must understand and modify rather than a greenfield build.
• An explicit ask for your reasoning, tradeoffs, or rejected approaches alongside the code.
• A stated expectation that you will discuss the submission live afterward.

Under this design, producing working code is table stakes and carries very little signal on its own. The differentiator is everything around it: whether you noticed the constraint the model glossed over, whether you verified the output instead of trusting it, whether you can say why the approach you shipped beat the one you discarded. Treating a permitted-AI take-home as a speed run to a passing test suite is the most common way to fail one.

What the follow-up conversation actually tests

The walkthrough round is where the assignment now gets graded, and it is worth understanding on its own terms. Writing for Built In on September 29, 2025, Art Hu argued that "live coding exercises and in-depth code walkthroughs" are what reveal whether a candidate demonstrates sound thinking rather than merely augmented output (How to Reshape the Developer Hiring Process for the AI Era).

In practice the interviewer is checking for ownership, and the questions that check for it are not hard to anticipate:

• Why this data structure and not the obvious alternative?
• What happens to this function if the input is empty, enormous, or malformed?
• You wrote a test for this case and not that one. Why?
• If we needed this to handle ten times the load, what breaks first?
• Walk me through this block line by line.

Every one of those questions is answerable if you read and understood your own submission before sending it, and none of them are answerable from memory of a prompt. This is the honest reason not to submit code you have not fully read, independent of any rule: the format has moved the scoring to a conversation where unread code is exposed within minutes.

The walkthrough is also usually a live screen-share session, which brings its own set of things worth knowing in advance about capture scope and what is visible to the other side — see what interviewers can actually see when you share your screen. If something in your submission does get questioned as an integrity concern rather than a technical one, what happens when a coding assessment flags you describes how those reviews typically proceed.

A short pre-submission checklist

Before you send an assignment, in either design:

1. Confirm the AI rule in writing, or ask.
2. Read every line you are about to submit and be able to justify it out loud.
3. Delete what the brief did not ask for. Unrequested scope reads as poor judgment, not enthusiasm.
4. Write a short README covering your approach, your tradeoffs, and what you would do with more time. Under a permitted-AI design this is often the highest-signal file in the repository.
5. If AI was permitted and you used it, say so plainly in the README. Disclosure is cheap when it was allowed, and it removes the question before it is asked.
6. Check the commit history you are handing over. A single squashed commit dropped at 2 a.m. invites a question you would rather not field.

When a take-home is a bad deal

Not every assignment deserves your weekend. Giraudel's objection that "being able to spend several hours on unpaid work is a privilege not everyone has" is a real constraint, not a complaint. A twelve-hour unpaid assignment at the first-round stage, a brief that reads like unshipped production work, or an employer who will not tell you the AI rule or the evaluation criteria are all reasonable grounds to negotiate the scope, ask for a live session instead, or decline. Candidates who ask for a time-boxed version of a sprawling assignment are, in the experience of most hiring managers writing publicly about this, more likely to get one than to be penalized for asking.

What to do with this

Sort the assignment before you start. If AI is prohibited, treat the prohibition as binding, keep the scope tight, and let the submission be a clean sample of your own work. If AI is permitted, assume the problem has been hardened against exactly the approach you were about to take, spend your saved time on verification and on the written reasoning, and disclose what you used. In both cases, plan for a live conversation about the code, because that conversation is now where the decision is actually made.

That conversation is a live technical interview, and it is the part of the process where preparation is genuinely the only thing that helps — no assistant can supply an explanation for a design decision you did not make. If you are trying to understand where live tools do and do not fit across the rest of a modern interview loop, our guide to AI interview assistants in screen-share workflows sets out the categories and their limits.