The question that got me the last time I practiced a mock API interview: “Walk me through how you’d design rate limiting for a public REST API where some customers are on free tiers and others have burst limits based on their contract.” I knew the answer in theory. I fumbled it in practice because I hadn’t actually thought through the data model for storing per-customer rate state without creating a read hotspot.
That’s the kind of question this post is about. Not “what does REST stand for” but the ones that actually show up when companies are trying to figure out if you’ve shipped real APIs at scale.
REST fundamentals that still trip people up
These seem basic until you’re asked to explain the tradeoffs under pressure.
Idempotency – GET, PUT, and DELETE are idempotent; POST is not. The follow-up that catches people: “If a client retries a PUT request due to a network timeout, what could go wrong, and how do you protect against it?” The answer involves idempotency keys and how you store them. Many candidates haven’t thought through the storage side.
HTTP status codes – beyond 200, 404, and 500. Interviewers at companies like Stripe, Twilio, and similar API-first companies will ask you to distinguish 400 from 422. (400 is malformed request syntax; 422 is syntactically correct but semantically invalid.) They’ll also ask when you’d return 202 vs 200 for async operations.
Versioning strategies – URI versioning (/v1/users), header versioning, and content negotiation each have real tradeoffs. URI versioning is easy for clients to understand but pollutes your URL namespace. Header versioning is cleaner but less cacheable. Most companies use URI versioning for public APIs and accept the tradeoff. Have an opinion and be able to explain it.
Caching questions, which come up constantly
For any senior API role, expect at least one caching question. Here are the ones I see most often:
- “How would you implement ETag-based caching and what problem does it solve vs. just setting a Cache-Control max-age?” The key distinction: ETags let the server say “here’s a fingerprint of the resource; if it hasn’t changed, return 304 Not Modified and don’t retransmit the body.” Cache-Control max-age is about time; ETags are about content identity.
- “You have a user profile endpoint that’s called 47 times per second per region. How do you cache it without serving stale data after an update?” This one has multiple valid answers: CDN with a short TTL and cache invalidation on write, application-level caching with a pub/sub invalidation mechanism, read-through cache with write-through updates. The interviewer wants to see you know the options and their failure modes, not just one answer.
- “When would you NOT cache an API response?” Personalized data, security-sensitive responses, and anything with high write volume relative to read volume are the right categories here.
GraphQL vs REST, the actual interview question
Most interviewers don’t ask you to pick a winner. They ask you to characterize the tradeoffs. Here’s what an accurate answer looks like:
REST is better for: public APIs where discoverability matters, caching at the HTTP layer, operations that map cleanly to resource CRUD, and teams without strong schema discipline.
GraphQL is better for: mobile clients that need to minimize payload size by requesting only needed fields, complex frontends with many different data shape requirements, and situations where your team can maintain a strongly-typed schema with proper versioning discipline.
The hard question is: “Tell me about a time you chose one over the other and what happened.” The Stack Overflow Developer Survey 2024 reported that about 30% of professional developers use GraphQL, which means most candidates have an opinion from real experience. Have yours ready with specifics.
Authentication and security
These questions have a lot of surface area. The ones that actually show up in loops:
OAuth 2.0 flow types – know the difference between authorization code flow (server-side apps), client credentials (machine-to-machine), and PKCE (public clients like mobile apps). Interviewers frequently ask “when would you use client credentials vs authorization code flow?” The answer is about whether there’s a human in the loop.
JWT storage and rotation – where do you store JWTs on the client, and why? HttpOnly cookies for web clients (resistant to XSS) vs localStorage (accessible to JavaScript, vulnerable to XSS). Refresh token rotation and what happens when two clients try to refresh simultaneously (this is a race condition that the spec addresses with refresh token reuse detection).
API key management – how do you store API keys in your database? Hopefully not in plaintext. The answer is hashing (bcrypt or similar), storing only the hash, displaying the key only once at creation time. This is a question where saying “we hash them” without knowing the implementation detail is a yellow flag for security-conscious interviewers.
System design questions for API roles
These come up for L5/L6 roles or senior individual contributor positions at most companies. The BLS Occupational Outlook for software developers reports median pay around $130K, but senior API-focused roles at API-first companies often significantly exceed this, in part because the system design skill is genuinely hard to hire for.
The questions I see for API-focused system design: design a webhook delivery system (bonus: how do you handle retries and exponential backoff without overwhelming a slow consumer?), design a rate limiting service that works across distributed nodes (bonus: leaky bucket vs token bucket), design an API gateway with per-route authentication (bonus: how do you handle 50ms latency budget across five downstream services?).
For each of these, walk through: the data model first, then the read path, then the write path, then failure modes. Interviewers who are good at this type of question will probe the failure modes hardest. “What happens when your rate limiting Redis node goes down?” has a real answer (fail open or fail closed, both are defensible with different tradeoffs) and a bad answer (“I’d add a replica”).
The question nobody practices but should
A good interviewer will end with: “Tell me about an API you designed that you’d design differently now.” This is an Ownership and self-awareness question disguised as a technical question. The right answer is honest: something specific you got wrong (the versioning strategy, the error response format, the authentication model), why it happened, what you’d change. Candidates who say “actually I’d keep it the same” almost never get the offer.