Comment-Prediction ML System (will_user_comment_on_posts)

Staff-level MLE system design: build an end-to-end ML system exposing `will_user_comment_on_posts(user_id, [post_ids])` that scores each post by the probability the user would comment, used as a signal in home-feed ranking. Covers modeling, features, class imbalance, and low-latency batched serving. Requirements Design an end-to-end ML system exposing a single call: will_user_comment_on_posts(user_id, [post_id, ...]) -> [float, ...] Input: one user id and a list of post ids. Output: one floating-point score per post id — the belief that, if exposed to the post, the user would comment on it. Context: when a user opens their Reddit home feed, the system has ~1,000 candidate posts to rank for them. This call's scores are one component of the home-feed ranking. The interviewer wants a full pipeline from modeling to serving — not just the model, but training data, features, model choice, serving topology, and how the scores feed the ranker. This is a Staff-level MLE system-design round, in the same engagement-prediction family that feeds the post / comment ranking system. Notes Frame comment-probability as a binary classification / CVR-style problem (label = commented after exposure). Be explicit about how exposure-without-comment forms the negative class and how to handle the heavy positive/negative imbalance (commenting is rare). Feature groups the interviewer expects: user features (history, subreddit affinity, recent activity), post features (subreddit, author, content embedding, age), and user×post cross features. Discuss where each lives and how fresh it must be (offline store vs streaming aggregation). Serving: scores must be produced for ~1,000 posts per home-feed request under tight latency. Batch the candidate posts into a single model forward pass; fetch user features once per request and post features in a batched multi-get. This mirrors the feature-store plus online-inference split discussed in the ML-infra rounds. The output is a probability used as one ranking signal, not the final order — calibration matters when the score is combined with other heads. Standard end-to-end discussion points: offline training pipeline, logging of features / scores / outcomes for the next training cycle, A/B testing the model, and cold-start for new users and posts. Role-dependent scope: for Software Engineer (non-MLE) roles, treat the model itself as a black box and focus the design mainly on the feature store and the inference / serving path, rather than on modeling depth (loss, negative sampling, calibration). Preparation Rehearse the binary-classification framing for "will the user comment" — label definition, negative sampling, class imbalance, and calibration — out loud in under 3 minutes. Draw the serving path: request → candidate posts → batched feature fetch (user once, posts multi-get) → single batched forward pass → scores → ranker. Prepare a feature-group table (user / post / cross) with freshness and storage for each, reusing the feature-store online/offline split.