Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Tiger Analytics hiring for Playwright Testing roles
Tiger Analytics is an AI and analytics consulting company working with clients in consumer goods, retail, insurance, banking and healthcare. Its India offices handle data engineering, data science and ML engineering work. It hires for data analysts, data scientists, data engineers and ML engineers. Many projects run on major cloud data platforms.
For Playwright Testing roles, this Tiger Analytics practice set focuses most on API Testing (7), Debugging and Trace Viewer (7), Fixtures and Hooks (5), Framework Design and CI/CD (4). It has 8 easy, 28 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Santa Clara, California, USA
Main India offices
Chennai, Bengaluru, Hyderabad
Tiger Analytics Playwright Testing interview process
Online assessment (SQL + Python + statistics)
Technical round 1
Technical round 2 or case round
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Tiger AnalyticsStart 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 typed helper that retries an async function a few times.
Never trust status alone. Assert the body structure, for example that error is absent and data has the expected fields, ideally with a schema check. Report the issue, because returning 200 for errors breaks clients and monitoring. Add a helper that validates both status and body shape so every test checks it consistently.
04
What is UI mode and how is it different from --debug?
UI mode, opened with npx playwright test --ui, is a dashboard to run, filter and watch tests, with a trace-like timeline for each one and a watch mode that reruns on file changes. --debug opens the Inspector to step through a single run live. Use UI mode for daily development and --debug for stepping through a specific action.
05
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.
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.
07
How do you share one authenticated API context across all tests in a worker?
Create a worker-scoped fixture that calls request.newContext with baseURL and an auth header, or logs in through the API and keeps the cookies. Pass it to use, and dispose it after use returns. Every test in that worker gets the same ready context, so login happens once per worker. Do not store per-test data on it, or tests start depending on each other.
mount renders the component into the test page and returns a locator pointing at the component root. You can call getByRole, click, and use web-first assertions on it like any locator. It also has helpers: update to re-render with new props or children, and unmount to remove it. Because it is a locator, the auto-waiting and retry behaviour of end-to-end tests applies here too.
Situation: on release day the test job failed for every build after a runner image update. Task: unblock the release safely. Action: I compared logs, found missing browser dependencies, pinned the Playwright Docker image version and reran. Result: tests passed within an hour, the release went out on time, and I added an alert for image changes.
beforeAll runs once before the tests in its file or describe block, and afterAll runs once after them. In Playwright they run once per worker, so if tests are spread over workers they can run more than once. They suit cheap shared setup. They cannot use test-scoped fixtures like page, so open your own page from the browser fixture if needed.
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 read a Playwright timeout error message?
The error names the action and locator, for example locator.click: Timeout 30000ms exceeded, followed by a call log. The call log lists each attempt, such as waiting for the element to be visible, enabled and stable, or another element intercepting pointer events. The last lines show what blocked the action. Read it before changing timeouts.
15
Why is sharing state between tests through module-level variables a bad idea?
Each worker has its own copy of module variables, so values set in one worker are invisible to others, and order changes between runs. Tests that pass alone fail in parallel or after a retry. Pass data through fixtures, or store it in an external source like the API. Each test should be able to run alone, in any order.
16
How do you wait for a network response in Playwright?
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.
19
Tests pass with one worker but fail with eight. How do you debug this?
This usually means tests share something: the same user account, the same records or a global server setting. Run the failing file with --workers=8 and --repeat-each to reproduce it. Look at which tests run at the same time in the report. Fix it by giving each test unique data, using workerIndex in names, or isolating shared settings per worker.
20
What is the difference between toHaveText and toContainText?
toHaveText checks that the element's full text matches the expected string or regex, after normalising whitespace. toContainText passes if the expected text appears anywhere inside it. Use toHaveText for exact labels like a heading, and toContainText for longer messages where only part matters. Both are web-first assertions, so they retry until the timeout before failing.
A failed test may leave the browser or worker-scoped fixtures in a bad state, such as an open dialog or corrupted login. To protect the remaining tests, Playwright throws that worker away and starts a fresh one for the next tests. This means worker fixtures run again and beforeAll hooks may run more than once, which is normal and something your setup must tolerate.
24
Write a GitHub Actions job that runs the suite in four shards.
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.
26
Describe how you handled a flaky test that was blocking releases.
Situation: a payment test failed randomly and blocked three release builds. Task: unblock releases without hiding a real problem. Action: I quarantined it with a tag and a ticket, kept it running in a separate job, and used traces from twenty runs to find a missing wait on a redirect. Result: it was fixed in two days and releases continued meanwhile.
27
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.
Listen with page.on('console', msg => ...) for console.log, warnings and errors, and page.on('pageerror', err => ...) for uncaught exceptions. Collect them in an array and attach them to the report on failure. Traces also show console output. Uncaught page errors often explain why a button did nothing or a page stayed blank.
31
Why should the Playwright Docker image version match your package version?
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.
32
Where does Playwright store baseline screenshots and how are the files named?
By default baselines go into a folder next to the test file named after it, for example checkout.spec.ts-snapshots. The file name combines the name you give, the project name and the platform, such as home-chromium-linux.png. Because the browser and operating system are part of the name, each project keeps its own baseline. You commit these images to the repository so every run compares against the same files.
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.
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.
const texts = await page.getByTestId('price').allTextContents();
const prices = texts.map(t => Number(t.replace(/[^0-9.]/g, '')));
const sorted = [...prices].sort((a, b) => a - b);
expect(prices).toEqual(sorted);
// wait for the list first with toHaveCount
It is a lint plugin with rules for common Playwright mistakes, such as missing await on assertions, leftover test.only or page.pause, forced clicks, fixed waits with waitForTimeout and element handles instead of locators. Running it in pull requests stops bad patterns before review. Teams usually enable the recommended rule set and add a few stricter rules over time.
39
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.
40
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.
Tips to crack the Tiger Analytics Playwright Testing interview
Revise machine learning algorithms, feature engineering and evaluation metrics, as technical rounds often go into depth.
Practise PySpark and SQL for data engineering roles, including data pipeline design on cloud platforms.
Prepare analytics case questions on demand forecasting or customer segmentation for retail and consumer goods clients.
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; Tiger Analytics interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Tiger Analytics Playwright Testing interview?
Candidates usually go through 5 stages: Online assessment (SQL + Python + statistics); Technical round 1; Technical round 2 or case round; Managerial 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 Tiger Analytics Playwright Testing interview?
This practice set leans on API Testing (7), Debugging and Trace Viewer (7), Fixtures and Hooks (5), Framework Design and CI/CD (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Tiger Analytics interviewers ask you to walk through real work.
Are these the exact questions asked at Tiger Analytics?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like Tiger Analytics's. They are not a leaked or verified list of past questions.
Where does Tiger Analytics hire Playwright Testing professionals in India?
Tiger Analytics has large teams in Chennai, Bengaluru, Hyderabad. Openings and locations change often, so check the Tiger Analytics careers page and filter by city and experience.
Playwright Testing questions for similar companies