Google Data Scientist Interview Guide

From hundreds of mock interviews, here's what catches candidates off guard about Google's Data Scientist role: the interview loop includes a dedicated statistics and probability round that most other big tech companies have dropped. Google still runs thousands of simultaneous A/B tests across Search, Ads, and Cloud, and they want DSs who can reason about multiple comparisons, interference effects, and metric sensitivity, not just fit an XGBoost model and call it a day.

Google Data Scientist Role

Google's DS org blends deep statistical work with product influence. You'll write BigQuery SQL against petabyte-scale logs tables, design A/B tests for Search ranking changes using Google's internal experimentation platform, and build causal inference models in Colab Enterprise notebooks. But you'll also spend real time in rooms with PMs and engineering leads, defending metric trade-offs and translating analysis into ship/no-ship recommendations. The role demands both technical depth and the ability to make a VP care about your one-pager.

A Typical Week

The thing the widget won't convey is how writing-heavy this job feels in practice. Experiment design docs, findings summaries, executive one-pagers: these aren't afterthoughts, they're primary deliverables that get scrutinized by peers before anything reaches a PM. Monday and Wednesday skew heavily toward meetings and cross-functional readouts (Search Quality PMs pushing back on your metric choices in a room of 12), which means you need to protect your analysis blocks aggressively or they'll evaporate.

Projects & Impact Areas

Search and Ads dominate the DS headcount because they dominate Google's revenue. You might be segmenting query intent types to evaluate a snippet relevance signal on the Search Quality team, while a colleague on Ads models heterogeneous treatment effects for auction bid optimization. Less visible but equally real is the infrastructure and operations research work: data center efficiency modeling, network capacity planning for Google Cloud, and supply chain optimization for hardware products like Pixel. These projects pull on linear programming and optimization under constraints, which is why Google's interview loop tests OR concepts that most other companies skip entirely.

Skills & What's Expected

The skill scores in the data tell a story worth reading carefully. Math and statistics are rated expert, ML is high, but modern AI and GenAI depth isn't emphasized for DS roles (that work lives with research scientists and MLEs). The underrated dimension is data visualization and executive communication, scored just as high as ML. You're expected to own the recommendation layer, translating complex statistical findings into clear narratives for stakeholders who won't read your notebook. Medium-level software engineering is sufficient: clean Python, solid BigQuery data modeling, no distributed systems design.

Levels & Career Growth

The widget shows the level bands and comp ranges, so here's the context it can't capture. The L5-to-L6 transition is where careers stall. L6 (Staff) requires demonstrated cross-team influence, meaning you're shaping the data science roadmap for a product area, not just executing analyses within one. It's a fundamentally different job, more strategy, less hands-on analysis. Getting your target level right before the recruiter screen matters because it determines your interview difficulty and the behavioral bar you'll be measured against.

Work Culture

Google requires three days per week in-office, with most DS teams coordinating Tuesday through Thursday as overlap days. The culture runs on peer review and data-driven rigor: expect your analyses to be scrutinized by other DSs and engineers before any recommendation moves forward. That raises the quality bar but also gives your work genuine visibility across the org.

Google Data Scientist Compensation

The vesting schedule looks generous up front, but the back half is where it bites. Years 3 and 4 vest significantly less, so your effective annual comp can quietly shrink unless refresh grants make up the difference. Refreshers aren't guaranteed, and from what candidates report, the size and timing vary widely even among strong performers.

Because the source data on Google's DS negotiation process is limited, take this as directional rather than gospel: the comp structure (base, equity, bonus) gives you multiple surfaces to negotiate against, and candidates with competing offers from peer companies tend to have more room to move. If you're sitting on another offer, don't leave it unmentioned. Silence rarely helps.

Google Data Scientist Interview Process

From what candidates report, the most common rejection trigger is insufficient depth across the stats-heavy rounds. Google's loop dedicates three separate stages (SQL & Data Modeling, Statistics & Probability, and Product Sense & Metrics) that all probe quantitative reasoning from different angles. Candidates who allocate most of their prep to ML and coding discover too late that those areas account for a smaller share of the overall signal.

Your interviewers don't make the hiring decision. They write up structured feedback, and a separate committee of people who've never met you reviews the full packet. One rough round won't automatically kill your chances, because the committee weighs aggregate signal across all seven stages.

That committee model changes how you should perform in each round. At Google, your answers need to survive being paraphrased in a written summary by someone who may not share your exact framing. Structured, clearly reasoned explanations that translate well onto paper will serve you better than conversational rapport alone.

Google Data Scientist Interview Questions

