Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About InMobi hiring for Playwright Testing roles
InMobi is a Bengaluru-based technology company known for its mobile advertising and marketing technology platforms. It helps advertisers reach users across apps and devices using data and machine learning, and its group also built the Glance content platform for smartphone lock screens. It hires software engineers, data scientists, data engineers and product managers for large-scale adtech systems.
For Playwright Testing roles, this InMobi practice set focuses most on Playwright Core (7), API Testing (6), Network Mocking (5), Framework Design and CI/CD (4). 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
Bengaluru, India
Main India offices
Bengaluru
InMobi Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (system design)
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for InMobiStart 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.
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.
03
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.
04
How do you set baseURL and common headers for API tests?
Put them in the use block of playwright.config: use: { baseURL: process.env.API_URL, extraHTTPHeaders: { Accept: 'application/json', Authorization: `Bearer ${process.env.TOKEN}` } }. The request fixture then sends them on every call, and tests use short paths like /api/users. Keep tokens in environment variables, never in the repository.
05
How do you validate an API response in Playwright?
Auto-waiting, a built-in test runner, Chromium/Firefox/WebKit with one API, network interception, the trace viewer and parallel runs out of the box — usually faster and less flaky.
They pick one element by position from a locator that matches many. They are fine when order is truly meaningful, such as the first search result. They are risky when order depends on data, sorting or rendering speed, because the test may silently act on the wrong element. Prefer filtering by text or a child element that identifies the item.
09
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.
10
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.
11
What are fixtures and how do you create a custom one?
Register a route with a counter: on the first call use route.fulfill with status 503, and on later calls fulfil with a success body. Perform the action, then assert the UI shows the final data and the counter equals 2. You can also check that no error message flashed. This proves the retry logic works without waiting for a real outage.
13
How do you reduce the execution time of a 2000-test suite?
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.
14
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.
15
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.
16
How do you listen to all network requests on a page?
Subscribe to events: page.on('request', r => ...), page.on('response', r => ...) and page.on('requestfailed', r => ...). You can log URLs, collect API calls or count failures. Unlike route, listeners only observe and cannot change traffic. They are handy for checks like 'no request returned a 5xx status during this flow'.
17
Component tests fail because imports like @/utils cannot be resolved, though the app builds fine. How do you fix it?
The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.
18
Write a test that updates a user with PUT and verifies the change.
Situation: one morning 300 tests failed in CI. Task: restore the pipeline quickly. Action: the trace showed every test failing inside an auth fixture after a login API change, so I fixed the fixture, added a dedicated setup test that fails fast with a clear message, and alerted the team. Result: the pipeline recovered within an hour and similar outages became easy to spot.
20
One shard finishes in 4 minutes and another takes 15. How do you balance them?
Check whether fullyParallel is off, because file-level sharding puts big files together. Turn it on if tests are independent, or split the largest files. Use reportSlowTests and the merged report's durations to find heavy files, and move slow setup into API calls or shared storage state. Also check that one shard is not getting all the tests of a slow project such as WebKit.
21
How many workers does Playwright use by default, and how do you change it?
By default Playwright uses about half of the logical CPU cores on the machine. You can set workers in playwright.config as a number or a percentage string such as '50%', or override it on the command line with --workers=4. Many teams use process.env.CI ? 2 : undefined so CI runners with few cores are not overloaded while laptops use their full power.
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.
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.
26
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.
27
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.
Declarations of var and functions are moved to the top of their scope at compile time; let and const are hoisted but stay in the temporal dead zone until declared.
31
How do you test geolocation, permissions and time zones?
First confirm the change is intended and check a sample of diffs to make sure nothing else moved. Then regenerate baselines in the CI Docker environment in a separate commit, so reviewers can see only image changes. Longer term, reduce the count: most of those tests should not snapshot full pages. Keep a few page-level shots and move detail checks to component-level screenshots of key states.
33
Ten engineers write tests and quality varies a lot. How do you keep the framework consistent?
Write a short contribution guide with examples. Add ESLint with the Playwright plugin and the no-floating-promises rule, plus Prettier, enforced in CI. Require reviews from framework owners for shared fixtures and page objects. Provide generators or templates for new page objects, and run regular sessions to review flaky tests together.
34
How do you write a custom matcher with expect.extend?
expect.extend takes an object of matcher functions. Each receives the received value and arguments, and returns { pass, message, name, expected, actual }. For example a toHaveAmount matcher can read a locator's text, strip the currency symbol and compare numbers, retrying with expect.poll inside. Export the extended expect from a shared fixtures file so all tests use the same version.
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.
Situation: our API helpers returned loosely typed objects and tests often read fields that no longer existed. Task: make helpers safer. Action: I added response interfaces, turned on strict mode and replaced any with unknown plus type guards. Result: the compiler immediately showed eleven tests reading a renamed field, which had been passing because they compared undefined with undefined. We fixed them before the next release.
Record once with page.routeFromHAR('data/orders.har', { url: '**/api/**', update: true }) while running against a real server. Later runs replay the saved responses from the HAR instead of hitting the backend. You can edit the stored JSON to create edge cases. Re-record when the API changes, otherwise the replay drifts from reality.
40
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.
Tips to crack the InMobi Playwright Testing interview
Practise DSA problems along with concepts of high-throughput systems, caching and low-latency design used in advertising platforms.
For data roles, revise SQL, statistics and machine learning basics like click-through rate prediction and model evaluation metrics.
Read about how mobile advertising works, including ad auctions and targeting, to discuss the business side confidently.
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; InMobi interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the InMobi Playwright Testing interview?
Candidates usually go through 5 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (system design); Hiring manager 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 InMobi Playwright Testing interview?
This practice set leans on Playwright Core (7), API Testing (6), Network Mocking (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 InMobi interviewers ask you to walk through real work.
Are these the exact questions asked at InMobi?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like InMobi's. They are not a leaked or verified list of past questions.
Where does InMobi hire Playwright Testing professionals in India?
InMobi has large teams in Bengaluru. Openings and locations change often, so check the InMobi careers page and filter by city and experience.
Playwright Testing questions for similar companies