Data & Machine Learning Interview Coach

Ace ML System Design & Data Architecture Loops.

Master Machine Learning system design, high-throughput feature pipelines, recommendation engines, and LLM/RAG serving architectures.

Worked design / 01

Design a video recommendation feed.

An original interview walkthrough with hypothetical requirements. The numbers below are planning assumptions, not ClawPad benchmarks or a description of a real company’s system.

The prompt

“Help viewers discover videos they will find worth watching. How would you build and evaluate the recommendation system?”

Scope the home feed for signed-in adults in one region. Exclude ads, search, video delivery and moderation model design. Moderation eligibility is an input the feed must always respect.

01 / Define the target

Agree on value before choosing a model.

Use satisfied viewing sessions per active user as the business goal. For an initial measurable proxy, define a qualified watch as at least 30 seconds of a video lasting at least 60 seconds. Count sessions with at least one qualified watch, while checking hides, reports and satisfaction surveys. Watch time alone can reward content people regret watching.

Daily active users
1 million
Feed requests per user per day
10
Eligible video catalog
10 million
Server response target
p95 ≤ 200 ms

p95 means 95% of requests should complete within the target. Measure this over a stated window and traffic mix; it is a target here, not a measured result.

Traffic. 1,000,000 × 10 = 10 million requests/day. Divide by 86,400 seconds/day for about 116 requests/second on average. Assume a 10× peak, about 1,160 requests/second.

Impression logs. At 20 logged item impressions per request, allow 200 million events/day. At 200 bytes/event, that is 40 GB/day and 1.2 TB for 30 days in decimal units, before replication, indexes and extra click/watch events. Served items are not necessarily viewed; log actual exposure separately.

Item vectors. 10 million × 128 dimensions × 4 bytes = 5.12 GB of raw float32 vectors. Index overhead, metadata, replicas and model memory are additional. This is not the memory size of the complete serving system.

Rework these assumptions in the capacity math calculator. A 10× traffic assumption is a planning scenario, not evidence of the real peak.

02 / Draw the path

Retrieve broadly. Rank a bounded set.

Scoring every video per request would mean up to 11.6 billion user–item scores/second at the assumed peak. Retrieving at most 1,000 candidates bounds that to about 1.16 million ranking scores/second before filtering. Those are item scores, not model requests; batch candidates per feed request.

Online request flow, read in numbered order
  1. 1Request

    User ID, language and recent session activity.

  2. 2Retrieve

    Find up to 1,000 candidates from embeddings, recent items and popular items.

  3. 3Rank

    Score eligible candidates using user, item and context features.

  4. 4Re-rank & serve

    Apply diversity and eligibility rules; return up to 20 videos.

Feedback loop

Exposure, click and watch events → validated event log → time-correct training data → model validation → versioned model and matching item index → online retrieval and ranking.

Keep item embeddings and their approximate nearest-neighbor index in a serving tier. Batch-read user and item features from an online feature store. Cache a short-lived, per-user candidate pool; reapply current eligibility rules on every response. Never share a personalized cache entry across users.

Allocate an initial 20 ms for routing and context, 40 ms for retrieval, 30 ms for feature reads, 60 ms for ranking, and 20 ms for final filtering and serialization. This totals 170 ms, leaving 30 ms of the 200 ms deadline. These are engineering budgets, not independently measured percentiles; validate end-to-end tail latency under load.

03 / Protect the signal

Make training examples match serving reality.

Start with a popularity-by-language baseline. Then train a two-tower retrieval model: one encoder represents the viewer’s past activity, the other the video’s metadata and content. Train similar embeddings for qualified-watch pairs, with sampled negatives. A non-selected item is not necessarily disliked; compare negative-sampling choices on held-out retrieval quality.

Rank retrieved candidates with a gradient-boosted tree model using recent topic affinity, item age, historical quality and session context. Begin with binary cross-entropy for qualified-watch prediction. If negative examples are downsampled, weight training examples appropriately and check probability calibration on the natural exposure distribution. Add model complexity only when it beats the simpler baseline within the latency budget.

  • Capture the decision. Log request ID, event ID, pseudonymous user ID, exposed item, position, event time and model version. Deduplicate retried events. Join outcomes only after a fixed label window, such as 24 hours; pending outcomes are not negatives.
  • Prevent future information. Build each training row from features available at that impression’s time. A video’s eventual watch count or the viewer’s next click would leak the label. Recompute aggregates with time boundaries and fit preprocessing only on training data.
  • Test the right time period. Train on earlier dates, validate on later dates and reserve the latest period for a final test. Also report new-user and new-item results; repeated users across time splits are not automatically leakage.
  • Keep pipelines aligned. Reuse feature definitions, record freshness and compare served features with their offline reconstruction. Retrain daily initially; update recent-session features within a minute if measurements justify the cost. Version the retrieval encoders and index together.

Minimize retained identifiers and agree on retention and deletion rules. Propagate deleted users and removed videos into logs, features, indexes and future training inputs; do not keep them indefinitely just because they may help a model.

04 / Prove the benefit

Offline gains earn an experiment, not a launch.

Offline selection

Measure retrieval Recall@1,000, the fraction of held-out relevant items retrieved. Measure ranking NDCG@20, normalized discounted cumulative gain, which rewards relevant items near the top. Compare calibration, catalog coverage and performance for new users and items against the same baseline and time window.

