Google 数据科学家面试实录 2026：面试流程与形式完整复盘

公司：Google 岗位：数据科学家 (Data Scientist) 面试形式：Virtual Onsite（3 轮技术 + BQ）结果：Pass → Offer

面试流程与形式

先说流程：L4 DS 的 VO 是 3 轮技术面 + BQ（有的 loop 会把 BQ 单独算一轮）。DS 的 coding 难度明显低于 SDE（LeetCode easy–medium 为主），真正的区分度在 SQL 的口径准确性、统计基本功、以及 case 讨论的结构化程度。狗家的题库很大，interviewer 的命题自由度很高，遇到新题很正常，代码不需要运行，但通常会要求写 test case 和 dry run。

三轮的结构大概是：第一轮 SQL + 数据问题，第二轮 coding（两道 medium 以下），第三轮实验设计 / case。每轮 45–60 分钟，前 5 分钟 self intro。Google 的 editor 是一个简单的文本框，没有代码运行功能，写完要自己 dry run 一遍并分析复杂度。整体考察的是 clarity of thought：怎么理解模糊问题、怎么把业务问题翻译成数据问题、怎么把结论讲给非技术的人听。

第一轮：SQL 与数据问题

题目背景是 YouTube 的用户行为表 watch_events(user_id, video_id, watch_seconds, event_date, platform)，要求完成三个查询：

每周新增用户数（新用户：该 user 第一次产生 watch 事件）；
新用户的次周回访率（W1 retention）：首周活跃的用户，下一周是否再次活跃；
按 platform 拆分最近 90 天的日均人均观看时长。

第一题我用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_date) 定位首次事件再按周聚合，写完主动提了优化：表如果是按 event_date 分区的，先裁剪分区再开窗。第二题一开始我用 self join 写「首周活跃 AND 次周活跃」，面试官提示可以先物化一个 user 级的「活跃周」表（DISTINCT user_id, week_no）再做相邻周的 join——这个改写既清楚又快，是这轮印象最深的一点：DS 的 SQL 考的是口径 + 效率，不是技巧炫技。

Follow-up 很典型：「如果 watch_seconds 有脏数据（比如 999 小时的异常值），你的留存率会怎么偏？」我讲了异常值会让「活跃」定义失真，建议先用分布检查（分位数）定义合理的活跃阈值，并把这个决策写进数据字典。这类「数据质量如何影响指标」的追问，Google DS 几乎必问。

第二轮：Coding（两道 medium 以下）

两道题：一道是数组的 sliding window 题（找满足条件的最小子数组长度），一道是字符串 + 哈希的计数题。难度都在 LeetCode medium 之下，但面试官的要求跟 SDE 轮一样：dry run、边界条件、复杂度分析。

这轮的 follow-up 偏「工程化改造」：第一题被问「如果数据是流式进来的（比如实时观看事件），你的解法要怎么改」，我讲了滑动窗口换成基于时间戳的队列 + 双端队列维护窗口和，并说明内存上界是窗口大小。面试官明显对「能把离线算法改造成流式」这点满意。

我的感受：DS 的 coding 不追求算法难度，考的是基础数据结构是否扎实 + 能不能把解法往数据场景迁移。准备时把高频 medium 题每道都想一个「流式 / 大规模」变体，比多刷 50 道题有用。

第三轮：实验设计——为一个功能改版设计 A/B 测试

题目：「YouTube 想把『相关视频』列表从右侧改成底部堆叠，请设计实验验证效果」。这轮没有代码，全程讨论，45 分钟里被追问了五个层次：

