Test Type AI-assisted programming
The candidate codes with an AI assistant — the same one for everyone, inside the assessment environment. You measure what now sets a good software engineer apart: direction, verification and judgment.




Our ecosystem of deep integrations makes it easy to streamline your hiring processes.










It is a technical assessment in which the use of AI assistants is allowed and declared, instead of forbidden and hidden. It exists because the work has changed: most engineering teams already code with Copilot, Claude or Cursor in the editor, and a test that bans AI measures working conditions that no longer exist in the role. The right question is no longer "can this person code without help?" but "does this person deliver more and better with the tools the team uses?". On Coodesh, the company decides per assessment which rule applies, states it in the prompt, and designs the questions to measure what matters under each rule.
Three design decisions. First, an explicit rule: the prompt states that AI assistants are allowed, which removes the advantage of anyone who would cheat and levels the conditions for everyone. Second, the right problem: with AI allowed, classic algorithm exercises lose their point, because AI solves them in seconds; the prompt becomes a problem with context, ambiguity and constraints, where the value lies in the decisions, not the typing. Third, a defense step: in the same assessment, a video question or a conversational AI interview asks the candidate to explain their choices, point out the code's limitations and say what they would change in production. The deliverable shows the result; the defense shows who was driving the tool.
The skills that remain as a human differentiator, and that today separate a good hire from a bad one: breaking down the problem before prompting, critically evaluating what the AI returned, spotting the subtle mistake the AI made with confidence, integrating the parts into a coherent whole and explaining trade-offs. The question's evaluation criteria are written for exactly that: quality and fit of the final solution, handling of edge cases, and consistency between what was delivered and what the candidate can justify. Flawless code the author cannot explain is worth less than good code defended clearly, and the assessment is built to reveal that difference.
It can be made visible, which is what supports a decision. If the assessment rule is no assistants, the integrity features log what gives usage away: leaving the tab and window focus loss, pasting without a prior copy in the same question, text inserted without going through the clipboard (the insert button of assistants and extensions), a second screen and developer tools. The reviewer sees each event on the timeline, with the pasted content, and the browsing recording shows the process. Our recommendation is to use the restricted rule only when the role justifies it, and to tell the candidate why; a ban without purpose only increases drop-off.
Yes, and it is the design most often seen in mature processes. A section with AI allowed, with a realistic problem, measures the assisted productivity the role will demand; a short section without AI, covering fundamentals, confirms the foundation behind that productivity; and a video defense or AI interview completes the set. Each section has its own weight in the final score, so the company decides what matters most for that position. The candidate goes through both conditions knowing the rule for each, which is fairer than a single rule that favors only one profile.
Quite the opposite: for the generation that already works this way, it is the test that bans AI that feels outdated, while one that allows it signals how the company really works. What matters is clarity: the rule stated in the invitation and in the prompt, what will be assessed, and a heads-up that there will be a conversation about the solution. The assessment becomes an honest sample of the job, which improves completion rates and the quality of self-selection, because those who do not want to work with AI find out early that the role is not for them, and those who master the tool get a place to show it.
Pick an open technical role and build the assessment in three blocks: a free-form coding question with a contextualized problem and the AI rule stated in the prompt, a video question or conversational AI interview asking the candidate to defend the solution, and, if the role justifies it, a short fundamentals block with integrity enabled. Define review criteria with judgment in mind, not syntax, and use Try it yourself before sending. Results arrive with the deliverable, the recordings and the scored criteria for your review, and the comparison with your previous process usually becomes clear within one or two roles.