Backend API Design Interviews: How to Talk Through REST, Idempotency and Pagination

More companies now replace one of their algorithm rounds with an "API design" round. Instead of reversing a linked list, you are asked to design the endpoints for a booking service, a payments flow, or a simple notes app. It sounds easier than system design, but candidates often stumble because the round rewards precise thinking about contracts, not just boxes and arrows. Start with the resources, not the URLs Before writing a single endpoint, list the nouns. For a booking service that might be users, listings, reservations and payments. Ask which ones the client really needs to read and write. Interviewers like hearing you say "I'll keep payments behind the reservation resource for now, because the client never creates a payment directly." That one sentence shows scoping and judgment. Be explicit about status codes and errors Say what a successful create returns (201 with a Location header), what a validation failure returns (400 or 422 with a field-level error body), and what happens on a conflict, such as two people booking the same night (409). Many candidates design only the happy path. Spending two minutes on error shapes is a cheap way to look senior. Idempotency is the question behind the question If the round involves money or reservations, the interviewer is almost certainly waiting for you to mention retries. A mobile client on a bad connection will resend a POST. Propose an Idempotency-Key header stored with the result for 24 hours, so a retried request returns the original response instead of charging twice. Then mention the trade-off: you need storage and an expiry policy. Pagination and filtering For any list endpoint, offer cursor-based pagination and explain why: offset pagination breaks when rows are inserted while a user scrolls. Mention a sensible default page size and a maximum. Add filtering by status or date only if the use case needs it; adding everything "just in case" reads as unfocused. Versioning, auth and rate limits in one breath You do not need a lecture here. A short line works: "I'd version in the path as /v1, use OAuth bearer tokens, and return 429 with Retry-After when clients exceed limits." Then move on unless they dig in. Practise out loud The skill being tested is narration. Take three everyday apps and design their APIs aloud in twenty minutes each, recording yourself. Listen for places where you went silent or hand-waved. If you want support in the real thing, Linkjob AI (https://linkjob.ai) gives real-time help during live job interviews and technical interviews, which can be a useful safety net when nerves make you forget to cover error handling or retries. A good API design answer is calm, scoped and explicit about failure. Get those three right and the details usually follow.