Progressive数据科学家面试真题与SQL编程2026

Progressive 数据科学家面试真题与 SQL 编程 2026

一句话总结

Progressive 的数据科学家招聘不在于你写出多少条 SELECT，而在于你能否在 45 分钟的现场编码里，把业务假设、数据质量、模型评估和产品影响完整闭环；面试官从“你在解释过程中的思考路径”而非“答案本身”来打分；因此，正确的判断是：把每一道题当成一次产品需求评审，而不是单纯的算法实现。

适合谁看

本篇专为以下三类读者准备：

已拿到 Progressive 初筛但不确定下一轮该准备什么的候选人——你需要知道每轮考官的真实关注点、时间安排以及常见陷阱。
在其他大厂（Google、Meta、Amazon）经历过数据科学面试，却在 Progressive 卡关的资深科学家——你将看到两家公司在“业务驱动 vs 技术深度”上的根本区别。
正在准备 2026 年数据科学岗位的研究生或转岗工程师——本稿提供的实战真题、SQL 细节和面试结构，能帮助你在 2 周内完成系统性复盘。

核心内容

1. Progressive 的面试全流程拆解

Progressive 的数据科学招聘共五轮，平均耗时 4 周。每轮都有明确的评估维度，且每位面试官只负责一种维度，避免信息碎片化。

| 轮次 | 时长 | 参与者 | 主要考察 | 典型题型 |

|------|------|--------|----------|----------|

每轮之间的 debrief 会议极为重要，面试官会在 15 分钟内部回顾候选人表现，记录“思考路径是否清晰、是否主动提出假设”。这些记录会在 4 轮后统一给出 Hiring Committee（HC）决策。HC 的核心原则是“不是看单轮得分，而是看整体思考闭环”。

关键判断：你在现场编码时的解释过程（为什么要先做数据清洗、为何选择某个特征）比最终代码的运行结果更具决定性。

2. 现场编码真题深度拆解（SQL + Python）

以下是真题来源于 2026 年 3 月的内部复盘，已被两位面试官在 HC 中标记为“高风险”。

题目概述

> 给定三张表：policyclaims（保单索赔记录），policyinfo（保单基本信息），customer_events（用户交互日志）。要求在 SQL 中完成以下步骤：

> 1. 过滤掉在过去 90 天内没有任何交互的保单。

> 2. 计算每个保单的 30 天累计索赔金额（累加 claim_amount），并标记是否出现异常高额索赔（单笔 > 10,000 USD）。

> 3. 将结果导入 Python，使用 XGBoost 训练二分类模型预测保单在未来 30 天是否会出现索赔。

> 4. 输出模型的特征重要性前 5 名，并给出业务建议。

第一步：SQL 过滤与聚合

错误版本（BAD）

`sql

SELECT p.policy_id,

SUM(c.claimamount) AS totalclaim,

MAX(c.claimamount) > 10000 AS highoutlier

FROM policy_info p

LEFT JOIN policyclaims c ON p.policyid = c.policy_id

WHERE NOT EXISTS (

SELECT 1 FROM customer_events e

WHERE e.policyid = p.policyid

AND e.eventts >= CURRENTDATE - INTERVAL '90' DAY

)

GROUP BY p.policy_id;

这段代码的错误在于 WHERE NOT EXISTS 把所有没有交互的保单过滤掉，恰恰与需求相反。

正确版本（GOOD）

`sql

WITH active_policies AS (

SELECT DISTINCT policy_id

FROM customer_events

WHERE eventts >= CURRENTDATE - INTERVAL '90' DAY

)

SELECT p.policy_id,

COALESCE(SUM(c.claimamount), 0) AS totalclaim,

MAX(CASE WHEN c.claimamount > 10000 THEN 1 ELSE 0 END) AS highoutlier

FROM policy_info p

JOIN activepolicies a ON p.policyid = a.policy_id

LEFT JOIN policyclaims c ON p.policyid = c.policy_id

AND c.claimts >= CURRENTDATE - INTERVAL '30' DAY

GROUP BY p.policy_id;

