Revolut数据科学家面试真题与SQL编程2026
一句话总结
答得最流畅的候选人，往往在第二轮就被否掉——不是因为他们写不出窗口函数，而是因为把“分析逾期率”当成了纯技术题，而忽略了资金流动背后的用户行为模式。2026年Revolut数据科学家岗位的筛选标准已从“能写SQL”转向“能否用数据定义问题”，面试官不再关心你是否会用LAG()函数，而是看你是否能在模糊需求中锚定真正的业务变量。三个核心判断必须在首轮面试中完成：这不是一场关于查询语句的考试，而是一次产品逻辑的压力测试；
你提交的SQL不是给机器看的，是给下一位接手你分析的PM或风控经理看的；你展示的思维路径，必须能直接映射到Revolut正在推进的跨境资金沉淀项目。
适合谁看
这篇文章为三类人而写：第一类是已有1-3年数据分析或数据科学经验、正瞄准欧洲金融科技公司（尤其是Revolut、N26、Monzo）的中级从业者；第二类是北美或亚太背景的数据科学家，试图理解欧洲总部主导的技术评估逻辑，尤其是那些习惯用“机器学习模型复杂度”证明能力，却在欧洲面试中频繁卡在初级SQL case的人；第三类是已经通过简历筛选、收到第一轮HackerRank测试的候选人——你们即将面对的不是LeetCode风格的算法题，而是嵌套在真实业务场景中的多表关联与时间窗口陷阱。
如果你过去准备面试的方式是刷500道SQL题，这篇文章会直接推翻你的训练体系。因为Revolut要的不是“会写SQL的人”，而是“能用SQL发起对话的人”。你不需要精通PySpark，但你必须能在15分钟内向一个非技术风控主管解释清楚：为什么你选择用percent_rank()而不是ntile()来划分用户风险层级。
为什么Revolut的SQL面试和其他公司不一样？
不是考你会不会写JOIN，而是考你是否理解资金流如何驱动产品决策。大多数数据科学家准备面试时，把SQL当作编程语言来刷题，背诵窗口函数语法，记忆GROUP BY的执行顺序，甚至用LeetCode排行榜来衡量自己的水平。但2026年在Revolut，一场典型的SQL面试开场白是：“我们发现上周英国用户的跨境转账成功率下降了8%，你能查一下吗？
”——没有明确的表结构，没有字段清单，甚至没有时间范围。你需要做的第一件事不是写代码，而是反问：“我们定义的‘成功率’是支付发起到清算完成，还是到银行受理？”这才是面试的真实起点。
在一次真实的debrief会议中，两位面试官对同一位候选人给出了截然相反的评价。技术主管说：“他写的SQL很干净，用了CTE分层，还加了注释。”但业务负责人反驳：“他直接跳进了查询，连‘成功率’的定义都没确认。
如果他上线这个逻辑，会把临时冻结的交易算作失败，导致我们误判合作银行的接口稳定性。”最终HC（hiring committee）以3:1否决了该候选人。这就是关键差异：其他公司面试中，写错语法可能扣分，但在Revolut，跳过业务定义直接编码，直接出局。
另一个常见误解是：Revolut重视复杂查询。真实情况是，他们更警惕过度工程化。曾有一位候选人用三层嵌套子查询、加上ROW_NUMBER()和EXISTS判断，完成了“找出连续三天登录并完成转账的用户”题目。代码能跑通，但面试官当场追问：“如果这个查询每天要跑在5000万用户上，延迟会到多少？
有没有考虑分区剪枝？”候选人无法回答。相比之下，另一位候选人用简单datetrunc('day', createdat)配合lead()函数，分步输出中间表，并主动说明：“这里我假设transaction表已按userid和createdat分区，否则建议先建物化视图。”他被标记为“具备系统思维”。
这揭示了第一个“不是A，而是B”：不是考你SQL多复杂，而是考你是否意识到SQL是数据协作的起点，不是终点。第二个对仗是：不是你在向机器提问，而是你在向团队传递推理路径。第三个是：不是看你能否完成题目，而是看你能否重构题目。
2026年面试流程拆解：每一轮在筛什么？
Revolut数据科学家岗位的面试流程在2025年底完成重构，目前共四轮，每轮60分钟，全部远程进行，平均周期为18天。第一轮是HackerRank在线测试，45分钟完成两道SQL题。题目形式不再是“写一个查询返回某指标”，而是“根据一段产品背景描述和表结构，编写查询并解释你的假设”。
例如，一道真题是：“Revolut Business用户最近投诉‘费用不透明’，请分析上月每笔交易的费用展示与实际扣费的差异。”给出三张表：transactions、feerules、uilogs。考察点不是连接三张表，而是你是否意识到uilogs可能存在采样缺失，是否在代码中添加/ 假设uilogs为10%抽样日志 /注释。
第二轮是现场SQL白板，由两位数据科学家主持。这轮的核心不是写代码速度，而是对抗性推演。你写完一段查询，面试官会立刻提出：“如果这个逻辑用于实时风控策略，延迟超过200ms就会超时，你如何优化？”或“如果fee_rules表每天更新一次，但transactions是实时写入，你的JOIN策略会出什么问题？
”2026年新增了一个细节：候选人必须在写代码前，用三句话陈述“这个查询要支持什么决策”。说“帮助产品团队优化费用展示”得0分；说“识别高差异率用户群体，用于AB测试新费用弹窗设计”得满分。
第三轮是业务案例分析，由高级数据科学家+产品负责人联合主持。典型题目如：“波兰市场新上线了‘定期储蓄’功能，首月参与率仅1.2%，远低于预期。请用数据诊断原因。
”你有10分钟提问权，必须主动索取数据：用户画像分布、功能曝光路径、转化漏斗日志。曾有一位候选人直接开始构建留存模型，被当场打断：“你还没确认功能是否被正确曝光。”这场面试的评分标准是：30%看问题拆解，40%看数据验证路径，30%看沟通效率。
第四轮是Hiring Manager深度对谈，重点考察“影响边界”。问题如：“如果你发现某个分析结论与高管直觉相悖，如何推进？”或“如何向非技术团队解释p-value的实用性？”这轮没有SQL编码，但会回顾你前几轮的代码，问：“你在第二轮写的那个留存查询，如果用户在不同设备上登录，会不会重复计数？
我们OAuth系统如何处理多端会话？”——这说明：每一轮的输出，都会成为下一轮的输入。你的SQL不是一次性作业，而是持续可追溯的决策资产。
真题还原：一场典型SQL面试的全过程
场景设定：你正在参加第二轮现场SQL面试，面试官共享屏幕，给出以下信息：
- 表1：
usersessions，字段包括sessionid,userid,starttime,endtime,devicetype - 表2：
transactions，字段包括txnid,userid,amount,currency,status,created_at - 问题：“请找出过去30天内，至少完成3笔成功交易，且平均会话时长超过10分钟的用户。”
你开始写代码前，必须先确认三个隐含变量。第一，“成功交易”的定义是status = 'settled'，不包括'pending'或'reversed'——但面试官不会主动告诉你。如果你直接写status = 'success'，系统中根本无此值，直接暴露你未做基础验证。
第二，“会话时长”是否应排除device_type = 'bot'？第三，“过去30天”是自然日还是滚动窗口？这些不是陷阱，而是协作起点。
正确路径是：先口头确认定义。你说：“我假设‘成功交易’指status为settled，不包含pending。会话时长仅统计device_type为mobile或web的用户行为。时间窗口为从今天起倒推30天，包含今天。”面试官点头后，再开始编码。
接下来是结构选择。错误做法是写一个超长单查询：
`sql
SELECT user_id
FROM (
SELECT userid, avg(endtime - starttime) as avgduration
FROM user_sessions
WHERE starttime >= currentdate - 30
GROUP BY user_id
) s
JOIN (
SELECT userid, count() as txncount
FROM transactions
WHERE createdat >= currentdate - 30 AND status = 'settled'
GROUP BY user_id
) t
ON s.userid = t.userid
WHERE txncount >= 3 AND avgduration > '10 minutes';
`
这段代码能运行，但存在三个致命问题：未处理用户在两个表中范围不一致（比如某用户有会话但无交易）、未对时间字段做索引友好处理、未添加注释说明性能风险。
正确版本应分步、可读、可审计：
`sql
-- Step 1: 定义有效交易用户（settled状态，近30天）
WITH qualified_users AS (
SELECT
user_id,
COUNT() AS txn_count
FROM transactions
WHERE
status = 'settled'
AND createdat >= DATEADD(day, -30, CURRENTDATE) -- 显式函数，避免时区歧义
GROUP BY user_id
HAVING COUNT() >= 3
),
-- Step 2: 计算活跃会话时长（排除bot）
session_stats AS (
SELECT
user_id,
AVG(TIMESTAMPDIFF(minute, starttime, endtime)) AS avgdurationmin
FROM user_sessions
WHERE
starttime >= DATEADD(day, -30, CURRENTDATE)
AND device_type IN ('mobile', 'web')
GROUP BY user_id
)
-- Final: 交集查询，便于后续扩展
SELECT
q.user_id,
q.txn_count,
s.avgdurationmin
FROM qualified_users q
INNER JOIN session_stats s
ON q.userid = s.userid
WHERE s.avgdurationmin > 10;
`
关键区别在于：使用WITH明确逻辑分层，用TIMESTAMPDIFF确保单位清晰，添加注释说明device_type过滤依据。更重要的是，这个结构允许后续添加LEFT JOIN来分析流失用户，或导出中间表供其他团队使用。
在一次真实debrief中，面试官评价：“这段代码我可以直接交给BI团队复用，而上一个候选人写的，我得先拆解才能看懂他在做什么。”——这就是Revolut要的“协作型数据输出”。
薪资结构与晋升路径：数据科学家在Revolut的真实回报
2026年，Revolut数据科学家岗位分为三个层级：DS1（初级）、DS2（中级）、DS3（高级），对应薪资如下：
- DS1：Base $110K，RSU $40K/年（分4年归属），Bonus 10%（基于团队OKR），总包约$165K
- DS2：Base $140K，RSU $70K/年，Bonus 15%，总包约$230K
- DS3：Base $180K，RSU $120K/年，Bonus 20%，总包约$340K
这些数字基于伦敦总部标准，若派驻里斯本或华沙，base下调15%-20%，但税率更低。值得注意的是，Revolut的RSU发放与公司估值挂钩，2025年完成新一轮融资后，每股价值上升37%，导致2026年入职者的RSU实际购买成本低于老员工——这是罕见的“新人溢价”现象。
晋升路径上，DS2升DS3的平均周期为2.3年，但关键不在于完成多少分析报告，而在于是否主导过跨职能数据项目。例如，一位DS2在2025年Q4推动了“跨境转账失败归因看板”，整合了支付网关、风控规则、用户行为三套数据源，被产品团队采纳为默认监控工具。
他在晋升答辩中仅展示了该看板的使用率增长曲线和一次PM的书面感谢邮件，便顺利通过。评审标准明确写道：“数据科学家的影响力，不在于模型精度提升5%，而在于是否成为产品决策的默认数据源。”
另一个真实案例是：一位DS3候选人面试时被问：“你过去三年最有影响力的分析是什么？”他回答：“我构建了一个用户流失预测模型，AUC达到0.89。”面试官追问：“有多少团队在用？”答：“只有我们组。”直接被否。
而另一位候选人说：“我发现了‘首次转账后72小时内未收到返现’的用户流失率高出3倍，推动产品团队将返现延迟从48小时缩短至2小时。现在这个指标是增长团队的北极星指标之一。”他当场获得口头offer。这说明：在Revolut，分析的终点不是报告，而是机制变更。你的SQL如果不能推动产品逻辑调整，再漂亮也只是草稿。
准备清单
- 熟练掌握时间窗口函数的实际性能影响，尤其是
LAG()、LEAD()在十亿级表上的分区策略，避免全表扫描。 - 准备3个真实业务场景的SQL模板：用户留存计算、漏斗转化归因、异常检测基线，每个都包含注释层和假设声明。
- 模拟“10分钟提问权”训练：面对模糊需求，必须能快速列出关键数据依赖，例如“需要知道AB测试分组日志是否完整”。
- 理解Revolut核心业务指标：LTV/CAC ratio、资金沉淀率（float ratio）、跨境交易手续费占比，这些将出现在case分析中。
- 掌握SQL代码的“可交接性”标准：变量命名清晰（如
txnsuccessrate而非rate1），逻辑分层用CTE，关键过滤加注释。 - 系统性拆解面试结构（PM面试手册里有完整的数据科学家面试实战复盘可以参考），包括如何在白板编码时同步口述推理。
- 准备一个“反向问题清单”，例如：“团队目前最依赖的数据看板是什么？它的数据源更新延迟是多少？”——这类问题能展示你对数据运维的关注。
常见错误
案例一：忽略数据定义权
BAD：面试官问：“计算上月用户活跃率。”候选人立刻写：
`sql
SELECT COUNT(DISTINCT userid) FROM usersessions WHERE DATE(created_at) BETWEEN '2026-03-01' AND '2026-03-31';
`
问题在于，他擅自定义“活跃”为有会话，而未确认是否需包含交易行为。更糟的是，他用了DATE()函数，可能导致索引失效。
GOOD：候选人先问：“我们定义的‘活跃用户’是否需要完成至少一笔交易？”得到否定回答后，再写：
`sql
-- 假设活跃用户=有至少一次会话（非bot）
SELECT
COUNT(DISTINCT user_id) AS dau
FROM user_sessions
WHERE
start_time >= '2026-03-01'
AND start_time < '2026-04-01'
AND device_type IN ('mobile', 'web');
`
并补充：“建议后续增加session duration > 30秒过滤，避免爬虫干扰。”
案例二：过度依赖复杂语法
BAD：为计算“每月留存率”，候选人写：
`sql
SELECT
month,
COUNT() FILTER (WHERE ...) / LAG(COUNT()) OVER (ORDER BY month)
FROM ...
GROUP BY month;
`
嵌套聚合与窗口函数混合，语法错误且不可读。
GOOD：分步写：
`sql
WITH cohort_start AS (
SELECT
user_id,
DATETRUNC('month', firsttxndate) AS startmonth
FROM ...
),
retained AS (
SELECT
c.start_month,
DATETRUNC('month', t.createdat) AS activity_month,
COUNT() AS retained_count
FROM cohort_start c
JOIN transactions t ON c.userid = t.userid
GROUP BY 1, 2
)
SELECT
start_month,
retainedcount * 1.0 / LAG(retainedcount) OVER (PARTITION BY startmonth ORDER BY activitymonth) AS retention_rate
FROM retained;
`
清晰、可调试、可复用。
案例三：忽视协作上下文
BAD：在业务分析轮，候选人说：“我建议用随机森林预测用户流失。”面试官问：“谁来维护这个模型？”答：“我可以写Airflow DAG。”但团队根本不用Airflow。
GOOD：候选人说：“我建议先做归因分析，用SQL找出流失前72小时的关键行为断点。如果发现‘未开启通知’是主因，可先推动产品强制弹窗，暂不需模型。”——从低成本干预切入，匹配团队能力。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：是否需要准备机器学习题目？
不需要。Revolut数据科学家岗位的SQL轮和业务轮均不考察模型编码。曾有候选人花两周准备XGBoost调参，结果面试中从未被提及。真正重要的是：你能否用SQL做归因分析。例如，2025年一道真题是：“发现法国用户储蓄功能使用率下降，如何用数据定位原因？”正确路径不是建预测模型，而是先用SQL拆解：是新用户不转化？
老用户流失？功能曝光减少？一位候选人用三段SQL分别计算各环节漏斗，找出“注册后第7天邮件未送达”是断点，建议修复SMTP配置。他被评价为“用基础工具解决核心问题”。模型是手段，不是目的。如果你把80%时间花在刷LeetCode ML题上，你已经偏离了Revolut的评估重心。
Q：SQL使用PostgreSQL还是Redshift？
使用标准SQL，但需体现对执行引擎的理解。Revolut主要使用Snowflake，因此面试中应主动提及分区、聚簇、缓存机制。例如，写查询时加注释：“假设transactions表按created_at分区，此查询可高效剪枝。”或“建议对此结果集创建物化视图，因每日重复调用。
”曾有一位候选人写LIKE '%GBP%'进行货币过滤，被追问：“在十亿行表上，这个操作会触发全表扫描，如何优化？”他回答：“应改用enum类型或单独currency_id字段，并建立索引。”这个回答让他从“通过”升为“强烈推荐”。技术细节的价值，不在于你是否用对函数，而在于你是否预见到生产环境的代价。
Q：非欧盟候选人是否难通过？
不难，但需调整表达方式。一位美国候选人曾在面试中说：“我用p-value < 0.05判断显著性。”面试官追问：“如果产品团队说‘我们觉得变化很明显’，但p-value是0.07，你怎么办？”他回答：“坚持科学标准。”结果被否。
而另一位德国候选人说：“我会展示效应大小和置信区间，说‘虽然未达传统阈值，但转化提升3.2%（±1.1%），建议小流量继续观察’。”他获得offer。区别在于：前者把统计当权威，后者把数据当协商工具。Revolut总部在伦敦，团队高度国际化，但文化上推崇“数据驱动对话”，而非“数据强制决策”。你的SQL和表达，必须服务于协作，而不是证明自己正确。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。