QA take-home assignment practice
Generates a realistic automation take-home against a real public practice site, with the task list, deliverables, the weighted rubric reviewers score against, and the four reasons submissions get rejected.
Pick a stack, a seniority level and a time budget. Then start a timer and actually do it — before a real one arrives with a deadline attached.
Open the tool — free, no signupWhat is in the assignment
Three dropdowns produce a full brief in Markdown. Five stacks, each pointed at a real public target: Playwright + Python and Selenium + Java against SauceDemo, Cypress + JavaScript against the TodoMVC demo app, and API testing in pytest or Rest Assured against ReqRes. Four seniority levels control how many tasks you get — junior gets the core four, mid and senior add three, lead adds two more. Time budgets run 3 to 8 hours.
For UI stacks the core four tasks are: automate login including a failure case, automate an end-to-end purchase journey to the confirmation state, implement the Page Object Model with no raw locators in test files, and make the suite data-driven across multiple input sets.
For API stacks: automate the full CRUD lifecycle asserting status codes and bodies, add schema validation so a changed field type fails the test rather than only a changed value, cover negative cases, and handle auth — including proving an unauthenticated request is rejected.
Mid and above add CI wiring with the report as an artifact, test data that survives parallel execution, and documentation of one flaky failure you hit or foresee. Lead adds a one-page strategy — what you would automate, what you deliberately would not, and why — plus how the framework scales to 20 engineers and 500 tests, naming the first thing that would break.
The rubric
Worth reading before you write any code, because it is where candidates misallocate effort:
| Weight | Criterion |
|---|---|
| 30% | Correctness — assertions genuinely verify behaviour; no test that cannot fail |
| 25% | Design and structure — separation of concerns, no duplication, a new joiner navigates it in ten minutes |
| 20% | Reliability — no hard sleeps, proper waits, passes repeatedly rather than once |
| 15% | Coverage judgment — high-value scenarios chosen, and you can justify what you left out |
| 10% | Communication — a README covering how to run it, trade-offs, and what you'd do with more time |
Volume is not scored anywhere. Ten meaningful tests with clean structure beat forty shallow ones, and the rubric is why.
How to use it
Pick the stack you would actually be interviewed on, set seniority one level above your current role, and choose a time budget you will genuinely respect. Generate, copy the Markdown, then start a timer and stop when it runs out. The constraint is the exercise — reviewers assess judgment under time pressure, not endurance. Finish with the README: it is 10 percent of the score and the section most often skipped.
What makes submissions fail
Hard-coded waits. sleep(5) scattered
through the suite is the single most common rejection reason. Use the
framework's waiting mechanism.
Forty shallow tests instead of ten meaningful ones. Reviewers read a sample, not all of them. Padding is visible immediately.
No README. If the reviewer cannot run it, the code does not get evaluated at all.
Locators duplicated across test files. This is what the Page Object requirement is testing, and duplication shows the pattern was applied cosmetically.
Ignoring the time budget. Twenty hours on a four-hour task is not the win it feels like — the README is where you say what you would have done with more time, and that answer scores better than the extra work would have.
Generation happens in your browser; nothing is sent anywhere. The finished repository is also worth more than a certificate — a public repo with a clean framework and an honest README answers questions before they are asked.
Frequently asked questions
What does a QA take-home assignment involve?
Usually building a small automation suite against a demo application: a login flow with a failure case, one end-to-end journey, the Page Object Model, and data-driven tests. API assignments cover CRUD, schema validation, negative cases and authentication. A README explaining your decisions is expected.
How long should a take-home take?
Most specify 3 to 8 hours of work, often inside a 48-hour submission window. Respect the stated budget — reviewers are assessing judgment under constraints. If you run out of time, document what you would have done next; that scores better than an over-delivered submission.
What do reviewers score a take-home on?
Correctness of assertions carries the most weight, then design and structure, then reliability, coverage judgment, and communication. Notably, the number of tests is not a criterion. Ten well-designed tests with a clear README beat forty shallow ones.
Where can I practise QA automation for free?
This generator targets three public sites: SauceDemo for UI storefront flows, the TodoMVC demo app for Cypress, and ReqRes for REST API practice. All three are open, stable, and intended for automation practice, so you can complete the assignment end to end.
Is a completed take-home worth putting on GitHub?
Yes. A public repository with a working framework and an honest README is stronger evidence than any certificate, and it gives interviewers something concrete to discuss. Write the README as though a reviewer who has never met you will run it.