Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Juspay hiring for Playwright Testing roles
Juspay is a Bengaluru-based payments technology company that builds payment orchestration, checkout and UPI infrastructure for merchants and banks. Its products help businesses manage multiple payment gateways and improve transaction success rates. It is known for using functional programming languages such as Haskell and PureScript, and hires software engineers and product engineers.
For Playwright Testing roles, this Juspay practice set focuses most on JavaScript and TypeScript (8), Playwright Core (7), Network Mocking (5), Locators and Assertions (4). It has 3 easy, 29 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Bengaluru, India
Main India offices
Bengaluru
Juspay Playwright Testing interview process
Online coding assessment or hackathon-style challenge
Technical round 1 (problem solving)
Technical round 2 (design or functional programming)
Hiring manager and culture round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for JuspayStart 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
A third-party analytics script makes tests slow and flaky. What do you do?
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.
02
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.
03
How do you filter a list of locators by text or by a child element?
JavaScript runs one call stack and uses queues for async work; the event loop pushes callbacks from the microtask (promises) and task queues when the stack is empty.
07
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.
08
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.
09
The app polls a status endpoint every few seconds. How do you test the change from Pending to Done?
Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.
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.
11
How do you handle a page that opens a browser permission prompt for notifications?
Browser permission prompts are not part of the page, so you cannot click them. Instead grant the permission up front with the permissions option in the config or context, for example permissions: ['notifications'], or call context.grantPermissions. To test the denied path, create a context without the permission and assert that the app shows its fallback message.
12
How do you read environment variables safely in a TypeScript test project?
Load a .env file with a package like dotenv in playwright.config, then read process.env.BASE_URL. Values are string | undefined, so validate them early and throw a clear error if a required one is missing. Keep .env out of git and commit an .env.example instead. In CI, set the same names as secret variables.
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.
15
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.
readonly and as const stop test data from being changed by accident, for example one test editing a shared user object and breaking the next. as const also keeps literal types, so ['admin', 'viewer'] as const gives the type 'admin' | 'viewer'. That lets TypeScript reject invalid roles at compile time instead of during a run.
17
What is the difference between TypeScript and JavaScript?
TypeScript adds static types on top of JavaScript and compiles to it. Types catch errors early and give better autocomplete, which helps in larger test suites.
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.
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.
22
A test fails only in WebKit. How do you investigate?
Run it alone with --project=webkit --headed and record a trace. Compare it with the Chromium trace to see where behaviour differs, such as date input format, scrolling, font rendering or a missing browser API. Check the app's support matrix. If it is a real product bug, raise it, and skip the test for WebKit with a linked ticket until it is fixed.
Use the blob reporter in each shard job, upload each blob-report folder as an artifact, then in a final job download them all into one folder and run npx playwright merge-reports --reporter html ./all-blob-reports. This gives one HTML report for the whole run instead of one per shard, which makes reviewing failures much easier.
24
Why does Playwright start a new worker after a test fails?
A failed test may leave the browser or worker-scoped fixtures in a bad state, such as an open dialog or corrupted login. To protect the remaining tests, Playwright throws that worker away and starts a fresh one for the next tests. This means worker fixtures run again and beforeAll hooks may run more than once, which is normal and something your setup must tolerate.
25
How do you write a custom matcher with expect.extend?
expect.extend takes an object of matcher functions. Each receives the received value and arguments, and returns { pass, message, name, expected, actual }. For example a toHaveAmount matcher can read a locator's text, strip the currency symbol and compare numbers, retrying with expect.poll inside. Export the extended expect from a shared fixtures file so all tests use the same version.
Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.
28
An API test fails randomly because another test changes the same record. How do you fix it?
Make each test own its data. Create the record inside the test or a fixture with a unique name, such as one using a timestamp or the worker index, and delete it in teardown. Avoid shared seed records for anything that gets modified. Shared read-only reference data is fine. This also lets tests run fully in parallel.
29
How do you test a dropdown component's keyboard support in a component test?
Mount the dropdown, focus the trigger and press Enter or ArrowDown to open it. Assert the listbox is visible and the first option has aria-selected or focus. Press ArrowDown again and check the active option moves, then press Enter and assert the trigger shows the chosen value and the list is closed. Finally press Escape on an open list to confirm it closes without changing the value.
Count the items, then scroll the last item into view with lastItem.scrollIntoViewIfNeeded() or page.mouse.wheel. Assert with expect(items).toHaveCount greater than before, for example using expect.poll on items.count(). Repeat until an end-of-list message appears. Also check no duplicates appear and that a loading indicator shows while fetching.
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'.
35
An API returns 200 but the body contains an error field. How should your test catch this?
Never trust status alone. Assert the body structure, for example that error is absent and data has the expected fields, ideally with a schema check. Report the issue, because returning 200 for errors breaks clients and monitoring. Add a helper that validates both status and body shape so every test checks it consistently.
Put them in the use block of playwright.config: use: { baseURL: process.env.API_URL, extraHTTPHeaders: { Accept: 'application/json', Authorization: `Bearer ${process.env.TOKEN}` } }. The request fixture then sends them on every call, and tests use short paths like /api/users. Keep tokens in environment variables, never in the repository.
40
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.
Tips to crack the Juspay Playwright Testing interview
Practise DSA problems seriously, since Juspay hiring challenges are known to be competitive and focused on problem-solving ability.
Learn functional programming basics like immutability, pure functions and recursion, and try a little Haskell or PureScript.
Understand UPI and card payment flows, including authorisation and settlement, to discuss the domain with confidence.
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; Juspay interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Juspay Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment or hackathon-style challenge; Technical round 1 (problem solving); Technical round 2 (design or functional programming); Hiring manager and culture 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 Juspay Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (8), Playwright Core (7), Network Mocking (5), Locators and Assertions (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Juspay interviewers ask you to walk through real work.
Are these the exact questions asked at Juspay?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like Juspay's. They are not a leaked or verified list of past questions.
Where does Juspay hire Playwright Testing professionals in India?
Juspay has large teams in Bengaluru. Openings and locations change often, so check the Juspay careers page and filter by city and experience.
Playwright Testing questions for similar companies