CrackML by @ml.with.umang
Interview questions / ML System Design
ML System Design interview question

Design a Pinterest Recommendation System

Design recommendations for a visual discovery feed with strong long-tail and content-understanding requirements.

hardsystem designEvidence 66/1001 source reportPinterest

The 60-second answer

Define discovery goals beyond clicks: saves, long-term satisfaction, diversity, novelty, safety, and creator/ecosystem health. Generate candidates from graph/co-engagement, visual/text embeddings, boards/topics, followed creators, trending, and exploration sources.

Build the answer in this order

1
Frame the problem

Define discovery goals beyond clicks: saves, long-term satisfaction, diversity, novelty, safety, and creator/ecosystem health.

2
Design the data path

Generate candidates from graph/co-engagement, visual/text embeddings, boards/topics, followed creators, trending, and exploration sources.

3
Choose the modeling stack

Rank with user/item/context features plus multimodal content representations, correcting for exposure/popularity feedback loops.

4
Serve, evaluate, iterate

Evaluate retrieval recall, ranking quality, saves, session/long-term outcomes, diversity, tail coverage, latency, and negative feedback.

A useful interview mental model

This is the shape of a strong answer—not a script to memorize.

01Requirements
02Data
03Model / Retrieval
04Serving
05Monitor

Senior-level signal

  • Senior answers discuss visual/content cold start and exploration for new pins/creators.
  • Include multi-objective slate construction so diversity and ecosystem constraints are not bolted on after ranking.

What the interviewer is really testing

Product framing, data design, modeling choices, serving constraints, reliability, evaluation, and explicit trade-offs.

Likely follow-up questions

What changes at 10× traffic or data volume?
Which failure mode would you monitor first in production?
How would you evaluate this offline and online before rollout?

Common weak-answer patterns

  • Jumping to a model before defining the product contract.
  • Listing components without bottlenecks, metrics, or failure handling.
  • Ignoring data quality, serving latency, monitoring, and iteration.