← Pinterest Interview Insights

Pinterest·Machine Learning Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
May 2026

Summary

Pinterest MLE system design round focused entirely on building a CTR prediction system from scratch. Pretty deep dive, covered everything from feature stores to model architecture choices to serving infrastructure. Left feeling like I'd done okay on the ML side but probably rushed through the serving and experimentation bits.

Questions Asked (8)

Q1

Design an end-to-end ad click-through rate prediction system that takes a (user, ad, context) tuple at request time and returns a click probability used to rank candidate ads.

System DesignTechnical Trade-offs
Author's notes

This is the whole interview, not just one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then walk through the ML lifecycle: data collection, feature engineering, model training, serving, and monitoring. Emphasize trade-offs between latency, accuracy, and scalability, and how you would handle cold start and real-time constraints.

Pro tip: Pinterest's visual content and user engagement patterns mean features like image embeddings and board context are crucial; mention how you'd incorporate them without blowing up latency.

1. Clarify Requirements and Constraints

Ask about scale (QPS, number of users/ads), latency budget (e.g., <100ms), and business metrics (CTR, revenue). Confirm if it's a real-time bidding scenario or internal ranking.

2. Data and Feature Engineering

Outline data sources: user logs, ad metadata, context (time, device, page). Describe features: user demographics, historical CTR, ad embeddings, context features, and cross features. Discuss handling of categorical variables and feature hashing.

3. Model Selection and Training

Choose a model (e.g., logistic regression, GBDT, or deep neural networks like Wide & Deep). Explain training pipeline: offline training on historical data, validation, and calibration. Mention handling class imbalance and negative sampling.

4. Serving and Inference

Design a low-latency serving architecture: precompute ad embeddings, use a feature store for real-time features, and deploy model on a scalable service (e.g., TensorFlow Serving). Discuss caching and fallback strategies.

5. Monitoring and Iteration

Set up monitoring for prediction drift, latency, and CTR. Plan for A/B testing, retraining frequency, and feedback loops to continuously improve the model.

Key Points to Mention

  • Handling cold start for new users and ads via content-based features or exploration.
  • Real-time feature computation and feature store integration to avoid training-serving skew.
  • Model calibration to ensure predicted probabilities are accurate for ranking.
  • Scalability considerations: distributed training, model quantization, and horizontal scaling.
  • Trade-offs between model complexity and latency (e.g., using a two-stage ranking system).
  • Privacy and compliance (e.g., GDPR) when using user data.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you construct training data for CTR prediction, and how do you handle the delayed feedback problem?

Data ModelingTechnical Trade-offs
Author's notes

Impressions as negatives, clicks as positives, pretty standard setup.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by outlining the end-to-end pipeline for constructing CTR training data, from logging raw events to feature engineering and labeling. Then dive into the delayed feedback problem, explaining its impact and presenting both practical and advanced solutions like wait windows, importance weighting, and sequential modeling. Emphasize trade-offs and how you would validate the approach.

Pro tip: At Pinterest, where user actions like saves and clicks can be delayed by hours or days, it's crucial to balance label freshness with accuracy. Mention that you'd monitor the delay distribution and consider using a multi-task model that jointly predicts immediate and delayed actions to capture both short-term and long-term user interest.

1. Data Collection and Logging

Describe how to log user impressions, clicks, and other engagement events with timestamps, ensuring that all relevant context (user, item, context features) is captured. Highlight the importance of a unique request ID to join delayed labels.

2. Feature Engineering

Explain how to compute features from historical data, including user profiles, item attributes, and interaction history. Mention the need for point-in-time correctness to avoid label leakage.

3. Labeling and Delayed Feedback

Discuss how to assign labels (click/no-click) and the challenge of delayed clicks. Introduce strategies like using a fixed wait window, modeling the delay distribution, or using importance weighting to correct for bias.

4. Handling Delayed Feedback in Training

Detail specific techniques: (a) wait window with positive-unlabeled learning, (b) delayed feedback models (e.g., exponential delay distributions), (c) sequential models that incorporate time since impression, and (d) multi-task learning to predict both immediate and delayed actions.

5. Evaluation and Iteration

Explain how to evaluate the impact of delayed feedback handling, using offline metrics (e.g., AUC, calibration) and online A/B tests. Emphasize monitoring and iterating on the delay assumptions.

