QA take-home assignments: real examples and a worked solution

"Validate the first 100 articles are sorted newest to oldest" takes twenty minutes to make pass and four hours to make defensible. The gap is that nobody shows you a finished one. Search for examples and page one is a wall of candidate repos with no context. You can read a hundred submissions and still not know which ones got an offer.

This page covers the assignment shapes companies actually send, six real named examples with links, what reviewers score line by line, and one complete walkthrough of the most commonly assigned task — the thinking, the file layout, the README, and the specific bug that catches nearly everyone.

What a take-home actually is

A take-home is the cheapest way for a hiring team to see whether you can design tests, not whether you can write them. Anyone can be taught page.locator() in a week. What can't be taught quickly is knowing which three of the eleven possible checks are worth automating, and being able to say why.

Companies use them because live coding interviews reward speed and confidence, and QA work rewards neither. A take-home lets a nervous, careful engineer look good. That is the whole point, and it is why the interview that follows is usually a conversation about your submission rather than a fresh problem.

Two things follow. First, the reviewer is reading your code as evidence of a thought process, so make the thought process visible. Second, an incomplete submission with clear reasoning consistently beats a complete one with none.

The six assignment archetypes

1. Automate a flow on a real site

A starter repo with a framework installed and one sentence of instruction. Playwright, Cypress or Selenium against a live public site. Really evaluating: whether you can handle a target you don't control — real sites have flaky selectors, changing data and pagination. Budget: 3–4 hours. A strong submission handles the data changing under you mid-run, chooses selectors by stability rather than convenience, and states in the README what "correct" means, because the prompt didn't.

2. Test this app and report the bugs

A deliberately broken web or mobile app. You explore it and hand over findings. Really evaluating: bug report quality and coverage judgment — did you find the seven real bugs or thirty cosmetic ones? Budget: 2–3 hours. Order bugs by user impact, each with exact repro steps, environment, expected vs actual, and one line on suspected cause. Include a short "areas I did not cover and why" list — reviewers read that first.

3. Write a test plan or strategy

No code. A feature description in, a document out. Really evaluating: whether you think in risk rather than in checklists. Budget: 2 hours. A strong submission has a risk-ranked scope, an explicit statement of what you're not testing, entry and exit criteria, and a line showing where automation enters the timeline versus where manual exploration stays. Two pages beat ten.

4. API testing task

Test a public REST API — usually CRUD plus auth, often with seeded bugs. Really evaluating: whether you test contracts and edge cases or just happy paths. Budget: 2–3 hours. Tests own their own data setup and teardown, assert on response bodies rather than status alone, and at least one test documents a genuine API bug rather than being written around it.

5. Two-part: manual plus automated

The most common shape at mid-size companies. Part one is test cases or a plan; part two automates a subset. Really evaluating: the mapping between the two — which cases you chose to automate and whether you can justify the ones you left manual. Budget: 4–6 hours across both. State the traceability explicitly: "TC-03, TC-07 and TC-11 are automated; TC-05 is visual and stays manual; TC-09 requires a real payment card."

6. Fix or extend an existing suite

A repo with tests that are flaky, badly structured or failing. You improve it. Really evaluating: whether you can read someone else's code and refactor without breaking behaviour — this shape usually signals a senior role. Budget: 3–4 hours. Small, individually reviewable commits, and a README section naming each smell you found and what you did about it.

Real examples you can go read

All six below are publicly documented. Links go to the source, not to candidate solutions.

QA Wolf — Hacker News sorting. A starter repo with Playwright and an empty index.js. Edit it to open Hacker News's newest page and validate that exactly the first 100 articles are sorted newest to oldest; the second part is a two-minute video covering your motivation and a demo. Distinctive for how much it leaves unspecified — "newest to oldest" is never defined, and the site paginates at 30. It is reproduced across dozens of public candidate repos.

cLabs (Celo) — Detox on an Instagram clone. celo-org/qa-interview-assignment. Three hours, capped. Manually test only the Home section, document findings as if writing to an engineer, then write 5–8 Detox tests. Distinctive: they explicitly want a mix of passing and failing tests — passing where the feature works, failing where you found a bug. That inverts the usual instinct to make everything green.

ZoomCare — schedule page. zoom-care/candidate-project-qa-automation. Write 8–10 smoke test cases for their public scheduling page as an unauthenticated user, then automate at least three in any framework. Fork, replace the README, open a PR — the README is the deliverable format. Stated at 2–3 hours.

DEPT — two-part. Published on their site. Part one is a six-month test plan for an imaginary eCommerce project that has had no testing to date. Part two is a running automation suite with a generated report. One week to complete. Distinctive for testing planning across months, which almost no other assignment touches.

Gumtree UK — E2E plus API. gumtreeuk/technical-assignment-qa. Two tasks at 2–3 hours each: a browser flow, and functional tests against JSONPlaceholder. Their criteria are unusually explicit — page objects, HTML reports, a .gitignore, and "granular git commits showing thought process". Worth reading purely as a published rubric.

