Pinterest System Design Interview

Pinterest's home feed picks a few hundred Pins out of billions, for one person, in a couple hundred milliseconds, and the picking is the whole system. It does not deliver posts from people you follow. A Pin behaves like a catalog item in an interest corpus, so the home feed is a recommendation problem. Pull good candidates from a vast pool and score them with a model. Then spread them out, because a raw ranker would stack ten near-duplicate kitchen photos. Candidate generation, retrieval, ranking, diversification. That funnel is the spine of nearly every Pinterest design answer, and it is what the interviewers built for a living.

This matters most if you have already done the Meta or LinkedIn feed designs. Those are delivery stories: someone posts, and the system fans that write out to followers, where the hard parts are fan-out cost, the timeline table, and celebrity hot-spots. Pinterest carries essentially none of that, with almost no write-fan-out at all. The hard part sits earlier, in retrieving the right Pins from a billions-item corpus with approximate nearest-neighbor search over embeddings, then ranking them with a multi-task model. Reuse the timeline diagram here and you have quietly built the wrong machine. Say out loud, early, that this is a recommendation funnel and not a social feed, and then build the funnel.

The Pinterest angle

Open the home-feed prompt with "candidates, then ranking," and draw the retrieval box before anything else. A weak answer starts with a posts table, a follower edge, and a fan-out worker, then spends the hour optimizing a write path that Pinterest does not really have. A strong answer starts with billions of Pins on the left and a multi-stage funnel narrowing them to a feed on the right. Parallel candidate generators feed an ANN index, then come a lightweight pre-ranker, a heavy ranker and a diversification pass. You can do this cold, with no recommendations background. What it takes is the instinct to reach for retrieval-and-ranking, because fan-out is the reflex this round punishes.

The round, and which one you get

Two different design rounds live under one name here, and which you sit depends on your track. Generalist SWE loops carry one standalone system-design round, product-flavored, 45 to 60 minutes, with maybe thirty of those spent actively designing. ML-engineer loops swap a coding round for a dedicated ML-system-design round, scoped to the team you would join, and it is the most heavily weighted interview in the loop. Pinterest doesn't publish exact round lengths and reports vary, so rehearse for an hour and be ready to land the core in thirty minutes.

• SWE design round: The leveling decider. One standalone round, product-flavored: the home feed, visual search, Related Pins. At senior level, candidates report the design score as what holds an IC15 offer at IC15; slide on it and the same offer lands at IC14. A thin design hour sinks the loop even with strong coding.
• MLE ML-system-design: The most-weighted round. A separate, team-scoped round on the full production-ML lifecycle: retrieval, ranking, feature stores, training and serving, offline metrics, online A/B. Staying abstract, hand-waving the tool trade-offs at Pinterest scale, is the common way it goes wrong.
• Round length: ~45 to 60 min. A single open-ended prompt. Reports split on whether it is closer to thirty active minutes or a full hour; Pinterest does not document the format. Drawing happens on a shared surface, so narrate as you sketch.
• New grads: Usually no design round. Entry loops skew to four coding rounds and skip a standalone design. Design weight climbs with level: it appears around mid-level and becomes decisive at senior and above.

The prompts cluster tightly. Candidates report the home feed and visual search as the two that come up most on the SWE side. Related Pins on the Pin detail page is close behind. Image upload, search and typeahead, and notifications fill out the rest. On the MLE side, a Pin or product recommendation-and-ranking system is close to guaranteed, with trust-and-safety detection and ads ranking the next tier, scoped to whatever team you are matched with. Pinterest doesn't publish a question list, so read the ordering as a rough steer toward where prep pays off.

The funnel, and the real systems it maps to

Pinterest publishes prolifically, engineering blog plus a long trail of KDD and WWW papers, so you can name the actual systems and skip the generic boxes. That specificity is the whole edge of a Pinterest design answer. Here is the home-feed funnel as Pinterest's own stages, with the systems that fill each one.

Read the path in chips. A user request fans out to parallel generators, Pixie walking the Pin-Board graph, two-tower retrieval and PinnerSage embeddings, all querying the Manas HNSW index. Their merged candidate pool passes through light-weight scoring, then the Pinnability ranker, then SSD diversification, and lands as the home feed. Retrieval pulls a coarse, recall-heavy set from an enormous corpus. Ranking is precise but expensive, so it only sees a trimmed pool. Diversification has the last word and keeps the feed varied where relevance alone would collapse into sameness.

Two retrieval paradigms, and the model arc

Pinterest runs two distinct families of retrieval, and naming both is the kind of specificity that separates a grounded answer from a generic one. The graph paradigm is Pixie and PinSage: walk or convolve over the bipartite Pin-Board graph to find related items. PinSage is the GNN behind it. It runs GraphSAGE-style localized convolutions over a graph with billions of nodes and tens of billions of edges, producing 1,024-dimensional Pin embeddings. They're computed offline over MapReduce and served for Related Pins via ANN. The embedding paradigm is the two-tower retrieval above: learn user and item vectors, search by nearest neighbor. A good Related Pins answer holds both in tension; a good home-feed answer runs several generators from both families in parallel and merges them.

The ranker has a history worth telling, because it doubles as a scaling narrative. Pinterest moved from gradient-boosted trees in the early lightweight ranker, to a two-tower DNN dot-product for pre-ranking, to today's transformer-encoder plus DCN-v2 for full ranking. The transformer added more than twenty times the latency, which forced the move from CPU to GPU serving. The realtime user-action sequence grew from the latest hundred actions toward thousands of lifelong actions. When an interviewer pushes on "how would you make ranking better," that arc, richer features and a heavier model, paid for with GPU serving and aggressive retraining, is the answer Pinterest lived.

The Pinterest angle

The subtle failure here is embedding-space drift, and the best candidates raise it unprompted. Two-tower retrieval only works if the user tower and the item tower live in the same vector space. Roll out a new model version and your freshly computed user embeddings can query an index full of item embeddings from the old model, and the dot products turn to noise. Pinterest attaches model-version metadata to its ANN hosts so user and item embeddings stay matched through staged rollouts. If your design has an offline-computed item index and an online-computed user vector, walk through what happens during a model deploy and how you keep the two halves in sync. That is a real operational hazard of embedding retrieval, and noticing it is the fingerprint of someone who has operated one.

Running a recsys design

Five phases fit a recommendation prompt cleanly. First, clarify the objective and scale before you draw: what are you optimizing, repins, clicks, time, and at what order of magnitude, hundreds of millions of users over billions of Pins. Pin one or two hard guarantees and the latency budget. Second, design candidate generation, several parallel generators, and say which signals each leans on. Third, design ranking, and split it: a cheap pre-rank pass over the full pool, then a heavy multi-task model over the survivors.

Fourth, handle diversification and serving, the blending pass that spaces results, the ANN index, the offline-versus-online split between item and user embeddings, the GPU inference path. Fifth, close on metrics and experimentation, offline measures like recall and HIT@K, then online A/B as the real arbiter, plus retraining cadence and cold-start for new users and brand-new Pins. The back half is where seniority gets read, so go deep on one stage, the ANN serving path or the ranking model, and let the rest stay brisk.

The worked designs

Five designs, each mapped onto a real Pinterest system and a prompt candidates report. Start with the home feed: it is the fullest expression of the funnel above and the prompt most likely to decide a senior SWE loop.

Each design assumes the fundamentals from the System Design course. That means the scaling playbook for read and write paths, and the toolbox for when to reach for a log, a cache, a KV store, or an index. These pages stay on the Pinterest-flavored recsys design and leave the general mechanics to those.