// Interview Prep/Mock Interviews/API testing mock interview
🔌 API testing mock interview
Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.
// ROUND STRUCTURE
- 1Warm-up— 5 min
Intro, tools used (Postman, RestAssured, etc.), and current API testing scope.
- 2REST fundamentals— 12 min
HTTP methods, status codes, authentication, headers, idempotency.
- 3Test design & tooling— 8 min
Negative testing, schema validation, contract testing, test data management.
- 4Wrap-up— 5 min
Candidate questions and interviewer summary.
// INTERVIEW QUESTIONS
- 01
What is the difference between PUT and PATCH? Which is idempotent and why does it matter?
- 02
Walk me through everything you validate in an API response.
- 03
What does a 401 response mean? How is it different from 403?
- 04
How do you test an API endpoint that requires OAuth 2.0 authentication?
- 05
What is contract testing? How does it differ from integration testing?
- 06
How do you handle test data for API tests — creating it, using it, and cleaning it up?
- 07
An API returns 200 OK but the response body is wrong. How do you approach this?
- 08
What would you include in a negative test suite for a POST endpoint that creates a user?
// EXPECTED ANSWER POINTS
Compare your answers to these points — one per question, in order.
PUT replaces the entire resource with the payload — send a partial payload and the omitted fields are cleared. PATCH modifies only the specified fields. Both should be idempotent (calling them N times produces the same result as calling them once), but PATCH implementations sometimes are not. Idempotency matters for safe retries on network failure.
Validate: HTTP status code (exact, not just 2xx), response body schema (all required fields present, correct types), specific field values for the test scenario, Content-Type header, response time against SLA, error message format on invalid input, pagination fields if relevant.
401 Unauthorised = the client has not provided valid credentials (missing or invalid token). 403 Forbidden = the client is authenticated (we know who they are) but does not have permission to access the resource. A user is logged in (403) vs not logged in or token expired (401).
OAuth 2.0 setup: obtain an access token via the appropriate grant (client_credentials for machine-to-machine, auth_code for user flows). Include the token as a Bearer token in the Authorization header. Handle token expiry — request a new token when a 401 is returned. Store tokens in env variables, never hard-code them.
Contract testing verifies the interface agreement (schema, structure, field names, types) between consumer and provider — it catches breaking changes without needing a running integration environment. Integration testing checks end-to-end behaviour through real system interactions. Contract tests are faster, more isolated, and catch API evolution issues earlier.
Test data for APIs: create via API before each test (use POST endpoints, not direct DB inserts). Use a unique identifier per run (UUID or timestamp) to prevent collisions in parallel runs. Clean up in teardown by calling the DELETE endpoint. Never share mutable data between concurrent tests.
200 with wrong body: check schema validation first (does the response match the API contract?), compare against the API specification (OpenAPI/Swagger), identify which fields are incorrect and under what conditions. Raise a defect with the exact request, response body, and expected schema. Test with edge-case inputs to find the boundary of the bug.
Negative tests for POST /users: missing required fields (each independently), invalid field types (number for an email), invalid email format, duplicate email, payload exceeding max length limits, empty string where non-empty required, invalid auth token, expired token, no token, oversized JSON payload, malformed JSON (syntax error), special characters in name fields, SQL injection attempt in name field.
// SCORING RUBRIC
Knows PUT vs PATCH with idempotency semantics. Validates schema and not just status code. Has handled OAuth token lifecycle in tests. Knows contract testing tools (Pact, Dredd). Can design a comprehensive negative test suite systematically.
Knows REST verbs and common status codes. Does some response validation. Less confident on contract testing or OAuth token setup. Negative tests cover obvious cases but miss boundaries.
Cannot distinguish PUT from PATCH. Only tests happy paths. No knowledge of schema validation or contract testing. Has never cleaned up test data after an API test run.
// RED FLAGS
Answers or behaviours that signal a weak candidate to the interviewer.
Only tests happy paths — no negative, boundary, or unauthorised request tests.
Cannot distinguish 401 from 403.
No knowledge of schema validation or API contracts.
Hard-codes auth tokens in test files.
Has never cleaned up test data created during API tests.
Cannot explain what idempotency means or why it matters.
// FOLLOW-UP QUESTIONS
Questions a strong interviewer adds if you answered the main round well.
- 01
How would you test a GraphQL API differently from a REST API?
- 02
What is idempotency and why does it matter for API test design?
- 03
How do you test rate limiting on an API endpoint?
// SELF-ASSESSMENT CHECKLIST
Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.
- I correctly explained PUT vs PATCH including idempotency semantics.
- I listed at least five things to validate in an API response beyond status code.
- I correctly distinguished 401 (unauthenticated) from 403 (unauthorised).
- I described a concrete approach to OAuth test setup including token expiry handling.
- I articulated the difference between contract testing and integration testing clearly.
- I listed at least six distinct negative test cases for the POST endpoint.
// RECOMMENDED NEXT MOCK
☕ Selenium + Java mock interview
Mid · 45 min