Most API-testing interview prep lists are trivia: "What does 404 mean?" Anyone can memorise those, and interviewers know it.
The questions that actually separate candidates are the ones where the shape of your answer reveals how you think. Here are the ten I'd use to interview someone — each with the answer a senior gives, and what the interviewer is really listening for.
1. "A POST with an invalid body returns 500. Is that a bug?"
Yes — twice over if it also fails to explain itself. Invalid input should return 400 Bad Request with a useful error body. A 500 means the server didn't validate — it crashed into the bad data. The request being "correctly rejected" doesn't excuse the wrong status class.
Listening for: do you treat error behaviour as specified behaviour, or as noise?
2. "What do you test on an endpoint besides the status code?"
The layered answer: protocol (status, content type, response time), contract (the body matches its schema — fields, types, formats), data (the values are right), behaviour (state actually changed — after DELETE, a GET returns 404), and security (the auth negatives: no token → 401, wrong user's token → 403).
Listening for: a framework, not a grab-bag. Juniors list assertions; seniors list layers.
3. "How many negative tests does an endpoint need?"
Rule of thumb: five to ten negative/boundary cases per positive case — missing fields, wrong types, malformed JSON, unknown IDs, empty strings, zero, maximums, maximum-plus-one. If a suite is mostly green-path, it's mostly decorative.
Listening for: whether your instinct is adversarial or ceremonial.
4. "Your suite passes locally and fails in CI. Walk me through it."
The senior's ordered list: environment differences (wrong/missing environment file, unset variables — check what the runner actually resolved), secrets (injected locally via current values, absent in CI — should arrive via --env-var from the pipeline's secret store), data state (CI database doesn't have the record your test assumes — suites should create their own data), and timing (CI is slower; a 500 ms response-time assertion that's snug locally is flaky there).
Listening for: a debugging methodology, not a shrug.
5. "GET vs POST vs PUT vs PATCH — beyond the definitions, why does a tester care?"
Idempotency. GET, PUT, and DELETE should be idempotent — repeating them changes nothing further. POST typically isn't — send it twice, create two records (or charge twice). That single property generates test cases: replay the PUT and assert nothing changed; replay the POST and assert the system handled the duplicate the way the spec demands.
Listening for: whether HTTP semantics are trivia to you or a test-case generator.
6. "How do you handle test data in a suite that runs every night?"
Create, use, destroy. Each workflow creates its own records with unique values ({{$randomEmail}}, {{$guid}}), verifies behaviour, then deletes them — with a follow-up GET asserting 404 to prove the deletion. A suite that depends on pre-existing data, or leaves residue, stops being re-runnable — and re-runnability is the cardinal virtue of automation.
Listening for: have you actually maintained a suite over time, or only written one?
7. "Where do credentials live in your Postman setup?"
In current values (local-only) or Postman Vault — never in initial values, which sync to Postman's cloud and to collaborators. Variable type set to secret. Exported environment files sanitised before committing, with the real credential injected in CI at runtime: --env-var "token=$API_TOKEN" from the pipeline's secret store.
Listening for: the initial-vs-current distinction. It's the single fastest tell of real Postman experience.
8. "What makes a test suite trustworthy?"
Three disciplines: deterministic (a test that sometimes fails without a code change trains the team to ignore red — hunt down the shared state or time-dependence), independent (chains short and self-contained within folders), and readable when red (a failure named "PATCH ignores read-only fields" is a bug report; "test 12 failed" is homework).
Listening for: whether you think about the humans who read the results.
9. "Would you let an AI write your tests?"
"Yes — with review, because of one specific failure mode: AI generates assertions from the response the API currently gives, not from the spec. If current behaviour is a bug, the AI enshrines it as expected. So: generate the boilerplate, review every assertion against requirements, and add the negative cases myself — AI suggestions skew happy-path."
Listening for: neither "AI bad" nor "AI magic" — a mechanism-level understanding of where it breaks.
10. "What's the first thing you'd automate on a brand-new API?"
Risk-ordered: the endpoints whose failure costs most — auth and anything that writes or moves money — then the endpoints that change most often. A ten-test suite on the login endpoint beats a hundred tests on a static lookup. And from day one: every production bug earns a permanent regression test — a year of that builds the most valuable suite you'll own, because it's provably aligned with how the system actually fails.
Listening for: prioritisation. Effort is finite; seniors spend it where failure is expensive.
Notice the pattern across all ten: the senior answers are never facts — they're decisions with reasons. That's the real interview skill, and it's also just the job.
The full 37-question FAQ (including the facts you should also have cold) is a chapter of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing*. Read online, grab the PDF/EPUB, or contribute on GitHub.
I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.
Top comments (0)