Last checked against Postman's documentation: 9 October 2026.
Postman questions come up in interviews for QA, API testing and backend roles. Interviewers rarely want trivia. They want to know whether you can organise requests, reuse data safely, write assertions and run tests somewhere other than your own laptop. The answers below are checked against Postman's current documentation, including a recent change that trips up candidates who learned the tool a few years ago: Newman and the v3 collection format.
1. What is a collection, and why use one?
A collection is a group of saved requests, together with the scripts, variables and authorisation settings that apply to them. Collections let you organise requests by feature, share them with a team and run them together as a test suite. A good answer adds a practical habit: organise folders by user journey (for example "Sign up" and "Checkout") so the run order makes sense.
2. What variable scopes does Postman have, and which one wins?
According to Postman's variables documentation, the scopes from broadest to narrowest are global, collection, environment, data and local. If the same name exists in more than one scope, the narrowest scope wins, so a local username overrides a global username for that run.
A follow-up worth preparing: where should secrets go? The same page describes Postman Vault, which stores sensitive data as vault secrets kept separate from collections and environments. Never hard-code tokens in a shared collection.
3. What is an environment?
An environment is a set of variables you can switch between — typically one each for development, staging and production — so the same requests run against different base URLs and credentials. See Postman's page on managing environments. In an interview, mention the risk too: running a destructive test against production because the wrong environment was selected. Name environments clearly and keep write-heavy tests out of production runs.
4. What is the difference between pre-request and post-response scripts?
Postman's introduction to scripts explains that pre-request scripts run before the request is sent and post-response scripts run after the response arrives. Typical uses:
| Script | Typical use |
|---|---|
| Pre-request | Generate a timestamp or unique ID, compute a signature, fetch or refresh a token |
| Post-response | Assert status, body and headers; extract a value such as an ID for the next request |
5. Write a basic test
This example comes from Postman's test scripts documentation:
pm.test("Status test", function () {
pm.response.to.have.status(200);
});
Go one step further to show you can test the body. The docs note that the Chai assertion library is built in, so you can use pm.expect:
pm.test("Order has an id and the right status", function () {
const body = pm.response.json();
pm.expect(body.id).to.be.a("string");
pm.expect(body.status).to.eql("CREATED");
});
The field names in the second test are illustrative; adapt them to the API you are testing.
6. How do you chain requests?
Extract a value in a post-response script, store it in a variable, and reference it in the next request with double curly braces:
const body = pm.response.json();
pm.collectionVariables.set("orderId", body.id);
The next request's URL can then be {{baseUrl}}/orders/{{orderId}}. Explain why you chose collection scope: the value is needed across requests in this collection but shouldn't leak into other collections.
7. What does the Collection Runner do?
The Collection Runner runs a collection's requests in the order you choose, for a set number of iterations, with an optional delay in milliseconds before each request. You can supply a data file as iteration data, which is how data-driven testing works: each iteration reads one row, and its values are available as data-scope variables. Scripts can change the order with pm.execution.setNextRequest(). Runs can also be scheduled in the Postman cloud or with monitors.
8. How do you run Postman tests in CI/CD?
This is where outdated answers show. Postman's Newman page still describes Newman as a command-line tool for running collections, but warns that Newman isn't compatible with the collection v3 format used in Postman v12 and later, and tells users to migrate to the Postman CLI to keep running their collections. The Postman CLI overview gives the run command as:
postman collection run <path-or-id>
A strong answer sounds like this: "In a pipeline I'd run the collection with the Postman CLI against a test environment, fail the build on any failed assertion and publish the report. If the team still runs older collections on Newman, I'd plan the migration, because Newman doesn't support the v3 collection format."
9. What is a mock server for?
A mock server returns example responses for defined requests, so front-end developers and testers can work before the real API exists, or test error cases that are hard to trigger. Postman's mock server documentation covers setup. Mention the limit as well: a mock shows that your client handles the agreed contract, not that the real server behaves correctly.
10. API fundamentals interviewers mix in
Postman questions often turn into HTTP questions. Have crisp answers ready:
| Question | Answer |
|---|---|
| Which methods are idempotent? | Under RFC 9110, PUT, DELETE and the safe methods (GET, HEAD, OPTIONS, TRACE) are idempotent; POST is not |
| 401 or 403? | 401: authentication is missing or invalid. 403: the server understood the request but refuses to authorise it |
| 400 or 422? | 400 for a malformed request; 422 when the syntax is fine but the content can't be processed, such as a failed validation |
| 201 or 200? | 201 means a resource was created; 200 is a general success |
| What should you check besides status? | Body schema and values, headers such as Content-Type, response time, and error messages for negative cases |
Worked example: a test plan for one endpoint
The endpoint here is illustrative: POST /orders creates an order.
| Test | Input | Expected result |
|---|---|---|
| Happy path | Valid item and quantity, valid token | 201; body has an id; status is "CREATED" |
| Missing token | No Authorization header | 401 |
| Invalid quantity | Quantity of 0 | 400 or 422, as the API contract specifies, with a clear error message |
| Duplicate submit | Same idempotency key sent twice, if the API supports one | One order created; the second call returns the same order |
| Response time | Valid request | Within the agreed threshold |
| Chaining | Returned id used in GET /orders/{{orderId}} | 200 with the same order details |
Walking an interviewer through a plan like this — positive, negative and edge cases, plus chaining — usually impresses more than reciting a list of features.
Final checklist
- Know the five variable scopes and that the narrowest one wins.
- Write a status test and a body test with
pm.expectfrom memory. - Explain request chaining with
pm.collectionVariables.set. - Know that Newman doesn't support the v3 collection format, and how to run a collection with the Postman CLI.
- Prepare a test plan for one endpoint that includes negative cases.