Persistent Systems Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Persistent Systems hiring for Playwright Testing roles
Persistent Systems is an Indian technology services company focused on software product engineering, digital transformation, cloud and data services. It serves clients in banking, healthcare, life sciences and software. In India it hires for software engineers, quality engineers, data engineers and analysts, often through campus drives with coding-focused assessments.
For Playwright Testing roles, this Persistent Systems practice set focuses most on JavaScript and TypeScript (6), Framework Design and CI/CD (5), API Testing (5), Parallel Runs, Sharding & Reporting (4). It has 18 easy, 21 medium, 1 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Pune, India
Main India offices
Pune, Nagpur, Bengaluru, Hyderabad, Goa
Persistent Systems Playwright Testing interview process
Online assessment (aptitude + coding)
Technical round 1
Technical round 2
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Persistent SystemsStart 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 the difference between toHaveText and toContainText?
toHaveText checks that the element's full text matches the expected string or regex, after normalising whitespace. toContainText passes if the expected text appears anywhere inside it. Use toHaveText for exact labels like a heading, and toContainText for longer messages where only part matters. Both are web-first assertions, so they retry until the timeout before failing.
02
What is the difference between == and === in JavaScript?
=== compares value and type without conversion, so '5' === 5 is false. == converts types first, so '5' == 5 is true and null == undefined is true. Implicit conversion causes surprising bugs, so test code should always use === and !==. TypeScript and lint rules such as eqeqeq help enforce this.
03
Where does Playwright store baseline screenshots and how are the files named?
By default baselines go into a folder next to the test file named after it, for example checkout.spec.ts-snapshots. The file name combines the name you give, the project name and the platform, such as home-chromium-linux.png. Because the browser and operating system are part of the name, each project keeps its own baseline. You commit these images to the repository so every run compares against the same files.
04
Tell me about a time you reduced pipeline time with parallel runs or sharding.
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.
05
What is the difference between toHaveScreenshot and toMatchSnapshot?
toHaveScreenshot is for images of a page or locator. It waits for the page to become visually stable, retries the capture until two shots match, and supports options like mask and animations. toMatchSnapshot compares any value you pass in, such as a string, a buffer or text output, against a stored file, without waiting or retrying. Use toHaveScreenshot for UI and toMatchSnapshot for generated text or file content.
Import devices from @playwright/test and spread a profile into a project or test.use, for example use: { ...devices['Pixel 7'] }. This sets viewport, user agent, device scale factor, touch support and isMobile. It emulates the browser, not a real phone, so it is good for responsive layout tests but not a replacement for real-device testing.
07
How do you keep test code, page objects and utilities organised as a repository grows?
Use a clear layout: tests grouped by feature, a pages folder for page objects, a fixtures folder that exposes them, and api and data folders for helpers and builders. Add path aliases in tsconfig, a lint config with the Playwright plugin, and a short contributing guide. Review new helpers in pull requests so duplicate utilities do not spread.
08
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.
testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.
11
What does the open option of the HTML reporter control?
open decides whether the report opens in a browser after the run: 'always', 'never' or 'on-failure', which is the default. In CI you set it to 'never' so the process does not try to start a browser or hang waiting. Locally on-failure is convenient. You can also set the PLAYWRIGHT_HTML_OPEN environment variable instead of editing config.
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.
It reruns only the tests that failed in the previous run, using the results stored in the test-results folder. It saves time while you fix failures locally because you do not rerun the whole suite. Combine it with --headed or --debug to investigate. Run the full suite again before pushing to confirm nothing else broke.
15
How do you send query parameters in an API request?
It writes an XML file in the JUnit format, with test suites, test cases, durations and failure messages. Most CI servers and test management tools read this format to show test counts, failures and history in their own dashboards. Set outputFile so the path is predictable, and publish that file as a test result in the pipeline.
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.
The error names the action and locator, for example locator.click: Timeout 30000ms exceeded, followed by a call log. The call log lists each attempt, such as waiting for the element to be visible, enabled and stable, or another element intercepting pointer events. The last lines show what blocked the action. Read it before changing timeouts.
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.
Web-first assertions wait 5 seconds by default. Change it globally in playwright.config with expect: { timeout: 10000 }, or for one assertion with await expect(locator).toBeVisible({ timeout: 15000 }). Raise it only for genuinely slow steps like report generation. Raising it everywhere hides performance problems and makes failing tests slower to report.
25
How do you inspect a specific network request in the trace viewer?
Open the Network tab in the trace viewer, which lists every request in the test. Click one to see method, URL, status, request and response headers and bodies, and timing. Selecting an action filters the list to requests around that step. This shows whether a UI failure came from a failed API, a slow response or unexpected data.
26
How do you mock one GraphQL query when all calls go to /graphql?
Path parameters identify a specific resource and are part of the URL path, like /users/42. Query parameters filter, sort or paginate and follow a question mark, like /users?city=Delhi&page=2. In tests, check invalid path ids return 404, and that each query parameter changes results correctly, including invalid and missing values.
28
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.
By default Playwright runs test files in parallel but tests within one file in order in a single worker. fullyParallel: true lets tests inside a file run in parallel across workers too. It speeds up suites with big files, but every test must be independent. You can also enable it per file with test.describe.configure({ mode: 'parallel' }).
30
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.
31
What is the difference between the request fixture and request.newContext()?
The request fixture is a ready APIRequestContext that uses the config's baseURL and extraHTTPHeaders and is cleaned up automatically per test. playwright.request.newContext() creates your own context with custom settings, such as a different base URL or auth token, for example in a worker fixture. You must dispose a manually created context yourself.
Download trace.zip from the test results or CI artifact. Run npx playwright show-trace path/to/trace.zip to open it locally, or drag the file into trace.playwright.dev, which processes it in the browser without uploading it. In the HTML report, failed tests with a trace show a trace link you can click directly.
33
How does this behave in arrow functions compared with regular functions?
A regular function gets this from how it is called, so passing a class method as a callback can lose this. An arrow function has no own this and uses the value from the surrounding code. In page objects, arrow functions in callbacks such as map keep access to this.page, which avoids undefined errors.
34
Developers keep changing CSS class names and 40 tests break every sprint. How do you fix this long term?
Replace class-based selectors with role, label and text locators, and agree on data-testid for widgets without good semantics. Move all locators into page objects so future changes touch one file. Add a code review rule and a lint check that flags raw CSS selectors. Share a short locator guide with developers so they know which attributes tests depend on.
The use block sets default options for every test, such as baseURL, headless, viewport, locale, trace, screenshot and video. Each project can override them in its own use block, and a file can override again with test.use. This layered setup keeps shared settings in one place while still allowing browser- or file-specific changes.
36
How do access modifiers help in page object classes?
private and protected hide internal locators and helper steps, so tests can only call meaningful public methods such as login or addToCart. This keeps tests readable and lets you change internals without breaking callers. readonly on the page field prevents it from being replaced. TypeScript enforces these at compile time only, not at runtime.
37
How do you share cookies between API login and UI?
Run the tests with npx playwright test --update-snapshots, optionally filtered to the affected files or a tag. Playwright rewrites the baselines with the new images. Newer versions also accept modes such as --update-snapshots=changed or missing so only the needed files are touched. Always look at the diff in the pull request before merging, because blindly updating hides real regressions.
40
Which frameworks does Playwright component testing support?
Official packages exist for React, Vue and Svelte, named like @playwright/experimental-ct-react and @playwright/experimental-ct-vue. Each package provides the mount fixture and hooks in the style of its framework, such as slots and events for Vue. Support has changed between versions and the feature is experimental, so check the current docs and pin the package version alongside @playwright/test.
Tips to crack the Persistent Systems Playwright Testing interview
Practise coding problems of easy to medium difficulty, as Persistent assessments usually focus more on programming than service peers.
Revise data structures, OOP, DBMS and operating system basics for the technical rounds.
Read about Persistent's product engineering background and its partnerships with major cloud providers.
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; Persistent Systems interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Persistent Systems Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + coding); Technical round 1; Technical round 2; 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 Persistent Systems Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (6), Framework Design and CI/CD (5), API Testing (5), Parallel Runs, Sharding & Reporting (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Persistent Systems interviewers ask you to walk through real work.
Are these the exact questions asked at Persistent Systems?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Persistent Systems's. They are not a leaked or verified list of past questions.
Where does Persistent Systems hire Playwright Testing professionals in India?
Persistent Systems has large teams in Pune, Nagpur, Bengaluru, Hyderabad, Goa. Openings and locations change often, so check the Persistent Systems careers page and filter by city and experience.
Playwright Testing questions for similar companies