The Playwright Question That Ninety Percent of Candidates Fumble

Interviewer: Playwright auto-waits. Why would a test still be flaky?

Candidate: Actually Playwright is very stable, sir.
It waits automatically, so flakiness is mostly a Selenium problem.
If something fails I re-run it, and usually it passes.

Interviewer: And if it passes on re-run, what do you report?

Candidate: ... that it passed.

Interviewer: Playwright auto-waits. Why would a test still be flaky?

Candidate: Auto-waiting checks that an element is visible,
stable and enabled, and expect() retries assertions.
But it does not know my app's business state.

For example, a results table can be visible with the
old rows while the new search is still loading.
Playwright sees a ready table and my count check reads
the wrong data. So I wait for the right signal, like
the search response or the final row count.

import { test, expect } from '@playwright/test';

test('search filters the table', async ({ page }) => {
  await page.goto('/products');

  const searchDone = page.waitForResponse(
    r => r.url().includes('/api/products?q=lamp') && r.ok()
  );
  await page.getByRole('searchbox', { name: 'Search' }).fill('lamp');
  await page.getByRole('button', { name: 'Search' }).click();
  await searchDone;

  const rows = page.getByRole('row').filter({ hasText: 'Lamp' });
  await expect(rows).toHaveCount(3);
});

test('report finishes processing', async ({ page, request }) => {
  await page.goto('/reports/42');
  await expect.poll(async () => {
    const res = await request.get('/api/reports/42');
    return (await res.json()).status;
  }, { timeout: 30_000 }).toBe('READY');
  await page.reload();
  await expect(page.getByText('Download report')).toBeVisible();
});

import { test, expect } from '@playwright/test';

test('shows exchange rate from mocked API', async ({ page }) => {
  await page.route('**/api/rates*', route =>
    route.fulfill({ json: { base: 'USD', rate: 83.1 } })
  );

  await page.goto('/converter');
  await page.getByLabel('Amount in USD').fill('10');
  await expect(page.getByTestId('converted-amount'))
    .toHaveText('831.00');
});

// The rate here is fixed test data, not a real value.
// Mocking removes the network as a source of flakiness
// for tests that are about the UI, not the rates service.

"Auto-waiting makes sure an element is visible, stable and
enabled before an action, and web-first assertions retry.
What it cannot know is my app's state.

In my project, a cart total test failed about once a week in CI.
The trace showed the total was visible but still showing the
old value, because the price API was slower in CI.
I was reading the text once with textContent().

I changed it to await expect(total).toHaveText(...), and waited
on the cart update response. I also gave each test its own
cart through the API so parallel runs stopped colliding.

We keep retries at one in CI only to collect a trace,
and we treat any test that needs the retry as a bug to fix."

Likely follow-ups after your answer:

1. What does a strict mode violation mean?
   -> Locator matched more than one element; narrow it.

2. When would you use networkidle?
   -> Rarely. It is discouraged; wait for a specific
      response or a visible state instead.

3. Difference between expect.poll and toPass?
   -> poll retries a value-returning function;
      toPass retries a whole block of assertions.

4. How do you stop parallel tests colliding?
   -> Unique data per test, created via API fixtures.

5. How do you find flaky tests across runs?
   -> CI reports that flag tests passing only on retry.

BREAK IT ON PURPOSE (practice project)

1. Add a slow route to a local demo app, or mock an API
   with a random delay:
   await page.route('**/api/cart', async route => {
     await new Promise(r => setTimeout(r, Math.random() * 3000));
     await route.continue();
   });

2. Write the assertion the wrong way (textContent once).
3. Run it 20 times: npx playwright test --repeat-each=20
4. Watch it fail sometimes. Open the trace.
5. Fix it with a web-first assertion. Run 20 times again.

Now you have a real story to tell.

FLAKY TEST ANSWER CARD

Boundary:   auto-wait = element ready, not app ready
Example:    ______________________________________
Diagnosis:  trace -> failing step -> snapshot -> network
Cause:      ______________________________________
Fix:        wait for ____ / mock ____ / isolate data
Prevention: retry-only-passes are bugs, tracked in ____

Say it aloud 3 times. Record the third one.

SCORE YOUR RECORDING (1-5 each)

[ ] Named the auto-wait boundary in the first 20 seconds
[ ] Gave a specific example, not a general claim
[ ] Mentioned the trace and what I looked at in it
[ ] Fix waited on a signal, not on time
[ ] Did not present retries as the solution
[ ] Ended with how the team prevents repeats

Below 20? Re-record tomorrow with a sharper example.