API Testing With Postman Interview Questions: Practical and Conceptual

A Postman interview is rarely about the tool’s buttons. Interviewers use Postman as a window into three things: whether you understand HTTP, whether you can write tests that fail for the right reasons, and whether your collection could run unattended in a pipeline. A candidate who can click Send but cannot explain why a test passed against a broken API will struggle.

This guide works through one example API, layer by layer, in the order interviewers usually probe. Each layer lists the conceptual questions you are likely to hear and the practical task that often follows. Postman behaviour described here comes from Postman’s own documentation, checked in November 2026; the interface changes often, so describe concepts rather than menu paths.

The example: a small orders API

Imagine you are asked to test an API with four endpoints:

• POST /login returns a token.
• POST /orders creates an order and returns its id.
• GET /orders/{id} returns one order.
• DELETE /orders/{id} cancels it.

The API runs in a test environment and a staging environment with different base URLs and accounts. Every question below can be answered in terms of this API, which is exactly what a good interview answer does: it makes the concept concrete.

Layer 1: HTTP knowledge they check first

Before any Postman feature, expect questions that test whether you know what a correct response looks like.

“Which of these four requests are idempotent, and why does it matter for testing?”

GET and DELETE are idempotent; POST is not. MDN defines an idempotent method as one where making several identical requests has the same intended effect on the server as making one, and notes that safe methods, PUT and DELETE are idempotent while POST and PATCH are not guaranteed to be (MDN Web Docs). For testing, that means repeating POST /orders creates a second order, so a test that re-runs must clean up or use unique data.

A strong extra point: the status code of repeated idempotent calls can differ. MDN’s example is a DELETE that returns 200 the first time and 404 afterwards (MDN Web Docs). Your test for a second DELETE should expect that, not treat it as a failure.

“The token is missing. What status should you get, and what if the token is valid but belongs to another customer?”

A missing or invalid token should produce 401 Unauthorized. A valid token without permission for that order should produce 403 Forbidden. MDN describes 401 as a request lacking valid authentication credentials, and 403 as the response when the credentials are valid but the client lacks permission (MDN Web Docs). Candidates who test only the happy path miss both cases.

Layer 2: variables and environments

“How would you run the same collection against test and staging?”

Put values that differ by environment, such as the base URL and test account, in two environments, and reference them with double curly braces, for example {{base_url}}/orders. Only one environment can be active at a time, and switching it switches every request (Postman Docs).

“Explain Postman’s variable scopes and which one wins”

Postman’s documentation lists the scopes from broadest to narrowest as global, collection, environment, data and local. When the same name exists in several scopes, the value from the narrowest scope is used (Postman Docs). Postman’s script reference gives an example where a collection variable and an environment variable share a name, and pm.variables.get returns the environment value (Postman Docs).

A good answer adds when to use each: collection variables for values that belong to the API itself, environments for deployment-specific values, data variables for test data from a file, and local variables for temporary values inside one run. Data variables come from CSV or JSON files and don’t persist beyond the run (Postman Docs).

“Where would you keep the password for the test account?”

Not in a shared collection. Postman stores variable values locally by default, and a local value isn’t synced to the Postman cloud unless someone with Editor access shares it (Postman Docs). The same page describes Postman Vault for sensitive values, kept separate from collections and environments (Postman Docs). Mention your employer’s own secrets policy too; in a CI pipeline the secret usually comes from the pipeline’s secret store.

Layer 3: scripts and assertions

“When do pre-request and post-response scripts run?”

Pre-request scripts run before the request is sent; post-response scripts (the tests) run after a response is received (Postman Docs). Scripts can also be attached to a collection or a folder. For post-response scripts, Postman’s documentation states that the run order for each request is collection tests, then folder tests, then request tests (Postman Docs).

Practical task: “Write tests for POST /orders”

This is the most common live exercise. The example below is illustrative. Each assertion uses syntax from Postman’s documentation: pm.test to define a test, Chai BDD-style pm.expect assertions, pm.response.json() to parse the body, and response time and header checks (Postman Docs; Postman Docs).

pm.test("Order is created", function () {
    pm.response.to.have.status(201);
});

const body = pm.response.json();

pm.test("Response has an order id and the right total", function () {
    pm.expect(body.id).to.be.a("string");
    pm.expect(body.total).to.eql(150);
});

