Red Hat Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Red Hat hiring for Playwright Testing roles
Red Hat is an open source software company, now part of IBM, known for Red Hat Enterprise Linux, OpenShift and Ansible. It provides enterprise Linux, hybrid cloud, container and automation platforms with subscription-based support. In India it has a large presence in Pune and Bengaluru, hiring software engineers, quality engineers, support engineers and consultants.
For Playwright Testing roles, this Red Hat practice set focuses most on Parallel Runs, Sharding & Reporting (7), Framework Design and CI/CD (6), Visual & Accessibility Testing (5), Locators and Assertions (5). It has 2 easy, 28 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Raleigh, North Carolina, USA
Main India offices
Pune, Bengaluru
Red Hat Playwright Testing interview process
Online assessment or resume screening
Technical round 1 (Linux + programming)
Technical round 2 (domain or open source)
Hiring manager and HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Red HatStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
How can you apply extra CSS only while a screenshot is taken?
Pass the stylePath option to toHaveScreenshot or set it in the expect.toHaveScreenshot section of the config. The stylesheet is injected just for the capture, so you can hide scrollbars, freeze a carousel, or set visibility hidden on dynamic widgets without changing the app. It is cleaner than adding test-only classes and also works when a mask box would cover too much of the layout.
Write a custom reporter or parse the JSON report after each CI run, and store per test: id, status, retry count, duration, branch and commit. A test that passed after a retry counts as flaky. Aggregate over the last few hundred runs to rank tests by flake rate and duration, and show trends. Use it to assign owners and quarantine tests above an agreed threshold.
Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.
07
How do you debug a test in VS Code with the Playwright extension?
Install the Playwright Test for VS Code extension. Open the Testing panel to see tests, then set a breakpoint in the test file and click Debug Test. Execution stops at the breakpoint with the browser open, so you can inspect variables. Turn on Show browser to watch runs, and use Pick locator or Record at cursor to add steps.
08
How do you verify a page's URL and title after navigation?
await page.getByRole('link', { name: 'Orders' }).click();
await expect(page).toHaveURL(/\/orders$/);
await expect(page).toHaveTitle('My Orders | Shop');
// both retry, so no need to wait for navigation manually
09
Visual tests pass on developers' laptops but fail in CI with tiny font differences. Why, and how do you fix it?
Font rendering, anti-aliasing and installed fonts differ between Windows, macOS and Linux, so the same page produces slightly different pixels. The fix is to generate and compare baselines in one fixed environment, usually the official Playwright Docker image used in CI. Developers update baselines by running that container locally or through a CI job, not from their own machines. Loosening thresholds should be the last resort.
10
A designer changes the primary button colour and 300 visual tests fail at once. How do you handle it?
First confirm the change is intended and check a sample of diffs to make sure nothing else moved. Then regenerate baselines in the CI Docker environment in a separate commit, so reviewers can see only image changes. Longer term, reduce the count: most of those tests should not snapshot full pages. Keep a few page-level shots and move detail checks to component-level screenshots of key states.
11
How do you integrate Playwright with Allure or other reports?
--last-failed works only on the machine that kept the .last-run.json file, so it does not help across shards. Instead collect the failed tests from the merged JSON report or the blob reports, then run them in a follow-up job by file and line or with --grep on their titles. Many teams simply rely on retries and treat any test needing a rerun as flaky.
13
How do you locate elements inside a specific row or card?
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
It works badly for highly dynamic pages such as live feeds, personalised dashboards or content managed by editors, where most diffs are expected. It is also costly when the design changes every sprint, because baseline reviews eat time. In those cases use functional assertions, ARIA snapshots or component-level screenshots of fixed states instead of full-page pictures.
15
What is the difference between workerIndex and parallelIndex?
workerIndex is a unique number for every worker process started during the run, so it keeps growing when a worker is restarted after a failure. parallelIndex is a slot number from 0 to workers minus 1, and a restarted worker reuses its slot. Use parallelIndex, also exposed as TEST_PARALLEL_INDEX, to pick a fixed test account or database per slot.
16
CI runners have 2 CPU cores and workers is set to 8. Tests start timing out randomly. Why?
Eight browsers compete for two cores and limited memory, so pages render slowly, actions hit timeouts and the app under test may also be overloaded. More workers than cores rarely helps. Set workers to match the runner, such as 2, and scale out with shards on more machines instead. Watch CPU and memory metrics in CI to confirm.
17
Describe a time you improved how test results were reported to the team or managers.
Situation: managers only heard pass or fail and could not tell flaky tests from real bugs. Task: make results useful. Action: I added a custom reporter that posted a short summary to our team chat with failures, flaky tests and a report link, and a weekly trend of flake rate. Result: flaky tests dropped by half in two months because owners could see them.
18
How do you test file downloads and verify their content?
testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.
23
The team wants to replace all end-to-end tests with component tests to save time. What do you advise?
Agree to move detailed UI checks down to component tests, because they are faster and more precise. But keep a thin layer of end-to-end tests for critical journeys like signup, checkout and payment, since component tests use mocked data and cannot catch broken APIs, routing or deployment issues. Decide per risk, measure runtime savings, and track escaped defects after the change.
24
How do you wrap a component in a theme or router provider using hooksConfig?
Scanners like axe find rule-based problems such as missing labels, bad contrast or invalid ARIA, which is roughly a third to a half of real issues. They cannot judge whether alt text is meaningful, whether focus order makes sense, whether error messages are understandable, or whether a screen reader user can actually finish the task. So automated scans are combined with keyboard tests and periodic manual checks with screen readers.
26
A multi-select filter test passes even when an extra option stays selected. How do you tighten it?
The test probably checks only that the wanted options are selected, for example with a loop of toBeChecked or a contains check. Replace it with await expect(select).toHaveValues(['red', 'green']), which passes only when exactly those values are selected, and it retries until the timeout. For custom multi-select widgets, assert the full list of selected chips with toHaveText on the chip locator.
27
How do you return a fake JSON response that depends on the request body?
With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.
29
An API returns 200 but the body contains an error field. How should your test catch this?
Never trust status alone. Assert the body structure, for example that error is absent and data has the expected fields, ideally with a schema check. Report the issue, because returning 200 for errors breaks clients and monitoring. Add a helper that validates both status and body shape so every test checks it consistently.
A Promise represents a value that will be available later, such as an API response. It is pending at first, then either fulfilled with a value or rejected with an error, and it never changes after that. You consume it with await or then and catch. Almost every Playwright call returns a Promise, which is why tests use await so much.
31
How do you handle date pickers and custom dropdowns?
The best fix is to remove the shared resource, for example by giving each test its own tenant or user whose settings it can change. If that is impossible, put those tests in one file with test.describe.configure({ mode: 'serial' }), or in a separate project that runs with one worker after the main project. Document why, so the exception does not quietly spread.
page.route applies only to requests from that page. context.route applies to every page in the browser context, including pop-ups and new tabs opened later. Use context.route when a flow opens new windows, such as a payment pop-up, or when you set up mocks in a fixture before the page exists. Page routes take priority over context routes.
Use the official Playwright image which contains browsers and dependencies, mount the project and run npx playwright test for consistent CI environments.
37
Component tests fail because imports like @/utils cannot be resolved, though the app builds fine. How do you fix it?
The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.
38
Tell me about a disagreement with a developer over a failing test.
Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.
Use page.route to intercept the call and fulfil it with fixed JSON so tests do not depend on external systems.
Tips to crack the Red Hat Playwright Testing interview
Get comfortable with Linux commands, shell scripting, processes, permissions and networking, which are central to many Red Hat roles.
Contribute to an open source project or show GitHub work, since Red Hat values public collaboration and community involvement.
Learn the basics of containers, Kubernetes and Ansible, and consider Red Hat certifications such as RHCSA for support roles.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Red Hat interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Red Hat Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment or resume screening; Technical round 1 (Linux + programming); Technical round 2 (domain or open source); Hiring manager and HR round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Red Hat Playwright Testing interview?
This practice set leans on Parallel Runs, Sharding & Reporting (7), Framework Design and CI/CD (6), Visual & Accessibility Testing (5), Locators and Assertions (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Red Hat interviewers ask you to walk through real work.
Are these the exact questions asked at Red Hat?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Red Hat's. They are not a leaked or verified list of past questions.
Where does Red Hat hire Playwright Testing professionals in India?
Red Hat has large teams in Pune, Bengaluru. Openings and locations change often, so check the Red Hat careers page and filter by city and experience.
Playwright Testing questions for similar companies