Google Data Scientist (Entry Level) Interview Preparation Guide

Data Scientist

Google

entry

6 rounds

Updated 6/15/2026

Google's Data Scientist interview process for entry-level candidates consists of a recruiter screening call followed by a technical phone screen and four onsite interview rounds. The process evaluates candidates across coding proficiency (SQL and Python), statistical knowledge, machine learning fundamentals, product thinking, and cultural alignment. All technical rounds are conducted virtually using shared code editors or on-site with whiteboards. The entire process typically spans 4-6 weeks from initial recruiter contact to final decision.

Interview Rounds

Recruiter Screening

25 min3 focus topicsculture fit

What to Expect

Your initial conversation with a Google recruiter typically lasts 20-30 minutes and serves as a mutual fit assessment. The recruiter will discuss your background, motivation for the role, and explain the interview process timeline. This is not a technical round but rather an opportunity to make a positive impression through clear communication and enthusiasm. The recruiter may ask preliminary questions about relevant projects or experience, and you should be prepared to discuss your resume in narrative form rather than simply reciting it. This call also gives you a chance to ask questions about the team, projects, and role expectations.

Tips & Advice

Research Google's mission and data science applications across products before the call. Prepare a clear 2-3 minute narrative of your background emphasizing relevant projects and learning. Articulate why you're interested in Google and data science specifically—avoid generic answers. Ask thoughtful questions about the team and role to demonstrate genuine interest. Confirm all logistics: interview dates, panel composition, and what to expect in technical rounds. Take notes on the recruiter's name, team details, and key dates for follow-up.

Focus Topics

Understanding Role Expectations and Team Dynamics

Ask thoughtful questions about the specific team, current projects, and data science challenges they're solving. Inquire about what success looks like for entry-level data scientists, mentorship and growth opportunities, and how the team collaborates with product and engineering. Ask about the data science tech stack and tools used. These questions demonstrate engagement and help you understand realistic expectations, enabling better preparation for technical rounds.

Practice Interview

Study Questions

Motivation for Google and Data Science

Clearly articulate why you're drawn to data science and specifically why Google interests you. Research Google's data science impact: Search ranking and relevance, YouTube recommendations, Maps routing optimization, Gmail spam detection, or Ads performance. Reference specific products or problems that excite you. Explain what draws you to solving data-driven problems—whether it's using data to understand human behavior, optimizing systems, or improving user experiences. For entry-level candidates, emphasize learning opportunities and the chance to apply skills to products impacting billions of users.

Practice Interview

Study Questions

Background and Experience Narrative

Develop a compelling 2-3 minute summary of your background that highlights relevant skills for data science: programming experience (Python, R), statistics or math coursework, data-driven projects or internships, and any achievements with quantified impact. For entry-level candidates without extensive professional experience, emphasize academic projects, competitions (Kaggle, hackathons), internships, or personal projects that demonstrate core data science capabilities. Structure your narrative chronologically and focus on how each experience built your data science foundation.

Practice Interview

Study Questions

Technical Phone Screen - Coding and SQL

50 min3 focus topicstechnical

What to Expect

This 45-60 minute virtual interview tests your proficiency with SQL and Python for data manipulation and analysis. You'll use a shared code editor to solve 1-2 live coding problems while explaining your approach. Problems typically involve writing SQL queries to extract insights from databases or using Python to manipulate datasets and identify patterns. The interviewer assesses both technical correctness and your problem-solving process: how you clarify requirements, think through edge cases, communicate reasoning, and write clean code. For entry-level candidates, fundamentals and clear thinking matter more than optimization tricks.

Tips & Advice

Before writing any code, clarify the problem: What are we solving? What data constraints exist? What edge cases should we handle? Ask these questions aloud. Outline your approach verbally before coding—this helps you think clearly and shows the interviewer your logic. Write readable code with meaningful variable names and occasional comments. For SQL, optimize to avoid unnecessary full table scans where reasonable. Test your code mentally with various scenarios. If stuck, think aloud and ask for hints rather than sitting silently. Time management is critical: prioritize correctness and clear communication over optimization initially. For entry-level roles, solid fundamentals and structured thinking are valued over advanced techniques.

Focus Topics

Problem-Solving Approach and Communication

Develop a structured methodology: (1) clarify requirements and constraints thoroughly, (2) identify potential edge cases, (3) articulate your approach before coding, (4) implement carefully, (5) test with concrete examples. Communicate your thinking throughout the interview—explain why you chose certain data structures or algorithms, discuss trade-offs between approaches, and ask clarifying questions when uncertain. If you get stuck, verbalize your thinking so the interviewer can guide you. For entry-level candidates, demonstrating logical thinking and collaboration matters as much as achieving a perfect solution.

Practice Interview

Study Questions

Python for Data Manipulation and Problem-Solving

Be proficient in Python fundamentals: data structures (lists, dictionaries, sets), control flow (loops, conditionals), and functions. Master Pandas for data manipulation (filtering rows, selecting columns, grouping, merging datasets, calculating aggregates). Understand NumPy for numerical operations and basic statistics. Write algorithms that solve analytical problems: counting patterns, filtering based on conditions, transforming data structures. Understand time and space complexity for common operations—when does your solution scale? Write clean, readable code with meaningful variable names and occasional comments. For entry-level candidates, correctness and clarity are prioritized over the most advanced techniques.

Practice Interview

Study Questions

SQL Fundamentals and Data Querying

