Google Data Scientist Interview Experience — Four Technical Rounds, One Interviewer Showed Up Late and Never Apologized

Company: Google

Role: Data Scientist

Round: Onsite

Seniority: General

Overall the interview questions were pretty hard, but the interviewers were mostly friendly and did a good job guiding you along (except for one round). Google's interviews feel hard to prepare for — unlike Meta, which has a ton of interview writeups floating around. I think it really comes down to what you've built up over time. ## Technical: Statistics Question 1: Assume we have a sample with 100 data points. The sample mean is 100, and the margin of error is 10. The confidence interval is [70, 90]. The PM complains that the confidence interval is too wide. What can you do? Answer: You could consider increasing the sample size. Follow up: Let's say we increase the sample size to 10000. How will the CI change? Can you think of other ways to make the CI narrower without increasing the sample size? Answer: Increasing the significance level can make the CI narrower. Question 2: Assume we have a linear model Y = X * b, where X = (X_1, X_2, …, X_m) and b = (b_0, b_1, …, b_m). Also we have n data points (y_i, x_i). How would you estimate b? Answer: We can use OLS assuming m < n. The estimated b will be (X^T X)^{-1} X^T Y Follow up: Let's assume we actually have more features than data points, that is m > n. What would you do? Answer: A few options to consider. (1) Do we really need all m features? Consider feature selection before building the model, using business context. (2) Consider a regularization method such as lasso regression. (3) Upsample from the existing observations to make n > n. (Thinking about it more afterward, this one doesn't really make sense.) (4) Try other methods like random forecasts. Question 3: If we want to know whether some feature is relevant or not, what can we do? Answer: We can look at the t-test result on a single beta coefficient. Follow-up: How do you construct the t-test? What's the null and alternative hypothesis? .. Answer: Null hypothesis is H_0: beta_i = 0, and alternative is H_a: beta_i \ne 0. Follow-up: Why is it a t-distribution? Answer: I froze on this one for a while — I wasn't sure what he was getting at. I started by saying the CI looks like +/- 1.96 * (beta_hat / s.e.(beta_hat)), and that thing follows a t-distribution. Then the interviewer asked me, "why?" So I said, because beta_hat is normally distributed, and the thing in the denominator is chi-square. You can actually derive this — something like Var[beta_ols] = […] sigma^2 […]^T, and you can show the diagonal terms should be t-distributed? Then he said, "OK but what's the intuition here?" I thought about it for a while and said: if the standard error were known, it would be normal, but we don't know it, so we have to estimate it, so it's not normal anymore. ## Technical: Data analysis and intuition I This round was mainly about the YouTube Music mobile app. When you open the app, it shows a few suggested listening themes for the user, like Relax, Workout, or Commute. The question: suppose today a lawyer comes to you, worried that users who listen to the Commute playlist end up driving faster. As a DS, what would you do? My answer was that we could first consider a simple t-test to see whether there's actually a meaningful difference in driving speed between people who listen to the commute playlist and people who don't. Then, if there's time, we could build a model. It felt like a very open-ended question with no single correct answer. But the interviewer probed into a lot of detail — things like "what population are you modeling," "what's your data granularity," "some people start their commute listening to a different playlist and only switch to the commute playlist partway through, how would you handle that," "some people aren't actually driving during their commute, they're on the subway, would you include them in the analysis too," etc. ## Technical: Data analysis and intuition II The material covered was the same as the second round, so I didn't prepare much extra for it. Once I actually got into the interview, I realized the style of questions was still pretty different. First question: Let's say you have two features (X1, X2) and one target variable Y, and you want to build an OLS regression model to predict Y. You build model one as Y ~ X1 + X2. Now you also build model two with transformed features (X1 - X2) and (X1 + X2). Will you get the same model? What about the predictions? Answer: The models definitely won't be the same, because the coefficients are different. Then I got stuck. After a while I said, "I know you'll get the same model (same predicted value) if you apply a linear transform on features like aX + b, since the column space of the design matrix doesn't change. But I'm not 100% sure if X1-X2 and X1+X2 is a linear transformation." As soon as I said that, the interviewer looked kind of at a loss for words. Then she wrote out a matrix for me and told me it actually is a linear transformation. Fine, I did the math on paper myself. Second question: If we now use regularized regression, like ridge or lasso, are the coefficients of model one and model two still the same? What about the predicted values? My answer was pretty messy, and honestly I don't know what the correct answer is either. My gut feeling is that both the coefficients and the predicted values would be different. Third question: The company has a daily search log where each row is a query (i.e., what a user searched for). Now say we take a 10% random sample. How would you use this sample to estimate the total number of unique queries in the daily log? At first I thought "unique query" meant something like SELECT DISTINCT, but after clarifying, it turned out the definition was "a query that shows up exactly once." So if the full set of queries is (q1, q1, q2, q3), the number of unique queries is 2, not 3. My answer was: why not first calculate the number of unique queries in the random sample, then scale up proportionally. The interviewer then asked what's wrong with that approach, and I said it would overestimate the number of unique queries in the population, because a query might happen to show up exactly once in the sample while actually showing up multiple times in the full population. Then he asked if I had a better approach. I said I could think of two: (1) still do the proportional estimate, but apply some correction afterward (kind of just making this up on the spot), or (2) build a statistical model, for example assuming all the log entries follow a multinomial distribution. In the end, the "correct" answer the interviewer hinted at seemed to be modeling the number of occurrences of each query, maybe using something like Poisson. ## Technical: Programming This round didn't go so well. The interviewer showed up ten minutes late and didn't say sorry or explain at all. On top of that, he kept interrupting me the whole time and was rocking back and forth in his chair. The problems themselves weren't hard. The first question: you're given a binary classification model's output as a CSV with two columns, actual label and predicted probability. The true positive cases are about 5% of the total. First he asked, "what metric would you use to evaluate this model?" and that naturally led into writing a Python function to compute the precision/recall curve. My brain froze up a bit — I blanked on the definition of precision for a second. The Python function itself was easy enough to write. The second question: suppose you're given a regression model's output, where the model predicts revenue for each country. The CSV has three columns: country, actual revenue, predicted revenue. First we talked about what metric to use. I said MSE or weighted MSE, and the interviewer kept challenging me on it: why look at the mean instead of the sum, which is better, etc. Eventually he said, fine, implement RMSE. Halfway through writing it he said, "Wait, why are you taking the difference?" Turns out what he wanted was a percentage: sqrt(avg(sum_i (predicted_i / actual_i - 1)^2)). After I finished that, he asked how I'd get a confidence interval for this percentage RMSE metric (which I'd never even seen before). I said, "bootstrap." Halfway through writing the bootstrap code he said, "Wait a second, why is your bootstrap sample the same size as the original sample?" I said, "Oh, this is pretty standard, I think it's the normal procedure for nonparametric bootstrap?" He then asked, "So is there some probability that your bootstrap sample ends up identical to the original sample?" I thought this was some kind of probability trick question and was about to start calculating, but then he said, "Oh, actually it's not very likely. Never mind."

