Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About NetApp hiring for Playwright Testing roles
NetApp is a data infrastructure company that provides storage systems, data management software and cloud data services. Its ONTAP storage software and cloud offerings help enterprises store, protect and move data across on-premises and public cloud environments. Its Bengaluru centre is a major engineering site that hires software engineers, quality engineers and support engineers.
For Playwright Testing roles, this NetApp practice set focuses most on API Testing (6), Framework Design and CI/CD (6), Debugging and Trace Viewer (6), Locators and Assertions (5). It has 1 easy, 26 medium, 13 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
San Jose, California, USA
Main India offices
Bengaluru
NetApp Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA + C)
Technical round 2 (OS, storage or networking)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for NetAppStart 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
Write a test that deletes a record and confirms it is gone.
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.
Call context.setOffline(true) to cut all network access for the context, then check that the app shows an offline banner or queues actions. Switch back with setOffline(false) and verify it syncs. You can also set offline: true in the context options. For a single failing endpoint, use route.abort instead of going fully offline.
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.
08
How do you fail a test if the page logs any console error?
Open the CI trace and go to the failed click. Check the action log, which shows what Playwright waited for, such as the element not being visible or another element intercepting pointer events. Compare before and after snapshots and the network tab for slow or failed calls. Common causes are a slower environment, a cookie banner or different screen size.
Use page.routeWebSocket with a URL pattern. The handler gets a WebSocketRoute: you can reply to messages with ws.onMessage and ws.send without any server, or call connectToServer() to sit in the middle and change messages in both directions. This lets you test live dashboards and chat apps, for example pushing a fake price update.
12
How do you manage flaky tests without hiding real failures?
Use retries in CI so one-off failures do not block merges, but treat any test marked flaky in the report as a defect. Track flaky tests on a dashboard, quarantine repeat offenders with a tag and an owner, and set a deadline to fix or delete them. Never retry without investigating, or real intermittent bugs will be missed.
13
A test must confirm that an error banner does not appear, but it always waits the full timeout. How do you fix it?
Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.
14
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.
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
17
What is the difference between API testing and UI testing?
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.
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.
21
How do you attach a screenshot or log to the report from inside a test?
Newer Playwright versions provide a router fixture in component tests. You call router.route with a URL pattern and fulfil it with test data, much like page.route, and it can also use mock handlers written for Mock Service Worker. Alternatively, inject a fake data client through props or a provider in hooksConfig. Mocking keeps component tests fast and independent of any backend.
23
An API receives a payload with an unknown extra field. How do you test what it should do?
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.
24
A test checks a price that is formatted differently per locale. How do you make the assertion robust?
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.
25
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.
26
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.
27
What is the difference between map, filter and reduce?
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.
29
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.
toPass retries a whole block of code, including several actions and assertions, until it runs without throwing. expect.poll retries only one function that returns a value. Use toPass for flows like 'click refresh, then check the status' that must be repeated together. It has no timeout by default, so always pass a timeout to avoid a hung test.
32
Retries make the build green, but nobody notices flaky tests. How do you surface them?
Playwright already marks tests that passed on retry as flaky in the HTML and JSON reports. Read the JSON report in a small script after each run, post flaky test names to the team channel, and fail the build if the flaky count crosses a threshold. Over time you can track trends per test and per area.
Use the official Playwright image which contains browsers and dependencies, mount the project and run npx playwright test for consistent CI environments.
34
How do you record a trace manually with the tracing API?
Call await context.tracing.start({ screenshots: true, snapshots: true }) before the steps, and await context.tracing.stop({ path: 'trace.zip' }) after them. This is useful in scripts that use the library without the test runner, or when you want a trace of only part of a flow. tracing.group can label sections of steps.
35
Write a typed helper that retries an async function a few times.
force: true skips the actionability checks, so Playwright clicks even if the element is hidden, disabled or covered. It can make a test pass while a real user would be blocked. Use it only for special cases like a custom checkbox whose real input is visually hidden by design. Otherwise fix the cause, such as an overlay.
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.
40
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.
Tips to crack the NetApp Playwright Testing interview
Revise C programming, memory management, operating systems and file systems, which are frequently tested for storage engineering roles.
Learn storage basics such as RAID, snapshots, replication and protocols like NFS, SMB and iSCSI before interviews.
Practise DSA problems and be ready to debug code or explain behaviour of a program step by step.
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; NetApp interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the NetApp Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA + C); Technical round 2 (OS, storage or networking); Hiring manager 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 NetApp Playwright Testing interview?
This practice set leans on API Testing (6), Framework Design and CI/CD (6), Debugging and Trace Viewer (6), Locators and Assertions (5). Revise those first, then practise explaining one or two of your own projects end to end, because most NetApp interviewers ask you to walk through real work.
Are these the exact questions asked at NetApp?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like NetApp's. They are not a leaked or verified list of past questions.
Where does NetApp hire Playwright Testing professionals in India?
NetApp has large teams in Bengaluru. Openings and locations change often, so check the NetApp careers page and filter by city and experience.
Playwright Testing questions for similar companies