Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Dream11 hiring for Playwright Testing roles
Dream11 is an Indian sports technology platform and the flagship brand of Dream Sports, which also includes FanCode and other businesses. Its engineering and analytics teams build systems that handle very high traffic during live matches. It hires for software engineers, SDETs, data engineers, data analysts and data scientists.
For Playwright Testing roles, this Dream11 practice set focuses most on JavaScript and TypeScript (7), Component Testing (7), Framework Design and CI/CD (6), API Testing (5). It has 2 easy, 28 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Mumbai, India
Main India offices
Mumbai
Dream11 Playwright Testing interview process
Online assessment or assignment
Technical round 1
Technical round 2 (design or case)
Hiring manager round
Culture fit round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Dream11Start 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 must confirm that an error banner does not appear, but it always waits the full timeout. How do you fix it?
Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.
Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.
03
How do you return a fake JSON response that depends on the request body?
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.
08
How do you debug a test in VS Code with the Playwright extension?
Install the Playwright Test for VS Code extension. Open the Testing panel to see tests, then set a breakpoint in the test file and click Debug Test. Execution stops at the breakpoint with the browser open, so you can inspect variables. Turn on Show browser to watch runs, and use Pick locator or Record at cursor to add steps.
09
How do you verify a page's URL and title after navigation?
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
10
A test fails with 'Target page, context or browser has been closed'. What usually causes it?
Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.
11
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.
Use response.headers() for an object of lower-cased header names, or headersArray() for duplicates. Assert content-type contains application/json, cache-control matches the policy, and security headers such as strict-transport-security are present. Also check that sensitive headers like server version are not exposed. Header checks catch configuration bugs that body checks miss.
test.skip skips a test, optionally with a condition such as browserName === 'webkit'. test.fixme marks a test as broken and does not run it, so it is visible in reports as work to do. test.fail marks a test as expected to fail and reports an error if it unexpectedly passes, which is useful while a known bug is open.
14
How do you test a dropdown component's keyboard support in a component test?
Mount the dropdown, focus the trigger and press Enter or ArrowDown to open it. Assert the listbox is visible and the first option has aria-selected or focus. Press ArrowDown again and check the active option moves, then press Enter and assert the trigger shows the chosen value and the list is closed. Finally press Escape on an open list to confirm it closes without changing the value.
15
How do you open an HTML report downloaded from a CI artifact?
Unzip the artifact and run npx playwright show-report followed by the folder path, for example npx playwright show-report ./playwright-report. This starts a small local server, which is needed because traces load through it. Opening index.html directly from disk often fails to show traces. You can also upload a single trace zip to the online trace viewer.
16
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.
17
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.
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.
19
Write a typed helper that retries an async function a few times.
Load a .env file with a package like dotenv in playwright.config, then read process.env.BASE_URL. Values are string | undefined, so validate them early and throw a clear error if a required one is missing. Keep .env out of git and commit an .env.example instead. In CI, set the same names as secret variables.
22
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.
23
An API test fails randomly because another test changes the same record. How do you fix it?
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.
Functions that take other functions as arguments or return them, such as map, filter and reduce, or a helper that wraps retry logic around a test step.
25
How do you record a trace manually with the tracing API?
Call await context.tracing.start({ screenshots: true, snapshots: true }) before the steps, and await context.tracing.stop({ path: 'trace.zip' }) after them. This is useful in scripts that use the library without the test runner, or when you want a trace of only part of a flow. tracing.group can label sections of steps.
26
An axe scan reports 40 violations on a legacy page. How do you add accessibility checks without blocking every build?
Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.
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.
31
The team wants to replace all end-to-end tests with component tests to save time. What do you advise?
Agree to move detailed UI checks down to component tests, because they are faster and more precise. But keep a thin layer of end-to-end tests for critical journeys like signup, checkout and payment, since component tests use mocked data and cannot catch broken APIs, routing or deployment issues. Decide per risk, measure runtime savings, and track escaped defects after the change.
32
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.
33
What do maxDiffPixels, maxDiffPixelRatio and threshold control in a screenshot comparison?
threshold sets how different two pixels can be in colour, from 0 to 1, before they count as different; the default is 0.2. maxDiffPixels allows a fixed number of differing pixels, and maxDiffPixelRatio allows a fraction of the total image. Keep them tight so real regressions fail, and set them in the expect section of the config rather than loosening single tests one by one.
34
How do you keep API tests independent of environment data?
Do not depend on records that happen to exist in a shared environment. Each test or fixture creates what it needs through the API and cleans up after. Read environment-specific values such as base URL and credentials from config. For reference data that must exist, seed it in a setup project and verify it before tests run.
35
How do you manage flaky tests without hiding real failures?
Use retries in CI so one-off failures do not block merges, but treat any test marked flaky in the report as a defect. Track flaky tests on a dashboard, quarantine repeat offenders with a tag and an owner, and set a deadline to fix or delete them. Never retry without investigating, or real intermittent bugs will be missed.
36
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.
37
How do you change a mounted component's props during a test?
Call component.update with new JSX, for example await component.update(<Badge count={5} />). Playwright re-renders the same instance with the new props, so internal state is kept, just like a parent re-rendering it in the app. This lets you test effects that react to prop changes. To test fresh mounting behaviour instead, unmount and mount again.
38
What is the difference between unknown and any in TypeScript?
any switches off type checking, so any property access compiles even if it crashes at runtime. unknown accepts any value but forces you to narrow or validate it before use. For API JSON in tests, typing it as unknown and then validating or asserting a type is safer than any, because mistakes appear at compile time.
39
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.
40
Retries make the build green, but nobody notices flaky tests. How do you surface them?
Playwright already marks tests that passed on retry as flaky in the HTML and JSON reports. Read the JSON report in a small script after each run, post flaky test names to the team channel, and fail the build if the flaky count crosses a threshold. Over time you can track trends per test and per area.
Tips to crack the Dream11 Playwright Testing interview
Practise system design for sudden traffic spikes, such as many users joining just before a cricket match starts.
Prepare analytics cases on user engagement, retention and contest participation around major tournaments.
Keep up with regulatory changes affecting online gaming in India, as they directly shape the company's business.
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; Dream11 interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Dream11 Playwright Testing interview?
Candidates usually go through 5 stages: Online assessment or assignment; Technical round 1; Technical round 2 (design or case); Hiring manager round; Culture fit 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 Dream11 Playwright Testing interview?
This practice set leans on JavaScript and TypeScript (7), Component Testing (7), Framework Design and CI/CD (6), API Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Dream11 interviewers ask you to walk through real work.
Are these the exact questions asked at Dream11?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Dream11's. They are not a leaked or verified list of past questions.
Where does Dream11 hire Playwright Testing professionals in India?
Dream11 has large teams in Mumbai. Openings and locations change often, so check the Dream11 careers page and filter by city and experience.
Playwright Testing questions for similar companies