The API testing interview question that separates "I've read about it" from "I've done it"
Anyone can define a status code. The gap shows up the moment you ask what to do with one. Five questions from ten years of interviewing that tell the difference in under a minute.
"What's a 404?" gets the same answer from someone who's spent three years in Postman and someone who read one article last night. That's the problem with most API testing interview questions — they test recall of a table you could look up in ten seconds, not whether the candidate has ever had to figure out, live, why a request that should have worked didn't.
The gap between those two people shows up fast if you ask the right follow-up. It almost never shows up if you stop at the definition.
Why this matters more than it used to
A growing share of what a QA engineer tests has no interface at all. A webhook from a payment provider. A background job that runs on a schedule. An integration that only ever talks to another service, never to a browser. If a candidate's whole testing instinct starts and ends with "click around and see what breaks," a real slice of the product is invisible to them.
The other reason: locating a bug matters as much as finding one. "It doesn't work" costs a developer an hour reproducing what a tester could have narrowed down in two minutes — was there even a request, what came back, is this a 400 because of bad input or a 500 because of their code. That's not trivia. That's the actual job.
Five questions, and what they're really checking
"A user says a form submission 'doesn't work.' What's the first thing you check?" Listening for: DevTools, the Network tab, specifically — did a request fire, what status came back. A candidate who jumps straight to "I'd ask the developer to check the logs" hasn't yet learned to answer that question themselves, which is the whole point of having a tester in the loop before it reaches a developer.
"What's the difference between a 400 and a 500, and why does the difference matter for how you report the bug?" Listening for: not the textbook definition — whether they connect it to who's at fault. A 400 usually means the request was malformed (often the client's problem, sometimes a validation bug); a 500 means the server broke on something it should have handled. A bug report that says "getting an error" makes a developer redo work a tester could have done in one sentence: "sending X returns a 500, sending Y correctly returns 400."
"You send a POST request and get back a 200, but the data isn't actually saved. How would you have caught that before a user did?" Listening for: whether they'd think to check the response body's contents against what was sent, or query the underlying data directly, rather than trusting the status code alone. A 200 means the server didn't crash — it doesn't mean it did what you asked. This is the same class of bug as the one that slips past interface-only testing, and it's common.
"Walk me through how you'd test an endpoint that only accepts requests from a specific IP range or with a specific header." Listening for: comfort with actually constructing requests by hand — in Postman, curl, or similar — rather than only ever exercising an API through whatever UI happens to call it. A lot of real integration surface has no UI at all, and a tester who's only ever clicked buttons can't reach it.
"Two requests hit the same 'apply discount code' endpoint within a few milliseconds of each other. What could go wrong, and how would you test for it?" Listening for: whether they've thought about race conditions at all — a discount applied twice, a quantity double-decremented. Most candidates have never tested for this because most manual testing is inherently sequential: one click, one wait, one result. The ones who've hit this in production usually light up at the question, because they've been burned by exactly this.
What good actually looks like, briefly
Comfortable in Postman or a similar client — constructing a request, not just reading one someone else wrote. Reads a response and separates "the server acknowledged this" from "the server did what I asked." Reaches for the Network tab before asking someone else to check the logs. None of this requires a computer science background. It requires having actually done the thing more than once.
Same gap shows up at the database layer too — see the SQL interview question that predicts who finds the bug for the other half of it.
Practice this kind of question — and see exactly where your answer needed more — against real QA manual interview questions, with the free demo. No signup required.