20 Playwright Locator and Actionability Interview Scenarios for Senior SDETs

Senior locator interviews should test judgment under an unstable UI, not memory of selector methods. The useful question is rarely "Which API finds this button?" It is "What contract should the test express, what evidence explains the failure, and what maintenance cost does the proposed fix create?"

The scenarios below are built for that conversation. Answer each one as if a failing CI trace, an impatient product team, and a real accessibility tree are all part of the problem. The strongest response names the uncertainty, gathers evidence, and then chooses the smallest reliable action.

Use a Senior Answering Model

Playwright's locator guidance treats locators as the center of auto-waiting and retryability. A complete interview answer should therefore move through five stages: understand the DOM scenario, choose the user or test contract, diagnose actionability, explain alternatives, and state what would prove the decision correct.

Do not rush directly to code. In an interview, explicitly separating observation from hypothesis demonstrates that the candidate can debug a suite without converting every intermittent symptom into a longer timeout.

Locator Contracts and User Meaning

1. Why would you choose a role locator over a CSS class for a checkout button?

I would choose getByRole('button', { name: 'Place order' }) because the role and accessible name describe the control a customer operates. A generated CSS class describes implementation and may change during styling work. The role locator also exposes missing or incorrect accessible naming as useful product feedback. I would still confirm uniqueness, because semantic intent does not excuse a page that presents two identically named active controls.

2. How would you target one product row when every row has an Add button?

I would first identify the row by its business-visible identity, then search within it for the action. This preserves the relationship between product and button instead of depending on array position. I would assert the row count when duplicate product names would indicate bad test data.

const product = page
  .getByRole('listitem')
  .filter({ has: page.getByRole('heading', { name: 'Trail Backpack' }) })

await expect(product).toHaveCount(1)
await product.getByRole('button', { name: 'Add to cart' }).click()

3. Why can a test ID be better than visible text for a localized control?

A stable test ID can represent product identity when copy changes across locales and the exact translation is outside this test's purpose. I would not use it to avoid checking accessibility where the accessible name matters. A balanced design may click by test ID in a workflow test and separately assert translated labels and roles. The answer should make that division of responsibility explicit rather than calling either locator universally superior.

4. How would you test an icon-only button with no accessible name?

I would describe that as an application defect before inventing a selector. An icon-only interactive element needs an accessible name for keyboard and assistive-technology users. The test should prefer a role and expected name once the product is fixed. A temporary test ID may unblock unrelated coverage, but the defect must remain visible in the backlog and an accessibility assertion should prevent regression.

Strictness and Repeating Content

5. Why is using locator.first() risky after a strict mode violation?

first() changes an ambiguous business request into a positional choice. It can make the test pass while clicking a hidden template, stale notification, or wrong row. I would inspect all matches and narrow by region, accessible name, or parent content. Position is acceptable only when order itself is part of the requirement, such as selecting the first ranked result, and then the test should assert that ordering first.

6. How would you handle identical Save buttons in two visible dialogs?

I would treat each dialog as a scope. Locate the dialog by its heading or another stable identity, assert that it is the intended active modal, and find Save inside that boundary. If two modal dialogs are simultaneously interactive, I would question the product behavior as well as the test. A page-wide Save locator throws useful ambiguity; suppressing it would lose a signal about focus management and interaction design.

7. Why can nth() make virtualized-list tests misleading?

The nth visible DOM node is not necessarily the nth data record because virtualization recycles row elements as the user scrolls. I would locate by a durable record value after bringing that record into view through search, pagination, or controlled scrolling. If position is the requirement, I would assert the displayed index or record identifier, not assume DOM order equals dataset order. The answer should acknowledge the virtualization boundary.

8. How would you diagnose a strictness failure that appears only on retries?

I would compare the first attempt and retry traces for duplicate banners, stale dialogs, restored storage, or incomplete cleanup. The locator error is evidence that the retry started from a different state, not automatically a selector bug. I would inspect test isolation, navigation completion, and server-side data teardown. Narrowing the locator may be correct, but only after deciding whether both matches are legitimate in the retried scenario.

Actionability and Click Failures

9. Why does a visible element still fail a Playwright click?

Visibility is only one actionability condition. For a click, Playwright also needs a unique target that is stable, receives events, and is enabled. An overlay can intercept the pointer; animation can keep the box moving; a disabled attribute can block the action. I would read the call log and trace to identify the failing condition, then fix the state transition or product behavior rather than adding an unrelated visibility wait.

10. How would trial mode help investigate a flaky action?

A trial click runs the actionability checks without performing the click. It can prove that the target becomes actionable before a separate event or assertion is attempted. I use it as a diagnostic or synchronization tool, not as ritual before every action, because the real click still occurs later and the page can change between calls.

const submit = page.getByRole('button', { name: 'Submit payment' })

