API design is one of the best proxy signals for backend engineering quality. A well-designed API requires simultaneously: understanding HTTP semantics, resource modeling discipline, error handling depth, security awareness, and the ability to think about how a contract will evolve over time. A candidate who has genuinely built and maintained APIs at scale will answer differently from a candidate who has read about it.
This is part of a complete technical skills assessment — API design questions specifically target the architectural judgment layer that coding challenges often miss entirely.
This guide provides questions calibrated by seniority level, the correct evaluation criteria for each type, and a scoring rubric you can use immediately.
What API Design Questions Actually Test
Before selecting questions, clarify what you are trying to measure:
| What You're Testing | What It Reveals | Good Question Type |
|---|---|---|
| **HTTP fundamentals** | Whether they know the protocol correctly, not just the conventions | "What is the difference between PUT and PATCH?" "When should you use 202 Accepted vs 200 OK?" |
| **Resource modeling judgment** | Whether they can decompose a domain into well-bounded resources | "Design the resources and endpoints for a multi-tenant notification service." |
| **Error handling depth** | Whether they think beyond the happy path | "What HTTP status codes and response structures would you use for a failed payment?" |
| **Contract evolution thinking** | Whether they understand how APIs age and break clients | "How would you deprecate a field that 500 external clients are using?" |
| **Security awareness** | Whether authentication, authorization, and rate limiting are reflexive or forgotten | Observe what they include without prompting in a design exercise |
| **Trade-off reasoning** | Whether they understand when REST, GraphQL, or gRPC is the right tool | "We have a mobile app with 30 different data views. What should drive our API strategy?" |
Note what is absent from this list: trivia about HTTP status codes, memorized REST constraints, or theoretical knowledge of hypermedia. These surface knowledge, not engineering judgment.
Foundational API Design Questions (Any Backend Role)
Use these for mid-level backend engineers and anyone where API work is a significant part of the role.
1. "What is the difference between PUT and PATCH?"
Expected answer: PUT replaces the entire resource; PATCH applies a partial update. PUT is idempotent — calling it with the same payload multiple times produces the same state. PATCH may or may not be idempotent depending on implementation. Strong answers note that PATCH semantics are defined by the request body format, and that JSON Merge Patch and JSON Patch are two different PATCH body formats with different semantics.
2. "When should you return 400 vs. 422?"
Expected answer: 400 (Bad Request) for malformed requests — the server could not parse the request body or the request was syntactically invalid. 422 (Unprocessable Entity) for requests that are syntactically valid but semantically invalid — the JSON parsed correctly, but the fields do not satisfy business rule validation. Strong answers note that 400 vs. 422 consistency matters because clients may handle them differently, and a contract should be explicit about which validations produce which status codes.
3. "How would you design an endpoint to create a payment?"
Expected answer covers: POST /payments (not /createPayment — action in URL is an anti-pattern). Idempotency key in the header to prevent duplicate charges on network retry. Synchronous response for immediate decisions (accepted/rejected) but async status for settlement. 201 Created on success with Location header pointing to the new resource. 409 Conflict if the idempotency key was already used. Error response body with machine-readable error code, human-readable message, and field-level validation errors where applicable.
Red flag: Candidates who describe the happy path only.
4. "How do you handle authentication in an API?"
Expected answer: Bearer token (JWT or opaque) in the Authorization header. Not in the URL. Short-lived access tokens with a refresh token pattern for user-facing APIs. Service-to-service APIs use mutual TLS or API key in Authorization header. Strong answers mention token revocation strategy — a problem that JWTs make harder than opaque tokens, which is a real trade-off to discuss.
Intermediate-Level API Questions (Senior Backend)
5. "How would you version an API that 1,000 external clients depend on?"
Expected answer: Distinguish breaking changes from non-breaking changes. Non-breaking (adding optional response fields, adding new endpoints, adding optional request parameters) do not require a new version. Breaking changes (removing or renaming fields, changing field semantics, changing authentication requirements) require either a new version or a long deprecation period with active client migration support.
Versioning approaches: URL versioning (/v1/, /v2/) is the most common and easiest for clients. Header versioning (Accept header) is cleaner but harder to test and debug. Strong answers include: what the sunset policy looks like, how you communicate breaking changes to clients, and minimum supported version windows.
6. "When would you choose GraphQL over REST?"
Expected answer: GraphQL is appropriate when client data requirements are diverse and change frequently — a mobile app that renders 20 different views from the same underlying data, each needing a different subset of fields. It eliminates the over-fetching and under-fetching problems that multiply API round trips in REST. It is not appropriate when the client set is stable and predictable, when you need HTTP caching (GraphQL uses POST, breaking HTTP caching), or when your team lacks the tooling and operational experience to manage schema evolution, resolver depth limiting, and query complexity attacks.
Red flag: Candidates who say "GraphQL is better than REST" without context. This is a preference, not an engineering judgment.
7. "Design the API for a rate limiter — what endpoints, what response codes, what headers?"
Expected answer: 429 Too Many Requests when the rate limit is exceeded. Retry-After header indicating when the client can retry. X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers on all responses so clients can self-throttle before hitting the limit. Rate limit policy should be documented in the API contract: what scope is the limit (per user, per API key, per IP), what window (sliding window vs. fixed window), and whether the limit is soft (warning) or hard (rejection).
Advanced API Design Questions (Staff / Principal)
8. "How would you design an API that needs to be backward compatible for five years?"
Expected answer: Required reading: Hyrum's Law — "With a sufficient number of users of an API, it does not matter what you promise in the contract; all observable behaviors of your system will be depended on by somebody." Practical implications: treat the entire response structure as a contract, not just documented fields. Use additive-only changes for the first N years. Design a strong deprecation process: versioned deprecation notices, per-client usage tracking to know when it is safe to remove, minimum 12-month notice windows for breaking changes. Strong answers discuss the organizational component — backward compatibility is as much a process problem as a technical one.
9. "How would you design an event-driven API for a notification system?"
Expected answer: Distinguish push (webhooks) from pull (polling or long-polling). Webhooks require idempotent consumers, retry with exponential backoff, HMAC signature verification on inbound webhook payloads, and a delivery receipt mechanism. Server-Sent Events for browser clients needing real-time push without WebSocket complexity. WebSockets for bidirectional real-time requirements. Discuss the event schema design: event type as a discriminant, event version, timestamp, idempotency key on each event.
Scenario-Based API Design Questions
Scenario questions are the highest signal format. They require candidates to integrate multiple competencies — resource modeling, error handling, security, versioning — in a realistic context.
Scenario 1: E-commerce checkout API
"Design the API for a checkout flow. A user has a cart, selects shipping, provides payment, and confirms the order. Walk me through the resources, endpoints, and the tricky edge cases."
What to observe: Do they model the cart as a separate resource from the order? Do they handle the payment initiation as a separate step from order confirmation, or conflate them? Do they address idempotency for the payment step? Do they discuss what happens when payment succeeds but order creation fails?
Scenario 2: Multi-tenant API with resource isolation
"You're building a B2B SaaS API where each company has its own data that must be strictly isolated. How do you structure the API and authorization model?"
What to observe: Do they discuss URL structure choices (/tenants/{id}/resources vs. context from JWT claims)? Do they address the risk of IDOR (insecure direct object reference) — where a user from Tenant A can guess the ID of Tenant B's resource? Do they discuss row-level vs. schema-level isolation at the database level?
Scenario 3: API evolution under active usage
"You have an API endpoint that returns a user object. You realize the name field should be split into firstName and lastName. 800 external clients use this endpoint. How do you handle the migration?"
What to observe: Do they propose a versioned approach? Do they consider returning both old and new fields in parallel during a transition period? Do they discuss how to measure which clients have migrated? Do they acknowledge Hyrum's Law — that some clients may be parsing name in ways that depend on the exact format?
How to Score API Design Answers
A standard 1-4 rubric calibrated to backend level:
| Dimension | 4 (Strong) | 3 (Sufficient) | 2 (Developing) | 1 (Gap) |
|---|---|---|---|---|
| **HTTP semantics** | Correct and nuanced; explains trade-offs | Correct on core standards | Mostly correct with notable gaps | Significant misconceptions |
| **Resource modeling** | Clean, defensible, discusses alternatives | Generally sound with minor issues | Resources conflated or action-based URLs | No clear modeling approach |
| **Error handling** | Comprehensive: auth, validation, downstream, edge cases | Handles main cases; misses some edge cases | Happy path only; errors treated as exceptions | No error handling consideration |
| **Evolution thinking** | Discusses versioning, breaking changes, deprecation | Aware of versioning; limited deprecation strategy | Vague versioning approach | Does not consider API evolution |
| **Security awareness** | Auth, rate limiting, and IDOR raised without prompting | Raises authentication; prompted on others | Security only when directly asked | No security consideration |
For more on running backend assessments alongside live coding, see how to evaluate backend skills in a live coding interview. For role design that uses competency-based evaluation rather than credential proxies, see the skills-based hiring approach.
How Nextmantra AI Generates Role-Calibrated API Questions
Nextmantra AI generates API design questions dynamically from the job description and the candidate's claimed experience. For a candidate claiming "senior backend engineer with 6 years of microservices experience," the AI probes API gateway design, service-to-service authentication patterns, and event-driven contract design — not foundational HTTP semantics. For a candidate claiming "2 years of REST API development," the AI validates fundamentals before going deeper.
The AI interview produces a structured evaluation report scoring the candidate's API design answers across correctness, design judgment, and error handling depth — the same dimensions in the rubric above. Engineering managers receive calibrated signal before spending their own time on panel interviews. See how Nextmantra AI generates role-specific technical questions
Frequently Asked Questions
What are good API design interview questions for backend engineers?
The highest-signal questions focus on design decisions: designing a payment API with idempotency handling, API versioning strategy for external clients at scale, REST vs. GraphQL trade-off reasoning, and backward compatibility for an API with 1,000 active consumers. Questions requiring defense of decisions and reasoning about evolution produce more signal than HTTP trivia.
How do you evaluate an API design interview answer?
Score on five dimensions: correctness (HTTP semantics), design judgment (resource modeling), error handling completeness (beyond happy path), version management thinking, and communication clarity. Strong candidates volunteer trade-offs unprompted rather than waiting to be asked.
What API versioning strategies should candidates know?
URL versioning, header versioning, and query parameter versioning — each with trade-offs. The core principle: backward-compatible changes (adding optional fields, adding endpoints) do not require a new version. Breaking changes always require a version increment or a deprecation strategy with migration support.
How do you test API design skills without whiteboarding?
Open-ended design questions with structured follow-up probing, take-home API design exercises, and code review exercises where candidates review an implementation with design issues. The code review approach tests both design knowledge and communication quality simultaneously.
What is the difference between REST and GraphQL in an interview context?
REST is appropriate for stable, resource-oriented APIs with predictable access patterns. GraphQL is appropriate when clients have diverse, frequently changing data requirements and over/under-fetching are real operational problems. Strong answers explain when to choose each — candidates who default to one without context are showing preference, not judgment.
Conclusion
API design questions are among the highest-leverage questions in a backend engineering interview. They require integrating protocol knowledge, architectural judgment, security awareness, and evolutionary thinking — and they are difficult to answer well from surface-level preparation alone.
Use foundational questions to validate baseline competency. Use intermediate and advanced questions to probe depth. Use scenario questions to observe how candidates integrate multiple concerns under realistic conditions. Score against defined behavioral anchors rather than impressions. The result is a reliable, defensible signal that compound interview rounds can build on.
Need AI-powered first-round screening that generates role-calibrated API design questions? [See how Nextmantra AI works](https://nextmantra.ai/platform)
Sources: Fielding, R.T. (2000). Architectural Styles and the Design of Network-based Software Architectures (REST dissertation). Klabnik, S. & Richardson, L. (2013). RESTful Web APIs. Wright, A. et al. (2022). JSON Schema Specification. Wright, A. (2020). Hyrum's Law in Practice.