1import numpy as np
2
3def bootstrap_p99_diff(control, treatment, n_boot=5000, alpha=0.05, rng_seed=0):
4    """Returns (point_estimate, ci_low, ci_high) for treatment - control p99."""
5    rng = np.random.default_rng(rng_seed)
6    control = np.asarray(control)
7    treatment = np.asarray(treatment)
8
9    def p99(x):
10        return np.quantile(x, 0.99, method="linear")
11
12    point = p99(treatment) - p99(control)
13
14    boots = np.empty(n_boot)
15    n_c = control.shape[0]
16    n_t = treatment.shape[0]
17
18    for b in range(n_boot):
19        c_s = control[rng.integers(0, n_c, size=n_c)]
20        t_s = treatment[rng.integers(0, n_t, size=n_t)]
21        boots[b] = p99(t_s) - p99(c_s)
22
23    lo = np.quantile(boots, alpha / 2)
24    hi = np.quantile(boots, 1 - alpha / 2)
25    return float(point), float(lo), float(hi)
26

1/* Weekly queue wait time percentiles for batch jobs (BigQuery)
2   Assumed table: `infra.batch_job_attempts`
3   Columns: job_id, attempt_id, submit_ts, start_ts, state, cluster, region
4*/
5WITH first_attempt AS (
6  SELECT
7    job_id,
8    attempt_id,
9    submit_ts,
10    start_ts,
11    state
12  FROM `infra.batch_job_attempts`
13  WHERE submit_ts IS NOT NULL
14  QUALIFY ROW_NUMBER() OVER (
15    PARTITION BY job_id
16    ORDER BY submit_ts ASC, attempt_id ASC
17  ) = 1
18), cleaned AS (
19  SELECT
20    job_id,
21    DATE_TRUNC(DATE(submit_ts), ISOWEEK) AS week_start_date,
22    TIMESTAMP_DIFF(start_ts, submit_ts, SECOND) AS wait_seconds
23  FROM first_attempt
24  WHERE state != 'CANCELED'
25    AND start_ts IS NOT NULL
26    AND start_ts >= submit_ts
27)
28SELECT
29  week_start_date,
30  COUNT(*) AS jobs_started,
31  -- APPROX_QUANTILES returns an array of quantiles; for N=100, offsets map to percent.
32  APPROX_QUANTILES(wait_seconds, 100)[OFFSET(50)] AS p50_wait_seconds,
33  APPROX_QUANTILES(wait_seconds, 100)[OFFSET(95)] AS p95_wait_seconds
34FROM cleaned
35GROUP BY week_start_date
36ORDER BY week_start_date;