Key Points to Mention

  • Point-in-time correctness to prevent data leakage
  • Wait window trade-off: shorter windows reduce delay but introduce label noise
  • Importance weighting to correct for delayed feedback bias
  • Modeling delay distribution (e.g., exponential, survival analysis)
  • Multi-task learning to predict immediate and delayed actions
  • Online A/B testing to validate offline improvements

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Walk through your feature engineering strategy: what user, ad, and context features would you use, and how would you handle cross features?

System DesignData Modeling
Author's notes

Felt okay here.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by framing the problem: define the prediction task (e.g., ad CTR) and the data available. Then systematically cover user, ad, and context features, explaining how each is engineered and why it matters. Finally, discuss cross features, including how you generate, select, and handle them at scale, with attention to online-offline consistency.

Pro tip: Emphasize that feature engineering is iterative and tied to business metrics; mention how you validate features offline and monitor them online to catch drift. Also, highlight the importance of feature freshness and low-latency serving for real-time ad ranking.

1. Clarify the problem and data

Ask clarifying questions to understand the prediction task (e.g., CTR prediction), the scale of data, and available signals. Define success metrics and constraints like latency and freshness.

2. User features

Describe user features such as demographics, historical engagement (e.g., past clicks, saves), and long-term interests. Explain how to compute them (e.g., aggregations over time windows) and handle sparsity.

3. Ad features

Cover ad-specific features like ad content (text, image embeddings), advertiser quality, historical performance (CTR, conversion rate), and targeting criteria. Discuss how to encode categorical features and handle new ads.

4. Context features

Include context features such as time of day, device type, page context (e.g., search vs. home feed), and session-level signals. Explain how these capture situational relevance.

5. Cross features and engineering strategy

Explain how to create cross features (e.g., user-ad interactions, user-context, ad-context) using techniques like hashing, embeddings, or tree-based interactions. Discuss selection (e.g., feature importance), dimensionality reduction, and online serving considerations.

Key Points to Mention

  • Feature engineering should be driven by the problem and business metrics, not just data availability.
  • Use time-window aggregations for user and ad historical features, with careful handling of data leakage.
  • For cross features, consider hashing or embedding-based methods to manage high cardinality and sparsity.
  • Ensure online-offline consistency: features computed in batch must match those served in real-time.
  • Monitor feature drift and importance over time; retrain and update features as needed.
  • Leverage Pinterest-specific signals: e.g., pin saves, board follows, visual embeddings for ads.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

How do you ensure consistency between your offline training features and online serving features?

System DesignTechnical Trade-offs
Author's notes

Feature store question basically.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by acknowledging the training-serving skew problem and its impact on model performance. Then describe a systematic approach using a shared feature engineering library, a feature store, and rigorous validation. Emphasize trade-offs between consistency and latency, and how you would monitor and mitigate skew in production.

Pro tip: Highlight the importance of logging online features and using them for offline training (logging-based training) to eliminate skew, but also discuss the trade-offs like increased storage and potential latency. Mention that at Pinterest, where scale is massive, you'd need to balance consistency with performance, possibly using a hybrid approach.

1. Define Consistency Requirements

Clarify what consistency means for the use case: exact same transformations, same data sources, and same timing. Discuss the impact of skew on model performance and business metrics.

2. Use a Shared Feature Engineering Library

Implement a single codebase for feature transformations used both offline and online, ensuring identical logic. This reduces duplication and human error.

3. Leverage a Feature Store

Adopt a feature store that serves features consistently for training and inference, with point-in-time correctness to avoid data leakage. It handles offline/online storage and synchronization.

4. Validate and Monitor

Continuously compare offline and online feature distributions, set up alerts for drift, and use shadow deployment or A/B tests to detect skew. Log online features for offline analysis.

5. Address Trade-offs

Discuss trade-offs between consistency, latency, and cost. For example, exact consistency may require online computation of complex features, increasing latency; consider approximations or precomputation where acceptable.

Key Points to Mention

  • Training-serving skew and its consequences
  • Feature store (e.g., Feast, Tecton, or custom) for consistency
  • Point-in-time correctness to prevent data leakage
  • Logging online features for offline training (logging-based training)
  • Monitoring and alerting for feature drift and skew
  • Trade-offs: latency vs. consistency, cost vs. accuracy

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q5

