Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About UBS hiring for Playwright Testing roles
UBS is a Swiss global financial services firm known for wealth management, investment banking, asset management and Swiss retail banking. It acquired Credit Suisse in 2023. In India it runs large business solutions and technology centres that hire software engineers, data analysts, risk and finance professionals, and operations roles supporting its global businesses.
For Playwright Testing roles, this UBS practice set focuses most on API Testing (6), Playwright Core (6), JavaScript and TypeScript (5), Framework Design and CI/CD (5). It has 5 easy, 32 medium, 3 hard questions, so you can start easy and work up to the harder ones.
Company type
Banking & finance
Headquarters
Zurich, Switzerland
Main India offices
Pune, Mumbai, Hyderabad
UBS Playwright Testing interview process
Online assessment (aptitude + coding)
Technical interview
Managerial or business round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for UBSStart 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 are the options for the trace setting in playwright.config?
Values are 'off', 'on', 'retain-on-failure', 'on-first-retry' and 'on-all-retries'. 'on-first-retry' records only when a failed test is retried, which keeps the normal run fast and gives a trace for flaky failures. 'retain-on-failure' records every test but keeps only failed ones. 'on' records everything and is mainly for local investigation.
02
What is the difference between null and undefined?
Playwright supports multiple browsers, tabs, languages and has auto-waiting and tracing; Selenium has the widest ecosystem; Cypress runs in-browser with a great UI but has more limits across tabs.
05
How does Playwright talk to browsers, and why does that make it less flaky?
Playwright runs outside the browser and controls it through a persistent connection using each engine's own protocol, such as CDP for Chromium and patched protocols for Firefox and WebKit. It can watch DOM, network and events directly, so it waits on real state instead of polling from inside the page. This gives reliable auto-waiting, multi-tab and network control.
webServer tells Playwright to start your app with a command, such as npm run start, and wait until a URL or port responds before running tests. reuseExistingServer: !process.env.CI lets you use an already running dev server locally. You can define several servers, for example frontend and a mock API. It shuts them down after the run.
08
Which methods does the Playwright Reporter interface provide?
The main ones are onBegin with the config and full suite, onTestBegin and onTestEnd for each test, onStepBegin and onStepEnd for steps, onStdOut and onStdErr for output, onError for errors outside tests and onEnd with the overall result. onEnd can be async, so you can send results to an API before the process exits. You register the reporter by path in the reporter config.
await page.getByRole('link', { name: 'Orders' }).click();
await expect(page).toHaveURL(/\/orders$/);
await expect(page).toHaveTitle('My Orders | Shop');
// both retry, so no need to wait for navigation manually
12
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.
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.
15
Describe a time strict TypeScript types caught a bug in your test code.
Situation: our API helpers returned loosely typed objects and tests often read fields that no longer existed. Task: make helpers safer. Action: I added response interfaces, turned on strict mode and replaced any with unknown plus type guards. Result: the compiler immediately showed eleven tests reading a renamed field, which had been passing because they compared undefined with undefined. We fixed them before the next release.
By default Playwright API calls do not throw on error statuses, you check them yourself. Setting failOnStatusCode: true on a request or context makes it throw for any status other than 2xx or 3xx. It is useful in setup helpers, where any failure should stop the test immediately with a clear message, instead of continuing with bad data.
17
What is the difference between workerIndex and parallelIndex?
workerIndex is a unique number for every worker process started during the run, so it keeps growing when a worker is restarted after a failure. parallelIndex is a slot number from 0 to workers minus 1, and a restarted worker reuses its slot. Use parallelIndex, also exposed as TEST_PARALLEL_INDEX, to pick a fixed test account or database per slot.
18
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.
19
Write a visual assertion that masks a live clock and an ad banner.
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'.
21
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.
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.
Situation: our team ran tests only on laptops before releases. Task: run them automatically on every pull request. Action: I created a CI workflow with browser install, sharding over four machines, merged HTML reports and traces on retry. Result: feedback came within twelve minutes on each pull request, and release-day surprises dropped sharply.
25
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.
26
Parallel tests create users with the same email and fail with 'already exists'. How do you fix it?
Generate unique data per test, for example by adding testInfo.testId, the parallel index or a random suffix to the email, or by using a data builder that creates a fresh user through the API. Avoid hard-coded shared records in test files. Clean up created users in a fixture teardown so the database does not fill up over time.
27
A component under test needs a complex class instance as a prop and the test fails to serialise it. What do you do?
Create a small test story component in a separate file that builds the class instance inside the browser and renders the real component with it. The test then mounts the story with simple props, such as an id or a scenario name. This keeps the data creation on the browser side of the boundary and also documents test scenarios as reusable stories.
28
How do you filter a list of locators by text or by a child element?
Cover empty string, missing field, null, wrong type such as a number, no at sign, no domain, spaces, very long strings and a duplicate existing email. For each, assert a 400 or 422 status, a clear error message naming the field, and that nothing was created. Also check that a valid email with uppercase letters is accepted.
37
How do you test the difference between 401 and 403 responses?
401 Unauthorized means the caller is not authenticated, such as a missing or expired token. 403 Forbidden means the caller is known but lacks permission. Test 401 by calling without a token or with an invalid one. Test 403 by calling an admin endpoint with a normal user's token. Assert the status and that no data leaks in the body.
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.
39
How would you structure a large Playwright framework for a team?
Separate tests, page objects, fixtures, utilities, test data and config; use tags, projects, shared auth setup, linting, code review and a CI pipeline with sharding and reports.
Syntax over Promises: an async function returns a Promise and await pauses until it resolves. Every Playwright action returns a Promise, so you await each step.
Tips to crack the UBS Playwright Testing interview
Revise DSA, Java or Python, SQL and OOP concepts, and be ready to explain your code clearly in interviews.
Learn basics of wealth management, investment banking and financial markets to show interest in the business side.
Prepare examples of attention to detail and handling pressure, since banking technology roles demand reliability and accuracy.
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; UBS interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the UBS Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + coding); Technical interview; Managerial or business 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 UBS Playwright Testing interview?
This practice set leans on API Testing (6), Playwright Core (6), JavaScript and TypeScript (5), Framework Design and CI/CD (5). Revise those first, then practise explaining one or two of your own projects end to end, because most UBS interviewers ask you to walk through real work.
Are these the exact questions asked at UBS?
No. These are curated practice questions that match the skills and difficulty usually tested in banking & finance interviews like UBS's. They are not a leaked or verified list of past questions.
Where does UBS hire Playwright Testing professionals in India?
UBS has large teams in Pune, Mumbai, Hyderabad. Openings and locations change often, so check the UBS careers page and filter by city and experience.
Playwright Testing questions for similar companies