Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Postman hiring for Playwright Testing roles
Postman is an API platform used by millions of developers to design, test, document and monitor APIs. It began as a side project by Abhinav Asthana in Bengaluru and grew into a global company with headquarters in San Francisco. Its Bengaluru office hosts major engineering teams that hire software engineers, test engineers, developer advocates and product roles.
For Playwright Testing roles, this Postman practice set focuses most on Locators and Assertions (7), JavaScript and TypeScript (5), Fixtures and Hooks (4), Debugging and Trace Viewer (4). It has 32 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
San Francisco, USA
Main India offices
Bengaluru
Postman Playwright Testing interview process
Online coding assessment or take-home task
Technical round 1 (DSA or problem solving)
Technical round 2 (system design or API design)
Hiring manager and culture round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for PostmanStart 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
Your test clicks a button before the page's JavaScript has attached its handler, so nothing happens. What do you do?
This is a hydration problem: the button is visible and enabled but not yet interactive. Wait for a signal that the app is ready, such as a loaded data request or a visible element that only appears after hydration, then click. A better fix is to report it to developers, because real users hit the same issue. Avoid fixed waitForTimeout calls.
02
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.
03
A beforeAll creates one user and tests in the same file fail randomly in parallel mode. Why?
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.
04
A test must confirm that an error banner does not appear, but it always waits the full timeout. How do you fix it?
Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.
05
How do you share one authenticated API context across all tests in a worker?
Create a worker-scoped fixture that calls request.newContext with baseURL and an auth header, or logs in through the API and keeps the cookies. Pass it to use, and dispose it after use returns. Every test in that worker gets the same ready context, so login happens once per worker. Do not store per-test data on it, or tests start depending on each other.
JavaScript runs one call stack and uses queues for async work; the event loop pushes callbacks from the microtask (promises) and task queues when the stack is empty.
Run it many times in isolation: npx playwright test cart.spec.ts -g 'apply coupon' --repeat-each=30 --workers=4 --trace=on. Repeating it with several workers creates the timing pressure CI has. Add --retries=0 so failures are not hidden. Once it fails, open the trace for that run and compare it with a passing run.
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.
The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.
12
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.
13
Write a fixture that gives each parallel worker its own test account.
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.
15
How do you add or change request headers for only some requests?
Register a route for the matching URLs and call route.continue({ headers: { ...route.request().headers(), 'x-test-mode': 'true' } }). Other requests are untouched. For headers on every request, use extraHTTPHeaders in the config instead. This is useful for feature toggles, tenant ids or bypass tokens that only certain endpoints accept.
They are built-in utility types. Partial<User> makes all fields optional, handy for override objects in test data builders. Pick<User, 'id' | 'email'> keeps chosen fields, and Omit<User, 'password'> removes some. Record<Role, string> maps every key of a union to a value type, for example storing a credentials file path per role.
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.
19
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.
20
How do you handle rate limits or slow APIs in tests?
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.
24
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.
25
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.
26
How do you test an async job API that returns 202 and finishes later?
Start the job and assert the 202 status and the returned job id. Then poll the status endpoint with expect.poll, with sensible intervals and a timeout, until it reports completed. Finally fetch the result and validate it. Also test the failure path, for example invalid input leading to a failed status with a clear error message.
27
A test checks a price that is formatted differently per locale. How do you make the assertion robust?
Fix the locale for the test with the locale and timezoneId options so the format is predictable. Build the expected string with Intl.NumberFormat using the same locale, rather than hard-coding it. If you test several locales, run them as projects or parameterised tests. For business logic, also assert the raw number through the API response.
28
How would you handle a very flaky element that appears after an animation?
// scan the page but skip the chat widget you do not own
const results = await new AxeBuilder({ page })
.include('main')
.exclude('#third-party-chat')
.disableRules(['duplicate-id'])
.analyze();
expect(results.violations).toEqual([]);
// log a ticket for anything you exclude
31
Write a typed helper that retries an async function a few times.
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.
33
Write a test that deletes a record and confirms it is gone.
Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.
35
How do you add build details such as the commit and environment to the test report?
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.
36
How do you check that a product list on the page is sorted by price?
const texts = await page.getByTestId('price').allTextContents();
const prices = texts.map(t => Number(t.replace(/[^0-9.]/g, '')));
const sorted = [...prices].sort((a, b) => a - b);
expect(prices).toEqual(sorted);
// wait for the list first with toHaveCount
37
A test fails with 'Target page, context or browser has been closed'. What usually causes it?
Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.
38
How do you wait for a network response in Playwright?
Tips to crack the Postman Playwright Testing interview
Learn REST API concepts thoroughly, including HTTP methods, status codes, authentication and how to write API tests in Postman.
Practise DSA problems and be ready to build or debug a small JavaScript or Node.js feature in a practical round.
Show genuine developer empathy by discussing tools you use daily and how you would improve the API development workflow.
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; Postman interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Postman Playwright Testing interview?
Candidates usually go through 4 stages: Online coding assessment or take-home task; Technical round 1 (DSA or problem solving); Technical round 2 (system design or API design); Hiring manager and culture 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 Postman Playwright Testing interview?
This practice set leans on Locators and Assertions (7), JavaScript and TypeScript (5), Fixtures and Hooks (4), Debugging and Trace Viewer (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Postman interviewers ask you to walk through real work.
Are these the exact questions asked at Postman?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Postman's. They are not a leaked or verified list of past questions.
Where does Postman hire Playwright Testing professionals in India?
Postman has large teams in Bengaluru. Openings and locations change often, so check the Postman careers page and filter by city and experience.
Playwright Testing questions for similar companies