Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Fidelity Investments hiring for Playwright Testing roles
Fidelity Investments is a large American financial services company providing brokerage, retirement plans, mutual funds and wealth management. In India it operates technology and operations centres that build and support its trading, investment and customer platforms. These centres hire software engineers, quality engineers, data engineers, analysts and operations professionals.
For Playwright Testing roles, this Fidelity Investments practice set focuses most on API Testing (8), Framework Design and CI/CD (7), Playwright Core (6), Parallel Runs, Sharding & Reporting (4). It has 8 easy, 28 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
Banking & finance
Headquarters
Boston, USA
Main India offices
Bengaluru, Chennai, Gurugram
Fidelity Investments Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA + language)
Technical round 2 (design or domain)
Managerial and HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Fidelity InvestmentsStart 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 compares only the pricing card instead of the full page.
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.
05
How do you handle secrets such as passwords and tokens in CI?
Store them in the CI system's secret store and pass them as environment variables, never in the repository or config files. Read them through process.env and fail fast if they are missing. Use dedicated test accounts with limited rights. Avoid printing them in logs, and make sure traces and screenshots do not expose them in reports.
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.
07
A worker-scoped fixture holds shared data and some tests see stale values. How do you fix it?
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.
08
What does getByRole do and why is it the first-choice locator?
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.
09
How do you handle token refresh in long API test runs?
test.describe groups related tests under one title, which shows up in reports. Hooks and test.use inside the group apply only to those tests. You can nest groups, for example Checkout then Guest user. Groups are only for organisation, they do not make tests share a page or state, so each test still gets fresh fixtures.
12
How would you type the response of an API call in TypeScript?
Define an interface for the payload, cast or validate the parsed JSON to it (for example with zod), and use that type in assertions to catch shape changes.
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.
17
How do you run one group of tests serially while the rest of the suite runs in parallel?
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.
18
Does headless mode behave differently from headed mode?
Modern Chromium headless uses the same browser code as headed, so behaviour is very close. Differences still appear in viewport size, GPU rendering, fonts and some OS dialogs. Tests should set an explicit viewport and not depend on window focus. If something passes headed but fails headless, record a trace and compare screenshots.
19
Write a GitHub Actions job that runs the suite in four shards.
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.
21
How do you test how the UI handles a 500 error from the orders API?
Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.
22
What actionability checks does Playwright run before a click?
Before clicking, Playwright waits until the element is attached, visible, stable (not animating), enabled and able to receive events (not covered by another element). It also scrolls it into view. fill checks for an editable element. If the checks are not met before the timeout, the action fails with a log of what was missing.
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.
26
How do you wait for a network response in Playwright?
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 context created with request.newContext() holds cookies, connections and stored responses in memory. Calling await context.dispose() frees them, and any later call on it fails. Without disposing, long runs can leak memory. The built-in request fixture is disposed automatically, so this matters for contexts you create in fixtures or helpers.
Each Playwright version expects specific browser builds. The official Playwright Docker image tagged v1.x.y-noble contains the browsers for that exact version. If package.json has a different version, tests fail because browsers are missing or mismatched. Pin both together and update them in the same pull request.
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.
32
A component test passes alone but fails when the full component suite runs. What do you check?
Look for state that leaks between mounts: global stores or singletons created at module level in index.tsx, timers or listeners not cleaned up on unmount, and shared mock data mutated by one test. Make the providers create fresh state in beforeMount each time and reset mocks per test. Running with --repeat-each and a single worker often reproduces the leak quickly.
33
How do you validate an API response in Playwright?
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.
35
A locator matches three Delete buttons and the test fails with a strict mode violation. How do you fix it?
First scope the locator to the item you mean, for example the row that contains the user's name: page.getByRole('row', { name: 'Ravi Kumar' }).getByRole('button', { name: 'Delete' }). Do not reach for first() or nth() as a quick fix, because the order can change and the test may delete the wrong record. Scoping by meaningful context is stable and readable.
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.
A class receives page in its constructor, stores locators as properties and exposes actions like login(user, pass). Tests call page objects, not raw locators.
Tips to crack the Fidelity Investments Playwright Testing interview
Revise Java or Python, SQL and core CS subjects, and practise medium-level DSA problems for technical rounds.
Learn basic investment concepts like stocks, mutual funds and retirement accounts to understand the business domain.
Prepare behavioural answers on teamwork and learning, using clear STAR-format stories from projects or internships.
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; Fidelity Investments interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Fidelity Investments Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA + language); Technical round 2 (design or domain); Managerial and 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 Fidelity Investments Playwright Testing interview?
This practice set leans on API Testing (8), Framework Design and CI/CD (7), Playwright Core (6), Parallel Runs, Sharding & Reporting (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Fidelity Investments interviewers ask you to walk through real work.
Are these the exact questions asked at Fidelity Investments?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like Fidelity Investments's. They are not a leaked or verified list of past questions.
Where does Fidelity Investments hire Playwright Testing professionals in India?
Fidelity Investments has large teams in Bengaluru, Chennai, Gurugram. Openings and locations change often, so check the Fidelity Investments careers page and filter by city and experience.
Playwright Testing questions for similar companies