await submit.click({ trial: true })
await expect(page.getByTestId('payment-summary')).toContainText('Total')
await submit.click()

11. When would force click be defensible in a senior test design?

Force is defensible when the test intentionally triggers an element despite a nonessential browser hit-target condition and the scenario proves that this differs from user interaction. One example may be exercising an application handler in a tightly controlled component fixture. It is poor for an end-to-end purchase button covered by an overlay, because a user cannot complete that action. I would document the reason and assert the resulting state.

12. How would you investigate a button that never becomes enabled?

I would identify the enabling contract: valid form state, API response, feature permission, or client validation. Then I would inspect field values, network responses, console errors, and the disabled attribute over time. Waiting longer is justified only if a known asynchronous operation remains in progress. If the operation finished and the button stayed disabled, the test has found a product or setup failure that a forced click would hide.

Dynamic DOM and Timing Boundaries

13. Why are locators safer than cached element handles during rerenders?

A locator resolves against the current DOM when an action or assertion runs, so it can follow a component that was replaced during rerendering. A cached handle points to a particular node and may become detached. I would keep a locator that expresses identity, then let Playwright re-resolve it. This does not solve ambiguous identity; the locator still needs a stable semantic or explicit test contract.

14. How would you click a result that appears after debounced search?

I would fill the search field, then assert the intended result rather than sleeping for the debounce duration. The assertion retries until the application produces the visible state. If the feature contract includes a network response, I may also observe that response for diagnosis, but the user-facing result remains the action boundary. Fixed delays couple the test to an implementation duration and slow down fast runs.

15. Why can a locator.or() expression still violate strictness?

Both alternatives can be visible at the same time, producing two matches. I would use or() only when either state is valid and immediately branch based on the observed state. If simultaneous visibility is possible, scope or select the combined locator deliberately, then assert which branch occurred. A candidate who says or() simply disables strictness has misunderstood it; the operator broadens matching but retains action safety.

16. How would you handle a control replaced between hover and click?

I would keep one locator and allow each action to resolve the current matching node. Then I would ask why hover triggers replacement and whether the replacement preserves role, name, and state. If click still fails, the trace can show animation or event interception. Holding a handle to force continuity would test a node identity the user does not perceive and would usually make the scenario more brittle.

Diagnosis and Test Architecture

17. Why is waitForTimeout a weak response to locator flakiness?

It waits for elapsed time rather than required state. A slow environment can still fail after the delay, while a fast environment wastes the full duration. I would replace it with a web-first assertion, an action that auto-waits, or a specific event when that event is the actual contract. I would also investigate why the original action lacked a clear readiness signal instead of treating time as readiness.

18. How would you separate a locator defect from an application accessibility defect?

I would inspect the accessibility role and name expected for the control. If the UI is usable only through a CSS path because its semantics are absent or wrong, the application owns a defect. If the correct semantics exist but the test asks for outdated copy or the wrong region, the test owns the failure. This distinction matters because changing to CSS can silence evidence that users also lost an operable control.

19. Why should a page object return locators instead of hiding every assertion?

Returning a well-named locator lets the test state the scenario-specific expectation and preserves Playwright's retry behavior. A page object may encapsulate stable structure, but hiding all assertions turns failures into generic helper errors and makes business intent hard to review. I would place universal component invariants near the component and keep outcome assertions in the test, where the report can explain what the scenario expected.

20. How would you review a pull request that replaces role locators with long XPath expressions?

I would ask what regression motivated the change and inspect whether accessible names, duplicate controls, or shadow boundaries changed. Long XPath tied to ancestors usually transfers a product-contract problem into maintenance debt. I would propose a scoped role, label, relational filter, or agreed test ID, then add an assertion for uniqueness. If XPath is genuinely required, the pull request should explain the unsupported boundary and limit it to one helper.

Senior Evaluation Checklist

Use these signals when assessing an answer:

• The candidate identifies the product-facing identity before writing a selector.
• Strictness is treated as diagnostic evidence, not an obstacle to disable.
• Actionability failures are separated into visibility, stability, event targeting, and enabled state.
• Trace and call-log evidence precede timeout, force, or positional shortcuts.
• The proposed assertion proves the business outcome, not merely that a click returned.
• Accessibility defects remain visible instead of being buried under implementation selectors.
• The candidate explains where a test ID improves stability and where it would reduce user-level confidence.

Conclusion: Preserve the Interaction Contract

A senior SDET does not win a locator discussion by naming the shortest API call. The decisive answer preserves the identity of the user's target, uses Playwright's waiting and strictness as evidence, and fixes the state boundary that made the action unsafe. Choose locators that explain the scenario in a report, diagnose the exact actionability condition, and accept force, first, or XPath only when the requirement itself justifies that compromise.