Scenario-Based API Testing Interview Questions

“A clean pass for an hour and then a wall of 401s smells like an expired token, not a bug in the API. First I'd check how the suite gets its token. Often it's fetched once at the start, or someone pasted one into the environment. Then I'd decode it and look at the exp claim, or check expires_in from the login response. If it lives for sixty minutes, that's the whole story. The fix is in the suite: a small step before each request that checks the expiry and gets a new token when there's less than a minute left. I wouldn't just ask for longer-lived tokens in test, because then we stop exercising expiry at all. And I'd keep one deliberate test that sends an expired token and expects a clean 401 with no stack trace.”

“I wouldn't argue about it, I'd check it. Internal only is a claim about the network, so I'd try reaching the endpoint from outside: through the public gateway, with small path tricks like a trailing slash or different letter case, and on any public host name that routes to the same service. If I can reach it, the conversation is over. If I can't, I'd still ask how other services are meant to call it. If the design says they use a service token, I'd test that a call without one is refused. I'd explain the reason calmly: networks get breached, and one routing mistake turns an internal admin endpoint into a public one. If the team still decides no auth, that's fine, but I'd write it down as a risk for whoever owns security to accept, not me.”

“First I'd reproduce it with a real customer query and read the whole response. My guess is we're getting a 200 with an empty results array, or a body that says success false. Then I'd open the monitor's tests. If they only check the status code and response time, an empty list is a pass, so the monitor was green while search was broken. I'd fix that by seeding one product we control and searching for it by name, then asserting it's in the results. For a broad query I'd also assert the list isn't empty, and validate the body against the schema. I'd log two things: the search bug itself, and the monitor gap, because the gap is why customers found it before we did.”

“The tests passed because they moved with the code. The same pull request that renamed the field also updated the assertion, so our suite described the new API, not what the app depends on. First, I'd help confirm which app versions are affected, because the quick fix is usually to send both names for a while. Then I'd change two things. I'd make the response schema list the fields clients actually read as required, and treat edits to it as a review point, not a side effect. And I'd push for consumer-driven contract tests: the mobile team records what they read, and the backend build fails if a change breaks that. I'd also have the spec diff checked on every pull request, so a rename shows up as a breaking change before anyone merges it.”

“Running the v1 suite once isn't enough, because both versions write to the same data. First, I'd freeze the v1 regression suite and run it unchanged on every release for the whole six months, so nobody quietly updates it to match new behaviour. Then the interesting part: create an order through v2 and read it through v1, and the other way round. If v2 adds a new order status, what does v1 return for those orders? An old app might crash on a value it's never seen. If v2 makes a field required, what happens to orders created through v1 without it? I'd also check v1 sends a deprecation notice, and that we can see how much traffic still uses it. And I'd agree now what v1 returns once it's switched off, so that day isn't a surprise.”

“There are two usual suspects, and I'd check both. First, the sort. If the list is ordered by created date and several orders share the same timestamp, the database can return those ties in a different order on each query, so one lands on both pages and another on neither. I'd seed twenty-five orders with the same timestamp, walk every page, and collect the IDs. Second, data changing between requests. With page and offset, a new order arriving while you're on page one pushes everything down one place, so you see a repeat. A delete does the opposite and you skip one. I'd test that by inserting an order between page calls. The fixes I'd suggest are adding the order ID as a tie-breaker in the sort, and cursor-based paging for lists that change often.”

“Late at night and only some customers tells me it's time zones. I'd follow one order through the system. What's in the database: UTC, or the server's local time? What does the API send back: a full timestamp with a Z or an offset, or a bare date the server already formatted in its own zone? Then who turns it into a date on screen. If the server formats dates in its zone, a customer eight hours behind sees tomorrow. To test it, I'd create orders at 11:30 pm and 12:30 am from clients set to zones ahead of and behind the server, and check the response and any 'orders today' filters. I'd also try the days clocks change. The contract I'd push for is timestamps in UTC with the zone marked, and date-only fields that say which zone they mean.”

“If the raw bytes from curl are right but the browser shows something else, the value is changing when it's parsed. JavaScript stores every number as a double, which can only hold whole numbers exactly up to about nine quadrillion, that's 2 to the 53 minus one, sixteen digits. A 19-digit ID gets rounded to the nearest value it can hold, which is why they end in zeros. Then the app requests that rounded ID and gets not found. I'd prove it by parsing the raw response in a browser console and comparing. The fix is on the API: send IDs as strings, since nobody does maths on an ID. For testing, I'd make sure our test data includes IDs above that limit, and have the schema say the ID is a string so a regression fails straight away.”

