Design feedback-driven recommender

Quick Overview

Design feedback-driven recommender evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design feedback-driven recommender

Company: Google

Role: Machine Learning Engineer

Category: ML System Design

Difficulty: hard

Interview Round: Onsite

##### Question Design an online learning or bandit-style recommendation system: at each interaction you must choose 1 item out of 4 candidates to show the user, receive immediate feedback, and update the model so that future selections improve over time. Detail model choice, feature engineering, feedback handling, exploration–exploitation strategy, and offline/online evaluation.

Quick Answer: Design feedback-driven recommender evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/ML System Design/Google
Google logo
Google
Jul 29, 2025, 8:05 AM
hardMachine Learning EngineerOnsiteML System Design
21
0

Design feedback-driven recommender

Design: Contextual Bandit Recommendation with Online Learning

You are designing an online learning recommendation system. At each user interaction:

  • You receive exactly 4 candidate items from an upstream candidate generator.
  • You must choose exactly 1 item to show the user.
  • You receive immediate feedback (e.g., click or dwell time).
  • The model must update online so that future selections improve over time.

Provide a design that covers:

  1. Model choice (with justification) for a contextual bandit setup.
  2. Feature engineering for users, items, and context, including handling cold start.
  3. Feedback handling and reward definition, including delayed/implicit signals and logging for learning.
  4. Exploration–exploitation strategy and the selection algorithm.
  5. Offline evaluation methodology and online experimentation/monitoring.

State any minimal assumptions you need (e.g., feedback semantics, latency constraints), and make your design robust to non-stationarity and scale.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • ML-specific data, model, evaluation, serving, and monitoring choices.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...