API Developer Interview Questions That Actually Filter Candidates
According to Postman’s 2025 State of the API Report, 93% of developers use REST APIs and 82% of organizations have adopted some form of API-first development. So almost every backend and fullstack interview now includes an API design section. I’ve seen candidates who know their algorithms cold completely fall apart when asked to walk through a rate-limiting strategy or explain why their DELETE endpoint returns 204 instead of 200.
Thirteen questions with real answers, focused on the decision points that separate engineers who’ve built production APIs from those who’ve only read about them.
REST Fundamentals: Where Most Interviews Start
1. What makes an API truly RESTful vs just HTTP-based?
The six constraints Roy Fielding defined: client-server separation, statelessness, cacheability, uniform interface, layered system, and code-on-demand (optional). Most “REST APIs” skip HATEOAS (hypermedia links in responses) and that’s fine for most use cases. The practical answer interviewers want: stateless requests, resource-based URLs, correct HTTP method semantics, and meaningful status codes. If you can name HATEOAS and explain why you’d skip it in a startup context, you’ve already pulled ahead.
2. When do you use PUT vs PATCH?
PUT replaces the entire resource. PATCH applies a partial update. The idempotency difference is what trips people: PUT is idempotent (calling it 10 times produces the same result as once), PATCH isn’t necessarily. If your PATCH appends to a list rather than setting a value, repeated calls change state each time. Interviewers want to hear you discuss idempotency, not just the basic definition.
3. Walk me through how you’d design pagination for an endpoint that returns 500,000 records.
Offset pagination (?page=3&limit=50) is simple but breaks at scale. If a record is inserted between page 2 and page 3, your user skips a record. Cursor-based pagination uses a stable pointer (usually an ID or timestamp) instead of a numeric offset — records inserted mid-stream don’t cause gaps. The tradeoff: cursors don’t let users jump to page 47 directly. For most products that’s acceptable. What earns points in the interview: knowing which to pick and why, not reciting both definitions.
4. What HTTP status codes should a well-designed API actually use?
- 200 OK — successful GET, PATCH, or PUT with a response body
- 201 Created — successful POST that created a resource
- 204 No Content — successful DELETE (nothing to return)
- 400 Bad Request — client sent malformed input
- 401 Unauthorized — missing or invalid authentication
- 403 Forbidden — authenticated but not allowed to access this resource
- 404 Not Found — resource doesn’t exist
- 422 Unprocessable Entity — input is valid JSON but fails business rules (useful distinction from 400)
- 429 Too Many Requests — rate limited
- 500 Internal Server Error — something broke on your side
The mistake that shows up most: returning 200 with an error message in the body. Your client can’t detect failure programmatically without parsing every response body.
API Design: The Questions Senior Roles Lean On
5. How do you version an API without breaking existing clients?
Three approaches: URL versioning (/v1/users), request header versioning (API-Version: 2), and content negotiation via Accept headers. URL versioning wins on simplicity and discoverability. Header versioning is cleaner architecturally but harder to test in a browser. The strategy depends on who your consumers are. Internal microservices can coordinate a header bump. A public API with thousands of third-party clients needs URL versioning because you can’t control when they upgrade.
6. What’s the N+1 problem in API design and how do you solve it?
You return 100 orders, each with a customer object, each triggering a separate DB query. That’s 101 queries total. Solutions: eager loading (JOIN or include pattern), a batch endpoint (GET /customers?ids=1,2,3), or GraphQL with DataLoader. In GraphQL, DataLoader batches and deduplicates resolver calls within a single request cycle — that’s the canonical fix.
7. How would you make a POST endpoint idempotent?
Use an idempotency key — a unique string the client generates and sends in a header (Idempotency-Key: abc-123). The server stores the key alongside the result of the first request. If the same key arrives again, return the cached result instead of re-executing. Stripe does this. The storage layer matters: the key lookup needs to be atomic or you’ll still get duplicate processing under concurrent retries. A good signal for senior roles because it’s squarely in distributed systems territory.
What we see on LastRoundAI
Candidates who practice API design questions out loud consistently perform better than those who only read about them. In mock interviews on LastRoundAI, engineers who articulate their reasoning as they design — explaining tradeoffs, naming what they’d skip and why — get more positive signal from interviewers than those who jump straight to the “correct” answer. The process matters as much as the destination.
GraphQL: What They’re Actually Testing
8. When would you choose GraphQL over REST?
GraphQL makes sense when clients have genuinely different data needs you can’t serve from a fixed response shape — mobile fetching less than desktop is the classic example. It’s also useful for complex domain graphs (GitHub’s API is the reference point). Where I’d push back: small teams, internal-only APIs, or situations where you don’t want to invest in DataLoader and schema design up front. GraphQL’s overhead is real. Only 33% of teams use it according to Postman’s report, and REST dominates for good reason.
9. How do you handle authentication at the field level in GraphQL?
Resolver-level authorization (check permissions inside each resolver) or a schema directive like @auth(requires: ADMIN). Resolver-level is simpler but spreads auth logic everywhere. Directives centralize it but need custom infrastructure. The risk that doesn’t come up in REST interviews: introspection. By default, anyone can query your schema and see all types and fields, including those they can’t access. Disable introspection in production, or put it behind auth.
Security: The Section That Filters Senior Candidates
10. JWT vs session tokens. Which do you use and when?
JWTs are stateless — the server stores nothing because the token carries the claims. The downside: you can’t revoke a JWT before expiry without maintaining a blocklist, which reintroduces state. Session tokens let you revoke instantly but require a shared session store across servers. My opinion: JWTs get misused more than session tokens because developers underestimate the revocation problem. If “log out everywhere” is a real product requirement, think before defaulting to JWT.
11. How do you secure a webhook endpoint?
Validate the signature. The sender (GitHub, Stripe) includes an HMAC-SHA256 signature in a header, computed over the request body with a shared secret. Your server recomputes it and compares. Also validate the timestamp — reject payloads older than 5 minutes to block replay attacks. The detail that catches experienced developers: comparing signatures with regular string equality is vulnerable to timing attacks. Use constant-time comparison: hmac.compare_digest in Python, crypto.timingSafeEqual in Node.
12. What’s the OWASP API Security Top 10 and which items actually come up in interviews?
The full list is public (the OWASP API Security Top 10 2023 is worth 20 minutes of your time). The four that surface most in interviews: Broken Object Level Authorization (BOLA, previously IDOR — returning data the caller isn’t permitted to see), Broken Authentication, Excessive Data Exposure, and Unrestricted Resource Consumption (missing rate limits). If an interviewer asks “name a security issue in API design,” BOLA is almost always the answer they want.
Testing and Documentation
13. How do you document an API so developers actually use it?
OpenAPI (formerly Swagger) is the standard. Write the spec first, generate docs from it, host interactive docs with Swagger UI or Redoc. The 2024 Stack Overflow Developer Survey found that 90% of developers use API and SDK documentation as their primary reference — so poor docs are a usage problem, not a polish problem. What interviewers want to hear: spec-first design, examples in every endpoint, and error responses documented as thoroughly as success responses. Error docs are what most teams skip.
The filter question no one warns you about
The questions above are filters because they require you to have made a real decision: chosen cursor over offset, debugged an N+1, argued for or against GraphQL with a skeptical team. Reading the definition isn’t the same thing. At mid-to-senior level, the companies worth joining care about reasoning, not recitation. I don’t know if that’s universal, but it’s what I’ve consistently seen.
For more practice on adjacent topics, the posts on system design interview questions and software engineer interview questions cover the surrounding context.
