July 24, 2026·3 min read
If your take-home is "build a small CRUD API with tests," a language model will produce a clean, passing submission in the time it takes the candidate to read the prompt. You are no longer measuring the candidate. You are measuring the model, and every candidate has the same model.
The reflex is to ban AI and try to catch violators. That fight is unwinnable and, worse, it tests the wrong thing. The job now includes using AI well. The better move is to redesign the take-home so that AI is allowed, expected, and useless as a way to fake the outcome.
AI-detection tools are unreliable, and enforcement turns your assessment into a policing exercise the candidate resents. We wrote about the deeper version of this problem in is using AI in technical interviews acceptable, and the short answer holds here: pretending AI does not exist makes your assessment less like the job, not more.
The real issue is not that candidates use AI. It is that a from-scratch build task has a single Googleable, generatable answer. Change the task so there is no such answer, and the AI question mostly dissolves.
A take-home survives AI when the valuable output is judgment, not code. Some shapes that hold up:
The common thread: the answer is not a file, it is a set of decisions the candidate has to stand behind.
The single most effective anti-fake mechanism is a short live session after the take-home. Fifteen minutes, same environment, and you ask them to extend or change their own submission on the spot.
Someone who did the work navigates their own code instantly. Someone who pasted a generated solution stalls, because they never built the mental model. You are not accusing anyone. You are just asking them to keep working, and the take-home becomes a foundation for a real conversation instead of a document you have to trust.
This also makes the take-home fairer. A strong candidate who used AI heavily but understands every decision sails through the follow-up. That is the correct outcome. You wanted to hire that person.
Score the judgment layer, not the syntax:
A submission that is technically perfect but cannot survive two follow-up questions is a fail. A rougher submission whose author clearly owns every line is a pass.
A take-home you cannot observe is a take-home you have to trust. EasyEnv runs the challenge in a real environment and records the session, and the live follow-up happens in that same environment. You see whether the candidate moves through their own code like an author or a tourist. AI use stops being a thing to detect and becomes a thing you can watch them do well or badly, which is the actual signal you wanted.
You cannot out-detect AI, and you should not try. Design take-homes where the answer is judgment, require the candidate to defend their decisions, and close with a live follow-up in the same environment.
Let them use every tool they want. Then ask them to keep going, and see who actually understands what they submitted.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Calm under fire is the SRE trait you can't ask about and can't fake. Run a short simulated outage in a real environment and watch how a candidate triages. Here is how to set it up and what to score.
Asking a platform engineer to explain a pod tells you almost nothing. Give them a live, broken cluster and watch what they do. Here are the tasks that separate real operators from people who memorized the docs.
Read more
Most interviews test whether a candidate can write code from scratch. Real engineering is mostly reading, diagnosing, and fixing code you did not write. Here is how to interview for that.
Read more
