How to Detect AI Cheating in a QA Engineer Take-Home Assignment

A QA engineer take-home assignment shows AI-cheating signals when the submitted test plan or automation script is generic boilerplate that never touches the specific bug deliberately seeded into the sample application, arrives as a single massive commit with no iterative test-run history, and the candidate's write-up reads like AI explanation text rather than a tester's working notes.

Threat Model, Tells, and Evidence to Capture

Threat Model	Observable Tell	Evidence to Capture
AI-generated test plan or automation script (Selenium, Playwright, etc.)	Test cases are generic boilerplate that never exercises the specific bug seeded in the sample app	Manual check against a checklist of intentionally seeded defects
Single massive commit with no iterative development	One commit containing the entire test suite, with no visible "getting a test passing" history	Git commit timeline granularity; diff size per commit
No evidence of actually running tests iteratively	Absence of CI logs or local test-run history showing failed-then-fixed cycles	CI run log presence and iteration count
Write-up reads like generic AI explanation text	Test-plan rationale reads like a general QA textbook rather than notes specific to the provided application	AI-text-similarity scoring on the written rationale

Interviewer Script

Use this in the debrief after submission:

"What was the hardest bug to reproduce in the sample app?" A candidate who wrote the tests themselves will usually name the specific seeded defect and describe what made it tricky; a copier often can't identify it at all or names something generic and unrelated.
"Walk me through why you chose to test this edge case over that one." Genuine testers reason about risk and likelihood; an AI-generated plan often lists edge cases without prioritization logic behind them.
"Show me a test you wrote that initially failed — what did you learn from it?" This checks for evidence of the normal iterative debugging process that real test development involves.
If the candidate can't speak to the seeded bug specifically, treat that as a strong standalone signal regardless of how polished the submitted test suite looks.

FAQs

Isn't using an AI tool to scaffold test boilerplate normal for QA engineers? Yes, scaffolding is common and reasonable. The flag isn't AI assistance itself — it's a test suite that never actually catches the specific bug you seeded, which suggests the tests were generated without engaging with the real application at all.

What's the most reliable single question in the debrief? Asking about the hardest bug to reproduce, because it requires firsthand experience with the specific application rather than general QA knowledge an AI tool could produce without ever running the code.

How does this compare to a Software Engineer take-home assignment? The underlying detection method — commit granularity, debrief specificity, browser tab history — is the same, but QA assignments have an added, very reliable check: whether the submitted tests actually catch the deliberately seeded defect.

How common is AI-assisted cheating in take-home assessments generally? Fabric's dataset of 19,368 interviews (July 2025–January 2026) found 38.5% flagged overall for AI-cheating signals, and take-home formats are a significant contributor because they're unsupervised and asynchronous.

Should the seeded bug be difficult to find on purpose? It should be findable through reasonable manual or exploratory testing within the assignment's time window, but subtle enough that a generic, non-engaged test suite would plausibly miss it.

Related Guides

Get the Evidence Before You Extend an Offer

A QA take-home assignment is only useful if the submitted tests actually engaged with the application you provided. Neuroxa Browser Proctoring captures commit granularity, browser tab history, and time-on-task during the assignment window, giving your team the authorship evidence a passing test suite alone can't show.