Online decision

Assign users consistently to control or treatment. Compare qualified sessions per active user, alongside hide/report rate, retention, latency and serving cost. Choose a minimum detectable effect and calculate the sample size from baseline variance before the test. Run through complete weekly cycles and report uncertainty.

Historical logs reflect the old policy’s exposure and position bias. Offline metrics cannot establish the new policy’s causal effect. Reserve a small, bounded exploration stream among eligible items and log its selection probabilities; any bias correction needs sufficient overlap and checks for unstable weights.

Shadow traffic checks serving behavior without changing recommendations. A small canary checks operational safety. A properly powered experiment tests user benefit. None substitutes for the others, and there is no universal test duration without traffic and variance estimates.

05 / Handle the edges

A useful feed must survive missing information.

New viewer
Use chosen interests, language and a diverse popular feed. Adapt from session activity. Do not invent a personal history or require unnecessary sensitive attributes.
New video
Retrieve from content metadata before interaction history exists. Give eligible new items bounded exploration exposure and track coverage so popularity does not become permanent exclusion.
Feature or model timeout
Stop work at the deadline. Use a compatible model that was validated for missing features, or serve an eligible popular list. If current eligibility cannot be verified, omit the item, even if the feed becomes shorter.
Bad release or stale index
Monitor error rate, fallback rate, feature freshness, latency and outcome changes by segment. Roll back the model, feature schema and index as a compatible versioned set. Drift is a reason to investigate, not automatic permission to retrain and ship.

The central tradeoff. Approximate retrieval saves compute but can miss useful candidates; ranking cannot recover items it never sees. Larger candidate pools may improve recall while increasing feature traffic and latency. Start with the 1,000-candidate cap, measure both quality and cost, then change one constraint at a time.

Rehearse the follow-up

“What would you change if the traffic increased tenfold?”

Recalculate the ranking and feature-read load. Load-test batching, cache behavior and replicas before choosing sharding or a more complex model. Explain which quality or freshness tradeoff you would accept and how you would measure it.

ML System Design

How Staff & Principal ML Engineers structure designs.

Navigate the complex interplay between data pipelines, model training, and real-time inference SLAs.

  1. 01

    Business Objective & Framing

    Map the business problem to ML paradigms: Ranking, Classification, Regression, Vector Search, Anomaly Detection, or Reinforcement Learning.

  2. 02

    Data Ingestion & Feature Engineering

    Design streaming vs batch ingestion pipelines, point-in-time correct feature stores (Feast, Hopsworks), embedding representations, and missing data imputation.

  3. 03

    Model Selection & Loss Formulation

    Select model architectures (GBDTs, Two-Tower Transformers, GNNs) with objective loss functions, negative sampling strategies, and regularization bounds.

  4. 04

    Offline vs Online Evaluation

    Establish offline metrics (AUC-ROC, NDCG@K, MRR, LogLoss) and online A/B testing frameworks with sample size calculations, power analysis, and cannibalization checks.

  5. 05

    Serving Architecture & Low-Latency Inference

    Architect low-latency model inference: TensorRT/ONNX acceleration, multi-stage retrieval + heavy ranking cascades, model quantization (INT8/FP16), and caching.

  6. 06

    MLOps, Monitoring & Model Drift

    Design continuous retraining loops, feature drift (PSI/KL divergence) detection, shadow deployment, automated fallback heuristics, and data lineage tracking.

Core ML Systems

Production ML architectures covered.

From large-scale recommendation systems to real-time fraud detection and RAG.

Recommendation Systems

Video / E-Commerce Feed Ranking

Two-tower embedding retrieval, multi-task ranking (click + watch time), and exploration vs exploitation (LinUCB).

Generative AI & RAG

Enterprise Semantic Search Engine

HNSW vector index partitioning, hybrid BM25 + dense retrieval, reranking models, and context compression.

Streaming & Fraud

Real-Time Payment Anomaly Detector

Kafka event streaming, Flink sliding-window aggregations, low-latency GBDT inference, and automated quarantine rules.

Data Engineering

Petabyte-Scale Data Warehouse Lakehouse

Medallion architecture (Bronze/Silver/Gold), Iceberg table partitioning, CDC change data capture, and ETL pipelines.

Data & ML FAQ

Frequently asked questions about ML interview prep.

How ClawPad sharpens your machine learning and data engineering answers.

How does ClawPad assist in Machine Learning System Design interviews?

ClawPad provides end-to-end ML architectures covering data pipelines, feature stores, loss function formulation, two-stage retrieval/ranking pipelines, and online A/B testing infrastructure.

Does ClawPad cover Data Engineering and SQL questions?

Yes. The Data & ML pack includes data warehouse architectures, partitioning/sharding strategies in BigQuery/Snowflake, Spark stream processing, and complex SQL reasoning.

Can ClawPad help with GenAI and LLM System Design?

Yes. ClawPad includes specialized patterns for RAG pipelines, vector database sharding, hybrid lexical/semantic search, context window optimization, and fine-tuning vs prompting trade-offs.

How does ClawPad handle ML metric trade-offs?

Guidance highlights precision vs recall tradeoffs, latency budgets (e.g. 50ms candidate generation vs 100ms ranking), and compute cost scaling.

Step into your next ML interview prepared

Practice machine learning system design with structured guidance.

Download ClawPad