Frontend system design interview questions, and who asks them

The prompt can be the same. “Design a news feed” in a backend round means capacity estimates, a database schema and fan-out for accounts with millions of followers. In a frontend round, as GreatFrontEnd’s playbook lays it out, it means the feed’s API, pagination, posting and reacting, and how the page performs and reads with a screen reader. Its comparison comes down to four changes.

• The server is a box. You treat it as a black box unless the question needs more. The Front End Interview Handbook says frontend candidates probably do not have to design a database schema or choose between SQL and NoSQL.
• The data model is the client’s state. What the page holds, which component owns it, and which part came from the server and which from the person.
• No capacity estimate. GreatFrontEnd calls it usually not required. The numbers that do come up are per page: how many items a list holds before it slows down, and the Core Web Vitals targets, such as content showing within 2.5 seconds and a response to a tap within 200 milliseconds, which frontendprep.io lists.
• The deep dives are about the person. Speed, what the user sees at each moment, the network between client and server, and accessibility, where the backend round goes deep on scale, reliability and consistency.

Companies say the same in their own words. Amazon’s prep page lists the objectives it looks for: usability, performance, user experience, accessibility, security and scalability. Google’s guide puts its design topics where the front end and the back end meet: web apps, mobile apps and API design.

Coaching guides agree on the order: requirements, a design, the data and the API, then the deep dives. They differ a little on the minutes. GreatFrontEnd’s framework gives no more than 10% of the session to requirements, about 20% to the architecture, 10% to the data model, 20% to the API, and 40% to optimizations and deep dives. In 45 minutes that is roughly 4, 9, 4, 9 and 18 minutes. Juntao Qiu’s 45-minute plan is close: 5 minutes of questions, 5 for a mockup, 10 each for the data and the API, and 15 for optimizations.

The usable time is shorter than the booking. For Meta’s product architecture round, Hello Interview puts it at about 35 minutes.

What candidates draw is simpler than a backend diagram. Guides describe a rough wireframe of the screen first, then rectangles for the parts of the client (the view, a store, a layer that talks to the server, the server as one box) joined by arrows labelled with the data that flows. The fields of each entity go under the component that owns them, and the API goes in a small table of method, path, parameters and response. GreatFrontEnd names Excalidraw and diagrams.net as the tools you may be given. Sometimes the interviewer brings the picture: a Coinbase candidate reports being shown a screenshot of a trading screen and asked for its architecture.

GreatFrontEnd’s guide to question types splits the round in two. An application question asks for a whole product, such as a news feed, a chat or a store. It feels like a general design round, but the work happens inside the client, and the product decides the deep dive: search engines and load speed for a store, live updates for a chat.

A component question asks for one piece that other teams will use, such as an autocomplete, a data table or a modal. Here the API is the component’s props and events, you may write a little code to show its structure and state, and you should expect questions on keyboard use, focus and screen readers, and on how other teams change its look. The last group below holds these.

Data that arrives without being asked for: a reply streaming in, messages, scores, prices. The deep dives are about order, dropped connections and keeping the page fast while it changes.

Pages people read and edit: feeds, boards, documents, files. The deep dives are about the shape of the data on the client, long lists, and what the person sees when the server says no.

One piece other teams build with. Expect to be asked about its API, its states, and how it works with a keyboard and a screen reader.

The sources agree on most of the list. GreatFrontEnd’s common mistakes start with answering before asking: jumping into a design without clarifying the question. The rest are about how you work. Approaching it without a structure, insisting there is one best solution, going quiet, going down a rabbit hole, and naming techniques you cannot explain.

Drifting to the backend is a frontend-specific one. GreatFrontEnd warns that database schemas, load balancers and service layouts eat the time, and Prepfully’s guide to Meta’s frontend round lists talking about sharding or infrastructure before the frontend architecture is defined.

FrontendAtlas adds the ones that show in the design itself: no loading, empty or error states, accessibility and focus left out, unclear ownership of state, and performance fixes with no named bottleneck. An interviewer writing about the round calls starting to code straight away a red flag.

GreatFrontEnd’s introduction also warns that general system design material will mislead your preparation. A backend answer moved over unchanged spends the time on the parts the interviewer has set aside.

Some companies ask the same kind of question and expect both halves. Stripe’s full-stack design round, as GreatFrontEnd describes it, has three parts: a data model written as TypeScript interfaces, a handler function against endpoints you cannot see inside, and a component drawn on a whiteboard. Its frontend design round is client-only.

At OpenAI, frontend loops have been moving toward full stack, according to Design Gurus. On a chat or a playground, interviewers are reported to expect both the client architecture and the contract with the backend: how the reply streams, where the state lives, and what happens when the model is slow.

Meta’s product architecture round is mostly backend, with the screens and the API added. Hello Interview reports that about 15% of its candidates were asked for only the screens and the API, most often for a news feed. Atlassian’s full-stack guide keeps the same design interview as its front-end loop and adds a separate craft interview. For LinkedIn’s chat question, the Front End Interview Handbook advises asking which server responsibilities the interviewer wants to discuss.

That advice holds everywhere, because no source gives a split of the time between client and server. In a full-stack round, expect the same question plus the tables behind the API, the API’s errors and retries, and where state lives on the server. Ask early which half the interviewer wants to see more of.

Pick one question above, set a 45-minute timer and say every step out loud. Sketch the screen before you draw a box. Name the state each component owns and the calls it makes. Get every requirement working on the board by about minute 25, then go deep in two places and say what each choice gave up.

Every “Practice this one” link opens a practice system design interview on Star Interview with that question chosen. To get a frontend question without choosing one, set up a system design round and choose Frontend or full stack as the kind of system. The interviewer asks about components, state, the network and what the user sees. The report gives feedback and a practice-level assessment; it does not predict an employer’s decision.

All 25 questions, with their briefs, are also in the frontend system design practice library. For the backend round, read 62 system design interview questions, and who asks them.