API Design Interview Questions: What Backend Candidates Should Practice

Many backend candidates can name GET, POST, PUT, and DELETE. Far fewer can explain a retried payment, two users racing for the last seat, or an old mobile app receiving a changed response.

That gap is what API design interview questions are built to expose. Before memorizing more definitions, practice real API design interview questions on PracHub and filter backend engineer interview questions by your target company. The goal is to design a contract, then defend it when the interviewer changes the requirements.

Backend candidate practicing API design interview questions, contracts, idempotency, pagination, and security

Quick Answer

Backend candidates should practice turning an ambiguous product flow into a clear, secure, retry-safe, and evolvable API contract. A strong answer covers consumers, resources, endpoints, schemas, errors, authorization, idempotency, pagination, rate limits, observability, and backward compatibility, while explaining which decisions depend on scale or business rules.

Start with the consumer and the invariant the API must protect. Then move through resources, contract, failures, and evolution. This order works even when the prompt is unfamiliar.

What an API Design Interview Actually Tests

An API design round may appear inside system design, low-level design, backend coding, or a dedicated architecture interview. It can test product judgment, data modeling, distributed systems, security, and communication in one conversation.

Google's API Design Guide, used internally for Google APIs since 2014, starts from resource-oriented design and consistent standard methods. That is useful interview guidance: model the domain before choosing routes.

A good candidate treats the API as a long-lived contract. Google AIP-180 distinguishes source, wire, and semantic compatibility because valid JSON can still break a reasonable client.

Start With Consumers and Invariants

In the first five minutes, clarify who calls the API and what must never go wrong. A public partner API needs stronger compatibility and abuse controls than a private service. A mobile client may stay outdated for months.

Ask about actors, operations, volume, consistency, sensitive data, and failure tolerance. Then state the core invariant in one sentence.

For a ticket-reservation API, the invariant might be: one seat cannot be sold twice, and a retry cannot create a second charge. That sentence immediately shapes concurrency control, idempotency, and the order of operations.

Model Resources Before Endpoints

Turn product nouns into resources and relationships. A ticketing flow might contain Event, Seat, Hold, Order, Payment, and Ticket. Decide which objects have independent lifecycles.

Do not expose database tables directly. A public resource is a consumer contract, not a storage mirror. When an action does not fit CRUD, justify a custom action or state-transition resource.

Confirming a hold could be POST /holds/{hold_id}/confirm or creation of an order from a hold. Choose one, define its semantics, and stay consistent.

Build a Concrete API Contract

Show the happy path first, then attach one important decision to each operation.

Create a temporary hold: POST /events/{event_id}/holds must combine an atomic capacity check with expiration.

Read a hold: GET /holds/{hold_id} must enforce ownership and define which states remain visible.

Confirm purchase: POST /holds/{hold_id}/confirm needs idempotency and clear payment-failure behavior.

Read an order: GET /orders/{order_id} requires object-level authorization.

List available seats: GET /events/{event_id}/seats?cursor=... needs stable pagination while inventory changes.

Define one request and response in enough detail to make the contract testable:

POST /events/evt_42/holds
Idempotency-Key: 8fa2...

{ "seat_ids": ["A12", "A13"] }

201 Created
{ "id": "hold_91", "status": "active", "expires_at": "2026-08-05T20:15:00Z" }

Now the interviewer can probe duplicates, expiration, unavailable seats, partial failure, and authorization. That depth matters more than a large endpoint catalog.

API Design Interview Questions You Should Practice

How do you choose HTTP methods and status codes?

Explain the operation's semantics before naming a method. Reads should not create hidden side effects. Repeated idempotent operations should converge on the same intended state. Use status codes that let clients distinguish success, validation failure, missing resources, conflicts, rate limits, and server failures.

RFC 9110 defines HTTP method and status semantics. Consistency matters more than obscure codes. A clear 409 Conflict for an unavailable seat beats 200 OK with an error string.

How do you make writes safe to retry?

Assume the client can time out after the server commits. For create or payment-like operations, accept an idempotency key, bind it to the caller and normalized request, and return the stored outcome for a legitimate retry.

Stripe documents this retry pattern, and Google AIP-155 connects request IDs with idempotency guarantees. Discuss key lifetime, concurrent duplicates, mismatched payloads, and storage failure.

How do you handle concurrent updates?

Name the invariant first. For the last ticket, an unprotected read-then-write is unsafe. Options include a constraint, transaction, compare-and-swap, conditional update, or serialized workflow.

Then explain the client-visible result. One caller succeeds; the loser receives a stable conflict response and can choose another seat. Do not promise “exactly once” without describing where deduplication state lives.

Offset or cursor pagination?

