Block数据科学家面试真题与SQL编程2026
一句话总结
Block的数据科学家面试，从来不是考你能不能写出一条JOIN语句，而是看你能否用数据定义问题、主导决策。大多数候选人败在把SQL当成技术题来刷，而不是业务推理的工具。正确的判断是：面试官要的不是“语法正确”，而是“逻辑闭环”——你写的每行代码，必须对应一个可解释的商业假设。答得最好的人，往往不是刷了1000道LeetCode的人，而是能用三条SQL讲出完整用户流失分析的人。
不是你在陈述数据，而是数据在为你作证。薪资结构上，Block为L4级别提供$140K base、$200K RSU（分四年）、15% bonus，总包接近$500K，但只有30%的候选人能走到最终debrie，因为他们输在了“看起来专业，实则无判断力”的陷阱里。真正的筛选标准，藏在第四轮的case study中：你能不能在数据不全、需求模糊的情况下，主动定义“值得分析的问题”？大多数人以为是技术面，其实是产品思维的伪装测试。
适合谁看
如果你正在准备Block（前Square）的数据科学家岗位，且目标是L3到L5级别，这篇文章是为你写的。你不缺SQL基础，也刷过LeetCode中等难度题，但你在模拟面试中总被反馈“分析不够深入”或“缺乏业务sense”——这说明你还在用“学生思维”应对“决策者测试”。本文适用于那些已经通过简历筛选、即将进入技术轮的候选人，尤其是有1-5年经验、来自金融科技、电商或SaaS背景的数据从业者。你不缺工具能力，缺的是Block内部真实的判断标准。比如：在hiring committee（HC）讨论中，一名候选人写出了完美的窗口函数，但因未能解释“为什么选择7天滑动平均”而被否决；
另一人仅用三张表关联，却因清晰定义了“欺诈高发商户的识别阈值”而通过。这种差异不在技术，而在判断优先级。你适合看这篇文章，如果你曾困惑于“为什么我答得全对却没过”，或“面试官问的和我准备的完全不是一回事”。你不是来学语法的，你是来学Block人真正相信什么的。
面试流程为什么不是技术筛选，而是决策权测试？
Block的数据科学家面试流程共五轮，每轮60分钟，跨度2-3周。第一轮是30分钟HR电话，确认动机与背景匹配度。第二轮是45分钟SQL + 15分钟统计基础，由一线数据科学家主持。第三轮是产品分析case，考察数据与业务结合能力。
第四轮是深度技术面，涉及建模、AB测试设计与系统设计。第五轮是跨职能案例，与产品、工程、风控代表共同讨论一个真实历史问题。表面上看是技能递进，实则是决策权的逐步移交。面试官不是在评估“你会不会”，而是在判断“我敢不敢把一个问题交给你独立处理”。
以2025年Q2的一场真实debref会议为例，一名L4候选人第二轮SQL表现极佳，写出复杂CTE结构，但在第三轮被否。原因记录在HC notes中：“能够执行预设分析，但无法主动定义问题边界。当被问‘假设商户欺诈率上升，你会如何定位？’，他直接跳入‘查交易表JOIN商户表’，而未先确认‘上升是绝对值还是比率’、‘是否季节性波动’或‘新商户占比变化’。
”反观通过者，她在同一问题中先提出三个假设：“1. 新商户审核机制失效；2. 某类高风险行业渗透增加；3. 地理集中性爆发”，再对应设计SQL验证路径。不是你会写子查询，而是你是否知道该查什么。
第四轮的建模面更明显。一名候选人用XGBoost跑出高AUC，但被质疑：“你有没有考虑模型上线后的解释性成本？风控团队需要向商户解释拒单原因。”他回答“可以用SHAP”，但未提前纳入特征可解释性设计。最终结论是：“技术能力达标，但不具备跨职能协作所需的决策透明度。
”Block的数据科学家不是后台支持，而是决策发起者。你的SQL不是为了“出报告”，而是为了“定策略”。流程设计的深层逻辑是：越往后，越少给你明确问题，越多要求你定义问题。这才是真正的筛选器。
SQL真题背后的真实考察点是什么？
Block的SQL面试题从不来自题库，而是从真实业务场景抽象而来。例如一道高频题：“找出过去30天内，交易金额突增但活跃天数下降的商户，并分析其风险特征。”表面是多表关联与条件筛选，实则考察三层能力：1. 业务定义能力（“突增”是绝对值还是相对？下降是否显著？
）；2. 数据建模理解（交易表、商户表、行为日志表的粒度是否对齐？）；3. 异常处理意识（缺失值、重复记录、时区问题）。
内部hiring manager曾分享一个案例：两名候选人在同一题中写出几乎相同的SQL。一人写：
`sql
WITH active_days AS (
SELECT merchantid, COUNT(DISTINCT DATE(timestamp)) as activedays
FROM transactions
WHERE DATE(timestamp) BETWEEN '2025-03-01' AND '2025-03-30'
GROUP BY merchant_id
),
transaction_stats AS (
SELECT merchant_id,
SUM(amount) as total_amount,
AVG(amount) as avg_amount
FROM transactions
WHERE DATE(timestamp) BETWEEN '2025-03-01' AND '2025-03-30'
GROUP BY merchant_id
)
SELECT t.merchantid, t.totalamount, a.active_days
FROM transaction_stats t
JOIN activedays a ON t.merchantid = a.merchant_id
WHERE t.totalamount > (SELECT PERCENTILECONT(0.95) WITHIN GROUP (ORDER BY totalamount) FROM transactionstats)
AND a.activedays < (SELECT AVG(activedays) - STDDEV(activedays) FROM activedays);
`
另一人则先提问：“‘突增’是相对于该商户自身历史，还是行业均值？如果按全局分位数，高频低额商户可能被误判。”然后写出基于商户个体趋势的版本：
`sql
WITH historical_baseline AS (
SELECT merchant_id,
PERCENTILECONT(0.75) WITHIN GROUP (ORDER BY SUM(amount)) AS medmonthly
FROM transactions
WHERE DATE(timestamp) BETWEEN '2024-10-01' AND '2025-02-28'
GROUP BY merchantid, DATETRUNC('month', timestamp)
GROUP BY merchant_id
),
current_period AS (
SELECT merchant_id,
SUM(amount) as curr_amount,
COUNT(DISTINCT DATE(timestamp)) as curr_days
FROM transactions
WHERE DATE(timestamp) BETWEEN '2025-03-01' AND '2025-03-30'
GROUP BY merchant_id
)
SELECT c.merchantid, c.curramount, c.curr_days,
(c.curramount - h.medmonthly) / NULLIF(h.medmonthly, 0) as growthrate
FROM current_period c
JOIN historicalbaseline h ON c.merchantid = h.merchant_id
WHERE (c.curramount > h.medmonthly 2)
AND c.currdays < (h.medmonthly / 30 0.5); -- 假设月均活跃天数
`
第一版被标记为“执行者”，第二版被标记为“决策者”。不是你写不写CTE，而是你是否意识到基准选择决定结论。Block的SQL面试不是语法考试，而是假设检验的前端。你写的WHERE条件，本质上是你的业务判断。HC讨论中明确记录：“我们不需要更多能写JOIN的人，我们需要能定义‘风险’的人。”真正的考察点，是你的代码能否成为会议桌上说服他人的证据链。
为什么80%的人输在AB测试设计这一轮？
第四轮的AB测试设计是Block数据科学家的最大淘汰区。典型题目如：“我们想测试新风控规则对欺诈率的影响，但担心误杀率上升。如何设计实验？”大多数人立即回答“随机分组、A/B对比、看p值”，但这恰恰是被淘汰的原因。不是你不懂方法，而是你忽略了Block的核心约束：商户体验不可逆。
在一次真实的跨部门debref中，一名候选人提出“将新规则随机推给10%商户”，被风控负责人当场挑战：“如果新规则误杀了高价值商户，我们无法恢复信任。”候选人回应“可以事后补偿”，负责人摇头：“补偿不是解决方案，是失败的补救。”最终HC结论是：“缺乏对业务不可逆性的认知。”通过者的做法完全不同。她先问：“当前规则的误杀率是多少？
哪些商户被频繁误杀？”然后提出分阶段实验：第一阶段仅监控，不执行；第二阶段在低风险商户中灰度；第三阶段结合商户生命周期设计异步实验。她甚至建议用合成控制法（synthetic control）替代随机化，避免对真实商户造成影响。
这不是统计知识问题，而是权力意识问题。你有没有意识到，你的实验设计会直接决定某个商户是否能继续收款？Block的AB测试面，本质是测试你是否理解“数据决策的社会成本”。
大多数人还在背“样本量计算公式”，但面试官想听的是：“我建议不启动A/B测试，因为风险不对称——欺诈损失可量化，但商户流失的长期价值不可逆。”这种判断，才是L5级数据科学家的门槛。不是你能不能算p值，而是你敢不敢说“这个实验不该做”。
另一个常见错误是忽略时间窗口。一名候选人设计实验为期7天，但被质疑：“商户交易周期是月度的，7天数据能否反映真实行为变化？”他未能回答。通过者则主动提出：“建议观察至少两个完整周期，并检查滞后效应，因为商户可能在被拦截后延迟申诉。”真正的问题不是统计严谨性，而是时间粒度与业务节奏的对齐。你的测试设计，必须嵌入现实世界的节拍中，而不是教科书的真空里。
如何应对跨职能案例面的真正挑战？
第五轮的跨职能案例面是Block独有的设计，由产品、工程、数据、风控代表共同参与。题目通常来自过去6个月的真实争议事件，例如：“2025年1月，新商户注册转化率下降12%，但内部无产品变更。请分析原因并提出对策。”这不是让你“出报告”，而是让你主导一次跨部门对齐会议。
真实场景发生在2025年4月：一名候选人进入会议室后，立即打开笔记本开始写SQL。产品代表打断：“我们还没确认问题是否存在。”候选人愣住。工程代表补充：“上周有CDN故障，可能影响前端埋点。”数据候选人这才转向问：“是否有监控报警？日志完整性如何？”但已失去主导权。HC评语：“被动响应，而非引领讨论。”最终被淘汰。
通过者则开场说：“我建议先验证三个层面：1. 数据准确性——是否有埋点丢失或ETL延迟；2. 外部因素——支付渠道、设备分布、地域变化；3. 内部策略——风控规则、审核队列积压。”她主动提出先查监控系统，确认数据可信，再分析。
当工程代表提到CDN问题时，她立即说：“那我们先排除前3天数据，用后28天做基准。”她甚至调出第三方网络监测数据（如Cloudflare状态页）佐证。整个过程，她不是在“回答问题”，而是在建立分析秩序。
这才是跨职能面的真正挑战：你不是专家，而是协调者。你的技术能力只是入场券，真正考验的是你能否在信息混乱、利益冲突中，用数据建立共同认知。薪资中高达$200K的RSU，不是为写SQL发的，是为承担这种决策协调责任发的。你必须意识到，会议室里的每个人都有KPI，你的任务不是“正确”，而是“可行且被接受”。不是你展示多聪明，而是你让别人愿意跟随你的分析路径。
准备清单
- 精通PostgreSQL语法，特别是窗口函数（ROW_NUMBER、RANK）、CTE递归、日期序列生成。Block使用PG作为主要分析数据库，不是MySQL或BigQuery。
- 掌握至少一种因果推断方法：合成控制、双重差分（DID）、工具变量。AB测试面中，随机化常不可行，必须能提出替代方案。
- 熟悉支付业务核心指标：GTV（总交易额）、take rate（抽佣率）、fraud rate（欺诈率）、MOT（平均交易额）、activation rate（激活率）。能用SQL从原始表计算这些。
- 准备3个完整案例，每个包含：问题定义、假设提出、SQL验证、结论建议。案例必须来自真实业务，如“分析退款率上升”、“评估新定价策略”。
- 系统性拆解面试结构（PM面试手册里有完整的[数据科学家面试]实战复盘可以参考），特别是如何将技术分析转化为决策建议。
- 模拟跨职能会议：找朋友扮演产品、工程、风控，练习在干扰中保持分析框架。重点训练“先确认数据可信，再分析趋势”的话术。
- 了解Block的核心产品线：Square POS、Cash App、Tidal、Block Bank（新业务）。能说出各业务的数据特点，如Cash App的P2P交易高频低额，POS的B2B周期性强。
常见错误
BAD案例1：盲目使用全局基准
候选人被问：“找出高风险商户。”他立即写SQL查交易金额TOP 10%。面试官问：“如果一个农夫市场商户在丰收季交易量翻倍，算高风险吗？”他答：“可以加时间平滑。”但未意识到问题本质是个体趋势 vs 群体分布。GOOD做法是先按商户类型分群，再用历史基线比较变化率。不是“谁最大”，而是“谁变最快”。
BAD案例2：AB测试忽略执行成本
候选人设计实验时说：“随机分50%流量。”面试官问：“如果新规则导致商户无法收款，谁负责？”他答：“实验有监控，异常会停止。”但未提出熔断机制或补偿方案。GOOD做法是明确写出：“实验包含自动熔断逻辑，当误杀率>2%时暂停，并触发人工审核队列。”不是“统计显著”，而是“业务安全”。
BAD案例3：跨职能面中抢答
候选人听到问题后立刻说：“我查交易表JOIN商户表。”产品代表还没说完需求。结果被质疑：“你甚至不知道问题是否真实存在。”GOOD做法是先说：“我建议先验证数据准确性，再定位根因。”不是“快”，而是“稳”。在HC讨论中，这类候选人被标记为“技术冒进，缺乏协作意识”。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
为什么我SQL全对却没过？
因为你把面试当考试，而Block当决策模拟。2025年有一场真实案例：候选人写出完美SQL，计算出“欺诈率上升15%”，但未检查数据延迟——当天ETL pipeline故障，数据只到中午。面试官说：“你基于不完整数据下结论，现实中会导致误杀商户。”他被淘汰。通过者在同样题中先问：“今天的数据是否完整？
Kafka lag是多少？”然后才开始分析。不是代码正确，而是判断时机成熟。Block要的是在不确定性中做出负责任决策的人，不是在理想条件下跑通代码的人。
是否需要准备机器学习？
需要，但不是你以为的方式。L3-L4岗位不考手推公式，而是考“建模的代价”。例如面试官问：“用模型预测商户流失，你会选什么特征？”BAD回答：“RFM、交易频率、登录次数。
”GOOD回答：“我会避免使用支付失败次数，因为这可能由我们自身系统问题导致，用它建模会形成负向循环——系统越差，模型越预测流失，越减少资源投入。”真正的考察是：你有没有意识到模型会反向塑造现实？在HC讨论中，一名候选人因提出“模型解释性优先于AUC”而被特别标注。不是模型多准，而是它上线后是否可管理。
薪资和职级对应关系是什么？
L3：$110K base、$120K RSU（分四年）、10% bonus，总包约$300K。L4：$140K base、$200K RSU、15% bonus，总包近$500K。L5：$180K base、$350K RSU、20% bonus，总包可达$700K。但薪资差异不在技术，而在决策影响力。
L4以上需主导跨职能项目。一名L4候选人曾因“独立推动一次风控策略迭代，减少误杀12%”而获高评。RSU不是为写SQL发的，是为承担业务结果责任发的。你拿多少，取决于你敢扛多大风险。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。