What's Really Happening with API Testing Right Now
API testing has moved from a specialist add-on to the part of QA that hiring managers protect budget for. The reason is structural: microservices and mobile clients mean most business logic is now behind an endpoint, and UI tests have become too slow and too expensive to be the primary safety net. What is genuinely new is the contract layer — teams now ask about OpenAPI validation, schema drift, and consumer-driven contracts far more often than they did, and "can you test an API" has quietly become "can you stop a breaking change from reaching a consumer."
What we'd actually recommend
Stop practising on public toy APIs and build one small service test suite that covers a real workflow end to end: authenticate, create a resource, read it back, mutate it, verify the error paths, then clean up. The workflow is the interview answer. Also make schema validation part of every response assertion — validating status code and one field is what a beginner does; validating the full contract catches the class of bug you are actually being paid to catch. If you can add one contract test that fails when a producer removes a field, you are already ahead of most mid-level applicants.
The pitfall: confusing status-code checking with API testing
The misconception that costs candidates offers is believing an API test is `assert response.status == 200`. Interviewers probe negative and boundary behaviour: what does the API return for an expired token, a malformed body, a valid body with an unauthorised user, a duplicate idempotency key, or a payload one byte over the limit? Most rejected answers are not wrong, they are shallow — the candidate never tested the failure paths because the happy path always passed in Postman.