Boston Consulting Group Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Boston Consulting Group hiring for Playwright Testing roles
Boston Consulting Group is a global management consulting firm known for strategy work and frameworks such as the growth-share matrix. It advises clients on strategy, digital transformation, operations and sustainability. In India it has consulting offices and capability centres, and it hires associates, analysts, data scientists and engineers, including for its technology and AI unit known as BCG X.
For Playwright Testing roles, this Boston Consulting Group practice set focuses most on JavaScript and TypeScript (6), API Testing (6), Component Testing (6), Playwright Core (5). It has 7 easy, 23 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
Boston, USA
Main India offices
Mumbai, New Delhi, Bengaluru, Chennai
Boston Consulting Group Playwright Testing interview process
Online assessment (case or aptitude based)
Case interview round 1
Case interview round 2
Final round with senior leadership
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Boston Consulting GroupStart 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 test uses forEach with an async callback and the checks inside never seem to run. Why?
forEach does not wait for async callbacks, so it starts each callback and returns at once. The test may finish before the assertions run, or their errors are lost. Use for...of with await to run steps in order, or Promise.all with map when the steps can safely run in parallel. A lint rule can flag this pattern.
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.
Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.
06
How do you simulate a slow API to test a loading spinner?
The call log will say another element intercepts pointer events. Find what the overlay is, such as a loading mask, cookie banner or chat widget. Wait for it to disappear with expect(overlay).toBeHidden(), or close it in a fixture. Do not use force: true, because it hides a real issue: a user would also be blocked by that overlay.
08
A setup fixture creates expensive test data and suite time has doubled. How do you redesign it?
Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.
09
How do you take visual snapshots of each component state in component tests?
Mount the component once per state, for example default, disabled, loading and error, and call await expect(component).toHaveScreenshot() for each. Since only the component is on the page, images are small, stable and fast to review. Run them in the same Docker image as CI. This often replaces many full-page visual tests that break for unrelated reasons.
A Promise represents a value that will be available later, such as an API response. It is pending at first, then either fulfilled with a value or rejected with an error, and it never changes after that. You consume it with await or then and catch. Almost every Playwright call returns a Promise, which is why tests use await so much.
It is the entry file bundled into the component test page, so it runs in the browser before every mount. You import global CSS, fonts and theme files there, and register beforeMount and afterMount hooks to wrap components in providers such as a router, theme or state store. Keeping this setup in one place means individual tests can mount components without repeating boilerplate.
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.
15
Tell me about a time you introduced component tests to a frontend team.
Situation: our end-to-end suite took 40 minutes and most failures were in form validation. Task: speed up feedback. Action: I set up Playwright component tests for the form library, wrote ten examples and a short guide, and paired with two developers on their first tests. Result: validation checks moved to component level, the end-to-end suite dropped to 25 minutes and developers began writing component tests themselves.
16
How do you test conditional GET requests that use ETag and If-None-Match?
Call the endpoint once and read the etag header from the response. Call it again with the If-None-Match header set to that value and assert status 304 with an empty body. Then change the resource, repeat the conditional call and assert 200 with a new ETag. This proves caching works and that updates are not hidden behind stale responses.
17
How do you pass slots and listen to events in a Vue component test?
With the Vue package you can mount with an options object: mount(Button, { props: { label: 'Save' }, slots: { default: 'Click me' }, on: { click: handler } }). The on map receives emitted events, so you can push payloads into an array and assert on them. JSX syntax is also supported if the project is configured for it.
18
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.
19
An API receives a payload with an unknown extra field. How do you test what it should do?
First confirm the contract: should unknown fields be rejected with 400 or silently ignored? Then send a valid body with an extra field and assert that behaviour. If they are ignored, fetch the record and check the extra field was not stored. Also try sending a field that should be read-only, such as role or id, to catch mass assignment bugs.
A worker is a separate operating system process that runs test files. Each worker starts its own browser, and tests inside a worker run one after another, while different workers run at the same time. Workers do not share memory, so you cannot pass variables between them. Worker-scoped fixtures are created once per worker, which is why expensive setup is often placed there.
23
A test passes locally but fails in CI with a timeout on a click. How do you use the trace?
Open the CI trace and go to the failed click. Check the action log, which shows what Playwright waited for, such as the element not being visible or another element intercepting pointer events. Compare before and after snapshots and the network tab for slow or failed calls. Common causes are a slower environment, a cookie banner or different screen size.
24
How do you handle rate limits or slow APIs in tests?
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.
27
Images load lazily and are sometimes missing from full-page screenshots. How do you make them stable?
Scroll the content into view or remove loading=lazy for the test, then wait until every image has loaded, for example with expect.poll checking that all img elements report complete and a natural width above zero. Serving images from mocked routes removes network timing too. Only after that call toHaveScreenshot, which then waits for two identical frames.
28
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.
A browser context is an isolated session inside one browser, like a fresh incognito profile with its own cookies, storage and cache. Creating one takes milliseconds, unlike launching a new browser. Playwright gives every test a new context, so tests do not leak state into each other, and you can open several contexts to simulate different users.
30
What is the difference between a type and an enum in TypeScript?
Run in parallel with sharding, reuse authentication state, set up data through APIs, avoid unnecessary waits, run smoke on every commit and the full suite nightly.
32
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.
33
How would you design API test coverage for a new endpoint?
Situation: I joined a team whose Playwright suite was in TypeScript while I knew only basic JavaScript. Task: become productive in two weeks. Action: I studied types, interfaces and generics in the evenings, read the team's page objects, and fixed small compiler errors as practice. Result: by week three I was writing new tests and reviewing simple pull requests.
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.
37
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.
38
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.
ctViteConfig is an option in the use block of playwright-ct.config.ts that passes extra Vite settings to the component bundle. You need it when the app relies on path aliases, plugins, environment defines or special asset handling that Playwright's default Vite setup does not know about. A typical case is adding resolve.alias so imports like @/components work in tests.
Tips to crack the Boston Consulting Group Playwright Testing interview
Practise interviewer-led and candidate-led cases with a partner, paying attention to clear structure, hypotheses and summarising recommendations.
Work on quick, accurate calculations and chart reading, since case interviews often include data interpretation under time pressure.
For BCG X or analytics roles, be ready for coding, SQL and machine learning questions in addition to business cases.
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; Boston Consulting Group interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Boston Consulting Group Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (case or aptitude based); Case interview round 1; Case interview round 2; Final round with senior leadership. 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 Boston Consulting Group Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (6), API Testing (6), Component Testing (6), Playwright Core (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Boston Consulting Group interviewers ask you to walk through real work.
Are these the exact questions asked at Boston Consulting Group?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like Boston Consulting Group's. They are not a leaked or verified list of past questions.
Where does Boston Consulting Group hire Playwright Testing professionals in India?
Boston Consulting Group has large teams in Mumbai, New Delhi, Bengaluru, Chennai. Openings and locations change often, so check the Boston Consulting Group careers page and filter by city and experience.
Playwright Testing questions for similar companies