Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About PwC hiring for Playwright Testing roles
PwC is one of the Big Four professional services networks, offering assurance, tax, consulting and deals services. In India, PwC member firms and acceleration centres support global clients with technology consulting, data analytics, cyber, risk and process work. It hires for associate and consultant roles in analytics, BI, testing, ERP and risk assurance.
For Playwright Testing roles, this PwC practice set focuses most on Fixtures and Hooks (8), API Testing (5), Component Testing (5), Framework Design and CI/CD (5). It has 9 easy, 26 medium, 5 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
London, United Kingdom
Main India offices
Kolkata, Bengaluru, Mumbai, Hyderabad, Gurugram
PwC Playwright Testing interview process
Online assessment (aptitude + technical)
Group discussion or case round
Technical interview
Partner or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for PwCStart 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
What is the difference between beforeEach and fixtures?
Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.
Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.
// waits until exactly 5 data rows are rendered
const rows = page.getByRole('table').getByRole('row');
await expect(rows).toHaveCount(6); // 1 header + 5 rows
// avoid: expect(await rows.count()).toBe(6)
// that reads once and does not retry
06
Tell me about a bug you found through API testing that UI tests missed.
Situation: the UI hid a delete button for normal users, so UI tests passed. Task: check permissions properly. Action: I called the delete endpoint directly with a normal user's token and it returned 204. Result: the team fixed the server-side permission check, and I added role-based API tests for every admin endpoint.
The error names the action and locator, for example locator.click: Timeout 30000ms exceeded, followed by a call log. The call log lists each attempt, such as waiting for the element to be visible, enabled and stable, or another element intercepting pointer events. The last lines show what blocked the action. Read it before changing timeouts.
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.
Worker fixtures and beforeAll run first for the worker. For each test, the test fixtures it needs are set up, then beforeEach hooks run, then the test body. Afterwards afterEach hooks run, then test fixtures are torn down in reverse order. afterAll and worker fixture teardown run when the worker finishes. Fixtures are lazy, so unused ones never run.
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.
19
What happens before and after await use() in a fixture?
Code before await use(value) is setup and runs before the test. use hands the value to the test and waits while the test runs. Code after it is teardown and runs when the test finishes, even if it failed. This keeps setup and cleanup for one resource in one place, which is cleaner than a separate beforeEach and afterEach pair.
20
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.
21
Tell me about the first time you used the trace viewer to solve a failure.
Situation: during my internship a login test failed only in CI and I could not reproduce it. Task: find the cause. Action: I enabled trace on first retry, downloaded the trace and stepped through the actions, and saw a cookie banner covering the sign-in button in the CI viewport. Result: I added a step to accept the banner, the test became stable, and I shared the method with my team.
ctViteConfig is an option in the use block of playwright-ct.config.ts that passes extra Vite settings to the component bundle. You need it when the app relies on path aliases, plugins, environment defines or special asset handling that Playwright's default Vite setup does not know about. A typical case is adding resolve.alias so imports like @/components work in tests.
24
Describe a time you had to decide which testing level a feature belonged to.
Situation: a pricing table had many discount rules shown in the UI. Task: decide how to test them. Action: I proposed unit tests for the calculation, component tests for how each rule rendered, and one end-to-end test for buying a discounted plan. I explained the runtime and maintenance cost of each. Result: the team agreed, we covered 30 rules in under a minute, and the approach became our default.
Situation: our team ran tests only on laptops before releases. Task: run them automatically on every pull request. Action: I created a CI workflow with browser install, sharding over four machines, merged HTML reports and traces on retry. Result: feedback came within twelve minutes on each pull request, and release-day surprises dropped sharply.
27
How do you take visual snapshots of each component state in component tests?
Mount the component once per state, for example default, disabled, loading and error, and call await expect(component).toHaveScreenshot() for each. Since only the component is on the page, images are small, stable and fast to review. Run them in the same Docker image as CI. This often replaces many full-page visual tests that break for unrelated reasons.
28
What are the serial and parallel modes of test.describe.configure?
test.describe.configure({ mode: 'serial' }) runs tests in order in one worker, and if one fails the rest are skipped. mode: 'parallel' lets tests in one file run across workers. Serial mode suits a true step-by-step flow, but it makes tests depend on each other, so prefer independent tests and use serial only when there is no alternative.
The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.
readonly and as const stop test data from being changed by accident, for example one test editing a shared user object and breaking the next. as const also keeps literal types, so ['admin', 'viewer'] as const gives the type 'admin' | 'viewer'. That lets TypeScript reject invalid roles at compile time instead of during a run.
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.
35
How do you run one group of tests serially while the rest of the suite runs in parallel?
Put the group in its own project with fullyParallel: false and limit it to one worker, which recent versions allow with a workers setting on the project, or run it in a separate CI step with --project=serial --workers=1. Inside a file, test.describe.configure({ mode: 'serial' }) keeps order. Use project dependencies if the group must run after the parallel tests.
Main options are testDir for where tests live, timeout, retries, workers, fullyParallel, reporter, and the use block for shared settings like baseURL, trace, screenshot and video. projects define browsers or setups, and webServer can start the app before tests. Most values can depend on process.env.CI so local and CI runs behave differently.
Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.
39
When should you choose a component test over an end-to-end test?
Choose a component test when the behaviour lives inside one component: validation messages, disabled states, sorting in a table, keyboard handling in a dropdown or rendering of edge-case data. These are slow and awkward to reach through full flows. Choose end-to-end when the risk is in integration, such as routing, authentication or data saved on the server.
Use the official Playwright image which contains browsers and dependencies, mount the project and run npx playwright test for consistent CI environments.
Tips to crack the PwC Playwright Testing interview
Learn about the PwC Professional framework, which covers whole leadership, business acumen, technical capabilities and relationships.
Practise case questions and guesstimates with a clear structure, especially for consulting and advisory roles.
Revise Excel, SQL and a BI tool, and be ready to describe how analysis helped a decision.
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; PwC interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the PwC Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical); Group discussion or case round; Technical interview; Partner or 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 PwC Playwright Testing interview?
This practice set leans on Fixtures and Hooks (8), API Testing (5), Component Testing (5), Framework Design and CI/CD (5). Revise those first, then practise explaining one or two of your own projects end to end, because most PwC interviewers ask you to walk through real work.
Are these the exact questions asked at PwC?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like PwC's. They are not a leaked or verified list of past questions.
Where does PwC hire Playwright Testing professionals in India?
PwC has large teams in Kolkata, Bengaluru, Mumbai, Hyderabad, Gurugram. Openings and locations change often, so check the PwC careers page and filter by city and experience.
Playwright Testing questions for similar companies