Back to QA / Automation Engineer Job Simulation

Prerequisites & resources - QA / Automation Engineer simulation

Nothing to install and nothing to upload. Both tickets are answered in the browser: five questions and a written note each. No repository is submitted and no code of yours is executed.

Everything needed is printed in the tickets - a Playwright test file, forty runs of CI history, and a set of release constraints.

What you should already know

You do not need professional QA experience. You need to read a test suite and judge whether it would actually catch a bug.

  • What a test asserts - and the difference between asserting behaviour and asserting a mock
  • Mocking - what a spy replaces, and why over-mocking makes a test vacuous
  • Flakiness - fixed sleeps versus waiting for a condition, and why CI machines expose it
  • Test isolation - shared state, execution order, and shared test data
  • Selectors - why a CSS class is a fragile hook and what a stable one looks like
  • The testing pyramid (or trophy) - roughly what belongs at each layer and what each costs
  • CI basics - that a suite has a time budget and that budget shapes strategy

Playwright is the framework in the file, but the defects are framework-independent. Cypress or Selenium experience transfers cleanly.

Reference material

Looking things up is expected.

  • Auto-waiting and web-first assertions - Playwright docs → Auto-waiting, and Best Practices (the section on avoiding waitForTimeout)
  • Testing implementation details - Kent C. Dodds, Testing Implementation Details
  • Locator strategy - Testing Library → Which query should I use? (accessible roles over classes)
  • Test isolation - Playwright docs → Test isolation, and per-worker fixtures
  • Flaky tests - Google Testing Blog → Flaky Tests at Google, on quarantine over retry
  • The test pyramid - Martin Fowler, The Practical Test Pyramid
  • Testing Trophy - Kent C. Dodds, for the counter-argument to a strict pyramid

Ground rules

  • Answer from the file and the CI table. Generic QA advice scores badly - each question points at a specific test or a specific numbered requirement.
  • QA-101 asks you to separate two different failures. A test that is flaky and a test that is worthless are not the same problem, and the answers depend on telling them apart.
  • QA-102 has an opposing argument built in. The engineering lead wants more end-to-end tests. The rubric rewards engaging with that, not ignoring it.
  • Using AI assistance is allowed, as on the job. The questions turn on this specific file, and the notes are graded on reasoning you would have to defend.
  • Two free submissions per ticket. Read the feedback before resubmitting.