← Google Interview Insights

Google·Data Scientist·Technical Phone Screen·Senior

SeniorPrefer not to say
Jul 2026Remote

Summary

Deep technical screen for a DS role at Google, basically one massive ML system design question broken into five parts. The whole thing felt like a take-home prompt read aloud, and they expected you to just... go. No warm-up, no softball.

Questions Asked (5)

Q1

Given minute-level battery telemetry for a specific device currently at 37% charge, how would you implement a baseline time-to-empty estimator using piecewise linear interpolation on the discharge curve? How do you handle irregular timestamps, short charging periods, and screen-off segments?

System DesignTechnical Trade-offsAlgorithms & Data Structures
Author's notes

This is where I spent way too long.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by outlining the data preprocessing steps to clean and segment the telemetry, then describe how to build a piecewise linear discharge curve from historical data. Explain how to use interpolation to estimate time-to-empty from the current 37% charge, and discuss handling of irregular timestamps, charging periods, and screen-off segments.

Pro tip: Emphasize that the baseline should be simple and interpretable, and that handling edge cases like charging and screen-off is crucial for robustness. Mention that you would validate the estimator against held-out data and consider confidence intervals.

1. Data Cleaning and Segmentation

Filter out charging periods and screen-off segments, and resample irregular timestamps to a regular grid (e.g., 1-minute intervals) using interpolation.

2. Build Discharge Curve

From historical discharge data, compute the average discharge rate or battery percentage over time, and construct a piecewise linear function mapping battery percentage to time-to-empty.

3. Estimate Time-to-Empty

Given current charge (37%), interpolate on the piecewise linear curve to estimate remaining time, and optionally adjust for recent usage patterns.

4. Handle Edge Cases

For irregular timestamps, use interpolation or binning; for short charging periods, exclude them from discharge curve; for screen-off, either exclude or model separately as they may have different discharge rates.

5. Validation and Iteration

Validate the estimator using hold-out data, compute error metrics (e.g., MAE), and consider improvements like separate curves for screen-on/off or time-of-day effects.

Key Points to Mention

  • Piecewise linear interpolation: constructing segments between known battery levels and times, and interpolating for 37%.
  • Irregular timestamps: resampling to regular intervals using linear interpolation or forward-fill, and handling missing data.
  • Charging periods: identifying and excluding them from discharge curve to avoid skewing the rate.
  • Screen-off segments: either exclude or model separately because discharge rate may differ significantly.
  • Baseline simplicity: starting with a simple model before adding complexity, and validating with metrics.
  • Confidence intervals or uncertainty: acknowledging variability and providing a range rather than a point estimate.

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

Q2

Name at least 8 engineered features you would add to improve the time-to-empty prediction beyond the raw discharge curve, and explain the expected direction of each feature's effect on the estimate.

Data ModelingProduct Analytics & Metrics
Author's notes

Rattled off a bunch: rolling discharge slope over the last N minutes (steeper slope means less time remaining), screen-on duty cycle, brightness-weighted screen time, CPU utilization moving average, thermal state (higher temp accelerates discharge), foreground app category encoded as activity intensity, network type as a proxy for radio power draw, and battery health degradation as a scalar penalty.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem context: time-to-empty prediction for a battery or similar system, where the raw discharge curve alone is insufficient. Then, systematically list engineered features from different categories (e.g., temporal, statistical, contextual, usage patterns) and for each, explain how it would shift the estimate (e.g., higher temperature accelerates discharge, so it decreases time-to-empty). Finally, emphasize that the direction of effect should be grounded in domain knowledge and validated empirically.

Pro tip: Tie each feature to a real-world mechanism and mention that you would validate the expected direction with feature importance or partial dependence plots to ensure the model learns sensible relationships.

1. Clarify the problem and baseline

Confirm that the goal is to predict remaining time until empty (e.g., battery) and that the raw discharge curve is the only current input. Acknowledge that additional features can capture external and internal factors affecting discharge rate.

2. Categorize feature types

