← Google Interview Insights

Google·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
Jun 2026

Summary

Google SWE ML system design round, roughly 60 minutes, covering recommender systems, vision classifiers, chatbots, and video deduplication at scale. The bar was higher than I expected, especially around cold start and post-launch monitoring.

Questions Asked (8)

Q1

Design a real-time recommendation system for an e-commerce or social platform.

System DesignTechnical Trade-offs
Author's notes

I went straight into two-tower retrieval and the interviewer seemed fine with it, but I fumbled when they pushed on freshness requirements.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the platform (e-commerce or social), scale, and latency requirements, then outline a high-level architecture with data ingestion, feature computation, model serving, and feedback loops. Focus on the trade-offs between batch and real-time processing, and how to handle cold start and scalability.

Pro tip: Emphasize the importance of a feedback loop and online evaluation (e.g., A/B testing) to continuously improve recommendations, and discuss how to handle the cold-start problem with content-based or hybrid approaches.

1. Clarify Requirements

Ask about the platform type, scale (users, items, QPS), latency requirements, and whether recommendations are personalized or non-personalized. This sets the scope and guides design decisions.

2. High-Level Architecture

Sketch the main components: data collection (user interactions, item metadata), data processing (batch and stream), feature store, model training, model serving, and API layer. Explain how data flows from ingestion to serving.

3. Real-Time Processing Pipeline

Detail how to handle real-time events (clicks, purchases) using a stream processing framework (e.g., Kafka, Flink) to update features and models incrementally. Discuss how to maintain low latency and consistency.

4. Model Serving and Scalability

Explain how to serve recommendations at scale: caching, sharding, load balancing, and using a mix of precomputed and on-the-fly recommendations. Address latency vs. accuracy trade-offs.

5. Evaluation and Iteration

Describe offline metrics (precision, recall, NDCG) and online metrics (CTR, conversion rate). Discuss A/B testing, multi-armed bandits, and how to incorporate user feedback to improve the system.

Key Points to Mention

  • Batch vs. stream processing trade-offs (e.g., Lambda architecture vs. Kappa architecture)
  • Feature store for consistent features between training and serving
  • Cold-start problem and solutions (content-based, hybrid, exploration)
  • Scalability and low-latency serving (caching, approximate nearest neighbor, model quantization)
  • Online evaluation and feedback loops (A/B testing, multi-armed bandits)
  • Data privacy and ethical considerations (filtering, fairness, GDPR)

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

Q2

Design a mobile app that lets users photograph a leaf and identify its species from a large set of possibilities.

System DesignTechnical Trade-offs
Author's notes

My first instinct was a big softmax over all species and the interviewer kind of just waited.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then outline a high-level architecture that separates the mobile client from the backend ML pipeline. Focus on the trade-offs between on-device and cloud inference, and discuss how to handle scalability, latency, and accuracy for a large species dataset.

Pro tip: Emphasize the importance of a feedback loop where user corrections improve the model over time, and discuss how to handle low-confidence predictions gracefully to maintain user trust.

1. Clarify Requirements

Ask questions to understand scale (number of species, user base), performance needs (latency, offline support), and constraints (privacy, cost). This ensures the design meets actual needs.

2. High-Level Architecture

Sketch the main components: mobile app, backend services, ML model serving, and database. Decide on data flow from image capture to prediction.

3. Model and Inference Strategy

Discuss model choice (e.g., CNN, transfer learning), training data, and whether to run inference on-device or in the cloud. Consider trade-offs like latency, privacy, and accuracy.

4. Scalability and Reliability

Explain how to handle large-scale requests, including load balancing, caching, and fallback mechanisms. Address how to update the model without disrupting service.

5. User Experience and Feedback

Describe how users interact with the app, including handling low-confidence results, providing feedback, and continuous improvement of the model.

