What this prompt does
This prompt runs an interactive API design interview where the model acts as interviewer and you design an API for [api_purpose] under the constraints in [requirements]. It opens by asking clarifying questions about scale and users, then evaluates your resource naming, HTTP methods and status codes, auth approach, pagination and filtering, rate limiting, versioning, error format, and webhook design for [async_events]. After you design, it scores you on RESTfulness, Scalability, Developer Experience, and Security, and provides an ideal OpenAPI snippet for comparison at the [level] you set.
The structure works because real API interviews are dialogues, not lectures — the model asks before it reveals, which forces you to reason aloud the way you would in an actual interview. The [requirements] variable injects realistic scale constraints that shape every decision, [async_events] drives the webhook portion, and [level] calibrates how deep the challenges go. The scoring across four dimensions gives you a concrete read on where your API instincts are weakest. Because it starts by asking clarifying questions about scale and users, it also rehearses the habit interviewers reward most: pinning down requirements before drawing a single endpoint, which is where many candidates lose points by designing too early.
When to use it
- You are preparing for backend or API-focused technical interviews
- You want to practice designing REST or GraphQL contracts under realistic constraints
- You need feedback on resource naming, versioning, and status-code choices
- You want to rehearse explaining auth, rate limiting, and pagination out loud
- You are designing a new API and want a structured second opinion on the contract
- You want a scored, dimension-by-dimension read on your API design skill
Example output
Expect an interactive session: clarifying questions first, then back-and-forth evaluation of each design decision as you make it. After you finish, you get scores out of five on RESTfulness, Scalability, Developer Experience, and Security, plus an ideal OpenAPI snippet to compare against your design. The tone matches the [level] you set, with deeper challenges for senior or staff targets, and it covers versioning, error-format consistency, and webhook design for your [async_events] so the contract is evaluated end to end.
Pro tips
- Set
[requirements]with real scale numbers; "10M users, 1B files" forces different decisions than a toy API - Match
[level]to your target role so the challenges and scoring calibrate correctly - Actually answer the clarifying questions before designing — skipping them defeats the interview simulation
- Use realistic
[async_events]so the webhook design portion exercises real event-driven thinking - Treat the four scores as a diagnostic; the lowest dimension tells you where to focus practice next
- Re-run with a different
[api_purpose]once you score well, since variety exposes gaps a single design hides