假设与指标：主指标我定了「单 session 观看总时长」（比点击率更能反映真实价值），guardrail 指标定「跳出率」和「举报率」，我解释了为什么不能只看 CTR——底部堆叠天然让前几个视频更突出，CTR 会虚高但用户可能更快离开。
实验单元：按 user 分桶而不是 session 分桶，避免同一用户跨桶污染；移动端和桌面端是否分层分析也讨论了（布局改动在两端的影响可能不同）。
样本量与时长：baseline 下估算 MDE（最小可检测效应）5% 相对提升、power 80% 所需的用户数，反推出要跑 2–3 周；强调必须跑满完整周以覆盖 weekday/weekend 差异，并提到 novelty effect 会让第一周读数偏乐观。
多重比较：如果同时看 10 个指标，p<0.05 里大概有 1 个是假阳性——要么用 Bonferroni 校正，要么事先指定唯一主指标。
结果沟通：如果 p=0.07 但点估计是 +3% 时长，怎么跟 PM 汇报？我给了「置信区间 + 业务影响量化（全量后每周多多少小时观看）+ 继续观测的成本」三层说法。

最后还追问了一个 SRM 检查：上线后先看两组流量比是否 50:50，偏差超过容差先查分桶逻辑再谈结论。这轮基本是 Google DS 统计知识图谱的完整巡礼，按「假设→指标→单元→样本量→时长→多重比较→解读」这条链准备，就是最优策略。

二、划重点（DS 轮怎么得分）

SQL 口径永远先定义：「活跃」「新用户」「留存」先说出你的定义再动手写，写完整句「生产环境我会怎么优化」。
统计追问有固定链路：Google 的 A/B 追问逃不出「指标选择 → 分桶单元 → 样本量 → 时长 → 多重比较 → 结果解读」六步，每步准备一个 backup 答案。
Coding 准备「流式变体」：每道高频题多想一步「数据是流式 / 超大规模时怎么改」，这是 DS 轮 follow-up 的高发区。
结论要能被非技术人听懂：case 和实验的最后一步永远是「怎么跟 PM/业务方讲」，用业务量（钱、时长、用户数）而不是统计量收尾。

三、Follow-up 的常见方向

Google DS 面试的 follow-up 集中在四类：数据质量（脏数据、口径变化对指标的影响）、规模（数据量 ×10 查询怎么改）、统计陷阱（peeking、多重比较、SRM、选择偏差）、业务解读（p 值边缘时怎么决策）。准备时给每类想两个真实案例，现场直接调用。

四、聊聊 BQ 重点 - Googleyness

BQ 的核心是评估 candidate 的 Googleyness。这个词看起来抽象，其实指的是候选人是否具备 Google 所看重的工作方式与价值观。它和亚麻的 Leadership Principles 在本质上非常相似。面试官通常会从几个维度来考察：团队合作能力、领导力、用户导向思维、解决问题的创造性，以及沟通与协作的效率。准备这部分时，建议使用 STAR 框架（Situation、Task、Action、Result）来组织答案。围绕你真实经历的故事展开，在此基础上可以适当添加细节或数据来强化影响力。一个好的故事不仅要展示结果，更要体现你在过程中如何影响他人、推动进展并从错误中学习。如果你已经准备过 Amazon 的 BQ，那么大部分素材都可以直接沿用，只需用 Google 的价值观语言进行微调即可。

面试总结

成功经验

先定义再计算：SQL 和实验设计都是先花 2–3 分钟把口径讲清楚，后面几乎没有返工。
统计链路当 checklist 用：六步链路每步都有 backup 答案，第三轮的连续追问基本在预期内。
coding 不恋战：两道题都控制在 15 分钟内完成，留足时间讲流式改造，面试官对工程化讨论明显更感兴趣。
结论用业务语言收尾：p=0.07 那题用「置信区间 + 业务量化 + 观测成本」三层答完，面试官直接说「this is how I’d present it」。

面试注意事项

时间管理：SQL 轮控制在 25 分钟写完三个查询，留 20 分钟给数据质量和优化追问。 别跳过定义：DS 轮最大的减分项是「指标口径没定义就开写」，被追问时被迫改口径非常被动。 统计细节不能含糊：peeking、SRM、多重比较是三个高频陷阱点，每个都要能展开讲 2 分钟。

💡 需要面试辅导？

如果你对准备技术面试感到迷茫，或者想要个性化的面试指导和简历优化，欢迎联系 Interview Coach Pro 获取一对一辅导服务。

👉 数据科学家 / DS 面试辅导：SQL、统计、A/B 测试与 DS 项目 mock
👉 联系我们获取专属面试准备方案