The Meta product architecture interview is a 45-minute design round about a product’s client-server contract. An easy way for an Android engineer to fail it is to design the app instead. They draw a ViewModel, a repository, Room and a Compose screen. Those boxes are correct. Yet they sit on one side of the line the interviewer wants to discuss. Meta’s own prep material frames its product design questions around the boundary. How does the client fetch a large object in pieces? How is the data shaped in the response? How do new server features avoid breaking older clients? So start from the screen, then spend most of the round on the API. Define the requests, the response shape and the paging. Then show how version 2 ships without breaking version 1. Bring in client architecture only where it changes the contract. Below is one Meta-style prompt answered that way, with a full script to adapt.<\/p>\n
Meta’s prep post for software engineering interviews<\/a> was last updated in 2022. It describes one 45-minute design interview in the full loop. That round almost never involves coding. It comes in two types, systems design and product design. Meta says it tries to match each candidate with an interviewer from a similar background. It names people who build complex user interfaces as one such background. An Android engineer is likely to land in the product track. Ask your recruiter which one you have, because the post is four years old.<\/p>\n The product version now goes by product architecture. Evan King is a former Meta staff engineer. He co-founded Hello Interview, a company that sells interview prep. His May 2024 guide to the round<\/a> calls it the system design equivalent for product engineers. He lists three tasks inside it. Define the requirements, design the APIs and draw a high-level system diagram. His guide is written for backend-leaning candidates. Its practice categories are built from cloud services like queues, caches and blob storage. Neither source says what an Android engineer should do with mobile knowledge in this round.<\/p>\n Meta’s post gives a sample product prompt. It asks how you’d design a client-server API for a rich document editor. Three follow-up questions come with it. The first asks how the client loads a document too large for one request. The second asks how the response represents styling like bold and italics. The third asks how the server adds features without breaking older clients. All three are about the boundary between app and server.<\/p>\n Now picture the common Android answer. The candidate draws a Compose screen, a ViewModel, a repository and a Room cache. They explain unidirectional data flow and process death. Every box is sound engineering. But none of it answers the three questions. The interviewer still doesn’t know what crosses the network. So their notes say nothing about the API. That’s the main thing the round asks for.<\/p>\n The opposite failure is real too. Some Android candidates hear “product architecture” and pretend to be backend engineers. They spend the round on database sharding they’ve never run. The interviewer probes it. Then the answers turn thin. The safer move is to anchor on the contract. You already know it from the client side, because you’ve parsed and paged real API responses.<\/p>\n Take Meta’s document editor prompt as the running example. Open with two minutes of requirements, chosen for how they shape the API. Users read and edit on phones. Documents can run to hundreds of pages. Styling covers bold, italics and links today. More types will come later. Old app versions will stay installed. Each requirement maps to one of Meta’s three questions.<\/p>\n Then design the read path. Split the document into blocks. A block is a paragraph, a list item or a heading. The client asks for one page of blocks at a time, using a cursor from the last response. The response carries the document’s revision number. A large document loads in pieces. The client can show the first screen before the rest arrives. That answers the first question.<\/p>\n Next, the styling question. Send each block as plain text plus a list of style ranges. A range has a type, a start offset and an end offset. Here’s the shape you might write on the board:<\/p>\n Plain text plus ranges keeps the text readable by any client. A client that doesn’t understand a range can still show the words. That property sets up the third question.<\/p>\n An Android app changes only when a new version gets installed on the phone. Google’s in-app updates guide<\/a> notes that some users turn on background updates. Others need reminding to install updates at all. So the server will talk to several app versions at once. You’ve lived with this from the client side, so say it out loud in the round.<\/p>\n Google’s public, undated API design guidance on backwards compatibility<\/a> gives you the rules to cite. Old clients must keep working against newer servers. New required fields must not be added to existing requests. Fields the server already sends must keep being sent. New enum values in responses need caution, because client code may not handle them. The guide also warns about adding paging later. Old clients that expect everything in one response will think the list is complete. That’s why the cursor belongs in version 1.<\/p>\n Apply the rules to the example. Say the server adds a new span type for mentions. A version 1 client has never seen it. The contract says unknown span types render as plain text, so the words still show. The new client draws the mention chip. Nothing breaks. No forced update is needed either.<\/p>\n Your Android knowledge still belongs in the round. Use it when it changes what the API must carry. Offline editing is the clearest case. If users edit on a train, the app queues changes locally. Each queued change needs an ID and the revision it was based on. The server can then spot a retried change and a stale edit. That requirement came from the client. Yet it lands in the API.<\/p>\n The same test works for every client detail. Does it change a request, a response or a server rule? If yes, explain it. If no, give it one sentence and move on. A local cache keyed by revision passes that test. Your choice of state holder doesn’t.<\/p>\n Here’s the whole answer as you might say it across about 35 minutes. Adapt the nouns to your prompt.<\/p>\n Let me pin down requirements first, since they shape the API. Users read and edit on phones. Documents can be hundreds of pages. Styling is bold, italics and links today, with more types later. And old app versions will stay installed for months.<\/p>\n So the client never fetches a whole document. It asks for blocks, one page at a time, with a cursor. Every response carries the revision number. The first screen renders from the first page.<\/p>\n Each block is plain text plus style ranges, with a type, start and end. In the contract, unknown range types render as plain text. That lets the server add mentions later without breaking version 1 clients.<\/p>\n For edits, the client sends operations, each with an ID and a base revision. The ID makes retries safe. The base revision lets the server catch an edit made against old content. The app queues operations offline and sends them when it reconnects.<\/p>\n On the server, I’d store blocks by document and position, with a cache for hot documents. Open documents get changes pushed over a socket. Closed ones refresh on the next fetch.<\/p>\n The hardest part is two people editing one paragraph. I’d like to spend the remaining time there, unless you’d rather go deeper on paging.<\/p>\n<\/blockquote>\n The requirements are picked for their effect on the API, so none of them is filler. The paging section answers Meta’s first question in two sentences. The range format answers the second. The unknown-type rule answers the third. The edit section is where client experience turns into API fields. The server section is short and honest about its depth. The last line picks a hard problem and offers the interviewer a choice. That follows Meta’s own advice to find the hard parts and drive the discussion.<\/p>\nThe trap is drawing the inside of the app<\/h2>\n
Start from the screen and work outward to the API<\/h2>\n
{\n "revision": 412,\n "blocks": [\n {\n "id": "b17",\n "text": "Ship the beta on Friday",\n "spans": [\n { "type": "bold", "start": 0, "end": 4 },\n { "type": "link", "start": 17, "end": 23, "url": "https:\/\/example.com\/plan" }\n ]\n }\n ],\n "nextCursor": "b18"\n}<\/pre>\nOld app versions are where Android experience pays off<\/h2>\n
Bring in client architecture only where it changes the contract<\/h2>\n
A sample script for the document editor prompt<\/h2>\n
\n
Practice by shipping version 2 of a design<\/h2>\n