Practical hiring exercises should allow AI

A hiring exercise should not require candidates to pretend they work in a tool-free world.

If the job allows AI for code understanding, implementation, tests, or documentation, banning it in the assessment measures compliance with an artificial environment. Secret use then becomes an integrity problem, and honest candidates are penalized for following a rule that may not predict performance.

HackerRank's 2025 Developer Skills Report found that two thirds of developers preferred practical challenges, while large majorities said assessments did not reflect real work and AI made gaming easier. The answer is not surveillance theater. It is an exercise that makes AI use explicit and moves the signal toward judgment.

I would allow AI, require a short disclosure, provide the same baseline access, and spend the interview discussing decisions, defects, tests, and next steps.

The artifact is the beginning of the assessment. The review conversation is where authorship becomes legible.

Match the real job

The exercise should simulate a bounded version of the decisions the role will actually make.

I would pressure-test that decision with four questions:

• Which task repeats on the team?
• Which constraints matter?
• Which tools are normal?
• What would success look like at work?

The failure mode here is choosing a familiar puzzle because it is easy to grade. In technical hiring exercises where candidates will use AI tools on the job, assessment integrity matters, and teams need to evaluate problem framing, implementation judgment, verification, and communication, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a role-to-exercise mapping. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is an assessment with stronger job relevance. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a role-to-exercise mapping beside the question “Which task repeats on the team?” before the first implementation review. The next pass would use “Which constraints matter?” to test the boundary, then “Which tools are normal?” to expose the state most likely to be missed. I would keep “What would success look like at work?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports an assessment with stronger job relevance.

State AI policy plainly

Candidates need the same clear rules about allowed tools, data, attribution, and disclosure.

The practical review starts here:

• Which tools are allowed?
• What data must stay private?
• What disclosure is useful?
• Will access be provided?

Those questions keep using vague language that rewards candidates willing to guess from becoming the default. I would capture the decision in a short AI use policy inside the brief, then use it while the work is still cheap to change. For skills-first technical assessment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like more consistent and transparent participation. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a short AI use policy inside the brief part of the working surface. I would use it to answer “Which tools are allowed?” while scope is still flexible, and “What data must stay private?” before code or content becomes expensive to unwind. During QA, “What disclosure is useful?” and “Will access be provided?” become concrete checks rather than discussion prompts. That sequence turns skills-first technical assessment into something the team can operate and gives me a specific outcome to report: more consistent and transparent participation.

Provide equitable access

An AI-permitted exercise should not depend on who can afford the most capable subscription.

Before implementation, I would answer:

• Is a baseline tool provided?
• Can candidates opt out?
• Does the task require premium features?
• What accessibility needs exist?

The artifact is a tool access and accommodation plan. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is allowing AI without addressing unequal tooling; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is a fairer comparison of judgment rather than purchasing power. That connects an AI-permitted work sample as a transparent simulation of modern engineering practice to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Is a baseline tool provided?” easy to answer. The boundary should force a decision about “Can candidates opt out?” and “Does the task require premium features?.” I would record both in a tool access and accommodation plan, including the part that stayed unresolved after the first pass. The final check, “What accessibility needs exist?,” is where the artifact earns its place: it either supports a fairer comparison of judgment rather than purchasing power, or it shows exactly why another iteration is needed.

Timebox the right work

The task should be small enough that candidates can frame, implement, test, and explain within the stated time.

I would use these prompts during the working review:

• What is the minimum useful slice?
• Which polish is optional?
• How long should setup take?
• Can stopping well earn credit?

If the team slips into creating a take-home that expands with every available AI capability, the product can still look complete while its operating rule stays ambiguous. I would make a scoped starter repository and explicit stop point the shared reference and keep it small enough to update as evidence changes.

The standard is respect for candidate time and better prioritization evidence. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a scoped starter repository and explicit stop point, review it against “What is the minimum useful slice?,” implement the narrowest useful path, and then return with evidence for “Which polish is optional?.” I would use “How long should setup take?” to inspect product consequence and “Can stopping well earn credit?” to decide whether the result is stable enough to ship. This keeps creating a take-home that expands with every available AI capability visible as a known risk and makes respect for candidate time and better prioritization evidence the release receipt rather than a hopeful conclusion.

Ask for a verification receipt

A concise record of assumptions, commands, tests, and gaps makes tool use easier to discuss.

I would pressure-test that decision with four questions:

• What did the candidate verify?
• What failed first?
• Which assumption remains?
• What would they check in production?

The failure mode here is grading only the final repository state. In technical hiring exercises where candidates will use AI tools on the job, assessment integrity matters, and teams need to evaluate problem framing, implementation judgment, verification, and communication, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a one-page assessment receipt. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is a more legible path from work to confidence. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a one-page assessment receipt beside the question “What did the candidate verify?” before the first implementation review. The next pass would use “What failed first?” to test the boundary, then “Which assumption remains?” to expose the state most likely to be missed. I would keep “What would they check in production?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports a more legible path from work to confidence.

Grade judgment separately

The rubric should distinguish product framing, implementation, verification, communication, and responsible tool use.

The practical review starts here:

• Was scope appropriate?
• Did the candidate catch generated defects?
• Were tradeoffs explicit?
• Could they change course?

Those questions keep using one overall score that hides why reviewers disagree from becoming the default. I would capture the decision in a behavior-anchored rubric, then use it while the work is still cheap to change. For skills-first technical assessment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like more specific and defensible hiring evidence. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a behavior-anchored rubric part of the working surface. I would use it to answer “Was scope appropriate?” while scope is still flexible, and “Did the candidate catch generated defects?” before code or content becomes expensive to unwind. During QA, “Were tradeoffs explicit?” and “Could they change course?” become concrete checks rather than discussion prompts. That sequence turns skills-first technical assessment into something the team can operate and gives me a specific outcome to report: more specific and defensible hiring evidence.

