5 technical interview questions with model answers — practise the English vocabulary and structure of strong Playwright responses.
0 / 10 completed
1 / 10
The interviewer asks: "How do you make your Playwright selectors resilient to UI changes?" Which answer best demonstrates expertise?
Option B is strongest: it explains the reasoning (semantic matching, accessibility signal) not just the preference. Option A (CSS selectors) is fragile. Option C (test-ids) is acceptable but doesn't explain the trade-off. Option D (XPath) is rarely preferred in modern Playwright.
2 / 10
The interviewer asks: "Explain how Playwright fixtures work." Which answer is most complete?
Option C demonstrates depth: composability, lazy evaluation, and scoping are the three key fixture concepts. Option A and B show surface-level understanding. Option D is incorrect — fixtures don't automatically mock; that's MSW or route handlers.
3 / 10
The interviewer asks: "How do you debug a flaky test that fails only in CI?"
Option C shows systematic debugging: trace-first, then hypothesis-driven investigation. Mentioning trace, viewport differences, and CPU throttling shows real CI debugging experience. Options A, B, and D are poor practices that don't address the root cause.
4 / 10
The interviewer asks: "When would you use the Page Object Model?"
Option C shows pragmatic judgment: not dogmatic about POM, but articulates when it adds value (scale, repeated journeys) vs when it's overhead (simple tests). This "it depends" answer with clear criteria is exactly what interviewers want to hear.
5 / 10
The interviewer asks: "How do you handle authentication in Playwright tests without logging in for every test?"
Option C demonstrates production-level thinking: storageState for reuse, multiple state files for multiple roles, and route interception for OAuth flows. This shows experience with real authentication complexity, not just the basic login form scenario.
6 / 10
Sarah from the QA team just left a comment on your PR describing a failing test. The error message is: 'TypeError: Cannot read property 'name' of undefined'. She asks, "How can I ensure my Playwright tests are robust against changes in the page structure and handle potential missing data?"
This situation requires a practical response to a common Playwright issue. The correct answer focuses on using try...catch blocks with Page.locator to handle potentially missing elements safely, avoiding brittle selectors and preventing test failures. Options A and C are incorrect because they misdiagnose the root cause or suggest inappropriate strategies for handling undefined data. Option D is unreliable due to relying solely on evaluate which can introduce additional complexity and potential issues.
7 / 10
During a standup meeting with the team, your manager asks: "Can you briefly describe how Playwright fixtures contribute to test maintainability and reusability?"
Fixtures are a crucial component of Playwright testing best practices. They allow you to isolate your tests by setting up the necessary conditions – such as database connections or logged-in user states - before each test run. This eliminates redundant setup code and ensures consistent test environments. Options A, C, and D misrepresent the core purpose and benefits of fixtures.
8 / 10
You've identified a flaky Playwright test that intermittently fails in your CI environment. The logs show it's failing due to timing issues. A colleague suggests: "Let's use Page.pause() after each interaction to ensure the page has fully loaded before proceeding."
While Page.pause() can sometimes help with flaky tests caused by asynchronous loading, it's not a robust solution in itself and can mask underlying issues. The correct answer acknowledges its value but emphasizes that it is a blunt tool. Using waitForTimeout provides a more controlled approach to allowing time for asynchronous operations without the risk of introducing artificial delays or making tests overly sensitive to timing variations – which are often the source of flaky tests.
9 / 10
You're reviewing a colleague's PR that includes a Playwright test. The description reads: "This test verifies the user can successfully log in to the application and navigate to the dashboard after entering valid credentials."
A good PR description for a Playwright test needs to provide sufficient context for reviewers. The provided description is too high-level and doesn't address crucial aspects like error handling or data validation. Including details about how the test handles invalid credentials or verifies user input would significantly improve its clarity and usefulness.
10 / 10
Your team is discussing strategies for handling authentication in Playwright tests. A junior developer suggests: "We should manually login to the application every time a test runs."
Manually logging in to the application for every test is highly discouraged in Playwright. It's inefficient, error-prone (due to potential credential changes or incorrect login steps), and doesn't scale well. Using fixtures to manage authentication state is a much more robust and maintainable approach, ensuring consistent test environments and preventing flaky tests.
What does "Playwright Engineer Interview Questions — English Practice" cover?
Practise English for Playwright testing interviews: locators, fixtures, traces, page object model, and test architecture vocabulary.
How many questions are in this interview set?
This set has 10 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.