API Design vs. System Design Interview: When You'll Get Which
Stripe asks one. Meta sometimes asks both in the same loop. Here's how to tell within the first three minutes — and pivot gracefully when the interviewer reframes the question on you.
The most expensive mistake in design interviews isn’t picking the wrong database or the wrong sharding strategy. It’s spending 25 minutes answering the wrong question type.
You walk in expecting a system design interview. The interviewer says “design Instagram comments.” You start sketching boxes — load balancer, app servers, comments DB, cache, CDN. Twenty minutes later the interviewer is still nodding politely but their notes say “hasn’t engaged with the API surface at all.” You walk out thinking you crushed it. The debrief says no hire.
The reverse happens just as often. You expect API design. The question sounds like API design. You spend 25 minutes on resource modeling, idempotency keys, and versioning. The interviewer asks “and how does this scale to a billion users?” and you realize, far too late, that you were supposed to be drawing the system this whole time and the API design framing was just how the question was opened.
This article is about the signals that tell you which interview you’re actually in, the company-by-company breakdown of who asks what, and the exact phrases to use when you need to pivot mid-interview without losing points.
The fundamental difference (in one paragraph)
A system design interview scores you on how data and traffic flow through a distributed system at scale. The unit of thought is the box-and-arrow diagram. The questions are: where does the data live, how does it get there, how does it survive failure, how does it grow.
An API design interview scores you on the contract between systems. The unit of thought is the request/response. The questions are: what are the resources, what are the endpoints, what does a payload look like, how do clients evolve with the API.
These two interviews share maybe 30% of their material. The rest is genuinely different — different rubrics, different vocabulary, different things that earn you points. Treating them as the same is the most common reason senior engineers underperform on design loops.
The signals at the question level (the first 60 seconds)
The interviewer will tell you which interview you’re in if you listen for the exact words they use. Here are the dead giveaways.
You are in an API design interview if you hear:
“Design the API for…” (the most obvious tell, but easy to miss when you’re nervous)
“What does the request and response look like for…”
“How would a third-party developer integrate with…”
“Walk me through the contract between the client and the server”
“What endpoints would you expose for…”
The question is scoped to a single feature (refunds, comments, likes, search) rather than a whole product
You are in a system design interview if you hear:
“Design ____” (with no qualifier, naming a whole product — “design Twitter,” “design Uber”)
“How does this scale to X million users?”
“Walk me through the high-level architecture”
“Where does the data live?”
“How does the data flow through the system?”
“What happens when this region goes down?”
You are in a hybrid interview if you hear:
“Design the system that powers ____”
“Let’s start with the API and then we’ll talk about how it’s implemented”
“Design the X service, and walk me through both the surface and the internals”
The hybrid framing is the most dangerous one. It sounds like permission to do both, but in practice the interviewer has a primary axis they’re scoring you on, and they want you to spend 70% of your time there. If you split 50/50, you produce a half-graded answer on both sides.
The single best opening question you can ask in any design interview, regardless of how the question was framed:
“Quick clarification before I start — would you like me to focus more on the external API surface and the contract, or more on the internal system architecture and how it scales? I have opinions about both, but I want to invest my time where it’s most useful for you.”
That sentence does three things in one shot. It tells the interviewer you understand there are two distinct axes. It lets them tell you which one they’re scoring. And it preemptively earns you a point on interview literacy — interviewers love candidates who know what kind of room they’re in.
Company-by-company breakdown
Different companies have measurably different distributions across these interview types. Knowing which company you’re interviewing with is half of knowing how to prep.
Meta
Distribution: ~60% system design, ~25% API design, ~15% hybrid.
Meta is the company most likely to put both interview types in the same loop, and the company most likely to spring a hybrid question on you. At staff and above, it’s common to see one pure system design interview and one pure API design interview in a single onsite. Their API design questions tend to be product-flavored (”design the API for Instagram Reels reactions,” “design the API for Marketplace listings”) and lean heavily on resource modeling — partly because GraphQL is so deeply embedded at Meta that interviewers are calibrated to think in resource graphs.
What to prep: Both, with extra weight on resource modeling for the API design side and on data flow / consistency for the system design side. Expect at least one question that involves social graph traversal.
Stripe
Distribution: ~70% API design, ~20% system design, ~10% hybrid (always with API design as the primary axis).
Stripe is the API company. Even their “system design” interviews skew toward the API surface, because their entire business is the developer experience of their API. Expect deep questions on idempotency (this is the Stripe topic — get it cold), versioning strategy, error model design, webhook design, and reconciliation between distributed financial systems. If you can’t have a 20-minute conversation about idempotency keys, sub-second conflict resolution, and the difference between at-least-once and exactly-once delivery, you are not ready for a Stripe loop.
What to prep: API design, especially around payments, refunds, subscriptions, webhooks, and any flow involving money or events. Read Stripe’s actual API docs as study material — they’re considered the gold standard in the industry for a reason.
Uber
Distribution: ~80% system design, ~10% API design, ~10% hybrid.
Uber is system design heavy because the core interesting problems at Uber are real-time distributed systems problems — geospatial indexing, surge pricing, driver-rider matching, ETA computation, payment splitting across regions and currencies. API design comes up mostly if you’re interviewing for the API Platform team or for an external developer-facing role. Otherwise expect questions like “design the matching service for ride requests in a city” or “design the system that calculates surge pricing in real time.”
What to prep: System design with a heavy emphasis on real-time data flow, geospatial sharding, and high-throughput message processing. Know your Kafka, your Redis geospatial commands, and your S2/H3 cell indexing.
Airbnb
Distribution: ~75% system design, ~15% product/data design, ~10% API design.
Airbnb is system design heavy but with a distinctive twist: they care about product reasoning and data modeling in a way most companies don’t. Expect questions like “design Airbnb search” or “design the pricing recommendations system” — questions where the system architecture is intertwined with how you think about the product experience. They’re famous for asking what signals you’d surface in search ranking, which is half system design and half product intuition. API design comes up mostly for backend infrastructure roles.
What to prep: System design with a strong product lens. Be ready to talk about ranking, recommendations, A/B testing infrastructure, and how product decisions translate into system requirements. Don’t go into an Airbnb loop without practicing at least one search-ranking question.
A few honorable mentions
Google is heavily system design, with very deep emphasis on data structures, storage internals, and consistency models. API design is rare unless you’re on an API platform team.
Amazon is system design with a strong service-oriented architecture flavor — every problem ends up looking like “what services would you decompose this into and what are the contracts between them,” which is almost API design but framed inside a system design rubric.
Netflix is system design with a relentless focus on reliability, fallback, and graceful degradation. Expect at least one question where the interviewer asks “what happens when this dependency fails.”
Coinbase, Plaid, and other fintech-API companies all skew heavily Stripe-style — API design is the primary axis.
Mid-interview pivot signals (this is where it gets hard)
Here’s the situation that wrecks otherwise-strong candidates. The question is opened in one mode. You start answering in that mode. Twenty minutes in, the interviewer subtly changes the question type on you, and you don’t notice.
These are the verbal cues that the interviewer has shifted axes. Memorize them — they are how you avoid the worst failure mode in this entire category of interview.
Signs the interviewer wants to pivot from system design → API design
“Let’s zoom in on the [X] service. What does its surface look like?”
“How would a client interact with this?”
“What does the request to that endpoint look like?”
“What does that endpoint return?”
“How would you version this?”
“What if a client retries?”
The interviewer stops asking about the diagram and starts asking about specific calls.
When you hear two of these in a row, the interview has pivoted. You are no longer being graded on your architecture — you’re being graded on your contract design. Stop drawing boxes and start writing endpoints.
Signs the interviewer wants to pivot from API design → system design
“Now how would this scale to a billion users?”
“Where does this data actually live?”
“What happens when this service goes down?”
“How is the data partitioned?”
“Walk me through what happens after the client makes that call — where does the request go?”
“How fresh does this data need to be?”
The interviewer starts asking what happens behind the endpoints you’ve drawn.
When you hear these, stop polishing the contract and start drawing the system. The endpoints you defined become the entry points into your system design diagram — they’re the load balancer’s first stop. You can carry your API work forward as the surface, and start filling in what’s behind it.
The general principle
Whenever you hear “let’s zoom in”, you’re being pulled toward API design or data modeling. Whenever you hear “let’s zoom out” or “how does this work at scale”, you’re being pulled toward system design. Zoom in = contract. Zoom out = system. It’s nearly that clean.
How to switch modes gracefully
Here’s the part nobody teaches. When you notice the pivot, you have to acknowledge it out loud — but in a way that doesn’t make you sound like you misread the question.
The wrong way to pivot:
“Oh, you want me to talk about the system design? Sorry, I thought we were doing API design.”
That’s a confession of confusion. It signals you weren’t tracking. The interviewer writes “got lost halfway” in their notes.
The right way to pivot:
“Got it — sounds like you want to dig into how this actually runs underneath. Let me build on what we have. The endpoints I defined are the entry points to the system, so the request flow starts at the API gateway, hits this routing layer, and then…”
That sentence does three magical things. First, it acknowledges the shift without admitting you missed it. Second, it explicitly bridges from your previous work to the new work, so nothing you’ve already drawn gets thrown away. Third, it frames the pivot as a natural progression, not a correction.
The same move works in the other direction:
“Sure — let me zoom in on the API surface for that service. The endpoints would be… and the request shape for the create call would look like…”
Notice the verbal tic that signals you’re tracking the interview rather than just answering questions: “sounds like you want to...” or “got it, let me...” These phrases telegraph that you noticed the shift, that you’re meeting the interviewer where they are, and that you’re collaborating rather than reciting a script. Interviewers reward this consistently because it’s the rarest skill in the candidate pool.
The decision cheat sheet
If you’re reading this on the train to your onsite, here’s the compressed version. Print it, screenshot it, whatever.
The opening question that always works, regardless of how the prompt was phrased:
“Would you like me to focus more on the external API surface or the internal system architecture? I have opinions about both, but I want to spend my time where it’s most useful for you.”
Memorize that sentence. Use it on every design interview. It will save your loop more times than any specific technical pattern.
The deeper point
Both of these interviews are testing the same underlying thing: can you decompose ambiguity into structure under time pressure. They just measure it on different surfaces.
If you’ve prepped one and not the other, you’re playing on hard mode. The good news is that the prep transfers heavily — the patterns of clarification, the discipline of stating tradeoffs out loud, the muscle of explaining why you made a choice rather than just stating the choice — those are the same in both interviews. The vocabulary is what differs. If you want a comprehensive walkthrough of the patterns that span both, the System Design Interview Guide is structured exactly around this — the foundational concepts that show up in both interview types, then the question patterns that diverge.
But the meta-skill that this article is really about — knowing which interview you’re in and being able to pivot — is one you can only practice in mock interviews. The next time you do a mock, ask your partner to deliberately pivot the question type halfway through. That’s the rep that almost nobody does, and it’s the rep that separates the candidates who can roll with anything from the candidates who only succeed when the question matches the prep.
The interview is an adversarial information game. The interviewer knows what they’re scoring. Your job is to figure out what they’re scoring before they’ve scored you.