一句话总结
数据科学面试不是考你会多少种机器学习模型，而是考你在数据不完整、业务目标模糊、时间压力下的决策质量。SQL和Python的考核本质上是两道筛选器：SQL筛掉那些不懂业务表结构的人，Python筛掉那些只会调包不懂数据流的人。2026年的毕业生如果还在LeetCode硬刷SQL题、在Kaggle上复制粘贴Notebook，会在面试官追问"这个join为什么慢"和"这个特征为什么 leakage"时直接出局。正确的判断是：把SQL当成业务建模工具来练，把Python当成数据生产代码来写，面试才能过。
适合谁看
这篇文章写给三类人。第一类是2026年毕业的统计学、计算机科学、应用数学硕士，手头有1-2个实习但不知道面试底层逻辑的人——你们简历上的"随机森林调参"项目，面试官三句话就能问穿。第二类是从金融咨询、生物统计、社会科学转行的职场新人，Python和SQL是自学的，代码能跑但经不起review——你们的短板不是语法，而是不知道工业界的代码标准是什么。第三类是正在准备Google、Meta、Stripe、Databricks这些公司数据科学岗位的求职者——你们需要知道的不是"考什么题"，而是"面试官在纸上记什么、在debrief会上说什么"。
不适合的人是：已经在大厂做ML Engineer想转Data Science的（你们的问题在别处）、完全零基础想靠三个月转行的人（这篇文章救不了你）、以及想找学术界研究岗的人（考核维度完全不同）。
薪资预期必须现实。2026年硅谷entry-level Data Scientist的base在$120K-$155K之间，RSU按公司规模从$15K到$80K不等（pre-IPO公司给期权，上市后换算），bonus普遍是base的10%-15%。总包范围$150K-$250K。纽约、西雅图同等级别，芝加哥、奥斯汀低10%-15%。不要拿2021年的包裹来锚定预期，那个市场已经死了。
SQL考核不是考语法，而是考你如何翻译业务问题
面试官在SQL环节最常犯的错误，是以为自己在考"会不会写"。不是会不会写，而是能不能在写之前，先问出那个让全场安静的问题。
场景还原：Stripe的SQL面试。面试官给了一张transactions表，让你找出"过去30天内有连续三天以上活跃的高风险商户"。你花15分钟写了一个三层嵌套、窗口函数拉满的查询，自认为漂亮。面试官在最后两分钟问："如果这张表是分区表，按merchant_id和date分区，你的查询会扫描多少数据？"你愣住。这不是语法问题，这是成本意识问题。
另一个场景来自Google的debrief会议室。HC（Hiring Committee）正在讨论一个候选人的SQL轮反馈。面试官的note写道："候选人写出了正确的CTE结构，但当我问'如果user_id有null值，你的left join结果会比预期多还是少'时，候选人犹豫了90秒，然后说'应该不影响吧'。"这个候选人最终被拒，不是语法错了，而是暴露了对数据质量的盲区。
SQL准备的核心误判是把时间花在"多少种窗口函数"上。不是窗口函数的种类，而是窗口函数的业务语义。rownumber()用于去重和排名，rank()用于处理并列，lag()/lead()用于计算环比——但面试官真正想听的是："我选择rownumber而不是group by，是因为需要保留原始行的粒度，方便下游聚合。"
正确的练习方式是拿真实业务表来练。不是LeetCode上那几张只有id和value的抽象表，而是有eventtime（需要处理时区）、devicetype（需要处理枚举值映射）、user_agent（需要解析提取信息）的脏表。练习时给自己加约束：查询必须在5秒内跑完，意味着你要考虑索引、分区、避免全表扫描。练习结束后问自己三个问题：这个查询如果上生产，监控告警怎么设？如果下游表schema变更，哪里会break？如果数据延迟了2小时，结果还准吗？
Python考核的不是算法能力，而是数据流控制能力
Python轮是SQL轮的延伸，但考核维度完全不同。SQL考的是"在约束下正确表达"，Python考的是"在混乱中建立秩序"。
一个常见的insider场景：Meta的数据科学Python面试。面试官给了一个CSV文件，大约200万行，要求你"随便看看，告诉我们你能发现什么"。这是面试中最危险的指令。错误的做法是立刻pd.readcsv然后.describe()和.valuecounts()一股脑丢出来。正确的做法是暂停，问三个问题：这行数据的业务定义是什么（不是技术定义，是业务定义）？缺失值是随机的还是有模式的？我需要给谁看结论，他们关心什么？
面试官在Python轮真正观察的，不是你是否记得groupby的语法，而是你的代码结构是否经得起生产环境的审视。一个具体的BAD vs GOOD对比：BAD版本是写一个200行的脚本，从头到尾顺序执行，变量名是df1、df2、df_final。GOOD版本是写一个DataPipeline类，分离数据加载、清洗、转换、输出四个阶段，每个阶段有明确的输入输出类型提示，关键步骤有断言检查。
Python轮的高频陷阱是pandas滥用。不是pandas不好，而是候选人把pandas当成了唯一工具。面试官会追问："如果数据装不下内存呢？"这时候懂dask或polars是加分，但更重要是展示你知道什么时候该离开pandas——"我会先采样做EDA，确定分析方向后再决定是全量处理还是用Spark"。另一个追问方向是代码可测试性："你怎么保证这个特征工程逻辑在明天数据来了之后还能跑？"BAD答案是"我手动检查过"。GOOD答案是"我写了一个pytest fixture，用固定种子生成模拟数据，验证输出schema和统计分布"。
2026年的一个趋势是Python轮中加入"实时协作编码"环节。面试官会共享一个Jupyter环境，看着你写。这时候的致命错误是沉默编码。正确的节奏是：先写注释 outlining 你的步骤，每完成一个chunk就 verbalize 你的假设和验证方式，遇到不确定的地方直接说"这里我需要查一下文档"而不是瞎猜。面试官不是在找全能的人，是在找能清晰表达自己思考过程的人。
机器学习考核的不是模型精度，而是问题定义能力
数据科学面试中的ML轮，最大的认知陷阱是把它和ML Engineer的面试混淆。ML Engineer考的是"怎么把模型推上线、怎么调参让AUC涨0.5%"，Data Scientist考的是"这个问题该不该用ML解、解完之后业务方能不能用"。
具体场景：Databricks的ML面试。面试官描述了一个场景："销售团队想预测哪些客户会churn，这样他们可以提前干预。"候选人立刻开始讲XGBoost和特征工程。面试官打断："等等，销售团队现在怎么干活的？"候选人答不上来。正确的展开方式是先问六个问题：churn的定义是什么——是取消订阅，还是30天未登录，还是连续两个月未付费？销售团队的"提前干预"具体指什么——是发优惠券、打电话、还是调整产品功能？干预后如何衡量效果——是用对照组还是历史同期比较？数据可得性如何——销售活动记录是否被系统捕获？预测结果是给销售每天看一次还是实时推送？模型错了（把不会churn的人标记为高风险）的成本是什么？
这些问题的答案决定了模型架构。如果churn定义模糊，你可能需要先做一个定义对齐的项目，而不是直接建模。如果销售干预是手动的，你可能需要一个可解释的规则集而不是黑盒模型。如果数据不可得，你可能需要用代理变量或者先做数据收集。
ML轮的准备，不是准备更多算法，而是准备更多"为什么不用这个算法"的故事。不是"我用了随机森林因为它精度高"，而是"我一开始尝试了线性模型作为baseline，发现特征间有非线性交互，所以切换到GBDT，但保留了线性模型用于特征重要性解释"。面试官想听到的是决策树，不是模型树。
案例面试不是考答案，而是考你在压力下的结构化
案例面试（Case Interview）是数据科学面试中最容易被低估的环节。它不是咨询公司的专利，Google、Meta、Uber的数据科学岗都有。
一个真实的hiring manager对话场景：Uber的Eats数据科学团队在讨论一个候选人。案例题是"Uber Eats的订单取消率在周末上升了15%，你怎么分析？"候选人的回答是：先看取消率定义，确认是用户主动取消还是餐厅取消还是骑手取消；然后按城市、时段、餐厅类型拆解；最后定位到具体原因。这个候选人拿到了offer。另一个候选人的回答是：立刻建一个预测取消率的模型。Hiring manager的反馈是："他在用解决方案找问题，不是用问题找解决方案。"
案例面试的正确结构不是固定的，但有一个反直觉的原则：不是给的信息越多越好，而是给的信息越结构化越好。一个有效的框架是：先花2分钟clarify问题（确认指标定义、时间范围、业务背景），然后给出假设树（可能的原因分支），按影响力*可验证性排序，选择top 2-3个假设深入，最后给出actionable建议并说明需要什么数据来验证。
压力场景的处理尤其关键。面试官会故意给模糊信息、打断你的思路、或者在你讲到一半时改变条件。常见的trick包括："如果我们没有用户行为数据呢？""如果产品团队坚持认为这是技术bug不是业务问题呢？""如果CEO要求明天给结论呢？"这时候的BAD反应是慌张或者硬撑。GOOD反应是："在没有X数据的情况下，我会用Y作为代理，同时说明这个代理的局限性是Z，需要在获得真实数据后重新校准。"
行为面试不是考故事，而是考你的决策痕迹
行为面试（Behavioral）在数据科学面试中通常占20%-30%的权重，但它的筛选作用经常被误解。不是考你"有没有领导力"，而是考你"在模糊和冲突中如何决策"。
一个具体的debrief场景：Google的HC在讨论两个背景相似的候选人。A的简历上有一个"优化推荐系统点击率"的项目，B的简历上有一个"发现推荐系统优化后用户平均观看时长下降"的项目。面试官对B的评价更高。原因是B展示了"指标冲突时的权衡能力"——不是单方面追求优化目标，而是能识别出目标之间的张力并主动沟通。
行为面试的准备，不是背诵STAR法则的故事，而是准备3-4个"决策痕迹"（decision trail）：一个展示你在数据不足时如何行动，一个展示你在技术理想与业务现实冲突时如何取舍，一个展示你在团队分歧时如何推动共识。每个故事要包含具体的数字：不是"提升了性能"，而是"把查询P95从800ms降到200ms，但增加了10%的内存占用，经过评估认为可接受"。
一个常见的错误是过度准备"成功故事"。面试官在2026年已经对"我如何带领团队超额完成KPI"免疫了。更有力的故事是"我如何识别到一个项目不该做并说服了团队"——这展示了判断力，而判断力是数据科学家最稀缺的品质。
准备清单
- SQL：用真实业务表练习，至少完成5个包含数据质量处理、时区转换、缓慢变化维的复杂查询。每个查询写完后，口头解释执行计划和潜在优化点。（PM面试手册里有完整的SQL实战复盘可以参考，特别是关于如何在面试中展示"查询背后的业务思考"那部分）
- Python：重构一个你过去的分析项目，目标是让代码能通过code review。标准包括：类型提示、单元测试、文档字符串、配置与代码分离。准备回答"如果数据量扩大100倍，这个代码哪里会崩"。
- ML：准备两个项目故事，一个展示"为什么选这个模型"，一个展示"为什么不选另一个模型"。每个故事包含：业务目标、约束条件、候选方案、选择依据、事后验证。
- 案例：找同学或朋友做mock case，要求对方在15分钟时突然改变问题条件。练习在压力下重新梳理分析框架，而不是执着于原定方向。
- 行为：用文档记录你过去2年中的5个关键决策，每个决策包含：当时的信息状态、可选动作、选择依据、实际结果、事后复盘。面试前复习，确保能流畅讲述。
- 公司研究：针对每个目标岗位，研究其数据科学团队的技术博客、公开演讲、开源项目。准备至少一个"基于你们的工作，我想了解……"的问题，展示你做了功课。
- 模拟面试：至少完成3次全流程模拟面试，包括SQL、Python、ML、Case、Behavioral五轮。每次模拟后录屏回放，观察自己的 verbalize 是否清晰，是否有过多填充词。
常见错误
错误一：把LeetCode当圣经。BAD表现：候选人能写出最优复杂度的SQL查询，但当面试官问"这个查询在你公司的数据仓库里要跑多久"时，完全没概念。GOOD表现：候选人写完后主动说"这个查询如果在大表上做nested loop join会很慢，我会考虑用hash join或者预先过滤分区"。区别不是技术水平，是成本意识。
错误二：把Kaggle项目当经验。BAD表现：候选人花10分钟讲述如何在Titanic数据集上达到99%准确率，但讲不清楚这个模型的业务落地场景。GOOD表现：候选人讲述一个真实（或高度仿真）的业务问题，包括如何与stakeholder沟通需求、如何处理数据收集中的偏差、如何设计A/B测试验证效果。区别不是项目难度，是问题真实性。
错误三：忽视"不合理"的面试问题。BAD表现：面试官问"如果只能用SQL不能做特征工程，你怎么做预测"，候选人回答"这不可能，实际工作中不会这样"。GOOD表现：候选人回答"这是一个约束优化问题，我会考虑用SQL的窗口函数构造滞后特征，用分箱处理非线性，虽然效果会打折扣但能在约束内给出最优解"。区别不是技术能力，是面对约束的创造性。
FAQ
Q: 我没有大厂实习，只有学校项目和Kaggle经验，怎么弥补？
关键不是经验来源，而是经验呈现方式。一个常见的误区是觉得Kaggle经历"低人一等"。实际上，Kaggle Grandmaster在简历上写得当，比普通大厂实习更有区分度。问题在于大多数人对Kaggle项目的描述是"参加了XX比赛，排名XX%"——这没有任何信息。正确的呈现方式是重构为一个业务故事：问题是什么（不是"预测房价"，而是"什么因素驱动了不同区域房价的非线性差异"），你做了什么（不是"用了XGBoost"，而是"发现官方特征集忽略了通勤可达性，用POI数据构造了新的特征族"），结果如何量化（不是"RMSE降低了10%"，而是"这个特征在holdout测试中对高价位区间的预测提升最大，说明它对 luxury segment 有解释力"）。对于学校项目，重点突出"我定义的问题"而不是"我用的方法"。面试官知道学校项目的数据是干净的，他们想看到的是你是否有能力在干净数据上提出有价值的问题。另外，可以主动提及"我意识到这个项目的数据和现实差距在于XX，如果让我重做，我会YY"——这种自省能力比项目本身更稀缺。
Q: 面试官追问"为什么不用深度学习"时，我该怎么回答？
这个问题本身就是陷阱。面试官不是在问深度学习好不好，而是在考你的技术判断力。BAD回答是罗列深度学习的缺点（"需要大量数据""黑盒不可解释"）——这显得你在防御。GOOD回答是先确认场景："在这个问题中，我们的约束是……"然后给出具体的技术经济分析。例如："如果这是一个实时推荐场景，用户行为特征更新频率在分钟级别，且需要解释为什么推荐这个商品，我会选择GBDT而不是深度学习，因为训练迭代快、特征重要性可直接输出。但如果SKU数量在千万级别且用户历史行为丰富，我会考虑用two-tower模型做召回，再用GBDT做精排——不过这需要验证离线A/B测试的基础设施是否ready。"这个回答展示了：你知道技术选型不是非黑即白，你知道不同架构的trade-off，你知道技术决策要和基础设施匹配。这才是面试官想听的。
Q: 非计算机背景（如统计、生物、经济）的候选人，如何证明自己能写出工业级代码？
这是2026年最常见的问题之一，因为数据科学岗的候选人背景越来越多元。核心策略不是掩盖背景，而是把背景转化为差异化优势。统计学背景的人应该强调实验设计和因果推断能力——"我知道随机化不足时怎么估计treatment effect"，这是纯CS背景候选人常缺的。生物背景的人可以强调处理高维小样本数据的经验——"我在XX项目中处理过p>>n的情况，这教会我谨慎对待过拟合"。但光有差异化不够，代码能力需要具体证据。最有效的做法是：在GitHub上维护一个repo，包含一个完整的数据分析项目，从数据获取、清洗、分析到报告生成，全部代码化、可复现。README中要说明环境配置、依赖版本、如何运行测试。更进一步，如果有和工程师合作的经验，描述一次具体的代码review经历——"我的pull request被指出变量命名不清晰，我后来采用了Google Python Style Guide中的命名约定"——这比任何证书都更有说服力。面试官不是在找CS科班生，是在找能快速融入工程文化的人。展示你"被纠正过并改进了"，比展示你"一直很好"更可信。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。