Key Points to Mention

  • On-device vs. cloud inference trade-offs (latency, privacy, cost, accuracy)
  • Model optimization techniques (quantization, pruning) for mobile deployment
  • Handling large species dataset (hierarchical classification, embedding similarity)
  • Scalable backend architecture (microservices, load balancing, caching)
  • User feedback loop for continuous model improvement
  • Privacy and data handling considerations (GDPR, user consent)

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

Q3

Design a chatbot that can answer questions grounded in both structured and unstructured data sources.

System DesignTechnical Trade-offs
Author's notes

RAG was the obvious starting point and I covered it, but I didn't bring up structured-data routing on my own.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the scope, then propose a high-level architecture that integrates structured and unstructured data sources. Focus on the retrieval and fusion mechanisms, and discuss trade-offs in design choices.

Pro tip: Emphasize the importance of grounding responses in verifiable data to reduce hallucinations, and discuss how to handle conflicting information from different sources.

1. Clarify Requirements

Ask questions to understand the use case, data sources, expected query types, and non-functional requirements like latency and accuracy.

2. High-Level Architecture

Outline the main components: data ingestion, indexing, query understanding, retrieval, fusion, and response generation.

3. Data Integration

Explain how to handle structured data (e.g., SQL databases) and unstructured data (e.g., documents) using appropriate indexing and retrieval methods.

4. Query Processing and Retrieval

Describe how to parse user queries, determine intent, and retrieve relevant information from both data types, possibly using hybrid search.

5. Response Generation and Grounding

Discuss how to generate answers using retrieved evidence, ensuring grounding and handling conflicts or missing information.

Key Points to Mention

  • Retrieval-Augmented Generation (RAG) for grounding responses in external data
  • Vector databases for semantic search over unstructured data
  • SQL and knowledge graphs for structured data querying
  • Hybrid retrieval combining keyword and semantic search
  • Handling conflicting information and source reliability
  • Evaluation metrics for correctness, faithfulness, and latency

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

Q4

Design a system to detect duplicate or near-duplicate short videos at billions-of-videos scale.

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

This one had the most follow-ups.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a multi-stage pipeline that first uses cheap hashing to find exact duplicates, followed by embedding-based approximate nearest neighbor search for near-duplicates. Discuss trade-offs between recall, precision, latency, and cost, and how to handle false positives with a verification step.

Pro tip: Emphasize that at billions scale, you cannot compare every pair; instead, use a two-tier approach where a fast, low-cost filter drastically reduces candidates before a more expensive similarity check. Also, mention that you would monitor and A/B test the system to balance false positives and negatives in production.

1. Clarify Requirements and Scale

Ask about video length, definition of near-duplicate (e.g., minor edits, re-encodes, overlays), acceptable false positive/negative rates, and latency requirements. Confirm scale: billions of videos, ingestion rate, and query patterns.

2. Design a Multi-Stage Pipeline

Propose a pipeline: (1) exact duplicate detection via cryptographic hashes (e.g., SHA-256) on file bytes or keyframes; (2) near-duplicate detection using perceptual hashes (e.g., pHash) or embeddings from a model (e.g., video CNN) followed by approximate nearest neighbor (ANN) search (e.g., FAISS, ScaNN).

3. Address Scalability and Storage

Discuss partitioning and indexing strategies: shard by video ID or hash, use distributed storage for hashes/embeddings, and leverage ANN indexes that support billions of vectors with low latency. Consider batch vs. real-time processing.

4. Handle Trade-offs and Verification

Explain how to tune thresholds to balance precision and recall, and add a verification step (e.g., human review or more expensive model) for borderline cases. Discuss cost vs. accuracy trade-offs.

5. Monitor, Evaluate, and Iterate

Propose metrics (e.g., precision, recall, latency, cost per video) and A/B testing to validate the system. Mention continuous improvement by retraining embeddings or adjusting thresholds based on feedback.

