Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About ThoughtSpot hiring for Playwright Testing roles
ThoughtSpot is an analytics software company known for search and AI-driven business intelligence that lets users ask questions of data in natural language. Its platform connects to cloud data warehouses and creates interactive charts and dashboards. It has an engineering presence in India and hires software engineers, data engineers, quality engineers and customer-facing technical roles.
For Playwright Testing roles, this ThoughtSpot practice set focuses most on Framework Design and CI/CD (7), Network Mocking (6), API Testing (5), Visual & Accessibility Testing (5). It has 1 easy, 29 medium, 10 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Mountain View, California, USA
Main India offices
Bengaluru
ThoughtSpot Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (system design or domain)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for ThoughtSpotStart 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.
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.
03
How do you read test data from a JSON file and loop over it?
Choose a component test when the behaviour lives inside one component: validation messages, disabled states, sorting in a table, keyboard handling in a dropdown or rendering of edge-case data. These are slow and awkward to reach through full flows. Choose end-to-end when the risk is in integration, such as routing, authentication or data saved on the server.
07
A fixture mocks every /api call, but one test needs a different response for /api/cart. How do you override it?
Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.
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.
11
What happens before and after await use() in a fixture?
Code before await use(value) is setup and runs before the test. use hands the value to the test and waits while the test runs. Code after it is teardown and runs when the test finishes, even if it failed. This keeps setup and cleanup for one resource in one place, which is cleaner than a separate beforeEach and afterEach pair.
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.
Situation: managers only heard pass or fail and could not tell flaky tests from real bugs. Task: make results useful. Action: I added a custom reporter that posted a short summary to our team chat with failures, flaky tests and a report link, and a weekly trend of flake rate. Result: flaky tests dropped by half in two months because owners could see them.
18
How do you simulate a slow API to test a loading spinner?
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.
21
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.
22
How do you organise tests with page object model in Playwright?
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.
24
Developers keep changing CSS class names and 40 tests break every sprint. How do you fix this long term?
Replace class-based selectors with role, label and text locators, and agree on data-testid for widgets without good semantics. Move all locators into page objects so future changes touch one file. Add a code review rule and a lint check that flags raw CSS selectors. Share a short locator guide with developers so they know which attributes tests depend on.
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.
26
How do you wait for a network response in Playwright?
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.
maxFailures stops the run after a set number of test failures, for example maxFailures: process.env.CI ? 10 : undefined. If an environment is down and every test fails, the build stops early instead of burning an hour of CI time. Set it high enough that a few real failures still show their full picture.
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.
31
How do you verify that an API returns consistent data across two versions of an endpoint?
Call both versions, for example /v1/orders/42 and /v2/orders/42, with the same test data. Map the fields that should match, since names may differ, and compare them with toEqual. Also assert that fields removed in v2 are really absent and new ones have correct types. Running this during a migration catches breaking changes before clients switch.
An option is a fixture whose value is configured rather than computed, declared with { option: true } and a default, for example defaultUser: ['standard', { option: true }]. Projects or test.use can override it, so one suite can run as admin in one project and as a viewer in another. Other fixtures can read the option to decide what to set up.
34
Parallel tests create users with the same email and fail with 'already exists'. How do you fix it?
Generate unique data per test, for example by adding testInfo.testId, the parallel index or a random suffix to the email, or by using a data builder that creates a fresh user through the API. Avoid hard-coded shared records in test files. Clean up created users in a fixture teardown so the database does not fill up over time.
Situation: a pricing table had many discount rules shown in the UI. Task: decide how to test them. Action: I proposed unit tests for the calculation, component tests for how each rule rendered, and one end-to-end test for buying a discounted plan. I explained the runtime and maintenance cost of each. Result: the team agreed, we covered 30 rules in under a minute, and the approach became our default.
38
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.
39
Baselines are always rendered in Docker, yet the repo has separate Windows and Linux image files. How do you keep one baseline per browser?
The default file name includes the platform, so a developer who updated baselines on Windows created a second set. Set snapshotPathTemplate in the config without the {platform} token, for example '{testDir}/__screenshots__/{testFilePath}/{arg}-{projectName}{ext}', delete the stray files and only update baselines through the Docker command or a CI job. Document the rule so it does not happen again.
40
Tell me about a disagreement with a developer over a failing test.
Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.
Tips to crack the ThoughtSpot Playwright Testing interview
Practise DSA problems carefully, as engineering interviews at product analytics companies often focus on strong problem-solving fundamentals.
Revise SQL, query execution basics and data warehouse concepts to discuss how analytics queries run on large datasets.
Try the product's free trial or demos so you can talk about search-based analytics from a user's perspective.
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; ThoughtSpot interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the ThoughtSpot Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (system design or domain); 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 ThoughtSpot Playwright Testing interview?
This practice set leans on Framework Design and CI/CD (7), Network Mocking (6), API Testing (5), Visual & Accessibility Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most ThoughtSpot interviewers ask you to walk through real work.
Are these the exact questions asked at ThoughtSpot?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like ThoughtSpot's. They are not a leaked or verified list of past questions.
Where does ThoughtSpot hire Playwright Testing professionals in India?
ThoughtSpot has large teams in Bengaluru. Openings and locations change often, so check the ThoughtSpot careers page and filter by city and experience.
Playwright Testing questions for similar companies