Use review as the authorship check

A live review reveals understanding more usefully than invasive monitoring or prompt surveillance.

Before implementation, I would answer:

• Can they explain the data path?
• Can they find a weak assumption?
• Can they implement feedback?
• Can they name risk?

The artifact is a structured review conversation with one small change. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is trying to prove every keystroke was unaided; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is evidence that the candidate can own and evolve the work. That connects an AI-permitted work sample as a transparent simulation of modern engineering practice to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Can they explain the data path?” easy to answer. The boundary should force a decision about “Can they find a weak assumption?” and “Can they implement feedback?.” I would record both in a structured review conversation with one small change, including the part that stayed unresolved after the first pass. The final check, “Can they name risk?,” is where the artifact earns its place: it either supports evidence that the candidate can own and evolve the work, or it shows exactly why another iteration is needed.

Include a seeded imperfection

A realistic starter defect lets candidates show diagnosis, skepticism, and prioritization.

I would use these prompts during the working review:

• Is the flaw job-relevant?
• Can it be discovered fairly?
• Does it have user consequence?
• Can different fixes be valid?

If the team slips into hiding a trick with one secret correct answer, the product can still look complete while its operating rule stays ambiguous. I would make a documented evaluator-only defect and expected signals the shared reference and keep it small enough to update as evidence changes.

The standard is a richer view of debugging and judgment. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a documented evaluator-only defect and expected signals, review it against “Is the flaw job-relevant?,” implement the narrowest useful path, and then return with evidence for “Can it be discovered fairly?.” I would use “Does it have user consequence?” to inspect product consequence and “Can different fixes be valid?” to decide whether the result is stable enough to ship. This keeps hiding a trick with one secret correct answer visible as a known risk and makes a richer view of debugging and judgment the release receipt rather than a hopeful conclusion.

Train interviewers on AI evidence

Reviewers need calibration so fluent explanation is not confused with good engineering and unfamiliar tools are not penalized.

I would pressure-test that decision with four questions:

• What behaviors earn credit?
• Which AI use is neutral?
• What evidence shows skepticism?
• How are disagreements resolved?

The failure mode here is introducing AI policy without changing interviewer habits. In technical hiring exercises where candidates will use AI tools on the job, assessment integrity matters, and teams need to evaluate problem framing, implementation judgment, verification, and communication, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a reviewer calibration pack with sample submissions. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is more consistent assessment across candidates. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a reviewer calibration pack with sample submissions beside the question “What behaviors earn credit?” before the first implementation review. The next pass would use “Which AI use is neutral?” to test the boundary, then “What evidence shows skepticism?” to expose the state most likely to be missed. I would keep “How are disagreements resolved?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports more consistent assessment across candidates.

Close the loop with candidate experience

The hiring team should measure whether the exercise felt relevant, clear, respectful, and accessible.

The practical review starts here:

• Did the task resemble the role?
• Were rules clear?
• Was the timebox honest?
• Did candidates receive closure?

Those questions keep treating candidate effort as free research data from becoming the default. I would capture the decision in a short post-assessment feedback survey, then use it while the work is still cheap to change. For skills-first technical assessment, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like a hiring process that improves its signal and trust. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a short post-assessment feedback survey part of the working surface. I would use it to answer “Did the task resemble the role?” while scope is still flexible, and “Were rules clear?” before code or content becomes expensive to unwind. During QA, “Was the timebox honest?” and “Did candidates receive closure?” become concrete checks rather than discussion prompts. That sequence turns skills-first technical assessment into something the team can operate and gives me a specific outcome to report: a hiring process that improves its signal and trust.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a role-to-exercise mapping
• a short AI use policy inside the brief
• a tool access and accommodation plan
• a scoped starter repository and explicit stop point
• a one-page assessment receipt

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because an AI-permitted work sample as a transparent simulation of modern engineering practice becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# allowed
docs search AI editor
Use any assistant; do not share private data; disclose material generated help.
# deliver
small change plus receipt
Code, assumptions, tests run, known gaps, and one decision you would revisit.
# review
thirty-minute pairing
Inspect one edge case, one AI suggestion rejected, and one improvement made live.

Resource path

The practical follow-up I would build is an AI-permitted assessment brief with task, allowed tools, timebox, starter context, evaluation rubric, disclosure prompt, review conversation, accessibility, data handling, and candidate feedback. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• Which task repeats on the team?
• Which tools are allowed?
• Is a baseline tool provided?
• What is the minimum useful slice?
• What did the candidate verify?
• Was scope appropriate?
• Can they explain the data path?
• Is the flaw job-relevant?
• What behaviors earn credit?
• Did the task resemble the role?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For skills-first technical assessment, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• more specific and defensible hiring evidence
• evidence that the candidate can own and evolve the work
• a richer view of debugging and judgment
• more consistent assessment across candidates
• a hiring process that improves its signal and trust

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• An AI-permitted assessment evaluates the complete work loop.
• The hiring signal shifts from memorization to operating judgment.
• A fair rubric separates outcome from process evidence.
• The assessment brief should make tool use and evidence explicit.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to technical hiring exercises where candidates will use AI tools on the job, assessment integrity matters, and teams need to evaluate problem framing, implementation judgment, verification, and communication: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through an AI-permitted work sample as a transparent simulation of modern engineering practice. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

An AI-permitted work sample creates a better hiring signal because it evaluates how a candidate uses available tools, checks their output, explains tradeoffs, and responds to review—the work the team actually needs.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.