“I'd start by asking how the fix works, because the usual answer is an idempotency key: the app makes a unique key per payment and sends the same one on every retry. Then I'd test that from the outside. Same key, same body, twice in a row: I expect one payment and the same response both times. Same key, different amount: I expect an agreed error, not a silent second charge. But the customer bug happened while the first request was still in flight, so I'd recreate that. I'd slow the payment provider's mock down past the timeout, fire the retry while the first call is still running, and also send two identical requests at the same moment. Then I'd check the proof that matters: one row in our payments table and one charge in the provider's sandbox.”

“Whether it's a bug depends on what the product needs, but first I'd find where the old value lives. I'd look at the GET response headers: Cache-Control, Age, or a header saying it was a cache hit. Then I'd call the service directly, skipping the CDN and gateway. If the direct call shows the new price, it's the edge cache. If it's still old, it's inside: maybe the service caches products and doesn't clear the entry on update, or reads go to a database replica that's behind. Then the judgement. A product page showing the old price for a minute might be acceptable. Charging the old price at checkout isn't. So I'd get the allowed delay written down, and add a test that updates a price and immediately places an order, checking the new price is charged.”

“I can recreate this with four calls, no clicking. User A and user B both GET the product. A sends a PUT with the new price. B then sends a PUT with the fixed description, but the rest of B's body is the old copy, including the old price. PUT replaces the whole record, so the price change is lost. The fix I'd expect is optimistic locking. The GET returns an ETag or a version number, and the save sends it back in an If-Match header. If the product changed in the meantime, the server refuses with 412, Precondition Failed, and the client reloads. So my tests would be: matching tag saves and returns a new one, stale tag gets 412, and a missing tag gets 428 if the server requires it. Using PATCH helps for different fields, but not when both edit the same one.”

“429 means Too Many Requests, so we're hitting a rate limit. I'd open one failing response and read the headers: Retry-After, and any rate-limit headers that show the limit and how many calls are left. Then I'd work out what changed since last month. Maybe the suite doubled in size, maybe we started running jobs in parallel with the same API key, or maybe CI runners share one outbound IP with other pipelines. It's also possible the backend team just switched the limiter on in this environment. The fix I'd want is a dedicated test client with its own sensible limit, or pacing our run. I wouldn't just add retries everywhere, because that hides real failures. And I'd keep one test that hits the limit on purpose and checks for a 429 with a Retry-After header.”

“We're probably both right. CORS is a rule the browser enforces. Postman doesn't apply it, so my green tests say nothing about this. For a POST with a JSON body and an Authorization header, the browser first sends an OPTIONS request, the preflight, asking if this origin may use that method and those headers. If the answer is missing or wrong, the browser blocks the real call. So I'd reproduce the preflight with curl, sending the front end's origin. Then I'd read the response: it should allow that origin, POST, and the authorization and content-type headers. Common causes are the OPTIONS call hitting auth and getting a 401, the origin not on the allowed list, or a wildcard origin used with credentials, which browsers refuse. Then I'd add that check to the suite.”

“My first question is how big those accounts really are. If our test account has fifty records and the big customers have two hundred thousand, the test environment can't show this bug. So I'd seed an account at that scale in a performance or staging environment. Then, rather than one timing, I'd measure the call at a few sizes, maybe a thousand, ten thousand and a hundred thousand records. If time grows in a straight line, it's probably just too much work in one request. If it climbs much faster, there's often a separate query for every item hiding in there, and I'd ask the developer to check the query count in the logs. I'd also note which timeout fires, the app's or a gateway's in front of it. Then the fix could be paging, an index, or making it a background export.”

“Both can be right. If most requests take 150 milliseconds and a few take eight seconds, the average still looks healthy. So first I'd ask for the 95th and 99th percentiles and the maximum, or work them out from the logs. Then I'd look for what the slow ones have in common. Is it certain carts, like ones with many items or a coupon? One server instance? The first request after a quiet period? A certain time of day when a batch job runs? Once I have a suspect, I'd send that request a few hundred times and record every timing, so I can show the spread rather than one number. Common causes are one path calling a slow dependency, cold starts, one unhealthy instance, or retries stacking up behind a timeout.”

