Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Workday hiring for Playwright Testing roles
Workday is an enterprise cloud software company that provides applications for human resources, finance, planning and payroll. Large organisations use its platform to manage employees, hiring, financial accounting and analytics. It has a growing India presence that hires software engineers, quality engineers, data engineers and support roles, and many organisations also hire Workday functional and technical consultants.
For Playwright Testing roles, this Workday practice set focuses most on Network Mocking (6), API Testing (6), Framework Design and CI/CD (6), Parallel Runs, Sharding & Reporting (5). It has 27 medium, 13 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Pleasanton, California, USA
Main India offices
Pune
Workday Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (design or domain)
Hiring manager and behavioural round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for WorkdayStart 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 do you listen to all network requests on a page?
Subscribe to events: page.on('request', r => ...), page.on('response', r => ...) and page.on('requestfailed', r => ...). You can log URLs, collect API calls or count failures. Unlike route, listeners only observe and cannot change traffic. They are handy for checks like 'no request returned a 5xx status during this flow'.
02
How do you pass slots and listen to events in a Vue component test?
With the Vue package you can mount with an options object: mount(Button, { props: { label: 'Save' }, slots: { default: 'Click me' }, on: { click: handler } }). The on map receives emitted events, so you can push payloads into an array and assert on them. JSX syntax is also supported if the project is configured for it.
They are built-in utility types. Partial<User> makes all fields optional, handy for override objects in test data builders. Pick<User, 'id' | 'email'> keeps chosen fields, and Omit<User, 'password'> removes some. Record<Role, string> maps every key of a union to a value type, for example storing a credentials file path per role.
04
How do you return a fake JSON response that depends on the request body?
First confirm the contract: should unknown fields be rejected with 400 or silently ignored? Then send a valid body with an extra field and assert that behaviour. If they are ignored, fetch the record and check the extra field was not stored. Also try sending a field that should be read-only, such as role or id, to catch mass assignment bugs.
06
Test data is left behind when tests fail midway. How do you guarantee cleanup?
Create the data inside a fixture and delete it after await use(). Fixture teardown runs even when the test fails or times out, so cleanup is reliable. Avoid cleanup steps at the end of the test body, because they never run after a failed assertion. As a safety net, tag test data with a prefix and run a nightly cleanup job.
Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.
09
How do you assert that a request was sent with the correct payload?
Fix the locale for the test with the locale and timezoneId options so the format is predictable. Build the expected string with Intl.NumberFormat using the same locale, rather than hard-coding it. If you test several locales, run them as projects or parameterised tests. For business logic, also assert the raw number through the API response.
11
Your test clicks a button before the page's JavaScript has attached its handler, so nothing happens. What do you do?
This is a hydration problem: the button is visible and enabled but not yet interactive. Wait for a signal that the app is ready, such as a loaded data request or a visible element that only appears after hydration, then click. A better fix is to report it to developers, because real users hit the same issue. Avoid fixed waitForTimeout calls.
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.
14
Show a config with a setup project and a browser project that reuses its login.
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.
16
The app logs in through a third-party OAuth pop-up. How do you automate it?
For most tests, avoid the pop-up: get a session through a test login API or a test identity provider and save it with storageState. Keep one test for the real flow, using const popup = page.waitForEvent('popup') before clicking, then fill the provider's form inside popup. Third-party pages can change and add captchas, so limit how often you depend on them.
17
Tell me about a time you reduced pipeline time with parallel runs or sharding.
Situation: our regression suite took 55 minutes, so developers skipped it. Task: bring it under 15. Action: I removed shared test data so fullyParallel could be turned on, split the three slowest files, and ran four shards with blob reports merged into one HTML report. Result: the suite finished in 12 minutes and it became a required check on every pull request.
18
What does the JSON reporter output and how would you use it?
The JSON reporter writes the full suite tree with every test, its status, retries, duration, errors and attachment paths into one file. Teams parse it in scripts to post a summary to chat, to collect flaky tests that passed on retry, or to push results to a database for trends. Set outputFile so the JSON does not mix with console output.
19
Design a Playwright framework for a 500-test suite.
TypeScript + POM + custom fixtures, environment configs, API helpers for test data, tags like @smoke, sharding across CI machines, retries with traces, HTML/Allure reports, lint and review rules.
Run it many times in isolation: npx playwright test cart.spec.ts -g 'apply coupon' --repeat-each=30 --workers=4 --trace=on. Repeating it with several workers creates the timing pressure CI has. Add --retries=0 so failures are not hidden. Once it fails, open the trace for that run and compare it with a passing run.
21
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.
22
Two test files edit the same global settings page and break each other when run in parallel. How do you handle it?
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.
23
Images load lazily and are sometimes missing from full-page screenshots. How do you make them stable?
Scroll the content into view or remove loading=lazy for the test, then wait until every image has loaded, for example with expect.poll checking that all img elements report complete and a natural width above zero. Serving images from mocked routes removes network timing too. Only after that call toHaveScreenshot, which then waits for two identical frames.
24
Component and end-to-end tests run together and slow down every commit. How do you separate them?
Give them separate configs, such as playwright-ct.config.ts with its own testDir for component specs and playwright.config.ts for end-to-end tests, because component tests also need the bundler options and framework test import. In CI, run component tests on every commit as a fast job and end-to-end tests later or in parallel. Shared settings like reporters can live in a common module both configs import.
Use response.headers() for an object of lower-cased header names, or headersArray() for duplicates. Assert content-type contains application/json, cache-control matches the policy, and security headers such as strict-transport-security are present. Also check that sensitive headers like server version are not exposed. Header checks catch configuration bugs that body checks miss.
26
How does sharding split tests when fullyParallel is on compared with off?
With fullyParallel off, Playwright shards by test file, so one large file always lands on one shard and shards can be uneven. With fullyParallel on, it shards by individual test, giving much more even distribution. Either way the split is deterministic, so the same shard number always gets the same tests for a given set of files, which helps reproduce failures.
27
How do you test a page in dark mode or with reduced motion?
Set colorScheme: 'dark' or reducedMotion: 'reduce' in the context options or test.use. You can also switch during a test with page.emulateMedia({ colorScheme: 'dark' }). Then assert the right styles or take a screenshot comparison. Reduced motion also helps stability, because many apps skip animations when that preference is set.
28
How do you test that duplicate POST requests do not create duplicate orders?
If the API supports an idempotency key header, send the same POST twice with the same key and assert one order exists and both responses return the same id. Send it with different keys and expect two orders. Also try concurrent requests with Promise.all to check race conditions. Without a key, document the risk to the team.
29
How do you integrate Playwright with Allure or other reports?
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.
Generate mock data from the API schema or real recorded responses instead of hand-writing it. Validate mocks against the OpenAPI schema in a unit test. Add contract tests on the backend side and re-record HAR files on a schedule. Keep a few unmocked end-to-end tests that run after each deploy. Treat mock files as code with owners and reviews.
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.
36
What are fixtures and how do you create a custom one?
and() returns a locator that matches elements satisfying both locators, for example a button that also has a certain title. or() matches either locator, which helps when the UI may show one of two states, such as a New email button or a security dialog. With or(), wrap the assertion carefully, because if both appear the strict check fails.
38
How would you design API test coverage for a new endpoint?
Use the official Playwright image which contains browsers and dependencies, mount the project and run npx playwright test for consistent CI environments.
40
How do you handle rate limits or slow APIs in tests?
Add retries with backoff for the API step, set a suitable timeout, and use mocks for non-critical dependencies.
Tips to crack the Workday Playwright Testing interview
Practise DSA problems and object-oriented design, and be ready to explain your reasoning clearly while coding live.
Learn basic HR and finance business processes, which helps you understand how Workday applications are used by customers.
Prepare behavioural stories showing collaboration and customer focus, since Workday highlights its people-first culture and core values.
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; Workday interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Workday Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (design or domain); Hiring manager and behavioural 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 Workday Playwright Testing interview?
This practice set leans on Network Mocking (6), API Testing (6), Framework Design and CI/CD (6), Parallel Runs, Sharding & Reporting (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Workday interviewers ask you to walk through real work.
Are these the exact questions asked at Workday?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Workday's. They are not a leaked or verified list of past questions.
Where does Workday hire Playwright Testing professionals in India?
Workday has large teams in Pune. Openings and locations change often, so check the Workday careers page and filter by city and experience.
Playwright Testing questions for similar companies