Key Points to Mention

  • Exact duplicate detection using cryptographic hashes (e.g., SHA-256) on video content or keyframes.
  • Perceptual hashing (e.g., pHash, dHash) for near-duplicate detection, robust to minor changes.
  • Deep learning embeddings (e.g., from video CNNs or transformers) combined with approximate nearest neighbor search (e.g., FAISS, ScaNN) for semantic similarity.
  • Scalability techniques: sharding, distributed indexing, and batch processing to handle billions of videos.
  • Trade-offs between precision, recall, latency, and cost; use of thresholds and verification steps.
  • A/B testing and monitoring to evaluate system performance and iterate.

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

Q5

How would you handle cold start for new users or new items in a recommendation system?

Technical Trade-offsSystem Design
Author's notes

Gave two approaches and the interviewer's body language made it pretty clear they wanted more.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the cold start problem for both new users and new items, then discuss strategies like using metadata, content-based filtering, and hybrid models. Emphasize how you would balance exploration and exploitation, and mention evaluation metrics to validate your approach.

Pro tip: Show awareness of Google's scale by discussing how to handle cold start in a distributed system with billions of users and items, and mention techniques like using side information and transfer learning from related domains.

1. Define the problem

Clearly state what cold start means for new users (lack of interaction history) and new items (lack of engagement data), and why it's challenging in recommendation systems.

2. Leverage available data

Discuss using metadata (user demographics, item attributes), content-based filtering, and knowledge graphs to make initial recommendations.

3. Employ hybrid and ensemble methods

Combine collaborative filtering with content-based methods, and use techniques like matrix factorization with side information or deep learning models that can generalize from few examples.

4. Balance exploration and exploitation

Explain how to use multi-armed bandits or reinforcement learning to explore new items and gather feedback while still providing relevant recommendations.

5. Evaluate and iterate

Mention offline metrics (e.g., coverage, diversity) and online A/B testing to measure the effectiveness of cold start strategies and refine them.

Key Points to Mention

  • Content-based filtering using item features and user profiles
  • Hybrid models that combine collaborative and content-based approaches
  • Exploration-exploitation trade-off via multi-armed bandits or Thompson sampling
  • Transfer learning and meta-learning to leverage data from similar users/items
  • Use of side information (e.g., demographics, item categories) in matrix factorization
  • Evaluation metrics like coverage, novelty, and online engagement metrics

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

Q6

How would you monitor a deployed ML system and handle issues like prediction drift, training-serving skew, or fairness regressions?

A/B Testing & ExperimentationRoot Cause Analysis
Author's notes

I almost skipped this because I was running low on time and figured they'd move on.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by outlining a comprehensive monitoring system that tracks data quality, model performance, and fairness metrics in production. Then, describe a systematic process for detecting and diagnosing issues like prediction drift, training-serving skew, and fairness regressions, and finally, explain how you would mitigate and prevent these issues.

Pro tip: Emphasize the importance of setting up alerts and automated rollback mechanisms to quickly address issues, and mention the need for continuous evaluation and retraining pipelines to keep the model up-to-date.

1. Establish Monitoring Metrics

Define and track key metrics such as prediction distribution, feature distributions, latency, and fairness metrics (e.g., demographic parity, equal opportunity). Use tools like TFX, Prometheus, or custom dashboards.

2. Detect Anomalies and Drift

Implement statistical tests (e.g., KL divergence, PSI) to detect prediction drift and training-serving skew. Set up alerts for significant deviations from baseline.

3. Diagnose Root Causes

When an alert triggers, investigate potential causes: data pipeline issues, feature changes, upstream data drift, or model staleness. Use logging and tracing to pinpoint the source.

4. Mitigate and Remediate

Take corrective actions such as rolling back to a previous model version, retraining with fresh data, or adjusting the model. For fairness regressions, apply bias mitigation techniques.

5. Prevent Recurrence

Implement continuous training pipelines, automated retraining triggers, and regular fairness audits. Update monitoring thresholds and improve data validation.