Master core SQL operations: SELECT with WHERE filtering, joins (INNER, LEFT, FULL OUTER) to combine tables, GROUP BY with aggregate functions (COUNT, SUM, AVG, MIN, MAX), HAVING to filter grouped results, and ORDER BY for sorting. Be comfortable calculating key metrics: finding top N items by metric, computing percentiles, handling NULL values appropriately, and deriving new columns. Understand window functions like ROW_NUMBER() and RANK() for ranking within groups. Practice query optimization: using indexes conceptually, filtering early to reduce data volume, and avoiding unnecessary computations. Study common interview questions: finding best-selling products, comparing columns across rows, and calculating engagement metrics across time periods.

Practice Interview

Study Questions

Onsite Round 1 - Statistics and Experimentation

50 min4 focus topicstechnical

What to Expect

This 45-60 minute onsite interview evaluates your understanding of statistical principles, hypothesis testing, A/B testing, and experimental design. You'll answer conceptual questions about probability and statistics, and tackle applied problems like designing experiments for product changes at Google. Questions might involve calculating probabilities, understanding statistical errors, designing A/B tests for YouTube recommendations or Google Maps features, and interpreting experimental results. The interviewer assesses whether you can frame business problems statistically, select appropriate methods, and interpret results in business context. For entry-level candidates, demonstrate solid fundamental understanding rather than advanced theory.

Tips & Advice

Use the scientific method framework when answering experiment design questions: define the business problem clearly, state your hypothesis, identify key metrics, describe experimental design (randomization, sample size, duration), and explain result interpretation. Always consider confounding variables—what else could affect results?—and how you'd control for them. Show you understand the practical business context: why does a metric matter? What decision does this experiment inform? For probability questions, show your work step-by-step. When explaining statistical concepts, use simple language and avoid unnecessary jargon. For entry-level candidates, it's acceptable to acknowledge gaps in knowledge while showing willingness to think through problems logically.

Focus Topics

Interpreting Results and Business Context

Practice translating statistical results into business insights and decisions. When is a result statistically significant but practically small? What does a 5% improvement in click-through rate mean for a product with billions of users? Consider external factors: did seasonality or external events affect results? Discuss confidence in the result and what assumptions underlie your interpretation. Think about next steps: if results support the hypothesis, what's the implementation plan? If not, what would you test next? For entry-level candidates, show you think beyond just whether p < 0.05.

Practice Interview

Study Questions

Probability and Statistical Fundamentals

Understand fundamental probability: calculating simple probabilities, conditional probability (given one event, probability of another), independence, and Bayes' theorem. Know probability distributions (normal, binomial, Poisson) and when each applies. Understand the law of large numbers and how sample size affects distributions. Understand basic statistical measures: mean, median, mode, variance, standard deviation, percentiles, and when to use each (e.g., median vs mean with outliers). Be comfortable with the central limit theorem concept. For entry-level candidates, focus on intuition and application rather than deriving distributions mathematically.

Practice Interview

Study Questions

Hypothesis Testing and Statistical Inference

