2026年2月面了Block，岗位是Cash App Trust and Safety团队里偏中级的senior DS。没拿到offer（他们选了一个在欺诈/风控建模上更有针对性经验的人），但流程足够完整，我可以给你一个真实的全貌。
Block的DS面试结构： Recruiter screen（30分钟，标准） DS phone screen（60分钟，SQL + 1道统计题） Onsite：共4轮 SQL deep dive 产品和指标 统计和ML Behavioral / leadership
SQL轮。 比大多数都难。题目不是“写个GROUP BY”这种。我这套包含window function、在transactions表上做self-join，以及一个关于用rolling window检测异常行为的问题。如果你对LAG/LEAD和PARTITION BY不熟，得补。他们内部用BigQuery，至少面试官有一次提到BQ的语法。
产品和指标轮。 这轮最有意思。他们给了一个场景：“Cash App上线了一个新功能，帮助用户追踪周期性支出。你怎么衡量它是否有效？”我需要定义成功指标、识别潜在混杂因素，并设计A/B test。他们会深挖实验设计：随机化单位是什么、在P2P支付场景下如何处理network effects、你能接受的最小可检测效应量是多少。
统计和ML。 覆盖概率（基础条件概率、Bayes）、模型评估指标，还有一个在欺诈检测场景下处理类不平衡的问题。他们想听到SMOTE / 重采样的讨论以及替代方案。
整体感觉这套DS loop更像严格的ML eng面试，而不是那种“会不会在Tableau里画图”的DS面试。把统计和实验设计好好准备起来。
5 条回复
analyst_ana (Primly starter)
peer-to-peer 产品的 A/B testing 里的 network effects 问题其实很难。用户互动时，标准的 SUTVA 假设就不成立了。他们是希望你给出「正确」答案，还是只是展示你知道这个问题的存在？
由 AI 翻译，查看原文
ds_dmitri (Primly starter)
更偏后者。我说正确答案是 cluster-based randomization（按社交图谱的 cluster 做随机，而不是按单个用户），但我也坦白这在落地上很复杂；更简单的备选是用一个完全不同的用户 holdout，这些用户和 treatment 组的连接尽可能少。他们看起来更满意的是我理解取舍，而不是一定要给出完美方案。
由 AI 翻译，查看原文
ml_mike (Primly starter)
在欺诈检测里做类别不平衡，对那个职位来说就是基本功。提 SMOTE 没问题，但也要聊 precision-recall 的权衡和校准。那种你优化 AUC，但真正关心的是在某个阈值下的实际 false positive rate 的欺诈模型，是实战的人才会懂的东西，Block 这种公司的面试官也会在意。
由 AI 翻译，查看原文
de_derek (Primly starter)
BQ 语法和标准 SQL 大体没问题，但要小心 DATE_DIFF 和 TIMESTAMP 相关函数。BigQuery 在日期类型上很烦，会用一些方式坑你一把，如果你只熟 Postgres 语法很容易中招。
由 AI 翻译，查看原文
Primly Team
在这种 DS 面试流程里，有一关经常被低估：把 case 或产品轮变成一份明确的决策备忘录。面试官往往想看你能否从一个模糊的功能想法，走到一个可衡量的判断，而不只是罗列指标。
一个好用的结构： 从决策开始：“Ship, iterate, or roll back?（上线、迭代，还是回滚？）”，以及对应的时间跨度。 定义一个与用户价值绑定的 North Star，再加 2 到 4 个 guardrail（信任、support 负担、延迟等）。 说明你会先选哪种评估设计（可行就 A/B，否则 diff-in-diff 或 matched cohorts），以及最大的混杂因素是什么、你会怎么验证。 收尾时说清楚：什么结果会改变你的建议，以及你会额外查看哪个后续切片（新用户 vs 老用户、重度用户、不同地区）。
你做这轮时最意外的是什么？下次在产品或指标轮你会怎么做得不同？
由 AI 翻译，查看原文