How to prepare for a QA take-home assignment

The QA take-home looks like a coding task — "automate these test cases for this app" — so candidates treat it like one and optimise for "tests pass." Then they get rejected with strong tests and can't work out why. The reason is that the take-home isn't really testing whether you can write a test. It's testing whether you think like a QA engineer, and the rubric for that is almost never written in the brief. Having reviewed a stack of these, here's what actually moves the score.

What they're really scoring

Reviewers are looking past "did it work" at signals like: did you figure out what to test, not just automate what you were told? Did you find anything? Did you communicate clearly? Are your decisions sound and explained? A submission that's 80% solid automation and 20% visible thinking beats one that's 100% automation and 0% reasoning, every time. The automation is the table stakes; the thinking is the differentiator.

Read the brief for what it doesn't say

The brief is usually vague on purpose — that's the test. "Write tests for the login feature" is checking whether you'll only test the happy path or whether you'll consider lockout, validation, session handling, error messages, and edge cases nobody mentioned. Treating an underspecified brief as an invitation to show range is exactly the unclear-requirements skill the job needs. Surface your interpretation; don't silently guess.

Spend your hours in the right order

Most people spend all their time on framework polish. Reallocate:

1. Explore and find bugs first (and write them up). Before automating anything, actually use the app and look for defects. Finding and clearly reporting a real bug is often the single highest-scoring thing you can do — it proves you test, not just script.
2. Cover the right cases, not the most cases. A focused set that includes negative paths and key edge cases beats fifty happy-path assertions. Show you chose deliberately.
3. Write the README / notes. Explain what you tested, what you found, what you deliberately left out and why, and what you'd do with more time. This is where you bank the "thinks like QA" score.
4. Then make the automation clean. Stable selectors, no hard-coded sleeps, readable structure — necessary, but it's the floor, not the ceiling.

Don't fake the scope

If the task is large and your time is limited, say so explicitly: "I focused on the checkout flow as highest-risk and time-boxed the rest; here's what I'd cover next." Reviewers respect a stated, reasoned trade-off far more than a sprawling half-finished submission with no explanation. Scoping is the skill — showing it is a positive signal, not an admission of weakness.

Common own-goals

• Only the happy path (the most common rejection)
• No bugs found or reported (suggests you didn't really test)
• Flaky submission — fails when they run it (test it clean-cloned before sending)
• No README, so all your reasoning is invisible
• Over-engineered framework for a small task (judgement signal, the wrong way)

Where this fits

The take-home is one stage of the loop; the SDET interview loop, decoded covers the rest. Build the same muscles beforehand on real targets — the practice & projects section and a portfolio that doesn't look fake are the same skills under a different name. The interview prep hub ties it together.

Before you submit a take-home

• Explored the app and reported at least one real bug, written up properly
• Covered negative paths and key edge cases, not just the happy path
• README explains what you tested, what you found, what you skipped, and why
• Automation is stable on a clean clone (no flakiness, no hard-coded sleeps)
• Scope is stated and reasoned where time was limited
• The framework matches the task size — not over-engineered