Design an ML Pin Ranking System

An MLE interviewer opens with that line, and the fastest way to lose the hour is to draw the same three boxes a SWE would: candidate generation, a ranker, a feed. The sketch is correct but incomplete; the ML-system-design round asks about everything around those boxes.

What exactly is the model predicting, and why that and not something else? Where do the labels come from, and what is wrong with them? What features feed the model, and how are they fresh at request time? How do you know the new model is better before you ship it, and how do you keep it from rotting a week after you do? Stay at the box-diagram altitude and you sound like someone who has seen a recsys slide but never trained one.

So scope it as a lifecycle with a spine you can defend. The system turns a user and a request context into a ranked list of Pins. It trains a multi-task model on engagement logs and serves it behind a retrieval funnel under a tight latency budget. It measures the model offline, then online, and retrains often enough to keep up with how people's taste moves. Five moving parts, training and serving and metrics knit together, and the round walks all five. The recommendation funnel itself, candidate generation into ranking into diversification, is the same one the home-feed design builds; here it is one stage inside a bigger loop, and the loop is the subject.

The Pinterest angle

The thing that separates this round from the SWE feed design is that training, serving, and metrics are all in scope, and a strong candidate keeps returning to them. The SWE version can stop at "a transformer ranks the candidates." The MLE version has to say what the transformer is trained on, how the training labels are biased, and how you correct for that. It covers how offline-job features stay consistent with live ones. And it covers how you measure a lift before an A/B test confirms it, and how often the whole thing is retrained.