technical · standard
"What is an API?" the PM interview answer
What is an API, and what would you consider before building one?
This is a filtering question. The interviewer is not checking whether you can recite a definition. They are checking whether you think about developers as users, understand that API design decisions are product decisions, and can walk through the considerations a PM owns before a single endpoint is built. The failure mode is stopping at “a way for two systems to talk to each other.”
Structure a strong answer
Start with the user frame, then walk the PM-owned considerations.
strong
"An API is a contract between a producer and a consumer. The producer says: here is what I expose, here is what you send me, here is what you will get back. The consumer, typically a developer at another company or team, builds their product on top of that contract. The most important word is contract, because the developer is betting their product on the promise that the interface won't change on them without warning.
Before building one, I'd work through six things. First: is an API even the right surface? Feasibility is not the constraint in 2026. The question is whether a developer audience is the right audience, or whether the job is better served by a no-code UI, an embedded widget, or an agent tool via MCP. Second: contract stability. Adding new fields and optional parameters is backward-compatible. Removing or renaming them is a breaking change that can take down integrations at other companies. Stripe has maintained this discipline since 2011, which is a primary reason developer trust is high. Third: rate limits, which are not an engineering detail. They enforce your pricing tiers: 5,000 requests per day on free, 100,000 on enterprise. A rate limit IS a pricing decision. OpenAI's tiers are denominated in tokens per minute and requests per minute. That is the product. Fourth: developer experience as UX. Time-to-first-successful-call is the DX equivalent of activation. Stripe's goal of a working payment in under 10 minutes was a product goal, not an engineering one. Error messages and sandbox environments are the UX layer. A '400 Bad Request' with no explanation is a product defect. Fifth: webhooks versus polling. Webhooks are lower latency and more efficient at scale but harder for developers to implement; polling is simpler but expensive. Twilio ships webhook signature verification code in their SDKs so developers don't have to figure it out themselves. Sixth: observability. Which endpoints drive value? Which are being called in ways you didn't anticipate? Deprecation is easier when you have the usage data to defend it."
weak
"An API stands for Application Programming Interface. It's a way for two systems to talk to each other. REST APIs use HTTP methods like GET, POST, PUT, and DELETE and return JSON responses." This shows the candidate looked up the Wikipedia entry. The interviewer learns nothing about how this person would run an API product: no developer-as-user framing, no product considerations, no trade-offs, no examples from real products. At companies like Stripe, Twilio, or OpenAI, this answer is a filter-out, not a filter-in.
The PM judgment
The interviewer is checking for three signals: you treat the developer as the user; you know rate limits, versioning, and error messages are product decisions; and you can name what a PM owns here versus what engineering owns.
The 2026 angle
APIs are now also the substrate for AI agents. MCP (Model Context Protocol) is a contract specifically for AI agents to consume tools and data sources. A machine consumer has zero tolerance for ambiguous error messages because there is no human to course-correct. When evaluating an API product in 2026, ask whether the design accounts for agent consumers, not only human developers.
The viable/lovable frame applies directly. Viable: there is a real developer problem and a monetization path (rate-limit tiers, usage-based billing). Lovable: a developer reaches their first successful call in under 10 minutes, trusts the contract, and finds answers in the docs before opening a ticket. Neither requires implementation-level knowledge. Both require PM thinking.
API-first companies treat their changelog and documentation as a product surface with dedicated PMs. Candidates who can name that, and explain why, consistently outperform those who treat API questions as a knowledge quiz.
For follow-up questions on the technical product manager track, see what separates TPMs from general PMs in a hiring context. The build vs buy vs partner question often arrives alongside this one as a pair, since choosing an API surface is a version of that decision.