Understand the framework: null hypothesis (baseline assumption) and alternative hypothesis (what you're testing). Know Type I errors (false positives) and Type II errors (false negatives) and their business implications. Understand p-values (probability of observing data if null hypothesis is true) and significance levels (e.g., 0.05). Know when to use different statistical tests: t-tests for comparing means, chi-square for categorical data, ANOVA for multiple groups. Understand relationships between sample size, effect size, and statistical power. Know the difference between statistical significance (p < 0.05) and practical significance (result is large enough to matter). For entry-level candidates, focus on conceptual understanding over mathematical derivations.

Practice Interview

Study Questions

A/B Testing and Experimental Design

Learn how to design controlled experiments: random assignment of users to control and treatment groups, holding all else constant except the change being tested. Understand statistical power: how many users you need to reliably detect an effect of a given size. Know the minimum detectable effect (smallest real effect your experiment can reliably find). Practice designing experiments for product scenarios: testing if a UI change increases engagement, if a new ranking algorithm improves search results, or if a recommendation system increases watch time. Identify appropriate metrics, discuss how to prevent selection bias and ensure randomization quality. Understand common pitfalls: peeking at results before completion (inflates false positive risk), multiple testing without correction, or external factors (seasonality, platform changes) affecting results.

Practice Interview

Study Questions

Onsite Round 2 - Technical Interview (Advanced Coding)

50 min3 focus topicstechnical

What to Expect

This 45-60 minute onsite interview tests your ability to tackle more complex technical problems combining data manipulation, algorithm design, and analytical thinking. Problems may involve designing efficient solutions for complex data filtering or aggregation, solving algorithmic challenges with data-driven constraints, or optimizing computations. You'll work on a whiteboard or shared editor, explaining your reasoning throughout. The interviewer evaluates code quality, algorithmic thinking, ability to discuss trade-offs, and communication under pressure. For entry-level candidates, a clear, correct solution with good explanation is valued more than an optimal solution delivered hastily.

Tips & Advice

Take time to understand the problem completely before coding—clarify ambiguities and constraints. Break complex problems into smaller, manageable pieces. Discuss your approach and trade-offs (time vs space complexity, readability vs optimization) before implementing. Write pseudocode first if helpful. Start with a correct solution; optimize only if time and clarity permit. Test your logic with concrete examples before finalizing. For entry-level candidates, don't feel pressured to deliver the most optimal solution immediately—a clear, correct, well-explained approach that shows structured thinking is more important. Ask clarifying questions throughout. If stuck, articulate your thinking so the interviewer can provide guidance.

Focus Topics

Writing Clean, Production-Quality Code

Write readable code that other engineers can understand and maintain: use meaningful variable names (avoid single letters except for loop counters), add clarifying comments for non-obvious logic, structure code logically with helper functions, and follow consistent style conventions. Handle edge cases and potential errors gracefully—validate input assumptions, use appropriate error handling. Write modular functions that are single-purpose, easy to test, and reusable. Avoid code duplication and repetitive patterns. For entry-level candidates, prioritize clarity and correctness. Clean code demonstrates professional development practices and respect for team collaboration.

Practice Interview

Study Questions

Problem-Solving Under Pressure and Adaptability

Develop strategies for tackling unfamiliar or challenging problems: stay calm and think methodically, break problems into components, ask clarifying questions, think before coding, and communicate throughout. When stuck, explain your thinking and ask for hints—this shows problem-solving maturity and collaborative ability. Manage time effectively by prioritizing correctness and clear communication over premature optimization. Adapt based on feedback: if the interviewer hints you're on the wrong track, listen and adjust. For entry-level candidates, articulating your thought process and demonstrating adaptability matters more than immediately solving complex problems.

Practice Interview

Study Questions

Data Structures and Algorithm Efficiency

Understand common data structures and their characteristics: arrays (fast access, fixed size), linked lists (flexible size, slower access), hash tables (fast lookups), stacks and queues (specific access patterns), heaps (priority access), and graphs (relationships). Know Big O time and space complexity for common operations on each structure. Understand when to use each data structure: use hash tables for fast lookups, heaps for finding min/max repeatedly, or graphs for modeling relationships. Be comfortable analyzing algorithm complexity and discussing trade-offs. Practice problems involving searching, sorting, filtering, and aggregating data efficiently. For entry-level candidates, focus on practical data structure selection and recognizing efficiency patterns rather than implementing advanced structures from scratch.

Practice Interview

Study Questions

Onsite Round 3 - Machine Learning and Applied Modeling

50 min4 focus topicstechnical

What to Expect

This 45-60 minute onsite interview evaluates your understanding of machine learning concepts, model selection, feature engineering, and model evaluation for real-world problems. You might be asked conceptual questions about when and how to apply different algorithms, how to build predictive models for specific use cases (e.g., predicting user engagement), how to evaluate model performance, or how to optimize models for production constraints. For entry-level roles, expect questions testing foundational ML knowledge rather than cutting-edge research. The interviewer assesses whether you can think through practical ML problems logically, understand trade-offs, and apply concepts to real Google products.

Tips & Advice

Focus on practical, intuitive understanding over mathematical rigor. Be able to explain what algorithms do and when to use them rather than deriving formulas from first principles. Discuss trade-offs explicitly: when to prefer simple interpretable models vs complex high-accuracy models, when to optimize for speed vs accuracy. Connect ML concepts to real products: how might YouTube use collaborative filtering? How does Gmail detect spam? For entry-level roles, logical thinking through model choices matters more than knowing every advanced technique. Practice explaining ML concepts simply—clarity is valued. Always discuss how you'd validate that a model works in practice.

Focus Topics

Unsupervised Learning and Exploratory Analysis

Understand clustering algorithms like K-means (partitioning data into groups) and their use cases: customer segmentation, finding patterns in data, anomaly detection. Know dimensionality reduction techniques like PCA (reducing number of features while preserving information) and their applications: reducing computational complexity, visualizing high-dimensional data, removing noise. Understand when unsupervised learning applies and key challenges: no ground truth for validation, determining optimal number of clusters, interpreting results. For entry-level candidates, understand these methods conceptually and when they apply rather than implementation details.

Practice Interview

Study Questions

Feature Engineering and Data Preparation

Understand that features often determine model success more than algorithm choice. Learn data preparation: handling missing values (deletion, imputation, or creating missingness features), normalizing/scaling numerical features (important for distance-based algorithms), encoding categorical variables (one-hot encoding, ordinal encoding), and creating new features through combinations. Understand feature selection: identifying which features matter most for predictions. Know how to handle imbalanced data (more of one class than another), outliers (detect and handle appropriately), and data leakage (using future information in training). For different use cases, features differ: predicting user engagement requires different features than predicting ad click-through. Practice thinking about feature engineering for specific prediction tasks.

Practice Interview

Study Questions

Model Evaluation and Validation

Know how to evaluate model performance appropriately: for classification, use accuracy (overall correctness), precision (of predicted positives, how many are actually positive), recall (of actual positives, how many we found), F1-score (balance precision and recall), and ROC-AUC (performance across thresholds). For regression, use mean squared error (MSE), mean absolute error (MAE), and R-squared. Understand when different metrics matter: precision vs recall trade-off in fraud detection (missing fraud is worse than false alarms). Know proper train/test splitting and cross-validation to validate that models generalize. Understand data leakage: accidentally using future information in training causes overly optimistic performance estimates. For entry-level candidates, focus on understanding what metrics mean and when to use each.

Practice Interview

Study Questions

Supervised Learning Algorithms and Model Selection

Understand fundamental supervised learning algorithms: linear regression (predicting continuous values), logistic regression (binary classification), decision trees (interpretable models), random forests (ensemble method), and basic neural networks. Know what problem each solves, when to apply each algorithm, and their trade-offs. Understand overfitting (model memorizes training data) vs underfitting (model too simple), and how regularization helps. Know concepts like bias-variance trade-off: high bias models are simple but potentially too simple; high variance models are complex but may overfit. Understand cross-validation: training on part of data and validating on held-out data. For entry-level candidates, focus on conceptual understanding and knowing when to apply each algorithm rather than implementing complex versions.

Practice Interview

Study Questions

Onsite Round 4 - Product Sense and Behavioral

50 min5 focus topicsbehavioral

What to Expect

This 45-60 minute onsite interview combines product sense questions with behavioral questions to assess alignment with Google's culture and values. You'll answer questions about approaching data problems from a product perspective, defining and measuring success for product features, and behavioral questions about your past experiences. Example questions: 'How would you measure success of a new YouTube recommendation system?' or 'Tell me about a time you had to work with a cross-functional team on a challenging project.' The interviewer assesses your ability to connect data to business decisions, communicate insights to diverse audiences, and demonstrate values like ownership, collaboration, and continuous learning.

Tips & Advice

For behavioral questions, use the STAR method: Situation (context), Task (your responsibility), Action (what you did), Result (outcome). Focus on situations demonstrating collaboration, problem-solving, learning, and positive impact. Quantify results where possible. For product sense questions, think about user value and business impact. Define clear metrics for measuring success. Ask clarifying questions about the product and users. Show curiosity about how products work and affect users. Connect answers back to Google's mission of organizing information and making it universally accessible. For entry-level candidates, use genuine examples from school, internships, or personal projects. Emphasize learning, adaptability, and teamwork. You're not expected to have deep product experience, but should show you think strategically about products and data.

Focus Topics

Communicating Technical Analysis to Non-Technical Stakeholders

Practice explaining complex technical analysis to non-technical audiences like product managers, business leaders, or executives. Avoid jargon—use analogies and simple language. Focus on insights and implications for decisions, not technical details. Be clear about confidence levels and limitations: 'We're 95% confident this effect is real and worth 5-10% improvement' conveys uncertainty appropriately. Practice questions like 'Explain why your model might not work as well in production' or 'Walk me through how you'd present findings to product leadership.' For entry-level candidates, clarity and honesty matter most—acknowledge gaps in knowledge and focus on helping others understand key insights.

Practice Interview

Study Questions

Behavioral: Teamwork and Collaboration

Prepare 2-3 stories about working effectively in teams using the STAR method. Examples: 'Tell me about a time you had to explain a technical concept to non-technical stakeholders—how did you approach it?' 'Describe a disagreement with a teammate and how you resolved it.' 'Share an example of when you helped a colleague succeed or learned from a peer.' Focus on demonstrating: listening to others' perspectives, seeking to understand different viewpoints, adapting communication style for different audiences, supporting teammates, and collaborating toward shared goals. For entry-level candidates, academic group projects, internship experiences, or volunteer work provide good story material.

Practice Interview

Study Questions

Behavioral: Learning, Ownership, and Problem-Solving

Prepare 2-3 stories demonstrating learning, ownership, and problem-solving using the STAR method. Examples: 'Tell me about a time you learned a new technical skill to solve a problem.' 'Describe a challenge you faced and how you approached it systematically.' 'Share an example of when you took initiative to improve something.' For entry-level candidates, demonstrate curiosity, willingness to learn, persistence through obstacles, and accountability. Quantify impact where possible. These qualities are especially valued at entry-level because they predict success as you develop expertise.

Practice Interview

Study Questions

Business Problem Framing and Impact Assessment

Practice translating vague business questions into concrete data science problems. Ask clarifying questions to understand context, business goals, constraints, and timeline. Assess feasibility: is this solvable with data? What data is available or needs to be collected? What's the timeline for this analysis? For entry-level candidates, demonstrate structured thinking about problems rather than proposing complex solutions immediately. Explain how your analysis would drive decisions: would leadership change the product roadmap based on your insights? Would teams prioritize differently? Would you recommend launching or not launching a feature? Connect your technical work to business value.

Practice Interview

Study Questions

Product Metrics and Success Definition

Learn to define appropriate metrics for product features based on user value and business goals. Understand that different products optimize for different metrics: YouTube prioritizes watch time and engagement (users return and spend time); Google Search optimizes for user satisfaction and search quality (users find relevant results quickly); Maps focuses on accuracy and reliability (users trust directions). Understand primary metrics (most important for strategy) vs secondary metrics (confirm primary or detect unintended consequences). Practice questions like 'How would you measure engagement for a new mobile app feature?' or 'What metrics indicate a successful new Maps feature?' Understand why certain metrics matter: reducing click-through time is valuable at scale with billions of users. For entry-level candidates, focus on thinking logically about what success means for a product and its users, not having memorized perfect answers.

Practice Interview

Study Questions

Frequently Asked Data Scientist Interview Questions

Hypothesis Testing and InferenceEasyTechnical

34 practiced

List and explain practical methods to assess the normality assumption for parametric tests in a data science workflow. Cover graphical approaches (histogram, QQ-plot), formal hypothesis tests (Shapiro-Wilk, Anderson-Darling), and caveats when sample size is very large or very small.

Sample Answer

Start by remembering: "normality" matters for some parametric tests (t-test, ANOVA, linear regression residuals), but you should test the relevant quantity (e.g., residuals), not always raw features.

Graphical approaches (practical use)- Histogram + density: quick view of shape, multimodality, heavy tails. Overlay normal curve for reference.- Boxplot/violin: highlights skewness and outliers.- QQ-plot (recommended): plot sample quantiles vs theoretical normal quantiles. If points lie on the 45° line the distribution is approximately normal; systematic S-shape = skew; concave/convex tails = heavy/light tails. QQ-plots are intuitive and scale well with moderate samples.

Formal hypothesis tests- Shapiro–Wilk: good power for small-to-moderate samples (n up to ~2000). Common choice for assessing normality.- Anderson–Darling: emphasizes tail behavior; useful when tail fit matters.- Kolmogorov–Smirnov / Lilliefors: general but less powerful; KS requires specifying parameters or using Lilliefors variant.- Jarque–Bera: uses skewness and kurtosis; common in econometrics.

Caveats & practical guidance- Small n: tests have low power — they often fail to detect departures. Rely more on graphical checks and domain knowledge.- Large n: tests detect trivially small departures (statistically significant but practically irrelevant). Combine p-values with effect-size measures (skewness, excess kurtosis) and QQ-plot.- Focus on impact: check whether departures meaningfully affect inference (e.g., via simulation/bootstrap or robust alternatives). If normality is violated and matters, consider transformations (log, Box–Cox), robust estimators, nonparametric tests, or permutation/bootstrap inference.- Always check residuals for models, not just raw predictors.

Workflow tip: use a QQ-plot + Shapiro–Wilk (or Anderson–Darling) together; if they disagree, inspect plots and quantify skewness/kurtosis and run a sensitivity analysis (transform or bootstrap) to confirm whether conclusions change.

Problem Solving and Communication ApproachEasyTechnical

36 practiced

A stakeholder asks why not use a simple linear model instead of a complex neural net for a small dataset. Explain in plain language the trade-offs you would convey (overfitting risk, interpretability, maintenance cost), and what evidence you'd collect to support your recommendation.

Sample Answer

Situation: A stakeholder suggests using a simple linear model instead of a neural net because the dataset is small. I would explain trade-offs in plain language and propose evidence to decide.

Trade-offs to convey:- Overfitting risk: Neural nets have many parameters and can memorize small datasets, giving good training performance but poor real-world results. Linear models are less flexible, so they're less likely to overfit on limited data.- Interpretability: Linear models give clear coefficients you can explain to business users (e.g., “X increases outcome by Y”), while neural nets are largely black boxes unless you invest in post-hoc explanation techniques.- Maintenance and cost: Neural nets typically need more compute, monitoring, and skill to retrain and tune. That increases operational and personnel costs. Linear models are cheaper to run and easier to maintain.

Evidence I’d collect to support a recommendation:- Baseline comparison: Fit a regularized linear model (ridge/lasso) and a small neural net using the same features.- Robust evaluation: Use k-fold cross-validation and a held-out test set to compare out-of-sample metrics (e.g., RMSE, AUC). Report confidence intervals.- Learning curves: Plot performance vs. training size to see if the neural net improves with more data — if curves converge, a complex model may not help.- Overfitting checks: Compare train vs. validation performance; large gaps indicate overfitting.- Explainability checks: Show feature importances or partial dependence for the linear model and attempt SHAP or LIME for the neural net; quantify how actionable each is.- Cost assessment: Estimate compute, deployment complexity, and expected maintenance effort.

Recommendation approach:- Start with the simpler model as a baseline. If the neural net yields materially better and robust out-of-sample performance and the business justifies the extra cost/complexity, adopt it; otherwise choose the linear model for interpretability, speed, and lower maintenance.

A and B Test DesignMediumTechnical

88 practiced

Design a safe ramp plan for releasing a new pricing page experiment. Define stages with traffic percentages and durations, list primary and guardrail metrics to monitor at each stage, and specify automated and manual rollback criteria. Discuss the trade-offs between learning quickly and minimizing user exposure to risk.

Sample Answer

Approach: staged, metric-driven canary rollout with automated safety gates and manual checkpoints.

Ramp stages:- 0% → 2% (hours: 24) — quick smoke test for stability and instrumentation.- 2% → 10% (days: 3) — early behavior/engagement signals.- 10% → 25% (days: 7) — broader behavioral and revenue signals.- 25% → 50% (days: 7) — operational load and conversion stability.- 50% → 100% (days: 7) — full rollout if stable.

Primary metrics (per stage):- Conversion rate to paid/target action (primary business metric)- Average revenue per user (ARPU) or expected basket value- Click-through and funnel-drop rates on pricing page

Guardrail metrics:- Overall page load time and frontend error rate- Checkout success rate / payment failures- Refund rate or increased support tickets- Net promoter score / qualitative negative feedback spikes- Session abandonment rate

Monitoring cadence & thresholds:- Real-time alerts for severe anomalies (e.g., +5% absolute drop in conversion or +200% payment failures).- Rolling 24h and 7-day comparisons with statistical significance (e.g., p<0.05 or Bayesian credible interval showing >95% probability of harm).

Automated rollback criteria:- Conversion rate drop >10% relative to control with p<0.05 sustained for 4+ hours at ≥10% traffic- Payment failure rate >2x baseline for 30 minutes- Page error rate above SLA (e.g., >1% frontend errors) for 15 minutes

Manual rollback / hold criteria (require on-call + PM review):- Moderate conversion drop (5–10%) sustained 24+ hours- Significant negative user feedback trend or support volume increase (>50% over baseline)- Operational load causing backend degradation (latency or cache thrashing) not resolved within 2 hours

Instrumentation & safeguards:- Feature-flagged rollout with quick toggle- Shadowing/logging full user flows for diagnosing issues- Roll-forward patch path (fix + continue) vs full rollback if critical

Trade-offs:- Faster ramps learn quicker and reduce experiment duration but increase user exposure to potential harm; require stronger automated gates and confidence in metrics.- Slower ramps reduce exposure and allow richer signals (support trends, qualitative feedback) but prolong learning and tie up experiment resources.- Balanced approach: start fast at tiny % for technical safety, then moderate paced increases with stricter statistical checks at higher traffic — this optimizes learning while limiting risk.

Collaboration and Communication SkillsEasyBehavioral

81 practiced

Describe a specific code or pipeline review you participated in on an ML project. How did you provide constructive feedback, handle disagreements about style or architecture, and how did you react when someone gave you critical feedback?

Sample Answer

Situation: At my last company I reviewed a pull request for a training pipeline that added a new feature store join and retraining workflow for a customer-churn model. The PR changed data-loading code, added a DAG task, and introduced a custom serialization helper.

Task: My goal was to ensure correctness, reproducibility, and maintainability before merging—especially because this pipeline would run daily and impact production predictions.

Action:- I ran the branch locally and executed unit tests and a small end-to-end run on a sampled dataset to confirm behavior.- In the PR comments I gave targeted, constructive feedback: - Pointed out a potential race condition in the join logic and suggested a defensive null-check with a small code snippet. - Recommended replacing the custom serializer with our existing utils to avoid duplication and improve observability, citing the existing function and linking to docs. - Asked for a small integration test that asserts schema invariants after the feature-store join. - Suggested a brief design note in the repo describing DAG retry semantics so future engineers understand trade-offs.- When a teammate argued the custom serializer was slightly faster and clearer, I proposed measuring both approaches on a realistic sample and agreed to prioritize maintainability unless performance differences exceeded 10%. We ran a quick benchmark and found no meaningful difference, so we adopted the shared utility.- Later, a senior teammate critiqued my suggestion about the retry semantics as overly conservative. I thanked them, re-evaluated failure modes, and updated the design note to a compromise: two retries with exponential backoff and clearer alerting.

Result: The pipeline merged with additional tests and documentation. Production retrains ran for two weeks with zero failures related to the change. The review improved team conventions (we added the serializer utility to the onboarding docs) and reduced future churn.

Learnings: Be specific and evidence-driven in feedback, offer concrete fixes not just problems, and treat disagreements as experiments—measure when possible and be willing to change your stance when shown better data.

Clean Code and Best PracticesHardTechnical

78 practiced

Design an automated system that scans PRs for code smells specific to data-science code (e.g., heavy loops over dataframes, new dependencies without justification, dangling random seeds, use of print instead of logging). Describe heuristics vs ML approaches, integration points (hooks/CI), and how to present recommendations in PR comments without overwhelming developers.

Sample Answer

Requirements:- Catch common DS-specific smells: expensive row-wise loops over DataFrames, unnecessary new deps, hardcoded/dangling random seeds, use of print/plt.show in library code, heavy materialization (to_numpy()/list()) and data leakage patterns.- Low false-positive rate, explainable suggestions, fast (CI-friendly), and optional autofix/suggestions.- Integrates into git PR workflows and provides actionable, concise feedback.

Architecture (high level):- Linter service with two analysis engines: rule-based heuristics + optional ML-based classifier.- Pre-commit/CI hook and GitHub/GitLab app that posts summarized comments on PRs and annotates files inline.- Rule registry + metadata store to track rule hits, justification links, and severity.- Feedback loop: developers can mark recommendations as valid/ignore; labeled data feeds ML retraining.

Heuristics (fast, explainable):- AST/static analysis rules: detect loops iterating over DataFrame.itertuples()/iterrows(), use of apply with Python functions, calls to tolist/to_numpy inside map/concat—flag with recommended vectorized alternative and cost estimate.- Dependency diff check: parse requirements/pyproject changes and flag new deps without change in import usage or missing justification in PR description.- Seed detection: regex/AST find np.random.seed, random.seed usage in library code — suggest use of fixtures or parameterized RNG.- Print/logging: detect print statements or plt.show() in library modules; recommend logging with context.- Complexity heuristics: estimate potential O(n^2) via nested loops over DataFrame.shape usage.

ML approaches (complementary):- Train a transformer-based classifier on labeled PR hunks to predict “likely true code smell” using code tokens + diff context + file path + runtime traces if available.- Use anomaly detection on runtime profiles (when CI runs small sample jobs) to find slow/oom regressions.- Use ML to prioritize and rank findings by developer-perceived relevance (learned from feedback).

Integration points:- Pre-commit: fast heuristics to catch local issues.- CI job: run full analysis with heuristics + ML; optional lightweight micro-benchmark on representative datasets.- PR bot: posts top-k findings and inline comments for high-confidence issues; links to docs and quick fix snippets.- IDE plugin: realtime hints for developers.

Presenting recommendations without overwhelm:- Summarize at top: counts by severity (Critical/Warning/Info) and a single “what to fix now” action item.- Inline comments only for high-confidence issues; group similar low-confidence findings into one PR comment with examples and “learn more” links.- Provide suggested code snippets or automated patch proposals for trivial fixes.- Allow configuration per repo/team: thresholds, ignored rules, and a “learning” mode where bot suggests but doesn’t comment.- Rate-limit bot comments per PR and collate duplicates across files.

Governance & metrics:- Track precision/recall via developer feedback, time-to-fix, and post-merge incidents.- Periodic review to add new rules or retrain models.- Security/privacy: run analysis inside org-controlled CI, avoid sending code externally.

Example heuristic message (inline, high-confidence):"Warning: iterrows detected in data/prep.py:25 — iterating rows on DataFrame scales poorly. Consider vectorized operations (df['x'] = df['a'] + df['b']) or using DataFrame.assign. Link: [opt guide]."

This hybrid, feedback-driven approach balances explainability, speed, and evolving accuracy for DS codebases.

Model Evaluation and ValidationEasyTechnical

72 practiced

Your team is building a demand forecasting model, and someone suggests doing a standard random 80/20 train-test split to save time. Walk through why that would be a problem for this kind of data, how you'd structure the training, validation, and test splits instead, and how you'd make sure your validation setup would catch issues like seasonal effects or the model's performance quietly degrading over time before you ever see production data.

Sample Answer

A random 80/20 split shuffles rows before splitting, so it would let the model train on data that comes chronologically after some of the test points. In forecasting, that is a leak: the model gets to see information it would never have at real prediction time (for example, training on next year's demand while being tested on this year's), so offline metrics on that random split look artificially good and will not reflect how the model does once it faces truly unseen future dates.

Structuring the splitsInstead of shuffling, keep the data in time order and cut it into three contiguous chunks:- Training set: the earliest, largest chunk of history.- Validation set: the period right after training, used to pick the model and tune hyperparameters.- Test set: the most recent contiguous period, held out untouched until the very end, used once to estimate real-world performance.

For example, with three years of daily demand data, I might train on year 1 plus the first half of year 2, validate on the second half of year 2, and reserve all of year 3 as the final test set.

Because a single validation window can be misleading (it might land on an unusually quiet or unusually busy period), I would validate using multiple folds instead of one. This is often called walk-forward validation (also called rolling-origin or time-series cross-validation): train on an initial window, validate on the next chunk of time sized to match the forecast horizon (for example the next 4 weeks, if the model forecasts 4 weeks out), then slide the training window forward and repeat, collecting a validation metric per fold. You can either expand the training window each time (keep all history) or use a fixed-size sliding window that drops the oldest data as new data comes in; the sliding window is useful if older demand patterns are no longer representative of current behavior.

Catching seasonalityIf demand has a yearly cycle (for example holiday spikes), a validation fold that only covers a few low-season weeks will look fine while completely missing the period the model actually struggles with. So the set of validation folds needs to span at least one full seasonal cycle, and I would specifically check the fold(s) that land on last year's holiday period, comparing predicted versus actual demand for the same calendar period across years.

Catching quiet performance degradation before productionTwo things I would build directly into this validation setup:1. Track the validation metric per fold over time, not just the overall average. If error is creeping up in the most recent folds, that is a sign of concept drift (the relationship between features and demand shifting), showing up before it ever hits production.2. Weight the most recent fold(s) more heavily when deciding whether the model is production-ready, since recent performance is the best available proxy for what production will look like tomorrow.

In production, I would keep this same discipline going: retrain and re-validate on a defined cadence with the newest data, and monitor live forecast error against actuals so real drift surfaces quickly instead of being discovered months later in a post-mortem.

Feature Engineering and SelectionMediumTechnical

26 practiced

Given a dataset suffering from multicollinearity among numeric features, explain how Variance Inflation Factor (VIF) is computed and how you'd use VIF to decide which features to drop, combine, or transform. Provide a Python snippet (pseudocode acceptable) that computes VIF for a DataFrame of numeric features.

Sample Answer

Approach (brief): VIF measures how much the variance of a coefficient is inflated due to multicollinearity. For feature j, VIF_j = 1 / (1 - R_j^2) where R_j^2 is the R-squared from regressing feature j on all other features. Higher VIF means stronger multicollinearity. Common thresholds: VIF > 5 (moderate concern) or VIF > 10 (serious).

Python snippet (uses statsmodels; pseudocode-ready):

python

import pandas as pd
import statsmodels.api as sm
from statsmodels.stats.outliers_influence import variance_inflation_factor

def compute_vif(df):
    """
    df: DataFrame of numeric features (no target, no constant column).
    Returns DataFrame with VIF per feature.
    """
    X = df.copy()
    X = sm.add_constant(X)  # adds intercept for stability
    vif_data = []
    for i, col in enumerate(X.columns):
        if col == 'const':
            continue
        vif = variance_inflation_factor(X.values, i+1)  # +1 because const at pos 0
        vif_data.append((col, float(vif)))
    return pd.DataFrame(vif_data, columns=['feature', 'VIF']).sort_values('VIF', ascending=False)

How to act on VIF:- If VIF >> threshold: consider dropping one of correlated features (prefer domain knowledge / predictive importance).- Combine features: create aggregates or principal components (PCA) to capture shared variance.- Transform: apply log/scaling or orthogonalize features (e.g., residualize one vs others).- Use regularized models (Ridge) that handle multicollinearity without dropping features.

Key points:- Remove constant or near-constant cols before computing VIF.- Very high multicollinearity can cause singular matrices; drop perfectly collinear columns first.- Complexity: O(p) regressions each with O(n p^2) cost => roughly O(p^3) for large p.

Hypothesis Testing and InferenceMediumTechnical

48 practiced

Write a Python function that accepts a contingency table (2D numpy array) and automatically selects and runs the appropriate test: chi-square test when expected counts are adequate, Fisher's exact test for 2x2 small tables, or Monte Carlo chi-square approximation when table is larger with low counts. Return the test used, test statistic if applicable, and p-value.

Sample Answer

Approach: compute expected counts under independence. If table is 2x2 and any expected < 5 -> Fisher's exact. If any expected < 5 for larger tables -> use Monte Carlo chi-square (simulate tables under null by multinomial with cell probabilities = expected / N). Otherwise use Pearson chi-square (scipy.stats.chi2_contingency).

python

import numpy as np
from scipy.stats import chi2_contingency, fisher_exact
from numpy.random import default_rng

def auto_contingency_test(table, monte_carlo_iters=10000, random_state=None):
    """
    table: 2D numpy array of non-negative counts
    Returns dict: {'test': str, 'statistic': float|None, 'p_value': float}
    """
    table = np.asarray(table)
    if table.ndim != 2:
        raise ValueError("Input must be a 2D array")
    if (table < 0).any():
        raise ValueError("Counts must be non-negative")
    N = table.sum()
    if N == 0:
        raise ValueError("Table has zero total count")

    # expected counts under independence
    row_sums = table.sum(axis=1, keepdims=True)
    col_sums = table.sum(axis=0, keepdims=True)
    expected = row_sums @ col_sums / N

    low_expected = (expected < 5).sum()
    rows, cols = table.shape

    # 2x2 small -> Fisher exact
    if rows == 2 and cols == 2 and low_expected > 0:
        # fisher_exact expects a 2x2 integer array
        oddsratio, p = fisher_exact(table)
        return {'test': "Fisher's exact (2x2)", 'statistic': oddsratio, 'p_value': p}

    # if any expected < 5 -> Monte Carlo chi-square
    if low_expected > 0:
        rng = default_rng(random_state)
        p_cell = (expected / N).ravel()  # probabilities for multinomial
        # observed chi2
        chi2_obs, _, _, _ = chi2_contingency(table, correction=False)
        sims = 0
        exceed = 0
        for _ in range(monte_carlo_iters):
            sim_flat = rng.multinomial(N, p_cell)
            sim_table = sim_flat.reshape(table.shape)
            chi2_sim, _, _, _ = chi2_contingency(sim_table, correction=False)
            if chi2_sim >= chi2_obs:
                exceed += 1
            sims += 1
        p_mc = (exceed + 1) / (sims + 1)  # add-one smoothing
        return {'test': "Monte Carlo chi-square", 'statistic': chi2_obs, 'p_value': p_mc}

    # otherwise standard chi-square
    chi2, p, dof, exp = chi2_contingency(table, correction=False)
    return {'test': "Chi-square test", 'statistic': chi2, 'p_value': p}

Key points:- Use Fisher's exact for 2x2 small expected counts (exact conditional test).- For larger tables with low expected counts, Monte Carlo simulates tables under the independence null via multinomial(N, expected/N) and compares chi-square statistics.- Otherwise use Pearson chi-square (no Yates correction here).Complexity: computing expected O(R*C); Monte Carlo O(iter*R*C). Edge cases: non-integer counts, zero total, very small sample sizes; multinomial simulation does not preserve margins (it approximates null of independence). Alternative: for exact tests on larger tables, consider network algorithms to sample conditional tables (more complex).

A and B Test DesignEasyTechnical

53 practiced

Explain how to compute and interpret a 95% confidence interval for the difference in conversion rates between treatment and control. Demonstrate how you would present that interval to a non-technical stakeholder and what decisions you might recommend based on whether the interval includes zero.

Collaboration and Communication SkillsMediumTechnical

58 practiced

An A/B test shows statistically significant uplift but the product manager questions if the change is practically meaningful. How would you explain statistical significance, confidence intervals, and practical significance to convince or correct the PM's interpretation?

Sample Answer

Situation: We ran an A/B test and the result is "statistically significant" but the PM doubts whether the change is practically meaningful.

Explanation (concise, non-technical then slightly technical):- Statistical significance means the observed difference is unlikely to be due to random chance given our sample and assumptions. It answers “Is there evidence of an effect?” not “Is the effect big or valuable?”- Confidence interval (CI) gives a range of plausible values for the true effect size (e.g., lift in conversion). A 95% CI of [0.5%, 1.5%] means we’re 95% confident the true lift lies in that range given our data — it quantifies uncertainty and precision.- Practical significance asks whether the effect size (and its CI) matters for the business: does a 0.6% lift translate to meaningful revenue, retention, or cost savings after accounting for implementation cost and risk?

How I’d communicate to the PM:1. Show the point estimate + 95% CI and translate into business metrics (e.g., extra users/day, revenue/month).2. Compare the CI to a pre-defined Minimum Detectable or Minimum Valuable Effect (MVE/MDE). If the entire CI is above MVE, it’s both statistically and practically significant. If the CI overlaps MVE, we’re uncertain.3. Present a simple cost–benefit: incremental revenue vs. cost to build/maintain and risk (rollback complexity).4. If uncertain, propose next steps: run longer to narrow the CI, segment analysis to find where impact is concentrated, or run a follow-up experiment (smaller, targeted rollout).

Example phrasing for the PM:“Our test shows a statistically significant 0.9% lift (95% CI: 0.2%–1.6%). That means the true lift is likely small but positive. If each 1% lift equals $50k/month, the CI corresponds to $10k–$80k/month. Compare that to the $40k one-time engineering cost: the lower bound suggests it might not pay off, the upper bound does. We should either collect more data to tighten the CI or run a staged rollout while monitoring key metrics.”

Practice Data Scientist questions across all topics

Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Data Scientist jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Google Data Scientist (Entry Level) Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Understanding Role Expectations and Team Dynamics

Practice Interview

Study Questions

Motivation for Google and Data Science

Practice Interview

Study Questions

Background and Experience Narrative

Practice Interview

Study Questions

Technical Phone Screen - Coding and SQL

What to Expect

Tips & Advice

Focus Topics

Problem-Solving Approach and Communication

Practice Interview

Study Questions

Python for Data Manipulation and Problem-Solving

Practice Interview

Study Questions

SQL Fundamentals and Data Querying

Practice Interview

Study Questions

Onsite Round 1 - Statistics and Experimentation

What to Expect

Tips & Advice

Focus Topics

Interpreting Results and Business Context

Practice Interview

Study Questions

Probability and Statistical Fundamentals

Practice Interview

Study Questions

Hypothesis Testing and Statistical Inference

Practice Interview

Study Questions

A/B Testing and Experimental Design

Practice Interview

Study Questions

Onsite Round 2 - Technical Interview (Advanced Coding)

What to Expect

Tips & Advice

Focus Topics

Writing Clean, Production-Quality Code

Practice Interview

Study Questions

Problem-Solving Under Pressure and Adaptability

Practice Interview

Study Questions

Data Structures and Algorithm Efficiency

Practice Interview

Study Questions

Onsite Round 3 - Machine Learning and Applied Modeling

What to Expect

Tips & Advice

Focus Topics

Unsupervised Learning and Exploratory Analysis

Practice Interview

Study Questions

Feature Engineering and Data Preparation

Practice Interview

Study Questions

Model Evaluation and Validation

Practice Interview

Study Questions

Supervised Learning Algorithms and Model Selection

Practice Interview

Study Questions

Onsite Round 4 - Product Sense and Behavioral

What to Expect

Tips & Advice

Focus Topics

Communicating Technical Analysis to Non-Technical Stakeholders

Practice Interview