Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About NielsenIQ hiring for Playwright Testing roles
NielsenIQ is a global consumer intelligence company that measures retail sales, shopper behaviour and product performance for consumer goods manufacturers and retailers. It became a separate company from Nielsen and is now often branded as NIQ. In India it runs large operations and technology centres that hire data analysts, data scientists, software engineers and client service analysts.
For Playwright Testing roles, this NielsenIQ practice set focuses most on Network Mocking (7), Fixtures and Hooks (6), API Testing (5), Component Testing (5). It has 6 easy, 26 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Chicago, USA
Main India offices
Vadodara, Chennai, Pune
NielsenIQ Playwright Testing interview process
Online assessment (aptitude + Excel or SQL)
Technical interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for NielsenIQStart 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 Playwright and which browsers does it support?
Each worker is a separate process with its own state. When tests from a file are split across workers, or a worker restarts after a failure, beforeAll runs again in the new worker. So never assume it runs only once globally. For one-time setup across the whole run, use a setup project with dependencies or globalSetup.
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.
05
A feature is controlled by a flag served from a config API. How do you test both states?
Mock the config endpoint in a fixture option so each test chooses the flag value, for example featureFlags: { newCheckout: true }. Run the flow with the flag on and off and assert the different UI. Mocking avoids changing shared environment settings that would affect other testers. Also keep one test against the real config to catch wiring mistakes.
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.
08
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.
09
How would you handle a very flaky element that appears after an animation?
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.
13
How is a component test different from an end-to-end test?
An end-to-end test opens the full deployed app, logs in and goes through pages backed by a real server. A component test mounts one component in isolation with props you control, so there is no backend, routing or login. Component tests are faster and pinpoint the failing piece, while end-to-end tests prove the parts work together. A healthy suite has many component tests and fewer end-to-end journeys.
14
Write a test that updates a user with PUT and verifies the change.
Situation: a new checkout redesign was ready for release. Task: I had just added an axe scan to our Playwright smoke tests. Action: the scan flagged that the payment form inputs had placeholder text but no labels, and a keyboard test showed the pay button was unreachable with Tab. I raised it with screenshots and the rule links. Result: the developer fixed both in a day and the release went out on time.
16
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.
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.
It is a lint plugin with rules for common Playwright mistakes, such as missing await on assertions, leftover test.only or page.pause, forced clicks, fixed waits with waitForTimeout and element handles instead of locators. Running it in pull requests stops bad patterns before review. Teams usually enable the recommended rule set and add a few stricter rules over time.
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.
21
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.
Listen with page.on('console', msg => ...) for console.log, warnings and errors, and page.on('pageerror', err => ...) for uncaught exceptions. Collect them in an array and attach them to the report on failure. Traces also show console output. Uncaught page errors often explain why a button did nothing or a page stayed blank.
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.
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.
28
How do you wrap a component in a theme or router provider using hooksConfig?
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.
30
How do you handle authentication to avoid logging in every test?
The blob reporter writes a compact archive of everything about a run, including results, attachments and traces, into the blob-report folder. It is meant for machines rather than people. Each shard produces one blob, and npx playwright merge-reports later combines them into a single HTML, JUnit or JSON report. Without it, every shard would produce its own separate HTML report.
32
How would you design API test coverage for a new endpoint?
Collect data first: flaky results from the reports across a few weeks, grouped by test, browser and error message. Run the worst offenders with --repeat-each and traces on. Fix common causes such as missing awaits, shared data, fixed sleeps and order-dependent tests. Quarantine tests you cannot fix quickly with a tag and a ticket, and track the rate weekly.
34
How do you block images and fonts to speed up tests?
Block it in tests with context.route on its domain and route.abort, or fulfill it with an empty script. Analytics is not what you are testing, and blocking it removes delays and random network errors. If tracking events matter, write a few separate tests that capture the requests with waitForRequest and assert their parameters.
Record once with page.routeFromHAR('data/orders.har', { url: '**/api/**', update: true }) while running against a real server. Later runs replay the saved responses from the HAR instead of hitting the backend. You can edit the stored JSON to create edge cases. Re-record when the API changes, otherwise the replay drifts from reality.
38
Write an accessibility scan that checks only WCAG 2.1 A and AA rules.
An ARIA snapshot is a YAML description of the accessibility tree for a part of the page: roles, names and states such as checked or level. toMatchAriaSnapshot compares the live tree of a locator against that template, and partial templates or regular expressions can be used for changing text. It tests structure and semantics, so it survives styling changes that would break a pixel screenshot.
maxFailures stops the run after a set number of test failures, for example maxFailures: process.env.CI ? 10 : undefined. If an environment is down and every test fails, the build stops early instead of burning an hour of CI time. Set it high enough that a few real failures still show their full picture.
Tips to crack the NielsenIQ Playwright Testing interview
Practise Excel functions like VLOOKUP, pivot tables and charts, plus basic SQL, which are common for analyst roles.
Learn retail measurement concepts such as market share, distribution and sales trends to discuss consumer goods data confidently.
Prepare examples showing attention to detail and data quality checks, since accuracy matters a lot in market measurement work.
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; NielsenIQ interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the NielsenIQ Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + Excel or SQL); Technical interview; Managerial 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 NielsenIQ Playwright Testing interview?
This practice set leans on Network Mocking (7), Fixtures and Hooks (6), API Testing (5), Component Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most NielsenIQ interviewers ask you to walk through real work.
Are these the exact questions asked at NielsenIQ?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like NielsenIQ's. They are not a leaked or verified list of past questions.
Where does NielsenIQ hire Playwright Testing professionals in India?
NielsenIQ has large teams in Vadodara, Chennai, Pune. Openings and locations change often, so check the NielsenIQ careers page and filter by city and experience.
Playwright Testing questions for similar companies