In this article
Before you start
This page belongs to the product analytics cases path, and it assumes only the three ideas below.
Why interviewers ask this
The round exists to see whether you can turn a vague product idea into a design that other engineers can build and clients can rely on. Meta's own preparation post says the design interview is forty-five minutes long, almost never involves coding, and comes in two kinds, systems design and product design, chosen by your background (Meta Careers, updated October 2022).
A weak answer lists boxes (a server, a database, a cache) without saying what the product does for a user. A strong answer starts from the user, fixes the interface, and then shows which parts of the system own which data. Third-party guides describe the same pattern: user-facing prompts, API-centric thinking, and evaluation on how well you navigate the problem, build the solution, go deep and communicate (Prepfully, February 2026).
The Meta product architecture interview from first principles
- Product architecture interview
- A product architecture interview is a design round in which a software engineer designs a user-facing product end to end, from user needs to interface, data and components, and is judged on the clarity of the interface and the reasoning about trade-offs more than on raw scale.
- Application programming interface
- An application programming interface (API) is the set of requests that one program can make to another, such as "fetch the next twenty events", together with the shape of each reply, so that the two programs can change independently.
- Cursor pagination
- Cursor pagination is a way of returning a long list in pages by asking for "the items after this marker" instead of "page number n", which keeps pages stable while new items arrive.
In plain words
A product architecture interview asks you to be the architect of a building before anyone pours concrete. The tenants are the product's users and the other teams. You decide what each door does (the API). You decide where each kind of belongings is kept (the data model). You decide which floor each service sits on. The analogy breaks in one place. A real building is finished once, but a product keeps changing after launch. So the interviewer also asks how your design changes without breaking the tenants already inside.
In one precise sentence: you state what the user needs, fix the interface clients call, choose the data behind it, place the components and defend the trade-offs.
Step 1: Clarify the product and its users
Clarifying the product means asking who uses it, what the main action is and what you are leaving out. The input is a one-line prompt such as an events feature or a messaging product. The output is a short list of user actions and a few stated assumptions.
Ask three things: who the users are, what the one action is that must work perfectly, and what the rough size is. Write the answers where the interviewer can see them. Reported guides give this step about five minutes of a forty-five minute round (DesignGurus, April 2026); treat that split as a pacing guide, not a rule from Meta.
What you now know: the product's core actions, which become the verbs of your API.
Step 2: Design the API and its paging
Designing the API means writing each user action as a request and a reply before drawing any server. The input is the action list from Step 1. The output is a few endpoints with their fields and an explicit answer to how long lists are paged.
For an events product the requests might be "create event", "respond to an invitation" and "list upcoming events". The common error is paging a list by page number. Offset paging asks the database to count past the skipped rows each time, which the author of a widely read indexing guide says puts a lot of work on the database for large offsets (Use The Index, Luke), and it repeats items when new rows arrive between two requests. The worked example below measures that repeat.
What you now know: the interface that clients will depend on, including how a feed or list stays correct while it grows.
Step 3: Model the data behind the API
Modelling the data means choosing the records that answer each request and who owns each one. The input is the API. The output is a few tables or objects with keys and the queries they must serve.
For each request ask which record it reads, which it writes and which index serves it (a database index is a sorted lookup structure, so the database does not read the whole table). An event record, an invitation record linking a user to an event, and a response status are enough for the example. Say which service owns each record: shared ownership is where bugs and arguments start. Guides describe data ownership and storage models as typical product architecture topics (Prepfully, February 2026).
What you now know: the tables and keys, which tell you what must be indexed and what could be cached.
Step 4: Draw the architecture and split client from server
Drawing the architecture means placing the components that carry the requests and deciding what logic runs on the client and what on the server. The input is the API and data model. The output is a box-and-arrow sketch with the data flow of the main request.
Keep it small: a client, an API service, the store, and one asynchronous path, meaning work done after the reply is sent, such as notifications. Decide what the client (the app on the person's device) may compute (formatting, local state) and what the server (the program answering requests) must (permissions, ordering). Say where you would cache and why: a cache is a stored copy of a frequent answer, kept closer to the client. The same system can be pushed toward either style of round, so show which one you are leaning toward (Prepfully, February 2026).
What you now know: the components and who does what on each request.
Step 5: Discuss trade-offs and how the product evolves
Discussing evolution means saying how the design survives new requirements without breaking existing clients. The input is the sketch. The output is two or three named trade-offs and a versioning plan.
Stripe describes naming API versions by release date, keeping compatibility with every version since 2011, and pinning each account to the version it first used (Stripe, August 2017). Adding a field is safe; removing or renaming one is not. Say which risks you would watch: a slow query, a hot record (one row that gets far more traffic than the rest), a retry that creates a duplicate.
What you now know: how to finish the round with decisions you can defend.
Step-by-step description
- Users, key action, assumptions.
- Requests, replies and paging.
- Records, keys and owners.
- Components and client-server split.
- Trade-offs and versioning.
- Clarify the product first.
- The API comes before the data model.
- End with trade-offs and how the product evolves.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
The worked example tests Step 2 on a real database. We built a SQLite table of one thousand events, numbered 1 to 1,0001, listed newest first in pages of twenty. A client reads page one. Then five new events arrive. The client asks for page two.
Page one is events 1000 to 981. With offset paging ("skip twenty, take twenty") page two began at event 985, so it repeated five events the client had already seen. Offset page two is events 985 to 966, which repeats 985 to 981. Cursor page two is events 980 to 961. With cursor paging ("take twenty before event 981") page two began at event 980 and repeated none.1
| Fact | Offset paging | Cursor paging |
|---|---|---|
| Items repeated on page two | 5 | 0 |
| Page two starts at event | 985 | 980 |
| Work grows with page depth | yes (skipped rows are still read) | no (index seek from the marker) |
| Needs a unique sort key | yes | yes (the cursor is that key) |
| Can jump to page 50 directly | yes | no |
Both methods need a unique sort order: the PostgreSQL manual warns that without one, paging with different row-limit and skip values gives inconsistent results (PostgreSQL documentation), and in cursor paging that sort key is the marker. The indexing guide lists the rest of the trade: skipped rows must still be fetched, so big offsets cost the database more, while cursor paging avoids drifting results but cannot jump to an arbitrary page (Use The Index, Luke). For a feed that people scroll, that is the right trade.
A second computed number sizes the storage. With illustrative inputs of two million invitation responses a day at forty bytes a row, one year is about 29.2 gigabytes of raw rows before indexes.1 If responses grow tenfold, the same arithmetic gives 292 gigabytes a year.1 The inputs are illustrative, not Meta figures; the point is to show the arithmetic you would say aloud.
Text description of the diagram
- Offset paging repeated 5 items on page two.
- Cursor paging repeated 0 items on page two.
Trade-offs and edge cases
Product architecture is not the same round as system design, and mixing them up wastes the forty-five minutes. Meta's preparation post describes systems design and product design as two kinds of design interview (Meta Careers, 2022). A third-party guide frames the difference as scalability, availability and failure behaviour in system design, against API boundaries, usability and product evolution in product architecture (Prepfully, February 2026).
| Dimension | System design | Product architecture |
|---|---|---|
| Main pressure | scalability, availability, failure | API boundaries, usability, product evolution |
| Typical topics | storage and scaling choices | data ownership, storage models, user-facing prompts |
The first edge case is that you may not get to choose: the interviewer matches the question to your background. The second is that the reported prompts differ by source, so treat any list of questions as a sample, not as what Meta will ask. The third is tooling: the hiring page says design interviews use CoderPad with Mermaid Markdown, so practise drawing a diagram as text. CoderPad is a shared online code editor, and Mermaid is a text format that turns a few lines of text into a diagram.
Text description of the diagram
- Page one is events 1000 to 981.
- Offset page two is events 985 to 966, which repeats 985 to 981.
- Cursor page two is events 980 to 961.
How to answer it in an interview
Open the round by stating the user, the one action that must work, and your first interface decision. The answer below shows the opening for an events prompt. It is an example of structure, not a script.
Design an events feature where people invite friends to go to the movies together.
I would start with the user: someone who proposes a plan and friends who respond. The action that must work is responding to an invitation. So the interface is create event, respond to invitation, and list upcoming events. I would page the list with a cursor, meaning "events after this marker", because page numbers repeat items when new events arrive. Behind it sits an event record, an invitation record and a response status, each owned by one service. The main trade-off is that a cursor cannot jump to a page, which is fine for a scrolling list.
Say it in this order: user, key action, interface, data, one trade-off. For the general method of structuring any answer, see how to answer interview questions; for the questions you ask the panel at the end, see questions to ask the interviewer; the story questions in the same loop are in behavioral interviews; and if your round is a product-management one instead, read the product management hub. The answer runs about forty-five seconds. Replace the example with the prompt you are given.
Common mistakes
- Starting with servers. (wrong) "I will draw a load balancer and a database." (right) "First, who uses this and what is the one action that must work?"
- Paging by page number. (wrong) "The list takes a page number and a size." (right) "The list takes a cursor, so new items cannot cause repeats."
- Leaving data ownership vague. (wrong) "The services share the tables." (right) "The events service owns events; others call its API."
- Treating the API as final. (wrong) "I will rename the field later." (right) "I will add fields and version the interface, since removing one breaks clients."
- Skipping the numbers. (wrong) "It will need a lot of storage." (right) "Two million responses a day at forty bytes is about 29.2 gigabytes a year, before indexes."
Follow-up questions
What is the Meta product architecture interview?
It is a design round for software engineers where you design a user-facing product from requirements through the API, data model and architecture; Meta describes design interviews as forty-five minutes with almost no coding (Meta Careers, 2022).
How is product architecture different from system design?
System design stresses scale, performance and failure; product architecture stresses API boundaries, data ownership and how the product changes, according to a third-party guide (Prepfully, February 2026). For the system side, read system design.
How would you design privacy level settings (Me, Public, Friends, Friends of Friends) for the Facebook app?
A privacy-settings design uses the same five steps, and the prompt is a real one reported for the round. The key action is changing who can see one item. The API reads and sets one visibility value per item; the data model stores that value next to the item and needs a friend-link record to answer "friends of friends"; and the server, not the client, checks it on every read, because permissions must not depend on the app being honest. State the trade-off: the widest setting is cheapest to check, the friends-of-friends setting needs an extra lookup.
How would you design a Facebook events product for going to the movies together?
An events design for going to the movies together is a real prompt reported for the round, narrowed by the interviewer. The worked example above is the answer's backbone: create event, respond to invitation, list upcoming events with a cursor. For the machine learning flavour of this kind of prompt, see machine learning system design.
How do edits, deletes and live updates change the events list?
The cursor is the sort key of the last item seen, not the item itself, so deleting that item does not break the next request. Edits that change the sort key would move an item between pages, so sort on a value that never changes, such as creation time plus id. For live updates, the server can send new items to the top of the list while the cursor keeps walking down; adding fields to replies is safe, as in Step 5.
What if responses grow tenfold?
Storage scales linearly, so ten times the responses is ten times the bytes. Twenty million responses a day at 40 bytes a row is 292 gigabytes a year before indexes, against 29.2 in the worked example.1 Say that the table now needs splitting by time or by event, and that cursor paging keeps working because it never counts skipped rows.
- Meta describes the design round as forty-five minutes, almost never coding, in systems or product form.
- Start from the user and one key action, then fix the API before the data model.
- Page long lists with a cursor: offset paging repeated five items in our run, and both methods need a unique sort key.
- Say who owns each record and how the interface changes without breaking clients.
Sources
- Meta Jobs hiring process — Meta (page shows no date; read 2026-10-24), 24 Oct 2026
- Preparing for your software engineering interview at Meta — Meta Careers (originally published 2016-06-27; updated 2022-10-06), 6 Oct 2022
- Meta SWE design interview guide — Prepfully (third-party; last updated February 2026), 1 Feb 2026
- Mastering Meta's product design interview — DesignGurus (third-party), 16 Apr 2026
- APIs as infrastructure: future-proofing Stripe with versioning — Stripe (Brandur Leach), 5 Aug 2017
- PostgreSQL documentation: LIMIT and OFFSET — PostgreSQL Global Development Group (current manual; read 2026-10-24), 24 Oct 2026
- We need tool support for keyset pagination — Use The Index, Luke (Markus Winand; page shows no date; read 2026-10-24), 24 Oct 2026
