Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About LatentView Analytics hiring for Playwright Testing roles
LatentView Analytics is an Indian data analytics company providing data engineering, business analytics and data science services to global clients, many in technology, consumer goods and financial services. It hires in India for analysts, data engineers and data scientists who work on dashboards, data pipelines and predictive models.
For Playwright Testing roles, this LatentView Analytics practice set focuses most on API Testing (7), Framework Design and CI/CD (5), Playwright Core (5), Fixtures and Hooks (4). It has 7 easy, 27 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Chennai, India
Main India offices
Chennai, Bengaluru
LatentView Analytics Playwright Testing interview process
Online assessment (aptitude + SQL)
Technical interview
Case or guesstimate round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for LatentView 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.
Worker fixtures and beforeAll run first for the worker. For each test, the test fixtures it needs are set up, then beforeEach hooks run, then the test body. Afterwards afterEach hooks run, then test fixtures are torn down in reverse order. afterAll and worker fixture teardown run when the worker finishes. Fixtures are lazy, so unused ones never run.
02
Write a custom fixture that gives a logged-in page.
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.
05
Write a typed helper that retries an async function a few times.
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.
08
How do you check a checkbox and verify it is checked?
Call context.setOffline(true) to cut all network access for the context, then check that the app shows an offline banner or queues actions. Switch back with setOffline(false) and verify it syncs. You can also set offline: true in the context options. For a single failing endpoint, use route.abort instead of going fully offline.
10
What is the difference between page, context and browser?
In a fixture or beforeEach, call the API (request.post) to create the user or order, use it in the UI test, then delete it in teardown. It is faster and more reliable than creating data through the UI.
12
The app polls a status endpoint every few seconds. How do you test the change from Pending to Done?
Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.
Locators are strict: an action such as click or fill throws a strict mode violation if the locator matches more than one element. This prevents a test from silently clicking the wrong item. Fix it by making the locator more specific with a name, filter or chaining. Methods like count(), all() or first() are allowed to work with many matches on purpose.
14
How do you wrap a component in a theme or router provider using hooksConfig?
Situation: the UI hid a delete button for normal users, so UI tests passed. Task: check permissions properly. Action: I called the delete endpoint directly with a normal user's token and it returned 204. Result: the team fixed the server-side permission check, and I added role-based API tests for every admin endpoint.
17
What does the JUnit reporter produce and why do CI tools need it?
It writes an XML file in the JUnit format, with test suites, test cases, durations and failure messages. Most CI servers and test management tools read this format to show test counts, failures and history in their own dashboards. Set outputFile so the path is predictable, and publish that file as a test result in the pipeline.
page is a fresh tab for each test. context is the isolated browser context that owns the page, with its own cookies and storage. browser is the shared browser instance for the worker. request is an APIRequestContext for HTTP calls. You ask for them by name in the test function, and Playwright creates and cleans them up automatically.
20
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.
21
A toast message disappears after two seconds and the assertion on it is flaky. How do you test it reliably?
Assert immediately after the action that triggers it, using a web-first assertion like toBeVisible and toHaveText, which start checking at once. Do not add sleeps before the check. If the toast is still missed, control time with page.clock so it does not auto-hide, or verify the result through the data it confirms, such as the saved record.
22
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.
23
How do you run the same visual tests at mobile, tablet and desktop sizes?
Create one project per size in playwright.config, for example using devices['Pixel 7'], devices['iPad Mini'] and a desktop viewport, and point them at the same visual test files with testMatch or a tag. Because the project name is part of the baseline file name, each size keeps its own images automatically. This keeps the test code identical while covering responsive layouts.
24
Write a GitHub Actions job that runs the suite in four shards.
When teams define fixtures in separate modules, such as dbTest and a11yTest, mergeTests(dbTest, a11yTest) returns one test object that has all their fixtures. mergeExpects does the same for custom matchers. This keeps fixture modules small and owned by different people. Watch for name clashes, because two modules defining the same fixture name will conflict.
26
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.
27
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.
28
When should you avoid mocking, and how do you balance mocked and real tests?
Avoid mocking in a small set of critical end-to-end journeys, such as signup, payment and checkout, where integration matters most. Use mocks for UI states, error handling and third-party services. Back the mocks with API contract tests so they match reality. A healthy split is many fast mocked component-level tests and a thin layer of full-stack tests.
Web-first assertions wait 5 seconds by default. Change it globally in playwright.config with expect: { timeout: 10000 }, or for one assertion with await expect(locator).toBeVisible({ timeout: 15000 }). Raise it only for genuinely slow steps like report generation. Raising it everywhere hides performance problems and makes failing tests slower to report.
30
What is the difference between the list, line and dot reporters?
All three print to the terminal. list prints one line per test with its status and is the default locally. line shows a single updating line with progress and prints only failures in full, which suits long runs. dot prints one character per test, the most compact output, and is the default on CI. Choose based on how much log noise you want.
Use locator.press('Enter') for a key on a focused element, or page.keyboard.press('Control+A') for page-level shortcuts. Modifiers combine with a plus sign, and ControlOrMeta picks Ctrl on Windows and Linux and Cmd on macOS. keyboard.down and keyboard.up hold keys. Use pressSequentially only when the app needs real keystrokes, such as autocomplete.
32
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.
33
How would you design API test coverage for a new endpoint?
page.goto starts a navigation to a URL and waits for the load state you choose. page.waitForURL does not navigate; it waits until the current page reaches a URL that matches a string, glob or regular expression, which is useful after a click that redirects, such as a login followed by a jump to the dashboard. Pair it with the click instead of adding fixed sleeps.
38
How do you test file downloads and verify their content?
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.
40
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.
Tips to crack the LatentView Analytics Playwright Testing interview
Practise SQL queries and Excel analysis, as many LatentView roles start with reporting and data preparation.
Prepare guesstimates and simple business cases, explaining your assumptions and calculation steps clearly to the interviewer.
Be ready to explain one dashboard or analysis project end to end, from data cleaning to insight.
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; LatentView Analytics interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the LatentView Analytics Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + SQL); Technical interview; Case or guesstimate 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 LatentView Analytics Playwright Testing interview?
This practice set leans on API Testing (7), Framework Design and CI/CD (5), Playwright Core (5), Fixtures and Hooks (4). Revise those first, then practise explaining one or two of your own projects end to end, because most LatentView Analytics interviewers ask you to walk through real work.
Are these the exact questions asked at LatentView Analytics?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like LatentView Analytics's. They are not a leaked or verified list of past questions.
Where does LatentView Analytics hire Playwright Testing professionals in India?
LatentView Analytics has large teams in Chennai, Bengaluru. Openings and locations change often, so check the LatentView Analytics careers page and filter by city and experience.
Playwright Testing questions for similar companies