Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Druva hiring for Playwright Testing roles
Druva is a data protection and backup software company that offers a cloud-native SaaS platform for backup, recovery and data security. It protects data across endpoints, SaaS applications and cloud workloads for enterprises worldwide. The company was founded in Pune, and its large Pune engineering centre hires software engineers, quality engineers, cloud engineers and site reliability engineers.
For Playwright Testing roles, this Druva practice set focuses most on Fixtures and Hooks (6), Parallel Runs, Sharding & Reporting (5), Locators and Assertions (5), Framework Design and CI/CD (5). It has 30 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
California, USA
Main India offices
Pune
Druva Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (OS, networking or design)
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for DruvaStart 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 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.
Functions that take other functions as arguments or return them, such as map, filter and reduce, or a helper that wraps retry logic around a test step.
03
How do you test geolocation, permissions and time zones?
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.
05
An endpoint streams server-sent events. How would you test it with Playwright?
The request fixture returns the full body only after the stream ends, so for a short finite stream you can read text() and parse each data line. For long-lived streams, test in the browser: open the page that uses EventSource, or open it inside page.evaluate, collect events into an array and assert with expect.poll. Mock the source with a route when you need precise timing.
06
A locator matches three Delete buttons and the test fails with a strict mode violation. How do you fix it?
First scope the locator to the item you mean, for example the row that contains the user's name: page.getByRole('row', { name: 'Ravi Kumar' }).getByRole('button', { name: 'Delete' }). Do not reach for first() or nth() as a quick fix, because the order can change and the test may delete the wrong record. Scoping by meaningful context is stable and readable.
07
One shard finishes in 4 minutes and another takes 15. How do you balance them?
Check whether fullyParallel is off, because file-level sharding puts big files together. Turn it on if tests are independent, or split the largest files. Use reportSlowTests and the merged report's durations to find heavy files, and move slow setup into API calls or shared storage state. Also check that one shard is not getting all the tests of a slow project such as WebKit.
08
Write a test that deletes a record and confirms it is gone.
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.
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.
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.
Call both versions, for example /v1/orders/42 and /v2/orders/42, with the same test data. Map the fields that should match, since names may differ, and compare them with toEqual. Also assert that fields removed in v2 are really absent and new ones have correct types. Running this during a migration catches breaking changes before clients switch.
17
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.
18
How does expect.poll work and when would you use it?
expect.poll calls a function again and again until the value it returns passes the matcher or the timeout runs out. It is useful for values that are not locators, such as an API status or a database count. Example: await expect.poll(async () => (await request.get('/api/job/7')).status()).toBe(200). You can tune the intervals and the timeout.
If the app registers a service worker, it may answer requests from its own cache, so page.route never sees them and mocks seem ignored. Set serviceWorkers: 'block' in the context or config options to turn them off when mocking. If you specifically test offline or PWA caching, keep them enabled and test that behaviour separately.
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.
23
How do you attach axe results to the Playwright HTML report?
Situation: three interns joined with little automation experience. Task: make them productive without lowering quality. Action: I ran short sessions on fixtures, locators and traces, paired with each of them on a first test, and gave detailed but kind review comments. Result: within a month they each shipped stable tests, and one later improved our reporting script.
27
Promise.all vs Promise.allSettled vs Promise.race?
all waits for every promise and rejects on the first failure; allSettled waits for all and reports each outcome; race settles with the first one to finish.
28
What is the difference between click and dispatchEvent?
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.
A trace contains every action with its timing, DOM snapshots before and after each action, screenshots in a filmstrip, console messages, network requests with headers and bodies, the source line of each step and the error. Because the DOM snapshots are real, you can inspect elements after the run. It is usually the fastest way to understand a CI failure.
36
How do you simulate a slow API to test a loading spinner?
Worker fixtures live across many tests, so any test that changes their data affects the next ones. Keep worker fixtures read-only, such as a connection or a reference catalogue. Move anything a test modifies into a test-scoped fixture that creates fresh data. If sharing is needed for speed, reset the relevant state in the test fixture before use.
38
How do you test how the UI handles a 500 error from the orders API?
Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.
39
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.
40
How do you mock a paginated endpoint that returns different data per page?
Tips to crack the Druva Playwright Testing interview
Revise operating systems, file systems and networking basics, since backup and storage products rely heavily on these concepts.
Practise DSA problems in your main language and be ready to discuss how you would design a scalable backup service.
Learn basic cloud services such as object storage and compute on AWS to connect your skills with Druva's platform.
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; Druva interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Druva Playwright Testing interview?
Candidates usually go through 5 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (OS, networking or design); Hiring manager round; 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 Druva Playwright Testing interview?
This practice set leans on Fixtures and Hooks (6), Parallel Runs, Sharding & Reporting (5), Locators and Assertions (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 Druva interviewers ask you to walk through real work.
Are these the exact questions asked at Druva?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Druva's. They are not a leaked or verified list of past questions.
Where does Druva hire Playwright Testing professionals in India?
Druva has large teams in Pune. Openings and locations change often, so check the Druva careers page and filter by city and experience.
Playwright Testing questions for similar companies