1from __future__ import annotations
2
3from dataclasses import dataclass
4from datetime import datetime
5from typing import Iterable, List, Dict, Any, Tuple
6
7
8@dataclass
9class RunBest:
10    length: int = 0
11    start_ts: datetime | None = None
12    end_ts: datetime | None = None
13
14
15def longest_high_util_runs(
16    rows: Iterable[Dict[str, Any]],
17    threshold: float,
18    step_seconds: int = 60,
19    top_k: int = 5,
20) -> List[Dict[str, Any]]:
21    """Compute longest continuous (no missing minutes) interval with cpu_util > threshold per cluster.
22
23    Args:
24        rows: Iterable of dicts with keys: minute_ts (datetime), cluster_id (hashable), cpu_util (float).
25        threshold: Strictly greater-than threshold for being in a high-util run.
26        step_seconds: Expected cadence in seconds, default 60.
27        top_k: Number of clusters to return.
28
29    Returns:
30        List of dicts: cluster_id, longest_minutes, start_ts, end_ts.
31    """
32    # Defensive copy into list so we can sort.
33    data = list(rows)
34    data.sort(key=lambda r: (r["cluster_id"], r["minute_ts"]))
35
36    best: Dict[Any, RunBest] = {}
37
38    cur_cluster = None
39    cur_len = 0
40    cur_start = None
41    cur_end = None
42    prev_ts = None
43
44    def flush_current_run(cluster_id: Any):
45        nonlocal cur_len, cur_start, cur_end
46        if cluster_id is None or cur_len == 0:
47            return
48        b = best.setdefault(cluster_id, RunBest())
49        # Prefer longer runs, then earlier start time.
50        if (cur_len > b.length) or (
51            cur_len == b.length and b.start_ts is not None and cur_start is not None and cur_start < b.start_ts
52        ) or (cur_len == b.length and b.start_ts is None and cur_start is not None):
53            b.length = cur_len
54            b.start_ts = cur_start
55            b.end_ts = cur_end
56
57    for r in data:
58        cid = r["cluster_id"]
59        ts: datetime = r["minute_ts"]
60        util = r["cpu_util"]
61
62        if cid != cur_cluster:
63            # New cluster. Flush prior run state.
64            flush_current_run(cur_cluster)
65            cur_cluster = cid
66            cur_len = 0
67            cur_start = None
68            cur_end = None
69            prev_ts = None
70
71        is_high = util > threshold
72        is_contiguous = (
73            prev_ts is not None and int((ts - prev_ts).total_seconds()) == step_seconds
74        )
75
76        if is_high:
77            if cur_len == 0:
78                # Start a new run.
79                cur_start = ts
80                cur_end = ts
81                cur_len = 1
82            else:
83                # Continue only if contiguous, otherwise start over.
84                if is_contiguous:
85                    cur_len += 1
86                    cur_end = ts
87                else:
88                    flush_current_run(cid)
89                    cur_start = ts
90                    cur_end = ts
91                    cur_len = 1
92        else:
93            # Not high, close any active run.
94            flush_current_run(cid)
95            cur_len = 0
96            cur_start = None
97            cur_end = None
98
99        prev_ts = ts
100
101    # Flush the last cluster.
102    flush_current_run(cur_cluster)
103
104    # Build sortable summary.
105    summary: List[Tuple[int, datetime, Any, datetime, datetime]] = []
106    for cid, b in best.items():
107        if b.length > 0 and b.start_ts is not None and b.end_ts is not None:
108            summary.append((b.length, b.start_ts, cid, b.start_ts, b.end_ts))
109
110    # Sort by length desc, start asc.
111    summary.sort(key=lambda x: (-x[0], x[1]))
112
113    out = []
114    for length, _, cid, start_ts, end_ts in summary[:top_k]:
115        out.append(
116            {
117                "cluster_id": cid,
118                "longest_minutes": length,
119                "start_ts": start_ts,
120                "end_ts": end_ts,
121            }
122        )
123    return out
124
125
126if __name__ == "__main__":
127    # Minimal sanity check.
128    from datetime import timedelta
129
130    base = datetime(2026, 1, 1, 0, 0, 0)
131    rows = []
132    # cluster A has a break (missing minute) that should split the run.
133    for i in [0, 1, 2, 4, 5]:
134        rows.append({"minute_ts": base + timedelta(minutes=i), "cluster_id": "A", "cpu_util": 0.9})
135    # cluster B has a continuous run of 4.
136    for i in [0, 1, 2, 3]:
137        rows.append({"minute_ts": base + timedelta(minutes=i), "cluster_id": "B", "cpu_util": 0.95})
138
139    print(longest_high_util_runs(rows, threshold=0.8))
140

1from __future__ import annotations
2
3from collections import Counter, deque
4from dataclasses import dataclass
5from datetime import datetime
6from typing import Deque, Dict, Iterable, Iterator, List, Optional, Tuple, Any
7
8
9@dataclass
10class Event:
11    ts: float  # seconds since epoch (or any monotone seconds)
12    dc: str
13    request_id: str
14
15
16def earliest_skew_timestamp(
17    events: Iterable[Tuple[float, str, str]],
18    window_seconds: float,
19    p: float,
20) -> Optional[float]:
21    """Return earliest ts where some dc exceeds p fraction within last window_seconds.
22
23    Online, amortized O(1) updates, assuming nondecreasing timestamps.
24
25    Args:
26        events: iterable of (ts, dc, request_id). request_id is unused here but realistic.
27        window_seconds: window size W.
28        p: fraction threshold in (0, 1]. Trigger if strictly greater than p.
29
30    Returns:
31        earliest triggering timestamp, or None.
32    """
33    if window_seconds < 0:
34        raise ValueError("window_seconds must be nonnegative")
35    if not (0 < p <= 1):
36        raise ValueError("p must be in (0, 1]")
37
38    q: Deque[Tuple[float, str]] = deque()  # (ts, dc)
39    counts: Counter[str] = Counter()
40    n_total = 0
41
42    # Track current max count to avoid scanning all DCs each time.
43    # This can become stale on decrements, so we lazily repair by rescanning when needed.
44    max_dc = None
45    max_count = 0
46
47    def expire(now: float):
48        nonlocal n_total, max_dc, max_count
49        cutoff = now - window_seconds
50        while q and q[0][0] <= cutoff:
51            ts0, dc0 = q.popleft()
52            counts[dc0] -= 1
53            n_total -= 1
54            if counts[dc0] == 0:
55                del counts[dc0]
56            # max_count might become stale, repair lazily later.
57
58        if n_total == 0:
59            max_dc = None
60            max_count = 0
61
62    def repair_max_if_needed():
63        nonlocal max_dc, max_count
64        if n_total == 0:
65            max_dc = None
66            max_count = 0
67            return
68        # If max_dc is missing or its count is less than max_count, we might be stale.
69        if max_dc is None or counts.get(max_dc, 0) != max_count:
70            # Full rescan, O(#dcs), happens only when max becomes stale.
71            dc, c = max(counts.items(), key=lambda kv: kv[1])
72            max_dc, max_count = dc, c
73
74    for ts, dc, _rid in events:
75        expire(ts)
76
77        q.append((ts, dc))
78        counts[dc] += 1
79        n_total += 1
80
81        # Update max optimistically.
82        if counts[dc] >= max_count:
83            max_dc = dc
84            max_count = counts[dc]
85
86        # Repair if decrements made max stale.
87        repair_max_if_needed()
88
89        if n_total > 0 and max_count > p * n_total:
90            return ts
91
92    return None
93
94
95if __name__ == "__main__":
96    # Example: DC1 dominates after 3 events in a window.
97    evs = [
98        (0.0, "dc1", "a"),
99        (1.0, "dc1", "b"),
100        (2.0, "dc2", "c"),
101        (3.0, "dc1", "d"),
102    ]
103    print(earliest_skew_timestamp(evs, window_seconds=10.0, p=0.6))
104

