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

Design People You May Know

Design an ML system that recommends people a user may want to connect with.

hardsystem designEvidence 41/1001 source reportMeta

The 60-second answer

Define the objective and constraints first: useful connection formation, privacy/safety, latency, and avoiding spammy recommendations. Generate candidates from graph proximity, shared context, contacts/groups, and embedding retrieval; apply eligibility/privacy filters before ranking.

Build the answer in this order

1
Frame the problem

Define the objective and constraints first: useful connection formation, privacy/safety, latency, and avoiding spammy recommendations.

2
Design the data path

Generate candidates from graph proximity, shared context, contacts/groups, and embedding retrieval; apply eligibility/privacy filters before ranking.

3
Choose the modeling stack

Rank with graph, profile, interaction, and freshness features while correcting for exposure bias and cold-start users.

4
Serve, evaluate, iterate

Evaluate candidate recall plus ranking quality, connection acceptance/quality, hides/reports, diversity, and long-term network health.

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 graph leakage, feedback loops, privacy boundaries, and exploration for sparse users.
  • Separate candidate-generation recall from ranker quality and design safe fallbacks when online features are stale.

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.