Group features into categories: temporal (e.g., time of day), environmental (e.g., temperature), usage (e.g., load), and derived statistical (e.g., variance of recent voltage). This ensures comprehensive coverage.

3. List and explain each feature

For each feature, state its name, how it is computed, and the expected direction of its effect on time-to-empty (e.g., higher temperature → shorter time-to-empty). Aim for at least 8 features.

4. Validate and prioritize

Mention that you would validate the direction and importance of features using model interpretability tools (e.g., SHAP, permutation importance) and iterate on feature engineering.

Key Points to Mention

  • Temperature: higher temperature increases discharge rate, decreasing time-to-empty.
  • Load/current: higher load draws more current, reducing time-to-empty.
  • Recent discharge rate (e.g., slope of last N points): steeper negative slope indicates faster depletion, decreasing time-to-empty.
  • Voltage variance: higher variance may indicate unstable conditions, potentially decreasing time-to-empty.
  • Time since last full charge: longer time may correlate with aging, decreasing time-to-empty.
  • Usage pattern (e.g., idle vs. active): active usage increases drain, decreasing time-to-empty.
  • Battery age/cycle count: older batteries have reduced capacity, decreasing time-to-empty.
  • Ambient humidity: extreme humidity may affect performance, but direction depends on battery type; typically higher humidity could increase self-discharge, decreasing time-to-empty.

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

Q3

For a device model with no historical data (cold start), how would you transfer discharge curve priors from other devices? Define your similarity metric, how you combine neighbor curves, and how you quantify prediction uncertainty.

System DesignTechnical Trade-offsAdaptability & Ambiguity
Author's notes

I went with a kNN-style approach using model family, battery health age, and a usage mix vector as the similarity space, then weighted-average the neighbor curves by inverse distance.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Frame the problem as a transfer learning task where you leverage discharge curves from similar devices to build a prior for the new device. Define a similarity metric based on device features and curve shape, combine neighbor curves via weighted averaging or Bayesian hierarchical modeling, and quantify uncertainty using posterior variance or conformal prediction intervals.

Pro tip: Emphasize that uncertainty quantification is critical for cold-start predictions—use it to decide when to fall back to a conservative prior or request more data. Also, mention that similarity should be validated on held-out devices to avoid overfitting to irrelevant features.

1. Define similarity metric

Identify relevant device features (e.g., battery capacity, chemistry, usage patterns) and curve characteristics (e.g., shape, inflection points). Use a combination of domain knowledge and data-driven methods (e.g., dynamic time warping, feature embeddings) to compute similarity scores.

2. Select and weight neighbors

Choose top-k similar devices based on the similarity metric. Assign weights proportional to similarity (e.g., softmax over negative distances) to emphasize more similar devices.

3. Combine neighbor curves

Aggregate the discharge curves of selected neighbors using weighted averaging, or fit a hierarchical Bayesian model where device-specific curves are drawn from a common prior. This yields a prior predictive distribution for the new device.

4. Quantify uncertainty

Estimate uncertainty via the variance of the weighted neighbor curves, posterior predictive variance from the Bayesian model, or conformal prediction intervals. Validate calibration on held-out devices.

5. Adapt and update

As new data arrives, update the prior using online learning or Bayesian updating to refine predictions and reduce uncertainty.

Key Points to Mention

  • Similarity metric: combine device metadata (e.g., battery type, capacity) with curve shape features (e.g., DTW distance, functional PCA).
  • Weighting scheme: use similarity scores to weight neighbor contributions, e.g., softmax or kernel weighting.
  • Combination method: weighted average or hierarchical Bayesian model to pool information across devices.
  • Uncertainty quantification: posterior variance, ensemble variance, or conformal prediction intervals.
  • Validation: use leave-one-device-out cross-validation to tune similarity and combination methods.
  • Fallback strategy: when uncertainty is high, default to a conservative prior or collect more data.

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

Q4

How would you design an offline evaluation protocol for this predictor? What metrics would you use as primary and secondary, and how would you guard against the model systematically underestimating time-to-empty?

A/B Testing & ExperimentationProduct Analytics & MetricsTechnical Trade-offs
Author's notes