Google Data Scientist Interview Experience — Four Technical Rounds, One Interviewer Showed Up Late and Never Apologized

Google·Data Scientist·Aug 2026

Onsitemedium

Technical: Statistics

Question 1: Assume we have a sample with 100 data points. The sample mean is 100, and the margin of error is 10. The confidence interval is [70, 90]. The PM complains that the confidence interval is too wide. What can you do?
Answer: You could consider increasing the sample size.
Follow up: Let's say we increase the sample size to 10000. How will the CI change? Can you think of other ways to make the CI narrower without increasing the sample size?
Answer: Increasing the significance level can make the CI narrower.

Question 2: Assume we have a linear model Y = X * b, where X = (X_1, X_2, …, X_m) and b = (b_0, b_1, …, b_m). Also we have n data points (y_i, x_i). How would you estimate b?
Answer: We can use OLS assuming m < n. The estimated b will be (X^T X)^{-1} X^T Y
Follow up: Let's assume we actually have more features than data points, that is m > n. What would you do?

Answer: A few options to consider. (1) Do we really need all m features? Consider feature selection before building the model, using business context. (2) Consider a regularization method such as lasso regression. (3) Upsample from the existing observations to make n > n. (Thinking about it more afterward, this one doesn't really make sense.) (4) Try other methods like random forecasts.

Question 3: If we want to know whether some feature is relevant or not, what can we do?
Answer: We can look at the t-test result on a single beta coefficient.
Follow-up: How do you construct the t-test? What's the null and alternative hypothesis? ..
Answer: Null hypothesis is H_0: beta_i = 0, and alternative is H_a: beta_i \ne 0.
Follow-up: Why is it a t-distribution?
Answer: I froze on this one for a while — I wasn't sure what he was getting at. I started by saying the CI looks like +/- 1.96 * (beta_hat / s.e.(beta_hat)), and that thing follows a t-distribution. Then the interviewer asked me, "why?" So I said, because beta_hat is normally distributed, and the thing in the denominator is chi-square. You can actually derive this — something like Var[beta_ols] = […] sigma^2 […]^T, and you can show the diagonal terms should be t-distributed? Then he said, "OK but what's the intuition here?" I thought about it for a while and said: if the standard error were known, it would be normal, but we don't know it, so we have to estimate it, so it's not normal anymore.

Technical: Data analysis and intuition I

This round was mainly about the YouTube Music mobile app. When you open the app, it shows a few suggested listening themes for the user, like Relax, Workout, or Commute. The question: suppose today a lawyer comes to you, worried that users who listen to the Commute playlist end up driving faster. As a DS, what would you do?
My answer was that we could first consider a simple t-test to see whether there's actually a meaningful difference in driving speed between people who listen to the commute playlist and people who don't. Then, if there's time, we could build a model. It felt like a very open-ended question with no single correct answer. But the interviewer probed into a lot of detail — things like "what population are you modeling," "what's your data granularity," "some people start their commute listening to a different playlist and only switch to the commute playlist partway through, how would you handle that," "some people aren't actually driving during their commute, they're on the subway, would you include them in the analysis too," etc.

Technical: Data analysis and intuition II

The material covered was the same as the second round, so I didn't prepare much extra for it. Once I actually got into the interview, I realized the style of questions was still pretty different.

First question: Let's say you have two features (X1, X2) and one target variable Y, and you want to build an OLS regression model to predict Y. You build model one as Y ~ X1 + X2. Now you also build model two with transformed features (X1 - X2) and (X1 + X2). Will you get the same model? What about the predictions?
Answer: The models definitely won't be the same, because the coefficients are different. Then I got stuck. After a while I said, "I know you'll get the same model (same predicted value) if you apply a linear transform on features like aX + b, since the column space of the design matrix doesn't change. But I'm not 100% sure if X1-X2 and X1+X2 is a linear transformation." As soon as I said that, the interviewer looked kind of at a loss for words. Then she wrote out a matrix for me and told me it actually is a linear transformation. Fine, I did the math on paper myself.

Second question: If we now use regularized regression, like ridge or lasso, are the coefficients of model one and model two still the same? What about the predicted values? My answer was pretty messy, and honestly I don't know what the correct answer is either. My gut feeling is that both the coefficients and the predicted values would be different.

Third question: The company has a daily search log where each row is a query (i.e., what a user searched for). Now say we take a 10% random sample. How would you use this sample to estimate the total number of unique queries in the daily log?
At first I thought "unique query" meant something like SELECT DISTINCT, but after clarifying, it turned out the definition was "a query that shows up exactly once." So if the full set of queries is (q1, q1, q2, q3), the number of unique queries is 2, not 3.
My answer was: why not first calculate the number of unique queries in the random sample, then scale up proportionally. The interviewer then asked what's wrong with that approach, and I said it would overestimate the number of unique queries in the population, because a query might happen to show up exactly once in the sample while actually showing up multiple times in the full population. Then he asked if I had a better approach. I said I could think of two: (1) still do the proportional estimate, but apply some correction afterward (kind of just making this up on the spot), or (2) build a statistical model, for example assuming all the log entries follow a multinomial distribution. In the end, the "correct" answer the interviewer hinted at seemed to be modeling the number of occurrences of each query, maybe using something like Poisson.

Technical: Programming

This round didn't go so well. The interviewer showed up ten minutes late and didn't say sorry or explain at all. On top of that, he kept interrupting me the whole time and was rocking back and forth in his chair.

The problems themselves weren't hard. The first question: you're given a binary classification model's output as a CSV with two columns, actual label and predicted probability. The true positive cases are about 5% of the total. First he asked, "what metric would you use to evaluate this model?" and that naturally led into writing a Python function to compute the precision/recall curve. My brain froze up a bit — I blanked on the definition of precision for a second. The Python function itself was easy enough to write.

The second question: suppose you're given a regression model's output, where the model predicts revenue for each country. The CSV has three columns: country, actual revenue, predicted revenue. First we talked about what metric to use. I said MSE or weighted MSE, and the interviewer kept challenging me on it: why look at the mean instead of the sum, which is better, etc. Eventually he said, fine, implement RMSE. Halfway through writing it he said, "Wait, why are you taking the difference?" Turns out what he wanted was a percentage: sqrt(avg(sum_i (predicted_i / actual_i - 1)^2)).

After I finished that, he asked how I'd get a confidence interval for this percentage RMSE metric (which I'd never even seen before). I said, "bootstrap." Halfway through writing the bootstrap code he said, "Wait a second, why is your bootstrap sample the same size as the original sample?" I said, "Oh, this is pretty standard, I think it's the normal procedure for nonparametric bootstrap?" He then asked, "So is there some probability that your bootstrap sample ends up identical to the original sample?" I thought this was some kind of probability trick question and was about to start calculating, but then he said, "Oh, actually it's not very likely. Never mind."

Curated and edited by PracHub