pm.test("Content type is JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

pm.test("Responds within 500 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.environment.set("order_id", body.id);

Talk through your choices as you write. Say why you check 201 rather than any 2xx, why the response-time threshold should come from an agreed requirement rather than a guess, and why the last line saves the id so that GET and DELETE can use {{order_id}}. pm.environment.set stores a value in the active environment (Postman Docs).

“How do you chain requests without copying values by hand?”

The last line above is the answer: save values from one response into a variable in a post-response script, then reference that variable in later requests. For the login token, the same pattern stores the token once and every request sends it in its Authorization header. Mention that you would put the login call first in the collection or in a collection-level pre-request script, so every request has a fresh token.

“Your test passes, but the API is broken. How can that happen?”

This question separates experienced testers. Good answers include: the test only checks the status code; the check is a plain comparison or a console.log rather than a pm.expect assertion inside pm.test, so nothing can fail; the test reads a stale variable from an earlier run rather than the current response; or the data in the test environment happens to match the hard-coded expected value. The fix is to assert on the specific fields that matter and to reset state before each run.

Layer 4: running collections at scale

“How would you test 200 order combinations?”

Use the collection runner with a CSV or JSON data file, one row per case. Each row’s columns become data variables, which scripts read with pm.iterationData (Postman Docs). Each test then compares the response with the expected values from the same row, so the data file documents the test cases.

“How would you run this in CI?”

From the command line. Postman’s documentation describes Newman as Postman’s command-line collection runner and the Postman CLI as the recommended command-line tool for running collections locally and in CI/CD pipelines (Postman Docs). The commands are similar:

newman run orders.postman_collection.json -e staging.json -d orders.csv -n 200
postman collection run orders.postman_collection.json -e staging.json -d orders.csv -n 200

Here -e sets the environment, -d the data file and -n the number of iterations (Postman Docs). If asked to compare them, Postman’s migration guide notes that Newman only runs collections and only supports the v2.1 JSON collection format, while the Postman CLI supports further Postman features such as monitors and mock servers (Postman Docs).

Layer 5: test design judgement

Experienced candidates are judged on what they choose to test, not just how. Be ready to explain:

• Negative cases: missing fields, wrong types, an order for a product that doesn’t exist, a total of zero, an expired token.
• Test independence: each request should create the data it needs, or the collection should run in a fixed order with setup and teardown steps. A test that only passes after another test has run is fragile.
• Contract checks: asserting the structure of the response (required fields and their types), not just one or two values, so a renamed field is caught.
• What Postman is not for: high-volume load testing and UI testing need other tools. Saying so shows judgement.

Postman interview questions for freshers and for experienced testers

The same layers apply to both, but the depth changes.

For a fresher role, being able to write and explain the POST /orders tests above is often enough to stand out. For a senior role, expect to design the whole collection and defend its structure.

Your CV should show the same evidence: the APIs you tested, the number of automated checks, and whether they ran in a pipeline. Our resume builder lets you add that under each job, and the ATS resume score checker shows whether tools like Postman and Newman are visible to screening software.

FAQ

Do I need to know JavaScript for a Postman interview?

Basic JavaScript, yes. Postman scripts are written in JavaScript, so you should be comfortable with objects, arrays, functions and reading JSON. You don’t need front-end framework knowledge.

What is the difference between Newman and the Postman CLI?

Both run collections from the command line with similar options. Postman’s documentation recommends the Postman CLI for local and CI/CD use and notes that Newman only runs collections in the v2.1 JSON format.

Which variable wins if two scopes use the same name?

The narrowest scope. From broadest to narrowest, Postman’s order is global, collection, environment, data and local.

Is Postman enough for an API testing role?

It covers manual and automated functional testing well. Many roles also expect a code-based framework, SQL for checking data, and CI experience, so read the job description carefully.

Sources

• Store and reuse values using variables, Postman Docs
• Reference variables in Postman scripts, Postman Docs
• Write scripts to test API response data in Postman, Postman Docs
• Postman test script examples, Postman Docs
• Migrate scripts from Newman to the Postman CLI, Postman Docs
• Idempotent, MDN Web Docs
• 401 Unauthorized, MDN Web Docs