The Designs Compared

Each design, reduced to the four decisions that shape it most. Read across a row to recall a design; read down a column to see how the same decision varies.

Seeing them together shows that the hard part differs every time, even when the architecture looks similar.

• In an interview, naming the hard part early is what earns the deep-dive time.

Recommendations, search, video search, video recommendations, events, similar listings, feed and people-you-may-know all follow the same shape:

• candidate generation from several cheap sources (embeddings, filters, graph, co-occurrence);
• a light ranker if candidates are many;
• a heavy ranker predicting one or more targets;
• re-ranking for list-level rules (diversity, policy, availability).

What changes is where candidates come from: an embedding index (products, videos), filters (events: place and time), the graph (people), the user's connections (feed).

Recognising the shape frees attention for what is specific.

• In an interview, draw the cascade in a minute, then spend the time on the candidate sources and labels that make this problem different.

Fraud, ad clicks, moderation and delivery time score a single item per request, then a decision layer acts:

• a calibrated probability or a percentile;
• thresholds or bands set from costs and capacity (fraud review, moderation queues);
• rules that override the model where policy requires;
• a fallback when the model cannot answer.

Here the model is only half the system: the decision layer decides what the prediction is worth.

• Interviewers expect thresholds tied to costs, and capacity limits for human review.

Forecasting and imagery blurring process everything in batch, and so do the heavy parts of people-you-may-know and video ingestion:

• throughput and total job time matter, not per-request latency;
• output validation before anything is used (forecasts paused on wild jumps; images audited);
• partitioned, re-runnable pipelines (module 8) and checkpointed workers (module 15);
• a fallback to the previous run's output if a run fails.

Batch systems fail differently: not slowly, but by producing a whole bad output at once.

• Validation gates on the output are their equivalent of a canary release.

Visual search, video search, similar listings, the retrieval stage of recommendations, and graph embeddings for people all learn embeddings:

• contrastive training on pairs that should be close (photo and product; query and watched video; listings in one session; connected people);
• negatives that teach the right distinctions (same brand different size; same market; non-connected people);
• nearest-neighbour indexes, rebuilt with every model change;
• cold start by content features or by averaging neighbours.

Most of the design effort goes into what counts as a positive pair and which negatives to use; the network architecture matters less.

In the first minute of a new question, ask four things:

• one item or a list? A list means retrieve-then-rank; one item means score-then-decide;
• now or in advance? Live means a latency budget; in advance means a batch pipeline;
• where do labels come from, and when? This usually reveals the hard part (delay, bias, cost);
• what does a mistake cost, and to whom? This sets the metric, the threshold and the guardrails.

Then pick the closest of the fifteen and adapt it out loud.

Interviewers vary the domain to stop memorised answers; the four questions transfer to any domain.

• 'This is like the event design, because every job posting is new and expires' is a strong opening.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.