Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Rapido hiring for Playwright Testing roles
Rapido is a Bengaluru-based ride-hailing platform that started with bike taxis and expanded into auto rickshaws, cabs and parcel delivery. It is known for affordable rides and a subscription-style model for driver partners. It hires software engineers, data scientists, data analysts, product managers and operations roles to run its mobility platform across many Indian cities.
For Playwright Testing roles, this Rapido practice set focuses most on Fixtures and Hooks (6), API Testing (6), Framework Design and CI/CD (5), Component Testing (4). It has 5 easy, 29 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Bengaluru, India
Main India offices
Bengaluru
Rapido Playwright Testing interview process
Online coding or analytics assessment
Technical round 1 (DSA or SQL)
Technical round 2 (design or case)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for RapidoStart 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.
A type annotation such as const user: User = data asks the compiler to check that the value really fits User. A type assertion such as data as User tells the compiler to trust you, so mismatches are not reported. In test code assertions are risky on API responses, because a wrong field passes compilation and fails later. Prefer annotations, type guards or runtime schema validation.
03
How do you set up Playwright component testing in an existing React project?
Run npm init playwright@latest -- --ct and choose React. It installs @playwright/experimental-ct-react, creates playwright-ct.config.ts and adds a playwright folder containing index.html and index.tsx. index.html hosts the mounted component and index.tsx is where global styles, themes and providers go. Tests then live in files such as Button.spec.tsx and run with npx playwright test -c playwright-ct.config.ts.
04
How do you attach a screenshot or log to the report from inside a test?
Set the metadata field in playwright.config, for example metadata: { commit: process.env.GIT_SHA, env: process.env.TEST_ENV }, which reporters can read and recent HTML reports show. Inside tests use testInfo.annotations.push for per-test details like a ticket id. Custom reporters can read config.metadata in onBegin and include it in messages or uploads.
06
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.
07
A product list uses infinite scroll. How do you test that more items load?
Count the items, then scroll the last item into view with lastItem.scrollIntoViewIfNeeded() or page.mouse.wheel. Assert with expect(items).toHaveCount greater than before, for example using expect.poll on items.count(). Repeat until an end-of-list message appears. Also check no duplicates appear and that a loading indicator shows while fetching.
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.
09
How would you type the response of an API call in TypeScript?
Define an interface for the payload, cast or validate the parsed JSON to it (for example with zod), and use that type in assertions to catch shape changes.
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.
15
Write a component test for a Counter that increments on click.
A context created with request.newContext() holds cookies, connections and stored responses in memory. Calling await context.dispose() frees them, and any later call on it fails. Without disposing, long runs can leak memory. The built-in request fixture is disposed automatically, so this matters for contexts you create in fixtures or helpers.
The blob reporter writes a compact archive of everything about a run, including results, attachments and traces, into the blob-report folder. It is meant for machines rather than people. Each shard produces one blob, and npx playwright merge-reports later combines them into a single HTML, JUnit or JSON report. Without it, every shard would produce its own separate HTML report.
If the app registers a service worker, it may answer requests from its own cache, so page.route never sees them and mocks seem ignored. Set serviceWorkers: 'block' in the context or config options to turn them off when mocking. If you specifically test offline or PWA caching, keep them enabled and test that behaviour separately.
24
How do access modifiers help in page object classes?
private and protected hide internal locators and helper steps, so tests can only call meaningful public methods such as login or addToCart. This keeps tests readable and lets you change internals without breaking callers. readonly on the page field prevents it from being replaced. TypeScript enforces these at compile time only, not at runtime.
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.
Snapshot stable, high-value screens and shared components, not every page. Render baselines only in a pinned Docker image, mask or mock dynamic data, and disable animations. Keep visual tests in their own project or tag so they can run on pull requests touching UI code. Define owners for baseline reviews and keep thresholds strict in config. Combine with functional assertions, because pictures alone do not tell you why something broke.
31
A trace shows the click landed on an overlay instead of the button. How do you fix it?
The call log will say another element intercepts pointer events. Find what the overlay is, such as a loading mask, cookie banner or chat widget. Wait for it to disappear with expect(overlay).toBeHidden(), or close it in a fixture. Do not use force: true, because it hides a real issue: a user would also be blocked by that overlay.
32
Write an accessibility scan that checks only WCAG 2.1 A and AA rules.
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.
Component testing mounts a single UI component, such as a React or Vue button or form, in a real browser page and tests it with the normal Playwright API. Playwright bundles the component with Vite, serves it on a small page and gives you a mount fixture. You get real browser rendering and events, which unit tests in jsdom cannot give, while staying much faster than full end-to-end flows. The feature is still marked experimental.
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.
38
Mocked responses drift from the real API and tests pass while production breaks. How do you prevent this?
Generate mock data from the API schema or real recorded responses instead of hand-writing it. Validate mocks against the OpenAPI schema in a unit test. Add contract tests on the backend side and re-record HAR files on a schedule. Keep a few unmocked end-to-end tests that run after each deploy. Treat mock files as code with owners and reviews.
39
The suite has a 3 percent flaky rate. How do you find and fix the causes systematically?
Collect data first: flaky results from the reports across a few weeks, grouped by test, browser and error message. Run the worst offenders with --repeat-each and traces on. Fix common causes such as missing awaits, shared data, fixed sleeps and order-dependent tests. Quarantine tests you cannot fix quickly with a tag and a ticket, and track the rate weekly.
40
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
Tips to crack the Rapido Playwright Testing interview
Practise DSA and design of location-based systems such as nearby driver matching, surge pricing and live tracking.
For analyst roles, prepare metrics like ride completion rate, cancellations and captain utilisation, and practise SQL on them.
Use the Rapido app in your city and form clear opinions on rider and driver experience before the interview.
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; Rapido interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Rapido Playwright Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round 1 (DSA or SQL); Technical round 2 (design or case); 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 Rapido Playwright Testing interview?
This practice set leans on Fixtures and Hooks (6), API Testing (6), Framework Design and CI/CD (5), Component Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Rapido interviewers ask you to walk through real work.
Are these the exact questions asked at Rapido?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Rapido's. They are not a leaked or verified list of past questions.
Where does Rapido hire Playwright Testing professionals in India?
Rapido has large teams in Bengaluru. Openings and locations change often, so check the Rapido careers page and filter by city and experience.
Playwright Testing questions for similar companies