Offset pagination is simple and supports page jumping, but inserts and deletes can cause duplicates or skipped rows. Cursor pagination is usually better for large, frequently changing ordered collections, provided the cursor encodes a stable continuation position and deterministic tie-breaker.

Google AIP-158 recommends pagination from the outset and opaque page tokens. Explain ordering, filters, limits, cursor expiry, and the list's consistency promise.

Authentication or authorization?

Authentication identifies the caller. Authorization decides whether that caller may act on this object. Check ownership or tenant membership server-side; a valid token does not authorize every ID.

OWASP's API Security Top 10 puts broken object-level authorization first and identifies authorization as a central API security challenge. Mention field-level exposure, sensitive business flows, rate limits, audit logs, and webhook verification when relevant.

What should an error response contain?

Return a stable code, appropriate status, safe explanation, trace identifier, and field details for validation failures. Never expose stack traces, SQL, secrets, or internal hostnames.

RFC 9457 defines a standard problem-details format for HTTP APIs. You do not have to reproduce the RFC in an interview; show that errors are part of the contract rather than an afterthought.

How will the API evolve without breaking clients?

Prefer additive changes: new optional request fields, new response fields that clients are expected to ignore, or new endpoints. Avoid renaming fields, changing types, tightening accepted values, or silently changing semantics inside a stable version.

When a break is unavoidable, describe the new major version, migration window, old-client telemetry, deprecation notice, and shutdown. Versioning is a migration plan, not just /v2.

Expect Production Follow-Ups

API design interview workflow from requirements and resources to failures, security, and evolution

Senior interviews move from contract to operations: provider timeouts, quota abuse, stale downstream data, or a major traffic spike.

Discuss timeouts, bounded retries, request IDs, metrics, logs, traces, and SLOs. Separate acknowledgement from asynchronous completion when needed. If you return 202 Accepted, define status lookup.

Rate limiting needs a policy, not only an algorithm. State the identity, window or token model, burst behavior, enforcement point, and response.

A 45-Minute Practice Routine

Minutes 0-5: clarify. Identify consumers, operations, invariants, scale, and security boundaries.
Minutes 5-12: model. Name resources, relationships, states, and ownership.
Minutes 12-25: define the contract. Write the critical endpoints, schemas, status codes, and one complete request-response example.
Minutes 25-37: attack the design. Test retries, concurrency, invalid input, authorization, pagination, rate limits, and downstream failure.
Minutes 37-45: evolve it. Add observability, backward compatibility, and one alternative with a clear trade-off.

Record yourself. If URL style consumes ten minutes, tighten the first half. If every answer is “it depends,” state a default and what would change it.

Use PracHub's company-specific interview prep to choose prompts that match the employer, then practice adjacent system design questions. For senior roles, also prepare behavioral and leadership questions about migrations, incidents, and cross-team API ownership.

Common Mistakes

The most common mistake is drawing routes before clarifying the consumer or invariant. Other weak answers expose storage, use POST for everything, return 200 for every outcome, or mention OAuth without object authorization.

Do not overdesign with REST, GraphQL, gRPC, Kafka, and event sourcing at once. Choose the simplest contract, then add complexity only when a constraint justifies it.

Finally, do not bolt on security, pagination, and versioning during the last minute. These concerns change the public contract and should appear while you design it.

Frequently Asked Questions

Is an API design interview the same as system design?

API design focuses on resources, operations, schemas, errors, security, and evolution. System design covers the broader architecture and scale. Backend interviews often move from the API surface into storage, concurrency, caching, queues, and reliability.

Should I always choose REST?

REST-style HTTP is a strong default for many public interfaces. GraphQL can serve flexible data graphs; gRPC can suit typed internal calls. Choose based on consumers, latency, streaming, tooling, and compatibility.

How many endpoints should I design?

Three to six critical operations are usually enough. Go deep on one write and one read or list path, including schemas, failures, authorization, and retries.

Do I need to memorize every HTTP status code?

Know the common success, validation, conflict, authorization, rate-limit, and server-error codes. Use them consistently with a stable, actionable error body.

What makes an API design answer senior-level?

A senior answer protects invariants, considers old clients and partial failures, separates authentication from authorization, adds observability, and revises the design when requirements change.

Final Takeaway

Prepare for API design interview questions by practicing complete contracts under pressure. Start with the consumer and invariant, define one precise request and response, then test retries, races, permissions, growth, and change.

Use PracHub's API design interview question collection to work through real prompts, compare your answer with written solutions, and repeat the 45-minute routine until the reasoning feels natural. Then use real interview questions with written solutions to prepare the rest of the loop.

Sources

Research checked August 5, 2026. Interview formats and API conventions vary by company; use the requirements and constraints stated in your specific interview.