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

Design a LinkedIn Classification System

Design a production classification system for a LinkedIn-scale product problem from labels through serving and monitoring.

hardsystem designEvidence 41/1001 source reportLinkedIn

The 60-second answer

Define the class taxonomy, action taken from predictions, latency/freshness, and asymmetric error costs before collecting labels. Build representative labels with clear annotation policy, a simple baseline, feature/data pipelines, calibrated model scores, and threshold policy.

Build the answer in this order

1
Frame the problem

Define the class taxonomy, action taken from predictions, latency/freshness, and asymmetric error costs before collecting labels.

2
Design the data path

Build representative labels with clear annotation policy, a simple baseline, feature/data pipelines, calibrated model scores, and threshold policy.

3
Choose the modeling stack

Evaluate PR/ROC as appropriate plus class-wise/slice metrics, calibration, and the downstream product metric.

4
Serve, evaluate, iterate

Serve with versioned features/model, monitor drift/label delay/performance, and create human-review or fallback paths for uncertain/high-impact cases.

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 policy/label drift separately from feature/model drift.
  • Include threshold changes and calibration as versioned production decisions, not hard-coded constants.

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.