Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About EXL hiring for Playwright Testing roles
EXL is a data analytics and digital operations company serving insurance, healthcare, banking and other industries. Its analytics teams build models for risk, marketing, collections and claims. In India it hires for business analysts, data analysts, data scientists and operations roles, many of them in insurance and banking analytics.
For Playwright Testing roles, this EXL practice set focuses most on JavaScript and TypeScript (6), Locators and Assertions (5), Playwright Core (5), Component Testing (4). It has 8 easy, 30 medium, 2 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
New York, USA
Main India offices
Noida, Gurugram, Bengaluru, Pune
EXL Playwright Testing interview process
Online assessment (aptitude + SQL or analytics)
Technical interview
Case or guesstimate round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for EXLStart 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
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.
// scan the page but skip the chat widget you do not own
const results = await new AxeBuilder({ page })
.include('main')
.exclude('#third-party-chat')
.disableRules(['duplicate-id'])
.analyze();
expect(results.violations).toEqual([]);
// log a ticket for anything you exclude
05
Tell me about a time you explained a failing test report to a non-technical stakeholder.
Situation: a product manager saw a red build and wanted to delay the release. Task: explain what actually failed. Action: I opened the HTML report, grouped failures into one real bug in the coupon flow and two flaky tests, and showed the screenshot of the real bug in plain words. Result: we shipped after the coupon fix, and the manager asked for that short summary on every release.
06
What is the difference between click and dispatchEvent?
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'.
09
How do you attach axe results to the Playwright HTML report?
Auto-waiting, a built-in test runner, Chromium/Firefox/WebKit with one API, network interception, the trace viewer and parallel runs out of the box — usually faster and less flaky.
getByRole finds elements by their ARIA role and accessible name, the same way screen readers and users see the page. For example getByRole('button', { name: 'Save' }) keeps working when CSS classes or DOM structure change. It also pushes the team towards accessible markup. The trade-off is that badly built components without proper roles may need a test id instead.
14
How do you add or change request headers for only some requests?
Register a route for the matching URLs and call route.continue({ headers: { ...route.request().headers(), 'x-test-mode': 'true' } }). Other requests are untouched. For headers on every request, use extraHTTPHeaders in the config instead. This is useful for feature toggles, tenant ids or bypass tokens that only certain endpoints accept.
15
What is the difference between the list, line and dot reporters?
All three print to the terminal. list prints one line per test with its status and is the default locally. line shows a single updating line with progress and prints only failures in full, which suits long runs. dot prints one character per test, the most compact output, and is the default on CI. Choose based on how much log noise you want.
16
Why are component tests usually faster than end-to-end tests?
They skip the expensive parts: no full app start, no backend calls, no login and no navigation through several pages. Playwright builds the component bundle once and each test simply mounts into an already loaded page. A typical component test finishes in well under a second, so hundreds can run in a pull request check, while end-to-end flows take several seconds each.
17
How do you balance pressure to automate quickly against writing stable tests?
Situation: a manager wanted 50 tests for a release in one week. Task: deliver without creating a flaky suite. Action: I agreed on the 20 highest-risk flows first, used stable locators and shared fixtures, and listed the rest as follow-ups. Result: the 20 tests ran green in CI from day one and the rest were added next sprint.
18
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.
19
Write code to fill a login form using label-based locators.
It is the entry file bundled into the component test page, so it runs in the browser before every mount. You import global CSS, fonts and theme files there, and register beforeMount and afterMount hooks to wrap components in providers such as a router, theme or state store. Keeping this setup in one place means individual tests can mount components without repeating boilerplate.
A fixture defined with { auto: true } runs for every test even when the test does not ask for it. It is useful for cross-cutting work such as attaching console logs on failure, setting a feature flag or checking for leftover data. Keep auto fixtures light, because they add cost to every test in the suite.
22
What does force: true do on an action, and why should you avoid it?
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.
23
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.
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.
26
How do you handle token refresh in long API test runs?
Run in parallel with sharding, reuse authentication state, set up data through APIs, avoid unnecessary waits, run smoke on every commit and the full suite nightly.
Component testing mounts a single UI component, such as a React or Vue button or form, in a real browser page and tests it with the normal Playwright API. Playwright bundles the component with Vite, serves it on a small page and gives you a mount fixture. You get real browser rendering and events, which unit tests in jsdom cannot give, while staying much faster than full end-to-end flows. The feature is still marked experimental.
31
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.
any switches off type checking, so any property access compiles even if it crashes at runtime. unknown accepts any value but forces you to narrow or validate it before use. For API JSON in tests, typing it as unknown and then validating or asserting a type is safer than any, because mistakes appear at compile time.
34
How do you handle date pickers and custom dropdowns?
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.
36
How do you mock a paginated endpoint that returns different data per page?
waitUntil decides when goto considers navigation finished: 'load' waits for the load event and is the default, 'domcontentloaded' waits only for the HTML to parse, 'networkidle' waits for no network for 500 ms, and 'commit' returns when the response starts. Avoid networkidle, which is discouraged and flaky; use assertions on the content you need instead.
test('delete product', async ({ request }) => {
const created = await request.post('/api/products', { data: { name: 'Temp' } });
const { id } = await created.json();
const del = await request.delete(`/api/products/${id}`);
expect(del.status()).toBe(204);
const get = await request.get(`/api/products/${id}`);
expect(get.status()).toBe(404);
});
Tips to crack the EXL Playwright Testing interview
Revise SQL, Excel and statistics such as hypothesis testing and regression, which are core to EXL analytics roles.
Practise guesstimates and simple business cases about credit card customers or insurance claims.
Learn insurance and banking analytics concepts like loss ratio, churn and collections propensity models.
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; EXL interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the EXL Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + SQL or analytics); Technical interview; Case or guesstimate 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 EXL Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (6), Locators and Assertions (5), Playwright Core (5), Component Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most EXL interviewers ask you to walk through real work.
Are these the exact questions asked at EXL?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like EXL's. They are not a leaked or verified list of past questions.
Where does EXL hire Playwright Testing professionals in India?
EXL has large teams in Noida, Gurugram, Bengaluru, Pune. Openings and locations change often, so check the EXL careers page and filter by city and experience.
Playwright Testing questions for similar companies