How would you set up the model serving infrastructure, including deployment strategies for safely rolling out new model versions?

System DesignA/B Testing & Experimentation
Author's notes

Shadow deploys and canary rollouts, model registry, rollback triggers.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements like scale, latency, and model update frequency, then propose a layered serving architecture (e.g., model registry, serving layer, canary infrastructure). Focus on safe rollout strategies such as shadow deployment, canary releases, and A/B testing, emphasizing monitoring and rollback mechanisms.

Pro tip: At Pinterest, models often serve billions of daily requests, so highlight how you'd balance low-latency serving with safe experimentation—e.g., using a feature flag system to decouple model deployment from code releases. Also, mention the importance of logging prediction data for offline evaluation and drift detection.

1. Clarify Requirements and Constraints

Ask about scale (QPS, latency SLOs), model types (real-time vs. batch), update frequency, and existing infrastructure. This ensures your design meets Pinterest's specific needs.

2. Design Serving Architecture

Propose a model registry for versioning, a serving layer (e.g., TensorFlow Serving, Triton, or custom microservice) with autoscaling, and a feature store for consistent online/offline features. Mention caching and batching for efficiency.

3. Implement Safe Rollout Strategies

Describe shadow deployment (mirror traffic to new model without affecting users), canary release (route a small % of traffic), and A/B testing (randomized controlled trials). Emphasize gradual rollout with automated rollback on metric degradation.

4. Set Up Monitoring and Observability

Define key metrics (latency, error rates, prediction distribution, business KPIs) and set up alerts. Use tools like Prometheus, Grafana, and logging for debugging. Include drift detection for model performance.

5. Plan for Iteration and Rollback

Outline a process for promoting models from staging to production, including automated tests, approval gates, and a rollback plan. Mention the importance of versioned artifacts and reproducible deployments.

Key Points to Mention

  • Model registry (e.g., MLflow, SageMaker Model Registry) for versioning and lineage
  • Canary deployment with traffic splitting and automated rollback based on metrics
  • Shadow deployment for safe testing without user impact
  • A/B testing framework with proper randomization and statistical significance
  • Monitoring for model drift, latency, and business metrics
  • Infrastructure considerations: autoscaling, GPU/CPU optimization, and caching

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q6

What metrics would you use to evaluate the model offline versus online, and how do you reconcile a mismatch between the two?

Product Analytics & MetricsA/B Testing & Experimentation
Author's notes

NE and calibration offline, CTR lift and revenue metrics online.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining offline metrics (e.g., AUC, precision@k, NDCG) and online metrics (e.g., CTR, engagement, retention) relevant to Pinterest's recommendation and ranking systems. Then explain how to diagnose mismatches by analyzing data distribution shifts, metric alignment, and system interactions, and propose iterative improvements to bridge the gap.

Pro tip: Emphasize that offline metrics are proxies, not ground truth; always validate with online experiments and consider business impact. Mention that at Pinterest, online metrics like saves, closeups, and long-term user satisfaction are critical.

1. Define Offline Metrics

Select offline metrics that correlate with the online objective, such as ranking metrics (NDCG, MAP) for retrieval, or calibration and AUC for prediction. Ensure they are computed on a representative validation set.

2. Define Online Metrics

Identify online metrics that directly measure user behavior and business goals, such as CTR, saves, repins, time spent, and retention. Use A/B tests to measure these metrics reliably.

3. Diagnose Mismatch

Investigate causes of mismatch: data leakage, distribution shift (e.g., new users, seasonal trends), feedback loops, or metric misalignment. Check if offline improvements translate to online gains.

4. Reconcile and Iterate

Address mismatch by refining offline metrics (e.g., using counterfactual evaluation, importance weighting), incorporating online signals into training, or running more granular online experiments to isolate effects.

5. Monitor and Validate

Continuously monitor both offline and online metrics, and establish a feedback loop to update models. Use online performance as the ultimate arbiter, but leverage offline metrics for rapid iteration.