Key Points to Mention

  • Prediction drift: monitor changes in output distribution over time.
  • Training-serving skew: ensure features used in training match those in serving; validate with consistency checks.
  • Fairness regressions: track fairness metrics across sensitive groups and set up alerts for disparities.
  • Use of A/B testing to validate model changes and measure impact.
  • Root cause analysis: use tools like logs, traces, and data lineage to diagnose issues.
  • Automated rollback and retraining pipelines to quickly address issues.

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

Q7

Walk through how you would set up an A/B test and holdback experiment to evaluate a new ranking model.

A/B Testing & Experimentation
Author's notes

Straightforward compared to the rest.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the goal and metrics, then describe the experiment design including randomization, holdback, and statistical analysis. Emphasize how you would ensure validity and interpret results to make a launch decision.

Pro tip: Always define success metrics and guardrail metrics upfront, and consider running a holdback to measure long-term effects beyond the A/B test period.

1. Define Objectives and Metrics

Clarify the goal of the new ranking model (e.g., increase user engagement) and select primary success metrics (e.g., CTR) and guardrail metrics (e.g., latency, revenue).

2. Design Experiment

Determine randomization unit (e.g., user), sample size, duration, and holdback percentage. Ensure control and treatment groups are comparable.

3. Implement and Launch

Set up logging, ensure consistent user experience, and launch the experiment with proper monitoring for technical issues.

4. Analyze Results

Use statistical tests to compare metrics between groups, check for significance, and analyze segments. Validate with holdback data.

5. Make Decision and Iterate

Decide whether to launch, iterate, or abandon based on results. Consider long-term effects and potential follow-up experiments.

Key Points to Mention

  • Randomization and avoiding bias (e.g., user-level randomization)
  • Holdback group for long-term impact and novelty effects
  • Statistical power and sample size calculation
  • Guardrail metrics to detect negative impacts
  • Segmentation analysis for heterogeneous effects
  • Iterative experimentation and learning

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

Q8

How would you trade off latency versus accuracy in an online serving system, and what techniques would you use to stay within a latency SLO?

Technical Trade-offsSystem Design
Author's notes

Talked about caching, model distillation, and near-line inference as the main levers.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the business context and SLO requirements, then explain how you would measure and model the latency-accuracy trade-off. Describe a layered approach: first optimize the model and system for efficiency, then apply dynamic techniques like early exit or cascading models to meet the SLO without sacrificing more accuracy than necessary.

Pro tip: Emphasize that latency and accuracy are not always a zero-sum trade-off—many optimizations (e.g., quantization, distillation, caching) can improve both. Also, mention that you would set up continuous monitoring and A/B testing to validate the trade-off decisions in production.

1. Clarify Requirements and Constraints

Understand the business impact of latency vs. accuracy, the exact SLO (e.g., p99 latency < 100ms), and the cost of errors. This sets the optimization target.

2. Measure and Model the Trade-off

Profile the current system to get latency-accuracy curves for different model sizes or configurations. Use offline evaluation and simulation to predict performance under various load conditions.

3. Optimize for Efficiency

Apply techniques that improve both latency and accuracy, such as model quantization, pruning, knowledge distillation, and hardware acceleration. Also optimize the serving stack (batching, caching, async I/O).

4. Implement Dynamic Adaptation

Use cascading models (fast model first, then complex model if needed), early exit in neural networks, or request-level prioritization to dynamically trade off based on input difficulty or system load.

5. Monitor and Iterate

Deploy with canary releases, monitor latency and accuracy metrics in real-time, and set up alerts. Use A/B testing to validate changes and adjust the trade-off as needed.

Key Points to Mention

  • Latency SLO definition (e.g., p50, p95, p99) and its impact on user experience
  • Model compression techniques: quantization, pruning, distillation
  • Cascading or ensemble models with early exit
  • Caching and precomputation of frequent requests
  • Hardware acceleration (TPU, GPU) and optimized serving frameworks (TensorFlow Serving, Triton)
  • Dynamic batching and request scheduling to maximize throughput while meeting latency

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