Moneyhub — Postman plus a broken form. moneyhub/qa-interview-task. Roughly 30 minutes of API work, then manual test cases and defect reports for a registration form. Distinctive for how short it is — a deliberate signal that they don't want a weekend of your time.

Worked walkthrough: the Hacker News sorting task

This is the QA Wolf task, but the reasoning transfers to any "validate this list" assignment.

Step 1 — Define the thing you're validating

The newest page renders 30 items per page. You need 100, so you need four page loads. Nothing in the prompt says that.

"Sorted newest to oldest" is also undefined. HN shows relative ages as text — "12 minutes ago". Comparing those as strings is wrong, and comparing them as parsed numbers is fragile, because "1 hour ago" and "59 minutes ago" can both be true of the same post. Look at the DOM instead: the age element carries an absolute timestamp in its title attribute. Use that. As a secondary signal, HN item IDs increase monotonically, so a correct list is also descending by ID — a cheap cross-check that catches timestamp-parsing mistakes.

Write both decisions down. This is the part reviewers score.

Step 2 — Find the bug the task is hiding

Between your first page load and your fourth, new posts arrive. Everything shifts down. Naively clicking "More" three times and concatenating gives you duplicate items and silently missed ones — and your sort check may still pass. You now have a green test validating the wrong 100 articles.

Two defensible fixes. Dedupe by item ID as you collect and keep going until you have 100 unique items. Or walk the pagination cursor rather than the "More" link, which pins each page to a fixed position in the list. Either is fine. Not noticing is what separates submissions.

Step 3 — Structure

Keep index.js as the entry point they told you to run, and put the logic behind it:

index.js               // orchestration only, ~20 lines
src/hackerNews.js      // page interaction, pagination, extraction
src/validate.js        // pure function: array of articles -> result
tests/validate.spec.js // unit tests for the pure function
README.md

Making the comparison a pure function is the highest-leverage move in the whole exercise. It lets you unit test the sort logic against fixtures with no browser, which demonstrates you understand the test pyramid without writing a paragraph claiming you do.

Step 4 — Assert like you mean it

Don't print "articles are sorted". Throw, and exit non-zero. On failure, report the specific pair that broke the order — index, both titles, both timestamps. A reviewer who deliberately feeds your script a broken fixture wants a message they could act on.

Handle the obvious failure paths: page load timeouts, fewer than 100 items available, a missing timestamp attribute on some row. Three try/catch blocks with real messages beat a global one.

Step 5 — The README

Six short sections. What it does. How to run it, with exact commands from a clean clone. How you defined "sorted" and why. Known limitations. What you'd do with more time. How long you spent. That last line is not humility theatre — it tells the reviewer how to calibrate everything else.

What reviewers actually score

• Does it run from a clean clone? Clone, install, run. If it needs a file you didn't commit, nothing else matters.
• README quality. Disproportionately weighted, because it is the only place your reasoning is visible.
• Test design reasoning. Why these checks, in this order, at this layer.
• Selector choices. Stable attributes over CSS paths that encode layout.
• Flake handling. Explicit waits on conditions, never sleep. Any fixed sleep is a mark against you.
• Repo hygiene. A .gitignore, no node_modules, no commented-out experiments.
• Commit history. Several meaningful commits telling a story. One commit called "solution" reads as rushed or copied.
• Failure output. They will break it on purpose. What does it say?
• Scope discipline. What you chose not to automate, stated explicitly. The most under-used way to look senior.

How candidates fail

1. Automating 30 items when the task said 100, because that's what one page holds.
2. Comparing relative time strings instead of absolute timestamps.
3. Fixed sleep calls instead of waiting on a condition.
4. No assertion — the script prints results and always exits 0.
5. Committing node_modules, or a .env with a real key in it.
6. A README that says "run npm start" and nothing else.
7. Over-building. A custom reporting framework and a Docker setup for a four-hour task reads as poor judgment, not enthusiasm.
8. Silently hiding a bug. If the app is broken, your test should say so, not be written to avoid the broken path.
9. Bug reports with no repro steps, or thirty cosmetic issues and none of the functional ones.
10. Ignoring an explicit instruction — the file they told you to edit, the framework they told you to use, the video they asked for.

Scoping "spend about 4 hours"

Treat it as a budget, not a target. Roughly: 30 minutes reading the prompt and the app before writing anything, 30 minutes deciding scope and writing it down, two hours building, 30 minutes on failure paths and cleanup, 30 minutes on the README.

If you overrun, stop and write down what's missing rather than shipping late or broken. "I ran out of time before adding the mobile viewport run; the config hook for it is in playwright.config.js and it would take about 40 minutes" is a strong sentence. It shows you know what's missing, which is the thing they're actually hiring for.

Never spend twenty hours on a four-hour task. Reviewers can tell, and it signals that you can't estimate — a worse problem than being slightly less polished. When you want the coding skills under the assignment to be less of a variable, that's what the Code Lab and the roadmap are for.