Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Broadcom hiring for Playwright Testing roles
Broadcom is a global technology company that designs semiconductors for networking, broadband, wireless and storage, and also sells infrastructure software. Its software business includes VMware, CA Technologies and Symantec enterprise products acquired over the years. In India it hires chip design and verification engineers, embedded engineers and software engineers for its semiconductor and software divisions.
For Playwright Testing roles, this Broadcom practice set focuses most on Locators and Assertions (7), API Testing (6), JavaScript and TypeScript (4), Visual & Accessibility Testing (4). It has 1 easy, 32 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
Hardware & semiconductors
Headquarters
Palo Alto, California, USA
Main India offices
Bengaluru, Pune, Chennai
Broadcom Playwright Testing interview process
Online assessment or resume screening
Technical round 1 (digital design or coding)
Technical round 2 (domain depth)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for BroadcomStart 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 and end-to-end tests run together and slow down every commit. How do you separate them?
Give them separate configs, such as playwright-ct.config.ts with its own testDir for component specs and playwright.config.ts for end-to-end tests, because component tests also need the bundler options and framework test import. In CI, run component tests on every commit as a fast job and end-to-end tests later or in parallel. Shared settings like reporters can live in a common module both configs import.
The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.
03
Why turn on strict mode in tsconfig for a test project?
strict enables checks such as strictNullChecks and noImplicitAny. They catch bugs like using a value that may be undefined, missing parameters or wrong property names before tests run. In a large suite this saves debugging time and makes page objects safer to refactor. Pair it with the no-floating-promises lint rule to catch missing awaits.
04
Write a test that checks keyboard Tab order through a login form.
--repeat-each=N runs every selected test N times in the same run, spread across workers. It is useful for checking a new or fixed test for flakiness before merging, for example npx playwright test checkout.spec.ts --repeat-each=20. Combined with several workers it also surfaces tests that collide with each other over shared data.
06
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.
07
How do you handle rate limits or slow APIs in tests?
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.
09
How do you mock API calls made by a component in a component test?
Newer Playwright versions provide a router fixture in component tests. You call router.route with a URL pattern and fulfil it with test data, much like page.route, and it can also use mock handlers written for Mock Service Worker. Alternatively, inject a fake data client through props or a provider in hooksConfig. Mocking keeps component tests fast and independent of any backend.
Declarations of var and functions are moved to the top of their scope at compile time; let and const are hoisted but stay in the temporal dead zone until declared.
11
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.
12
A beforeAll creates one user and tests in the same file fail randomly in parallel mode. Why?
With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.
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.
14
How do you handle date pickers and custom dropdowns?
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.
16
How do you test a component that reads from a global state store?
Wrap the mounted component in the store provider inside beforeMount, and use hooksConfig to choose the initial state for each test, such as a logged-in user or an empty cart. Build the store in the browser side of index.tsx, not in the test file. Then interact with the component and assert on the rendered output rather than reading store internals.
17
What do toHaveAccessibleName and toHaveAccessibleDescription check?
They assert the name and description that assistive technology computes for an element, using the accessibility tree rather than raw attributes. The name may come from a label, aria-label, aria-labelledby or inner text, and the description often from aria-describedby. For example an icon-only close button should have the name Close. These checks catch problems that a plain text assertion would miss.
18
Write a fixture that gives each parallel worker its own test account.
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
21
An endpoint should reject invalid email addresses. Which negative tests would you write?
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.
22
How does expect.poll work and when would you use it?
expect.poll calls a function again and again until the value it returns passes the matcher or the timeout runs out. It is useful for values that are not locators, such as an API status or a database count. Example: await expect.poll(async () => (await request.get('/api/job/7')).status()).toBe(200). You can tune the intervals and the timeout.
23
Write a GitHub Actions job that runs the suite in four shards.
TypeScript + POM + custom fixtures, environment configs, API helpers for test data, tags like @smoke, sharding across CI machines, retries with traces, HTML/Allure reports, lint and review rules.
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.
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.
33
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.
34
How do you design a locator strategy for a team so tests survive UI redesigns?
Set a written priority order: role with name, then label, placeholder or text, then test id, and CSS or XPath only as a last resort. Agree with developers to add data-testid on complex widgets. Keep locators inside page objects so a change is fixed in one place. Add a lint rule or review check against long CSS chains and nth-child selectors.
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.
36
Describe a time you convinced developers to add accessible labels or test ids.
Situation: many inputs had no labels, so our tests relied on long CSS selectors that broke often. Task: get stable hooks without slowing developers. Action: I listed the worst screens, showed how getByLabel tests read and how the same labels help screen reader users, and offered to raise small pull requests myself. Result: the team added labels to new work as a rule and locator breakages dropped sharply.
37
How do you test that a modal dialog traps focus and returns it when closed?
Open the dialog with a button and assert the dialog role is visible and focus moved inside it. Press Tab more times than there are controls and check with toBeFocused that focus never leaves the dialog. Press Escape, assert the dialog is hidden, and check that the opening button is focused again. Running the same test with Shift+Tab covers backward navigation as well.
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.
39
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.
Wait for the popup event with const [popup] = await Promise.all([page.waitForEvent('popup'), page.click('a')]), then interact with popup.
Tips to crack the Broadcom Playwright Testing interview
For hardware roles, revise digital electronics, Verilog, computer architecture and verification concepts such as SystemVerilog and UVM.
For software roles, revise C, data structures, operating systems and networking, especially for VMware and infrastructure software teams.
Be ready to go deep into your project, explaining design decisions and debugging steps, as interviewers often probe details.
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; Broadcom interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Broadcom Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment or resume screening; Technical round 1 (digital design or coding); Technical round 2 (domain depth); Hiring manager 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 Broadcom Playwright Testing interview?
This practice set leans on Locators and Assertions (7), API Testing (6), JavaScript and TypeScript (4), Visual & Accessibility Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Broadcom interviewers ask you to walk through real work.
Are these the exact questions asked at Broadcom?
No. These are curated practice questions that match the skills and difficulty usually tested in hardware & semiconductors interviews like Broadcom's. They are not a leaked or verified list of past questions.
Where does Broadcom hire Playwright Testing professionals in India?
Broadcom has large teams in Bengaluru, Pune, Chennai. Openings and locations change often, so check the Broadcom careers page and filter by city and experience.
Playwright Testing questions for similar companies