The heaviest two areas, stats and ML, compound each other in Google's loop because infrastructure experimentation problems (like testing a Borg scheduling change) force you to build a causal model and a forecasting model in the same answer. That overlap means weak stats foundations don't just cost you one round; they undermine your ML answers on capacity planning and anomaly detection too. The most under-practiced area is operations research, where questions about server fleet reliability or cross-region request allocation require constrained optimization thinking that no amount of A/B testing prep will cover.

Practice questions calibrated to Google's infrastructure-heavy DS loop at datainterview.com/questions.

How to Prepare for Google Data Scientist Interviews

Alphabet's annual revenue topped $400 billion in fiscal year 2025, with Google Search & Other still representing about 57% of the total. The company's stated bets right now: evolving Gemini, building autonomous AI agents, and transforming Search from a retrieval system into a synthesized answer engine. Compute infrastructure is expanding at a staggering pace, including gigawatt-scale data center partnerships with companies like NextEra Energy.

What does that mean if you're interviewing? You should expect interviewers to probe whether you can reason about the tensions these bets create. A good "why Google" answer isn't "I love the scale of Search." It's something like: "AI Overviews risk cannibalizing the ad clicks that fund 57% of revenue, and I want to work on the experimentation frameworks that measure whether synthesized answers actually shift long-term engagement enough to justify that tradeoff." Or point to Google Cloud (about 11% of revenue and growing fast) and articulate a specific measurement problem you'd want to own there. The bar is naming a real analytical tension at Google, not expressing admiration for the company. Interviewers at Google's hiring committees review candidate packets without context from small talk, so your specificity in product sense answers is what survives into the written feedback.

Try a Real Interview Question

1WITH joined AS (
2  SELECT
3    f.cluster,
4    f.week_start,
5    CAST(f.forecasted_incidents AS INT64) AS forecasted_incidents,
6    CAST(c.engineer_hours AS INT64) AS engineer_hours,
7    CAST(c.mean_minutes_per_incident AS INT64) AS mean_minutes_per_incident
8  FROM incident_forecast_weekly f
9  JOIN oncall_capacity_weekly c
10    USING (cluster, week_start)
11), capacity AS (
12  SELECT
13    cluster,
14    week_start,
15    forecasted_incidents,
16    CAST(FLOOR(engineer_hours * 60.0 / NULLIF(mean_minutes_per_incident, 0)) AS INT64) AS capacity_incidents
17  FROM joined
18)
19SELECT
20  cluster,
21  week_start,
22  forecasted_incidents,
23  capacity_incidents,
24  GREATEST(0, forecasted_incidents - capacity_incidents) AS expected_shortfall
25FROM capacity
26ORDER BY week_start, cluster;

Google's coding problems lean toward BigQuery-flavored SQL (STRUCT types, ARRAY functions, window functions over partitioned tables) and Python that tests clean analytical thinking rather than competitive-programming tricks. The round is a gate, not a differentiator, so you need fluency without needing to be brilliant. Build that fluency with DS-calibrated problems at datainterview.com/coding.

Test Your Readiness

The widget above shows where your gaps are. Fill them with targeted practice at datainterview.com/questions, paying extra attention to any category where you scored below confident.