What Is a Product Architecture Interview at Meta (Facebook)?

Product Architecture is the common market name for Meta's product facing design round. Meta's own careers pages call it the product design interview, and they say there are two types of design interview, systems design and product design. Treat the two names as the same round.

Preparation guides describe it as a forty five minute round. You design a user facing feature end to end. Requirements, then the API, then the data model, then the architecture.

Meta does not publish a round length or a grading rubric on its public careers pages. Everything below that Meta itself does not state is marked as reported.

Quick Overview

What Meta Publishes

Meta's careers material says there are two types of design interview, systems design and product design. It says Meta tries to match you with an interviewer from a similar background.

The same page names three kinds of candidate.

• People who build complex user interfaces.
• People who build network libraries.
• People who build platform APIs for others to use.

That last detail matters for mobile engineers. Client work and library work are treated as valid design backgrounds, not as a lesser version of backend work.

Meta's published advice for the design round is short. Start from requirements, then outline a high level approach.

Pick a focus, and move between the whole picture and the details. Explore trade offs, drive the discussion, and keep it conversational.

What the Round Grades

Preparation guides describe named competencies. The two that appear most often are problem navigation and solution design.

Problem navigation is how you find and frame the real problem. Solution design is what you build once it is framed. Communication is reported alongside both.

In practice, candidates report the round rewards the same five things a client design round rewards anywhere.

• User facing requirements. Who uses it, on what device, on what network, and what must work first.
• The client server contract. Endpoints, paging, error shape, and what one screen costs in requests.
• The data model on both sides. What the server stores, and separately what the device stores.
• Failure and offline behaviour. What the user sees with no network, and what happens to a tap made offline.
• Trade offs named out loud. The option you rejected and the reason, not just the option you chose.

The example question published most often for mobile roles is an email client style feature. Fetch mail, store it locally, notify the user, and keep it readable offline. For generalist roles, guides list a feed or a ticketing product instead.

How It Differs From the Systems Design Round

The systems design round is reported to cover infrastructure pieces. A distributed cache, a message queue, a storage system. The grading centres on machines, partitions and throughput.

Product Architecture centres on a product a person uses. The client and server talk to each other, and that conversation is part of the grade. Offline states, error states and paging come up because a real screen has them.

For an iOS or Android role, candidates report the round is scoped tighter still. The backend is often assumed to exist, and the design work sits inside the app.

How the Level Mapping Works

Meta uses bands. E4 is mid level, E5 is senior, E6 is staff.

Candidate reports say design performance drives the level decision more than any other round. They also say E6 loops carry two design rounds rather than one. Meta does not publish either point, so treat both as reported.

The bar itself is the same one used across this kind of round.

• Mid level. The design works. Components are correct and the API is sensible.
• Senior. Adds what breaks, what the user sees when it breaks, what each choice costs, and the alternative you rejected.
• Staff. Adds whether to build it at all, where module and team boundaries go, how it ships, and what it costs to own.

The most common senior rejection is a correct design given at the level below. Correct components, correct API, no failure modes, no offline behaviour, no rollout, no way to switch the feature off.