“A fixed sleep is either too long, which wastes time on every run, or too short on a busy day, which makes the test flaky. I'd poll instead. Call the status endpoint every two seconds until it says done or failed, with a hard deadline, say two minutes, after which the test fails with a clear message. Once it's done, I'd download the file and check the contents match what I asked for, not just that a link exists. Then the paths people skip. An export with bad filters should end as failed with a reason, not sit in running forever. An unknown job ID should give 404. And I'd log in as a different user and make sure they can't read my job or download my file, because export links often leak data.”

“Paid then back to pending sounds like events arriving out of order. Webhooks aren't guaranteed to come in sequence, and if our handler just writes the status from each event, a late pending event overwrites paid. I'd capture real payloads from the provider's sandbox and replay them against our endpoint, signed with the test secret. First the out-of-order case: paid, then pending. The order must stay paid. Then duplicates: the same event ID twice should be processed once, but still get a success response so the provider stops retrying. Then security: no signature, a wrong one, and a correctly signed but old event should all be rejected. Finally timing: if our handler takes too long, the provider retries, so I'd check we reply fast and do the heavy work afterwards.”

“The first missing test is size. I'd upload files just under the limit, exactly at it, and well over it. Over should come back fast with 413, which means the body is too large, and a clear message. But speed matters too. If the server reads the whole file into memory before checking, a big upload can still take it down even though the answer is right. So I'd watch the service's memory while sending a very large file, and check the rejection happens early. Then content: a video renamed to photo.jpg should be rejected by checking the actual file, not the extension. An empty file, a corrupt image, and names with slashes, dots or very long names too. Finally I'd send several uploads at the same time, because that's where memory problems show.”

“I'd reproduce with the exact name first and read the error body. For the 400, the likely cause is a validation rule that only allows plain A to Z letters, so the accents or the hyphen fail. If it's the apostrophe that breaks it, and especially if I get a 500, that's worth a closer look, because it can mean the input is going into a database query unsafely. For the garbled name, I'd check the request is sent as UTF-8, then look at what's stored, then the response's content type. Somewhere one layer is using a different encoding. Emoji are a good extra test because they need four bytes in UTF-8 and some databases are set up to store only three. After that I'd keep a set of real-world names in the regression data so this stays fixed.”

“Yes, I'd log it, and first I'd check what the spec says. The problem isn't the typo, it's what the client believes. If a report or a script sends a wrong status and gets a normal 200 with data, it assumes the filter worked. Someone could email a list of active products that includes discontinued ones. And if the same code pattern is used on a bulk update or delete endpoint, ignoring a bad filter means the action hits everything, which is serious. I'd separate two cases: unknown parameter names, which some APIs ignore by design, and known parameters with invalid values, which should give a 400 naming the value. I'd rate severity by where it's used, and I'd check every other filter for the same behaviour.”

“I'd say it does matter. DELETE is meant to be idempotent: calling it twice leaves the server in the same state as calling it once. The second call can answer 404, or 204 if the team agreed on that, but a 500 means the server hit something it didn't handle, probably code trying to delete a record that isn't there. It matters in practice because clients retry a delete when the first response times out. That retry will now look like a server failure, fire alerts and maybe show the user an error for something that worked. While I'm there, I'd check a GET on the item returns 404, it's gone from lists and search, and anything linked to it was handled the way the spec says.”

“I can't test forty endpoints deeply in two days, so the plan is about choosing. First hour: I'd rank them. Anything touching payments, login or personal data goes top, then whatever changed most, then whatever the app calls most. I'd ask the developers and product owner to check my ranking, because they know things I don't. Then I'd go wide: a quick smoke pass on all forty, ideally generated from the API spec, checking each one needs auth, works on the happy path and returns the right shape. That catches the embarrassing breaks. Then I'd spend most of the time deep on the top eight or so: bad input, boundaries, one user reaching another's data. Before sign-off, I'd share a short list of what I didn't test and why, so the go decision is made knowing the risk.”

“Cannot reproduce usually means I didn't give them enough to go on, so I'd fix that rather than argue. I'd export the exact failing request as curl, with headers and body. I'd note the time of each failure with the time zone, and grab the request ID or correlation ID from the response headers, because with that the developer can find the exact log line. Then I'd turn sometimes into a number: run the same request a couple of hundred times and count. If it's seven failures, that's real. I'd look for a pattern: particular carts, parallel calls, one server instance if a header shows it, or a time when a batch job runs. Then I'd reopen the bug with all of that and ask for fifteen minutes to look at the logs together.”