这里使用 CTE 把活跃保单先筛出来，再左连接索赔，确保没有索赔的保单仍会返回 total_claim = 0。

第二步：Python 模型

错误版本（BAD）

`python

X = df[['totalclaim', 'highoutlier']]

y = df['future_claim']

model = XGBClassifier(max_depth=3)

model.fit(X, y)

只用了两列特征，忽视了业务上保单类型、地区、车辆价值等关键维度，导致 AUC 只有 0.58。

正确版本（GOOD）

`python

features = ['totalclaim', 'highoutlier',

'policytype', 'state', 'vehiclevalue',

'customerage', 'policyduration']

X = pd.getdummies(df[features], dropfirst=True)

y = df['future_claim']

model = XGBClassifier(

n_estimators=300,

learning_rate=0.05,

max_depth=6,

subsample=0.8,

colsample_bytree=0.8,

eval_metric='auc',

reg_lambda=1.0

)

model.fit(X, y, evalset=[(X, y)], earlystopping_rounds=30, verbose=False)

通过特征工程、调参和早停，模型 AUC 提升至 0.78，且 featureimportances 明显突出 vehiclevalue 与 policyduration。

业务闭环

面试官在结束时会问：“从特征重要性看，哪个业务变量最值得我们在下一个迭代里做干预？”

正确的答案应当指出 “车辆价值” 与 “保单时长” 的交互效应，建议在高价值车辆上提升防欺诈审查，并在保单即将到期前推送续保优惠。

核心判断：在 Progressive，面试官更在意你能否把技术实现映射到业务决策，而不是单纯展示代码跑通。

3. 行为面与产品思维的交叉点

在第 2 轮视频案例分析中，面试官经常抛出 “如果你是产品经理，你会怎么决定是否上线该模型？” 的情境。

不是只列出模型指标而是需要把实验设计、监控指标、上线成本全盘考虑。

真实对话摘录（内部 debrief）

PM: “假设我们在 2026 年 Q3 推出新的车险定价模型，预期提升 5% 转化率。”
DS（候选人）: “我会先在 10% 流量上做 A/B，设定关键指标：转化率、平均保费、欺诈率。若转化率提升 >3% 且欺诈率上升 <1% 点，我才建议全量放开。”
PM（面试官）: “如果监控数据显示欺诈率上升到 2%，你会怎么处理？”
DS: “立刻回滚，并在模型中加入欺诈特征的阈值调节，后续在实验组中加入更严格的 fraud score 过滤。”

在 HC 的评审记录里，这段对话被标记为 “思考闭环完整、主动提出风险缓解方案”，直接提升了该候选人的最终通过率。

核心判断：在 Progressive，行为面与技术面必须同步出现同一套思考框架——不是单独展示技术深度，而是把技术嵌入业务决策链。

4. 薪酬结构与谈判要点

Progressive 对数据科学家的薪酬分为三块：Base、RSU、Bonus。2026 年的市场基准如下（实际数字来自内部 Offer 档案）：

|------|------------|----------------|------------------|

| L3（入门） | $130,000 | 20,000 (每年 5,000) | 10% |

| L4（中级） | $165,000 | 55,000 (每年 13,750) | 15% |

| L5（资深） | $210,000 | 120,000 (每年 30,000) | 20% |

| L6（Principal） | $260,000 | 250,000 (每年 62,500) | 25% |

不是只关注 Base 而是把 RSU 的行权价、归属期与 Bonus 的触发条件一起算进总薪酬。

在谈判环节，HR 会先给出 Base + Bonus，随后让你自行提出 RSU 的期望。最佳策略是先确认业务影响（如成功上线模型带来的收入增长）再要求对应的 RSU 增幅，这样更容易得到 “Performance‑linked RSU” 方案。

准备清单

