Most QA take-homes are not hard. They are ambiguous, and the ambiguity is the test. The candidates who get rejected almost always shipped something that ran.
Got four hours? Generate a realistic take-home for your stack and seniority, start a timer, build it against a real site — then come back and grade yourself on the scorer below, the same way a reviewer would.
Start a practice take-home — free, no signup"Validate the first 100 articles are sorted newest to oldest" takes twenty
minutes to make pass and four hours to make defensible. That gap is the whole
test. A take-home exists to show whether you can design
checks and say why — anyone can be taught page.locator() in a
week. The reviewer reads your code as evidence of a thought process, and an
incomplete submission with clear reasoning consistently beats a complete one
with none.
Really evaluating: can you handle a target you don't control — flaky selectors, changing data, pagination.
Survive the data changing mid-run, pick selectors by stability, and define "correct" in the README — the prompt won't. Rehearse on a real sandbox before the brief lands.
Really evaluating: bug report quality and coverage judgment — the seven real bugs, or thirty cosmetic ones?
Impact-ordered findings, exact repro steps, a "what I didn't cover" list. The bug report builder enforces the shape.
Really evaluating: do you think in risk or in checklists.
Risk-ranked scope, an explicit "not testing" list, entry/exit criteria. Two pages beat ten — the test plan generator grades the skeleton.
Really evaluating: contracts and edge cases, or just happy paths.
Own your data setup, assert on bodies not status codes, document at least one seeded bug. The boundary value generator enumerates the edges.
Really evaluating: the mapping — which cases you automated, and whether you can defend the ones you left manual.
State traceability outright: "TC-03, 07, 11 automated; TC-05 visual, stays manual; TC-09 needs a real card."
Really evaluating: can you read someone else's code and refactor without breaking it — usually a senior-role signal.
Small reviewable commits, and a README naming each smell and what you did about it.
All six are publicly documented. Links go to the source, not to candidate solutions.
QA Wolf — Hacker News sorting. Playwright starter, empty
index.js: validate the first 100 newest articles are sorted,
plus a two-minute video. The most-assigned task there is —
worked end to end
here.
cLabs (Celo) — Detox on an Instagram clone. celo-org/qa-interview-assignment. Three hours, capped. Distinctive: they want a mix of passing and failing tests — failing where you found a real bug.
ZoomCare — schedule page. zoom-care/candidate-project-qa-automation. 8–10 smoke cases, automate at least three; fork and open a PR — the README is the deliverable.
DEPT — two-part. Published on their site. A six-month test plan, then a running suite. Distinctive for testing planning across months.
Gumtree UK — E2E plus API. gumtreeuk/technical-assignment-qa. Unusually explicit criteria — page objects, HTML reports, "granular git commits". Worth reading purely as a published rubric.
Moneyhub — Postman plus a broken form. moneyhub/qa-interview-task. ~30 minutes of API work plus manual cases. Deliberately short — they don't want your weekend.
The QA Wolf Hacker News task deserves its own page: the pagination trap, the moving-list bug that keeps a wrong answer green, the file structure, the README and the video — the full walkthrough. The reasoning transfers to any "validate this list" assignment.
These nine lines are the review. Tick what's true of your submission and watch the score — the weighting mirrors how reviews actually go: if it doesn't run, nothing else matters, and the README carries more than anyone expects.
0Tick what your submission already has.
Automating 30 items when the task said 100 — that's what one page holds.
Comparing relative time strings instead of absolute timestamps.
Fixed sleep calls instead of waiting on a condition.
No assertion — the script prints results and always exits 0.
Committing node_modules, or a .env with a real key.
A README that says "run npm start" and nothing else.
Over-building — Docker and a custom reporter for a four-hour task reads as poor judgment.
Silently hiding a bug your test should have reported.
Thirty cosmetic bug reports and none of the functional ones.
Ignoring an explicit instruction — the file, the framework, the video they asked for.
Treat "about 4 hours" as a budget: 30 minutes reading, 30 scoping on paper, two hours building, 30 on failure paths, 30 on the README. If you overrun, stop and write down what's missing — that sentence scores better than the extra work, and twenty hours on a four-hour task signals you can't estimate. When the coding itself is the shaky part, that's what the Code Lab and the roadmap are for.
Most stated ranges are two to four hours, and published examples confirm it — cLabs caps theirs at three hours, ZoomCare at two to three. Treat the number as a budget. Going far over signals poor estimation, which reviewers weigh more heavily than a slightly thinner submission.
Use whichever you can explain under questioning, unless the assignment names one. Reviewers care far more about your test design and structure than your tool. If they let you choose, add one README line saying why you chose it — that sentence is scored.
Six sections: what the project does, exact setup and run commands from a clean clone, how you defined the acceptance criteria the prompt left vague, known limitations, what you'd do with more time, and how long you spent. It is the only place your reasoning is visible.
Yes, if you say so clearly. An honest "I did not automate the checkout flow; here's my approach and the estimate" reads better than a rushed, flaky version of it. Silent gaps look like oversight. Named gaps look like scope control.
Fewer than you think, chosen deliberately. Three well-structured tests with a stated rationale beat fifteen shallow ones. Where the assignment gives a number, hit it exactly, then list which remaining cases you'd automate next and which should stay manual.
Yes. Gumtree UK's published criteria explicitly ask for granular git commits showing thought process. A single commit called "solution" gives reviewers nothing and invites suspicion about where the code came from. Five commits that follow your build order tell a story they can follow.
Usually a follow-up interview where you walk through your submission and defend your choices. cLabs states outright that you'll be asked to explain your thinking. Write down why you made each significant decision while it's fresh, because you'll be asked about it two weeks later.