Postman Interview Questions: API Tests and Worked Examples

TL;DR

• Prepare Postman interview answers by showing a request, a meaningful assertion and the evidence you would keep when it fails.
• Test response content and authorization behavior as well as status codes; a successful HTTP response can still contain the wrong data.
• Keep test data and credentials scoped to a controlled environment, with cleanup that does not touch unrelated records.
• Use the original order-API exercise below to practise requests, scripts, negative cases and a reproducible defect report.

Begin with an API contract

Imagine a practice API that lets a signed-in customer read an order. For this exercise, GET /orders/order_demo_17 should return a JSON object containing id, status and totalCents. The allowed statuses are pending, paid and cancelled; the amount is a non-negative integer. These are invented exercise requirements, not a description of a particular company's API.

Before sending a request, ask which environment you may test, how the fixture is created, which customer owns it and what error behavior the contract promises. Then identify what success looks like. “I received a response” is too weak to distinguish a working endpoint from a response generated by the wrong service or account.

What should a basic Postman test verify?

Start with the HTTP status, response format and business-relevant fields. Postman provides a post-response scripting environment with pm.test, response access and Chai-style expectations. The official test-script documentation describes those interfaces.

For the invented read-order contract, this original post-response script checks the expected fixture and a few important invariants:

pm.test("Read-order contract matches the owned fixture", function () {
  pm.response.to.have.status(200);
  pm.expect(pm.response.headers.get("Content-Type"))
    .to.match(/^application\/json(?:\s*;|$)/i);

  const order = pm.response.json();
  pm.expect(order).to.be.an("object");
  pm.expect(order.id).to.equal("order_demo_17");
  pm.expect(["pending", "paid", "cancelled"])
    .to.include(order.status);
  pm.expect(Number.isSafeInteger(order.totalCents)).to.equal(true);
  pm.expect(order.totalCents).to.be.at.least(0);
});

The script deliberately does not assert a response-time threshold. Choose one only when the test environment and service objective justify it. A single request taking 300 milliseconds does not establish a production performance percentile.

This is also not a complete contract test. It does not check every possible field, authorization path or relationship to the database. Explain which requirement each assertion covers and which separate test would cover the remaining behavior. The test strategy round in the quality engineer interview questions guide takes this further, mapping each risk to the lowest test layer that can catch it.

How do variables improve a collection?

Use a configurable base URL so the same collection can target a local or isolated test service without editing every request. Keep fixture IDs scoped to the run where practical. Name variables so it is clear whether they describe an environment, a collection-wide value or a request-specific input.

A strong answer includes a failure case: a stale order ID from yesterday points to a record owned by a different test account. The test may fail for the wrong reason, or worse, read data it was never meant to touch. Reset the fixture deliberately and make ownership part of the setup.

Do not place a real token in a public collection example. Use the environment's approved secret handling, review what is shared with collaborators and avoid printing authorization headers in scripts. When explaining a test, show a redacted credential placeholder rather than a working production secret.

Which negative cases would you test?

Use the contract to choose assertions instead of treating every non-200 response as equivalent. For the order API, the following cases expose different responsibilities:

Do not insist that every API must choose the same 403 or 404 response for an unauthorized resource. Some APIs intentionally avoid revealing whether it exists. State the expected policy, then test that policy consistently.

For broader discussion of API boundaries, practise explaining the same cases aloud using the system-design preparation guide. Testing and design answers should agree about who owns the data.

How would you test a multi-request workflow?

Build a sequence that creates a fixture, reads it, changes it if permitted and cleans it up. Capture the created ID from a successful response rather than guessing the next identifier. Give the fixture a unique run marker so cleanup can identify only the records that the test created.

The interesting follow-up is what happens when creation succeeds but the read step fails. Cleanup should still be considered, and the failure report should retain enough information to investigate the created record. Avoid a blanket cleanup query that deletes every order in a shared test environment.

For retries, separate safe reads from operations with side effects. If a create request times out, the server may have committed it. Repeating it without an agreed idempotency design can create duplicate records. Explain how you would inspect the first attempt before deciding whether to retry.

What makes a useful API defect report?

Give the reader a reproducible case: environment, build or API version, request method and path, sanitized body, relevant headers, expected result and observed result. Include the correlation identifier if the service returns one. Remove tokens and personal data before sharing the evidence.

For example: “Using customer A's test credential, requesting customer B's fixture returned the full order object. The expected behavior is the documented denial response.” That identifies a specific authorization defect. “The API is insecure” does not tell an engineer which boundary failed or how to reproduce it.

Include the smallest reliable sequence. If the failure depends on a previous update, say so. A video of many requests without the fixture state can be harder to diagnose than a short collection and a clear written timeline.

How do you answer a scenario question using real experience?

For a technical question, begin with the behavior and the test. For an experience question, explain the situation, your responsibility, the investigation and the actual result. The STAR guide for engineers gives a structure for that account.

Do not turn this fictional order exercise into a story about a production security incident you handled. You can say, “In my practice API, I introduced an ownership bug and built a test that detected it.” That is honest, demonstrable experience and gives the interviewer a concrete follow-up.

Finish a practice session by changing one response field and checking that the relevant assertion fails. A test suite that has never been shown to detect its intended defect can create false confidence.

Frequently asked questions

Usually they are only the starting point. Explain expected response data, authorization, invalid input and the business outcome represented by the response.

A pre-request script prepares work before the request, while a post-response script can inspect the returned result. Keep setup and assertions understandable, and avoid hidden state that makes the collection difficult to reproduce.

No. Unit tests, database integration tests, load tests and security reviews address different questions. Explain the role of the collection and its limits rather than claiming one tool proves the whole system.

Understand the assertions and practise writing a small one. Being able to explain why a test fails, and whether the API or the fixture is wrong, is more useful than reproducing a long script from memory.