Video / E-Commerce Feed Ranking
Two-tower embedding retrieval, multi-task ranking (click + watch time), and exploration vs exploitation (LinUCB).
Master Machine Learning system design, high-throughput feature pipelines, recommendation engines, and LLM/RAG serving architectures.
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.
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.
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.
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.
User ID, language and recent session activity.
Find up to 1,000 candidates from embeddings, recent items and popular items.
Score eligible candidates using user, item and context features.
Apply diversity and eligibility rules; return up to 20 videos.
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.
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.
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.
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.
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.
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.
“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.
Navigate the complex interplay between data pipelines, model training, and real-time inference SLAs.
Map the business problem to ML paradigms: Ranking, Classification, Regression, Vector Search, Anomaly Detection, or Reinforcement Learning.
Design streaming vs batch ingestion pipelines, point-in-time correct feature stores (Feast, Hopsworks), embedding representations, and missing data imputation.
Select model architectures (GBDTs, Two-Tower Transformers, GNNs) with objective loss functions, negative sampling strategies, and regularization bounds.
Establish offline metrics (AUC-ROC, NDCG@K, MRR, LogLoss) and online A/B testing frameworks with sample size calculations, power analysis, and cannibalization checks.
Architect low-latency model inference: TensorRT/ONNX acceleration, multi-stage retrieval + heavy ranking cascades, model quantization (INT8/FP16), and caching.
Design continuous retraining loops, feature drift (PSI/KL divergence) detection, shadow deployment, automated fallback heuristics, and data lineage tracking.
From large-scale recommendation systems to real-time fraud detection and RAG.
Two-tower embedding retrieval, multi-task ranking (click + watch time), and exploration vs exploitation (LinUCB).
HNSW vector index partitioning, hybrid BM25 + dense retrieval, reranking models, and context compression.
Kafka event streaming, Flink sliding-window aggregations, low-latency GBDT inference, and automated quarantine rules.
Medallion architecture (Bronze/Silver/Gold), Iceberg table partitioning, CDC change data capture, and ETL pipelines.
How ClawPad sharpens your machine learning and data engineering answers.
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.
Yes. The Data & ML pack includes data warehouse architectures, partitioning/sharding strategies in BigQuery/Snowflake, Spark stream processing, and complex SQL reasoning.
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.
Guidance highlights precision vs recall tradeoffs, latency budgets (e.g. 50ms candidate generation vs 100ms ranking), and compute cost scaling.