Practice Playwright interview answers on resilient locators, web-first assertions, isolation and debugging, with a flaky checkout test scenario. Start with the question, explain the mechanism, and then state an assumption or tradeoff. The scenarios below are original practice examples, not questions supplied by an employer.
How do you choose a resilient locator?
Locate the element by a user-facing role and accessible name where that describes the interaction clearly. A dedicated test ID can help when no stable user-facing identifier exists. Avoid selectors tied to incidental nesting or generated class names. Explain what happens when two buttons share a name: scope the locator to the relevant region rather than picking an arbitrary first match. A locator should communicate which user action the test intends to perform.
Why use web-first assertions?
A web-first assertion can retry while waiting for an observable state to become true. Reading text immediately and comparing it once may capture a transient state. Wait for the behavior that matters instead of guessing a fixed duration. Distinguish readiness to click from completion of the business operation: an actionable button does not mean the order was saved. Verify the confirmation or persisted outcome separately.
What does test isolation protect?
Each test should have a controlled starting state and should not depend on another test having run first. Separate browser state and create data appropriate to the scenario. Shared backend data can still cause collisions even when browser contexts are isolated. Use unique identifiers or resettable fixtures, and explain cleanup. A test passing only after a different test creates an account is a hidden dependency, not a reliable workflow.
When should you mock a network response?
A controlled response is useful for a specific error or edge case that is difficult to reproduce through a live dependency. Keep some tests that exercise the real integration so the suite can detect contract mismatches. Explain what the mock proves and what it excludes. If every checkout test invents its own successful response, none of those tests establishes that the real payment integration works.
How do you investigate a flaky test?
Read the failure and available trace to identify the state before the failed action. Check unstable data, ambiguous locators, missing outcome assertions and environmental differences. Reproduce with a clear hypothesis rather than increasing every timeout. A retry may reduce visible failures while hiding the cause. After a fix, verify that the test fails for the intended broken behavior and succeeds under the supported execution conditions.
Worked example
Original scenario: checkout sometimes fails because the test clicks 'Pay' and immediately asserts an order ID. Replace the assumption about timing with an assertion on the completed order state. Confirm the locator identifies the intended button and that the test account has valid test data.
If a trace shows the server returned an error, waiting longer will not fix the application response. Separate a test synchronization issue from a product defect. Add a controlled server-error test with a user-visible expectation, while retaining an integration test against the approved test environment.
Practice plan
Design three tests: successful checkout, declined payment and a repeated submission. For each, identify setup, user action and observable outcome. Explain where a mock helps, where a real integration is necessary and what evidence you would read when a test fails in CI.
Use Cluegent during preparation to review your own answer: ask for one incorrect assumption and one follow-up question, then respond again without suggestions. Check current plans before choosing a subscription. Follow the employer's rules during the actual interview.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should I solve flaky tests with fixed waits?
Prefer waiting for a meaningful observable condition. A fixed delay can be both slower than necessary and too short under load.
Does browser isolation also reset the database?
No. Browser state and backend state need separate setup and isolation decisions.