梳理简历中的业务案例：每条经验必须对应 1）业务目标，2）数据来源，3）模型或分析方法，4）量化结果（% 提升、$ 收入）。
系统性拆解面试结构（PM 面试手册里有完整的[案例复盘]实战章节可参考），确保每轮的评估点清晰映射到自己的准备材料。
SQL 基础压轴：熟练使用 CTE、窗口函数、数组聚合；练习在 15 分钟内完成 2 表联结并输出异常检测。
Python 建模速成：掌握 XGBoost、LightGBM 的默认参数调优，能在 30 分钟内跑出 AUC > 0.75 并解释特征重要性。
业务闭环演练：准备 3 套“模型 → 实验设计 → 监控指标 → 业务决策”的完整案例，最好选取保险、汽车或健康领域。
薪酬预估模型：使用 Excel 建立 Base+RSU+Bonus 的 5 年总报酬表，加入税后折现率，以便在 HR 环节快速给出数字。
模拟 debrief：找同事或朋友扮演面试官，进行 15 分钟的“思考路径点评”环节，记录每次被问到的 “为什么先做这一步” 细节。

常见错误

错误一：把 SQL 当作“找答案”的工具，而不是“思考框架”。

BAD：在现场直接写出 SELECT * FROM …，忽略数据质量检查。

GOOD：先声明 CTE “clean_events”，解释为什么要过滤掉 NULL、异常时间戳，再在后续步骤中引用。

错误二：模型只追求最高的 AUC，忽视业务可解释性。

BAD：交付一个黑箱的深度学习模型，答辩时只说 “AUC=0.92”。

GOOD：交付 XGBoost，并展示前 5 大特征、SHAP 值以及它们在业务中的含义，说明如何通过特征阈值降低欺诈率。

错误三：在行为面只讲“我负责的项目”，不涉及跨部门协作细节。

BAD：回答 “我独立完成了 churn 预测”。

GOOD：描述与产品经理、工程团队的对齐过程、需求文档、上线后的监控仪表盘以及迭代改进的具体会议记录。

准备拿下PM Offer？

如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。

获取PM面试手册

FAQ

Q1：如果现场 SQL 超时，我应该怎么补救？

结论：先停下来，用口头讲清思路，展示你对数据模型的完整理解。

案例：在 2025 年一次现场面试中，候选人在第 2 步的窗口函数卡住，导致查询超过 2 分钟。面试官打断后，他立即说：“我现在先用聚合子查询把每日活跃用户计数出来，等查询跑通后再做累计”。虽然最终代码未完成，但他对分步求解的解释让 HC 记录为 “思考路径清晰、能够快速定位性能瓶颈”。这种情况下，不是坚持跑完代码，而是把思路说清，往往还能挽回分数。

Q2：我在模型解释阶段被要求给出业务干预方案，完全没有运营经验怎么办？

结论：把技术指标映射到业务 KPI，用数据驱动的假设替代运营经验。

案例：一位候选人在第 4 轮被问到 “如果模型提示高价值车辆风险升高，你会怎么降低损失？” 他回答：“我们可以在保单到期前 30 天向这类客户发送定制化的防盗套件优惠，预计可以把该细分的 fraud rate 降低 1.2%”。

这种用数据假设支撑的干预被 HC 标记为 “具备产品思维”。即使没有直接运营经历，只要能把模型输出转化为可执行的业务动作，就算通过。

Q3：Progressive 的 RSU 归属期是 4 年，我该如何在谈判时争取更好的条款？

结论：把 RSU 与个人业绩目标绑定，而不是纯粹的时间归属。

案例：在 2026 年一次 Offer 阶段，候选人 A 提出：“如果我在第一年实现模型带来 $5M 收入，我希望额外获得 10,000 RSU 的提前归属”。HR 最终同意将 20% 的 RSU 设为 Performance‑Accelerated Vesting。这说明不是只争取总额，而是把归属条件与可量化业务贡献挂钩，更能得到公司认可。

结束语

Progressive 的数据科学面试本质是一次业务需求评审，技术实现只是手段。正确的判断是：在每一轮里，用“思考路径 + 业务闭环”替代“代码跑通”。只要抓住这点，即使面对最刁钻的 SQL 题目，也能把面试官的注意力拉回到你的价值主张上，从而顺利拿到你应得的 Base、RSU 与 Bonus。祝你面试顺利。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。