Key Points to Mention

  • Offline metrics: AUC, precision@k, recall@k, NDCG, MAP, calibration.
  • Online metrics: CTR, saves, repins, time spent, retention, user satisfaction.
  • Common causes of mismatch: data leakage, distribution shift, feedback loops, metric misalignment.
  • Techniques to reconcile: counterfactual evaluation, importance weighting, online-offline correlation analysis.
  • Importance of A/B testing and statistical significance in online evaluation.
  • Pinterest-specific context: visual search, recommendation systems, and engagement metrics like closeups and saves.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q7

How would you handle cold-start for new ads and new users in your CTR prediction system?

Technical Trade-offsProduct Sense & Ideation
Author's notes

New ads get content-based features and inherit CTR estimates from similar ads.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by acknowledging that cold-start is a fundamental exploration-exploitation trade-off in CTR prediction, and that new ads and new users have distinct challenges. Then propose a multi-pronged solution: content-based features for new ads, contextual bandits or meta-learning for new users, and a fallback to exploration policies. Finally, emphasize the importance of logging and feedback loops to quickly learn from early interactions.

Pro tip: Mention that Pinterest's visual and textual content provides rich signals for new ads (e.g., image embeddings, ad copy), and that new users can be bootstrapped using their initial session context and demographics. Also, highlight the need for a separate exploration model or a hybrid system to avoid degrading overall CTR.

1. Define the cold-start problem

Clarify that new ads lack historical CTR data and new users lack interaction history, making it hard to predict CTR accurately. Distinguish between the two and note that they often co-occur.

2. Leverage content-based features

For new ads, use ad creative (images, text, category) to generate embeddings and predict CTR via content-based models. For new users, use contextual features like device, location, and initial query or pin interactions.

3. Apply exploration strategies

Use multi-armed bandits (e.g., Thompson sampling) or epsilon-greedy to explore new ads and users, balancing exploration with exploitation. Consider meta-learning to quickly adapt to new users with few interactions.

4. Design a hybrid system

Combine content-based predictions with collaborative filtering when data is scarce, and gradually shift to collaborative signals as interactions accumulate. Use a fallback model for cold-start cases.

5. Monitor and iterate

Set up metrics to track cold-start performance (e.g., CTR lift, time to convergence) and use online learning to update models quickly. A/B test different strategies to find the best trade-off.

Key Points to Mention

  • Exploration-exploitation trade-off and the need for bandit algorithms
  • Content-based filtering using ad creative and user context
  • Meta-learning or few-shot learning for rapid adaptation
  • Hybrid models that blend content and collaborative signals
  • Online learning and real-time feedback loops
  • Evaluation metrics specific to cold-start (e.g., time to first click, coverage)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q8

How would you approach exploration versus exploitation in ad ranking, and what are the tradeoffs?

Technical Trade-offsA/B Testing & Experimentation
Author's notes

Epsilon-greedy is the easy answer but feels lazy in this context.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining exploration and exploitation in ad ranking, then discuss common strategies like epsilon-greedy, Thompson sampling, and contextual bandits, and finally analyze tradeoffs such as short-term revenue vs. long-term learning and user experience. Emphasize how you would balance them using experimentation and metrics.

Pro tip: Highlight the importance of aligning exploration with business objectives and user experience—e.g., exploring only when it doesn't degrade user satisfaction, and using off-policy evaluation to minimize risk.

1. Define the problem

Explain exploration (showing new ads to gather data) vs. exploitation (showing best-known ads to maximize immediate reward) in the context of ad ranking.

2. Choose an algorithm

Discuss algorithms like epsilon-greedy, UCB, Thompson sampling, or contextual bandits, and justify which might be suitable for Pinterest's ad ranking.

3. Identify tradeoffs

Analyze tradeoffs: short-term revenue loss vs. long-term gain from learning, user experience impact, and computational cost.

4. Design experiments

Describe how to A/B test exploration strategies, measure metrics like CTR, revenue, and user engagement, and use counterfactual evaluation.

5. Monitor and adapt

Explain how to continuously monitor performance and adjust exploration rates based on business goals and user feedback.

Key Points to Mention

  • Multi-armed bandits and contextual bandits
  • Epsilon-greedy, Thompson sampling, UCB
  • Short-term vs. long-term reward tradeoff
  • User experience and satisfaction metrics
  • A/B testing and counterfactual evaluation
  • Business metrics like revenue and CTR

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.