The API Design Interview Framework
You'll learn to
- -Apply a repeatable process for API design prompts: clarify use cases, model resources, choose a protocol, design the contract, then discuss evolution
- -Recognize the most common failure mode - designing endpoints before clarifying who calls them and why
Just like the LLD framework from ScaleDojo's LLD Fundamentals course, API design interviews reward a repeatable process over improvisation - the prompt "design an API for a ride-sharing app" is deliberately broad, and how you narrow it down matters more than the first endpoint you write.
The Five Steps
- -Clarify use cases and clients: who calls this API, and for what? A mobile app, a partner integration, and an internal service all want different things from the same data.
- -Model the resources (or, for GraphQL, the schema's types): what are the nouns, and how do they relate? This is the same resource-modeling instinct as database schema design, applied to what gets exposed over the wire.
- -Choose the protocol: REST, GraphQL, or gRPC - justified by the client landscape and access patterns from step 1, not by default habit.
- -Design the contract: endpoints/methods, request/response shapes, status codes or error types, auth boundaries.
- -Discuss evolution: how does this API change without breaking existing clients? Versioning, deprecation, backward-compatible additions.
The Failure Mode: Endpoints Before Requirements
The most common way candidates lose points: sketching `GET /rides`, `POST /rides`, `GET /rides/{id}` within the first two minutes, before establishing who calls this API and what "a ride" even needs to represent for that caller. A driver-facing client needs different fields and different real-time guarantees than a rider-facing client or an internal billing service - designing the resource shape before knowing that leads to either an overloaded, kitchen-sink resource or a redesign mid-interview.
Watch for this same failure mode in reverse: over-clarifying for so long that you never actually design anything. Two to three minutes of clarifying questions, then move - the goal is enough context to make defensible decisions, not exhaustive certainty.
You're asked to "design an API for a food delivery app." What is your first move?
"I'd start with a Restaurant resource and a MenuItem resource, then build out CRUD endpoints for each."
"Before modeling anything, I want to know who's calling this - is this the customer-facing app, the restaurant's order-management dashboard, or the delivery driver's app? Each of those wants a different shape of the same underlying data, and possibly a different protocol - the driver app might need a real-time subscription for new orders, while the restaurant dashboard is fine with plain polling. That's what determines whether I'm designing one API or three."
What is the first step in the API design interview framework?