Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Blinkit hiring for Playwright Testing roles
Blinkit is an Indian quick commerce company, owned by Eternal (formerly Zomato), that delivers groceries and everyday essentials within minutes. It was earlier known as Grofers and runs a network of dark stores in many cities. It hires software engineers, data analysts, product managers, supply chain and operations professionals to run its fast delivery platform.
For Playwright Testing roles, this Blinkit practice set focuses most on API Testing (7), Framework Design and CI/CD (5), Network Mocking (5), Playwright Core (4). It has 3 easy, 33 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Gurugram, India
Main India offices
Gurugram
Blinkit Playwright Testing interview process
Online coding or analytics assessment
Technical round 1
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 BlinkitStart 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
How do you write data-driven API tests with many inputs?
Store them in the CI system's secret store and pass them as environment variables, never in the repository or config files. Read them through process.env and fail fast if they are missing. Use dedicated test accounts with limited rights. Avoid printing them in logs, and make sure traces and screenshots do not expose them in reports.
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'.
05
What is the difference between @playwright/test and the playwright package?
@playwright/test is the test runner with fixtures, assertions, parallel workers, retries, reports and config. The playwright package is the automation library alone, used for scripts like scraping or generating PDFs, where you launch browsers yourself. For testing, install @playwright/test. Both share the same browser automation API underneath.
06
How do you test that duplicate POST requests do not create duplicate orders?
If the API supports an idempotency key header, send the same POST twice with the same key and assert one order exists and both responses return the same id. Send it with different keys and expect two orders. Also try concurrent requests with Promise.all to check race conditions. Without a key, document the risk to the team.
07
Write a custom fixture that gives a logged-in page.
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.
09
How do you assert that a request was sent with the correct payload?
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.
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.
Modern Chromium headless uses the same browser code as headed, so behaviour is very close. Differences still appear in viewport size, GPU rendering, fonts and some OS dialogs. Tests should set an explicit viewport and not depend on window focus. If something passes headed but fails headless, record a trace and compare screenshots.
20
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.
21
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.
22
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.
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.
25
Tell me about a hard bug you found while debugging a test.
Situation: a search test failed about once in ten runs. Task: find the cause. Action: I ran it with --repeat-each and traces, and saw two search requests return out of order, so the older result replaced the newer one. Result: I proved it was a real race condition in the app, developers fixed it with request cancellation, and the test became stable.
26
What does the DEBUG=pw:api environment variable do?
Setting DEBUG=pw:api prints detailed logs of every Playwright API call to the terminal, including waits and retries inside actions. It helps when a test hangs and you need to see exactly which step is waiting and why. Other channels such as pw:browser show browser process output. It is noisy, so use it only while investigating.
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.
30
How is a Playwright component test different from a Jest unit test with jsdom?
jsdom is a JavaScript imitation of the DOM running in Node, so layout, CSS, real focus and many browser APIs are missing or fake. A Playwright component test renders in real Chromium, Firefox or WebKit, so visibility, scrolling, styles and keyboard behaviour are real. The cost is a build step and a browser, so it is slower than jsdom. Pure logic and hooks are still cheaper in unit tests.
31
Show a config with a setup project and a browser project that reuses its login.
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.
33
How do you locate elements inside a specific row or card?
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
34
Write a test that updates a user with PUT and verifies the change.
forEach does not wait for async callbacks, so it starts each callback and returns at once. The test may finish before the assertions run, or their errors are lost. Use for...of with await to run steps in order, or Promise.all with map when the steps can safely run in parallel. A lint rule can flag this pattern.
36
How do you assert an element's CSS class, attribute or value?
test.describe.configure({ mode: 'serial' }) runs tests in order in one worker, and if one fails the rest are skipped. mode: 'parallel' lets tests in one file run across workers. Serial mode suits a true step-by-step flow, but it makes tests depend on each other, so prefer independent tests and use serial only when there is no alternative.
39
How do you mock API calls made by a component in a component test?
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.
40
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.
Tips to crack the Blinkit Playwright Testing interview
Think about quick commerce challenges such as dark store inventory, demand forecasting and delivery time before case discussions.
Practise SQL with time-based analysis and metrics like order volume, delivery time and fill rate for analyst roles.
For engineering roles, revise DSA and design of real-time systems like order tracking and rider assignment.
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; Blinkit interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Blinkit Playwright Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round 1; 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 Blinkit Playwright Testing interview?
This practice set leans on API Testing (7), Framework Design and CI/CD (5), Network Mocking (5), Playwright Core (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Blinkit interviewers ask you to walk through real work.
Are these the exact questions asked at Blinkit?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Blinkit's. They are not a leaked or verified list of past questions.
Where does Blinkit hire Playwright Testing professionals in India?
Blinkit has large teams in Gurugram. Openings and locations change often, so check the Blinkit careers page and filter by city and experience.
Playwright Testing questions for similar companies