Session-level folds felt obvious to me so I led with that.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the offline evaluation protocol: data splitting, metrics, and validation. Then discuss primary and secondary metrics, and finally outline strategies to detect and mitigate systematic underestimation of time-to-empty, such as bias analysis and calibration.

Pro tip: Emphasize the importance of aligning offline metrics with online business objectives and using techniques like quantile loss or asymmetric loss to directly address underestimation bias.

1. Define Evaluation Setup

Specify the data splitting strategy (e.g., time-based split to mimic deployment) and ensure no leakage. Consider using a holdout set or cross-validation with time series awareness.

2. Select Primary and Secondary Metrics

Choose primary metrics that directly reflect the prediction goal (e.g., MAE, RMSE for time-to-empty) and secondary metrics for robustness (e.g., bias, quantile loss, calibration).

3. Guard Against Underestimation

Use asymmetric loss functions (e.g., quantile loss at high quantile) or post-hoc calibration. Analyze residuals to detect systematic bias and consider stratification by relevant segments.

4. Validate and Iterate

Perform error analysis, compare against baselines, and simulate online impact. Use techniques like bootstrapping to estimate confidence intervals for metrics.

Key Points to Mention

  • Time-based data splitting to avoid temporal leakage
  • Primary metric: Mean Absolute Error (MAE) or Root Mean Squared Error (RMSE) for time-to-empty
  • Secondary metrics: Bias (mean error), quantile loss, calibration plots
  • Asymmetric loss functions (e.g., pinball loss) to penalize underestimation more
  • Stratified analysis by device type, user segment, or usage patterns
  • Simulation of online A/B test to estimate business impact

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

Q5

After the model is live, how would you monitor for distribution shift in the discharge patterns, and what would an automatic recalibration procedure look like?

Root Cause AnalysisSystem Design
Author's notes

Talked about tracking the distribution of discharge slopes over rolling windows and flagging when it drifts outside a historical baseline, and also monitoring ambient temperature distributions since seasonal shifts affect battery behavior.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the monitoring strategy: track input feature distributions and output predictions using statistical tests and drift metrics, with alerts for significant deviations. Then describe an automatic recalibration procedure that triggers retraining or model updates when drift is detected, ensuring minimal manual intervention and maintaining performance.

Pro tip: Emphasize the importance of setting up a feedback loop with ground truth labels (e.g., from delayed discharge outcomes) to validate drift and recalibration effectiveness, and discuss trade-offs between frequent recalibration and operational costs.

1. Define Monitoring Metrics

Identify key input features (e.g., patient demographics, clinical indicators) and output distributions (e.g., discharge disposition) to monitor. Choose appropriate statistical tests (e.g., KS test, PSI) and set thresholds for alerts.

2. Implement Continuous Monitoring

Set up pipelines to compute drift metrics on a schedule (e.g., daily/weekly) and visualize trends. Use tools like TensorFlow Data Validation or custom dashboards to track changes over time.

3. Detect and Diagnose Drift

When drift is detected, analyze which features or predictions are affected and root causes (e.g., changes in hospital policies, patient mix). Correlate with external events to confirm.

4. Design Automatic Recalibration

Define triggers for recalibration (e.g., drift magnitude, performance degradation). Implement a pipeline that automatically retrains the model on recent data, validates it, and deploys if performance improves.

5. Validate and Iterate

After recalibration, monitor model performance and drift to ensure effectiveness. Use A/B testing or shadow deployment to compare new vs. old model. Continuously refine thresholds and procedures.

Key Points to Mention

  • Types of drift: covariate shift, label shift, concept drift
  • Statistical tests: Kolmogorov-Smirnov, Population Stability Index (PSI), Chi-square
  • Monitoring tools: TensorFlow Data Validation, Evidently AI, custom dashboards
  • Automatic retraining triggers: drift threshold, performance drop, time-based
  • Feedback loops: delayed ground truth labels for validation
  • Trade-offs: recalibration frequency vs. cost, false positives vs. missed drift

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