最近帮一个学弟做校招辅导他扒出一份2017年PayPal暑期实习生笔试卷数据科学家方向跑来问我前几年的题现在刷还有意义吗我把整份试卷从题型到考察逻辑完整过了一遍答案是题型会变但PayPal想招的数据科学家应该具备什么能力和今天几乎没有差别。作为一家每天处理海量跨境支付的金融科技公司PayPal的数据科学家不是埋头调参的算法工程师而是要能在放行这笔交易和拦截这笔交易之间做决策的人。这份笔试卷最值得研究的恰恰是它如何用几道题把统计功底、工程能力、业务敏感度一次问透。下面我结合PayPal的业务场景把这份笔试卷的考点、解题思路和准备方法拆开聊聊对想投数据科学实习、校招的同学应该会有帮助。1. 这份笔试卷的底色支付公司的数据科学岗到底在招什么人1.1 从PayPal的业务场景反推笔试设计PayPal的业务本质是连接买卖双方的支付网络。你在海淘时用工行Visa卡绑定PayPal完成付款这背后会触发一串事件交易请求进来系统判断这笔交易是否可信资金从发卡行划到PayPal的备付金账户再结算给商户。整个过程以毫秒计而数据科学家要做的就是在这些事件数据里找到规律既降低欺诈损失又尽可能不影响正常用户的支付体验。所以笔试题目几乎都围绕这类场景设计概率统计题判断一个账户突然高频交易是不是被盗号SQL取数题从交易表里计算某渠道的真实欺诈率建模评估题在欺诈样本极少的情况下如何衡量一个模型的好坏案例分析题给你一个业务问题如何设计一套数据驱动的风控决策机制。你会发现这份试卷不考深度学习论文复现也不考花哨的框架。PayPal要招的不是模型调包侠而是能理解支付链路、能和工程师顺畅协作、能对业务结果负责的数据科学家。换句话说笔试从第一题就在筛选你懂不懂业务。1.2 2017年前后的数据科学面试当时的行业风向2017年时深度学习在图像、语音领域已经火了但在支付风控这种强解释性、强合规的场景里主流仍然是逻辑回归、梯度提升树和规则引擎。原因很简单风控决策必须能让业务人员听懂出了问题要能回溯监管来问要能讲清楚为什么拦截了这笔交易。黑盒模型在那个环境里很难直接落地。所以2017年的笔试卷比较朴素侧重点很明确数学基础要扎实SQL要熟练机器学习部分更看重对偏斜数据、代价敏感和特征工程的理解而不是看你会不会搭一个神经网络。你去看当时的笔试回忆贴几乎没有手动推导Transformer这种题更多的还是贝叶斯和假设检验。这和今天相比好像变了其实没变。变化的是工具栈现在大家动不动就上XGBoost、LightGBM还会聊因果推断、模型可解释性不变的是考察内核——数据科学家得能从数据里发现业务问题并且给出可落地的方案。下面我按模块拆解题型。2. 统计与概率题PayPal为什么反复考贝叶斯和假设检验2.1 贝叶斯公式是风控的第一性原理风控领域最基本的场景是系统报警了这笔交易真正是欺诈的概率有多大贝叶斯公式就是干这个的。笔试中常见的版本是给你欺诈先验概率、检测模型的召回率和误报率要你算后验概率。举个典型题目假设某支付场景的真实欺诈率是1%风控模型的召回率是98%误报率是2%。如果模型对某笔交易打了高风险警报那么这笔交易真正是欺诈的概率是多少很多人的第一反应是98%这就是经典的基础比率忽视。先验只有1%即便模型很准警报里绝大多数仍然来自正常交易。正确解法是p(欺诈|警报) p(警报|欺诈) * p(欺诈) / p(警报)其中p(警报) 0.98 * 0.01 0.02 * 0.99 0.0098 0.0198 0.0296。代入得到p(欺诈|警报) 0.0098 / 0.0296 ≈ 0.331也就是说在模型报警的交易里真正欺诈的只有三分之一左右。PayPal风控系统每天可能发出几十万条警报如果分析师不明白这个数字的含义把警报当实锤去处理大量正常用户会被拦下来体验损失巨大。这种题表面上考公式实际上考你能不能把概率直觉用在业务判断上。2.2 假设检验与A/B测试别只记p值要讲业务代价支付页面改版比如把立即支付按钮从蓝色改成绿色需要验证是否真的提升了支付率。数据科学家要会设计A/B测试包括样本量计算、显著性检验、效应量判断。真题考察点一般有三个。第一指标选什么。支付率、客单价、复购率不同指标对实验结论的影响很大。第二样本量够不够。需要知道baseline转化率和最小可检测提升套用样本量公式算最小样本量。第三怎么解释p值。p0.05不等于效应大也不代表业务上有价值更不代表下一批用户一定会复现这个结果。常见错误是忽略多重比较。一个实验同时看几十个指标总有一个会显著。我见过候选人直接说p0.04所以上线但没做过多重检验校正这就很扣分。PayPal这种体量的平台每天有无数实验在跑如果每次只看p值不看业务显著性迟早会做出错误决策。2.3 概率分布与期望把随机过程当成业务语言有时笔试题会结合泊松分布交易事件按一定速率到达计算某段时间内出现N笔交易的概率。或者结合几何分布若每笔交易欺诈概率为p首次出现欺诈的等待次数期望是1/p。这些题目的核心是让候选人理解随机过程的业务含义。PayPal的交易量足够大完全可以用泊松过程近似描述每秒到达的交易数量。如果某个渠道的日均交易量是1000笔那么某分钟到达5笔交易的概率是多少这种计算看起来是数学题实际上是容量规划、系统压测的基础。另一个更贴近风控的例子是如果某类欺诈事件的发生符合泊松过程那么下一次欺诈什么时候来就不是拍脑袋能回答的必须用分布去建模。这部分内容平时容易忽略但一旦考到区分度很高。3. 数据结构与SQL从交易流水里取数是数据科学家的基本功3.1 典型取数场景聚合、过滤、join要用得滚瓜烂熟PayPal笔试试卷一般会给三张表users(user_id, country, signup_date)transactions(txn_id, user_id, txn_time, amount, status, channel)fraud_labels(txn_id, is_fraud)第一题通常是统计2017年5月各渠道的交易总额和成功交易笔数。这就是考察聚合和条件计数。SELECT channel, SUM(CASE WHEN status SUCCESS THEN amount ELSE 0 END) AS total_amount, COUNT(CASE WHEN status SUCCESS THEN txn_id END) AS success_txn_cnt FROM transactions WHERE txn_time 2017-05-01 AND txn_time 2017-06-01 GROUP BY channel ORDER BY total_amount DESC;看起来很基础但很多人会踩坑忘了过滤status或者把退款交易也算进去导致金额被高估。PayPal的真实数据里status字段有SUCCESS、FAILED、REFUNDED、REVERSED等不同状态对业务含义完全不同。如果题目没明确说最好写上假设比如只统计成功交易这会让阅卷人觉得你有业务意识。第二题一般会加难度计算每个用户的首次成功交易时间距注册时间的平均时长。这需要先找出每个用户的首次交易时间再和注册时间做差。很多候选人会写一个很复杂的join其实用窗口函数更优雅。3.2 窗口函数在海量交易数据里写高效SQL的必备技能窗口函数在2017年的笔试卷里就已经是高频考点了因为PayPal的数据量大写得烂的SQL跑不出来而窗口函数能很大程度避免低效的自连接。高频题目找出每个用户交易金额最大的前3笔交易。SELECT user_id, txn_id, amount FROM ( SELECT user_id, txn_id, amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn FROM transactions ) t WHERE rn 3;这里有一个细节ROW_NUMBER、RANK和DENSE_RANK在对并列金额的处理上不一样。如果题目问的是金额排名前三有并列时该用哪种通常业务上希望至少保留3笔或者按唯一交易算这时候ROW_NUMBER更合适如果希望保留并列的所有交易会考虑DENSE_RANK。这个细节在面试中往往是加分点因为很多人背了窗口函数却不清楚差异。3.3 数据清洗和异常值处理笔试里最容易埋坑的地方SQL题不会只给你一张干干净净的表通常会埋几个坑。比如status字段大小写不统一直接用WHERE statussuccess会漏数据交易时间存的是UTC业务方要的是北京时间需要做时区转换同一个txn_id可能出现两次可能是重试请求不能直接按行数统计。我建议拿到SQL题先花一分钟浏览表结构先检查主键和空值再开始写代码。在真实工作中PayPal的数据来自全球同一笔交易在不同时区可能落在不同日期如果直接GROUP BY日期报表会天天对不上。笔试时能主动写出过滤测试交易、过滤失败状态、按date(txn_time at time zone UTC at time zone America/Los_Angeles)分组这种细节会让阅卷人觉得你不是第一次处理脏数据。4. 机器学习与模型评估别只会调包要懂业务代价4.1 分类模型里的不平衡问题准确率是风控的陷阱欺诈检测这个任务天然是极度不平衡的。真实交易里欺诈率通常低于1%如果在测试集上直接跑逻辑回归模型把所有样本都预测成正常交易准确率也有99%以上。笔试问你准确率这么高模型能不能上线就是让你识别出评估指标的问题。正确的思路是看混淆矩阵用召回率、精确率、F1、AUC、PR曲线来评估。尤其是不平衡场景下PR曲线比ROC曲线更有区分度。因为ROC曲线受到大量负样本的影响FPR会被稀释而PR曲线直接关注正样本的精确率和召回率更贴近风控的实际诉求。评估指标优点缺点Accuracy直观不平衡数据下容易虚高Precision关注被拦截的交易里有多少是真欺诈对阈值敏感Recall关注真欺诈抓到了多少阈值低时会误伤大量正常用户AUC不受阈值影响综合排序能力对不平衡数据不够敏感PR AUC不平衡场景下区分度更好业务解释性略差实际做风控模型时我更推荐同时报告召回率某个精确率阈值比如在误报率低于1%的时候召回率能做到多少这样才能直接和业务方沟通。4.2 代价敏感学习与阈值选择模型分数只是起点很多候选人会调模型却不知道怎么选阈值。PayPal风控里拦截一笔正常交易和放行一笔欺诈交易的代价完全不同。放行欺诈直接损失这笔交易的金额拦截正常用户可能造成用户投诉、客服成本、甚至流失。所以阈值不能只看模型分数分布要算清楚业务代价矩阵。举一个简化例子真实情况预测为正常预测为欺诈正常交易0-10元欺诈交易-100元0这里拦截一笔正常交易损失10元客服和用户体验成本放行一笔欺诈损失100元直接金额损失。那么只有当一笔交易被预测为欺诈的后验概率大于10/110≈9.1%时拦截才是划算的。如果把100元改成1000元阈值就变成10/1010≈1%意味着风控可以更激进地拦截。笔试卷里如果让你选择合适的阈值不要只回答在PR曲线上找拐点要把代价矩阵、先验概率、业务约束都摆出来。这种答题思路比公式本身更值钱。4.3 特征工程与过拟合防控时间顺序是风控的生命线数据科学家要能从交易数据里构造特征常见的有交易金额、历史交易频次、设备指纹、IP地理位置、短时间内多笔交易的速度特征。但有个非常关键的点——特征泄露。比如该用户是否被风控规则命中如果这个规则是用未来数据生成的或者直接用规则结果当标签训练出的模型上线后效果必然崩盘。在PayPal这种业务里时间特征尤其敏感。训练时必须按时间切分比如用前6个月的数据做训练集接下来1个月做验证集最后1周做测试集。如果随机抽样同一笔用户的历史交易会同时出现在训练集和测试集里造成数据泄露模型性能被严重高估。笔试中如果给出时间字段一定要在建模方案里提到按时间划分样本这几乎是金融风控岗位的政治正确。哪怕题目没有明说这也是一项非常有效的加分动作。5. 案例分析题用数据回答要不要放行这笔交易5.1 开放式风控案例题的答题框架最后往往有一道开放题可能长这样PayPal要减少欺诈损失但不想影响用户体验你怎么设计一个风控系统这种题没有标准答案但得分差异很大。我的答题框架一般是五步定义目标最小化总体损失欺诈损失误伤损失约束是用户体验指标不下降梳理数据交易金额、用户历史行为、设备、IP、商户类型、绑卡信息等设计方法先用规则引擎拦截明显欺诈再用机器学习模型打分设置双阈值高风险直接拒绝、中风险二次验证、低风险放行离线评估用历史数据回测看PR曲线和业务指标在线落地先做影子模式让模型和现有规则并行打分不实际拦截观察一段时间后再灰度上线。这个框架看起来简单但很多人写的时候会漏掉影子模式这一环。PayPal这类公司对线上系统极其谨慎任何模型直接切换到生产环境都是高风险操作所以答出shadow mode到灰度发布的完整链路说明你有真实落地意识。5.2 业务敏感度跨境支付里的用户差异和规则差异PayPal是跨境支付公司业务遍布全球。答题时如果能体现这一点会非常加分。比如提到我不可能对全球用户用同一个模型因为不同国家的支付习惯和欺诈模式差异很大。举个例子国内用户很多会用工行Visa卡绑定PayPal海淘这类交易通常发生在深夜或凌晨金额相对集中而欧美用户可能习惯用信用卡直接在线上订阅服务表现为小额高频。如果模型只看单笔金额很容易把海外大额订单误判成欺诈。更合理的方式是分层建模或者至少把国家、支付方式、卡组织作为重要特征。另外不同国家的合规要求也不同。有些地区允许基于风险的二次验证有些地区则要求必须在多少秒内给出决定。这些约束直接影响模型复杂度——你不能让用户等10秒再返回结果那等于主动放弃交易。5.3 常见错误和加分项阅卷人希望看到的细节很多候选人在开放题里只写我会用XGBoost或者我会构建一个评分卡完事。这不算答案因为没有回答业务问题。常见错误包括不定义评估指标、不考虑误伤代价、不聊上线后的监控、不聊数据质量问题。加分项则包括提到模型可解释性说清楚风控决策需要给客服和监管提供理由提到模型回退机制万一新模型表现异常怎么切回旧规则提到数据质量比如交易数据可能有延迟、缺失、被篡改怎么处理。这些细节不需要多复杂但能把你的答案和只会调包的候选人区分开来。6. 从现在回看这份试卷哪些会变哪些不会变6.1 题型演化和新考点从规则引擎到可解释AI如果我们把2017年的笔试卷放到现在会发现一些明显的变化。首先是题型更多样可能会加入因果推断题比如如何评估风控拦截对用户复购率的影响其次是会更重视可解释性比如问你如果模型上线后监管要求解释某笔交易为什么被拦截你会怎么做最近一两年有些团队甚至开始聊大语言模型在客服和规则生成里的应用。但回到这份笔试卷本身统计、SQL、机器学习评估和案例分析仍然是占比最大的模块。原因很简单这些能力是数据科学家的基础设施无论工具怎么变你都需要靠它们来发现问题、定义指标、验证想法。6.2 给准备金融科技类数据科学岗位的读者一些建议如果你现在要投PayPal或类似金融科技公司的数据科学岗位我建议分四步准备系统过一遍统计推断贝叶斯公式、假设检验、A/B测试、常见概率分布不要只背公式要能结合业务场景解释刷SQL题重点练窗口函数、分组聚合、条件统计刷LeetCode Database题库前30道就够用找一个风控类开源数据集完整走一遍探索性分析、特征工程、模型训练、阈值选择、离线评估的流程把它写成一个可讲清楚的项目多看支付风控的公开分享理解真实业务中的约束条件和落地流程。第四点经常被忽略。数据科学面试不只是考算法还要考你能不能和业务方聊天。你不需要成为支付专家但至少要理解交易链路上的关键节点和风险点。6.3 做题和写方案时的一些实操小经验最后分享几个我在看这份试卷和辅导学弟过程中总结的小经验比较琐碎但很实用。拿到试卷先别急着动手。花五分钟通读全卷先做自己最有把握的题把不会的题放一放避免在一道题上浪费太多时间。PayPal这类公司更看重思路哪怕某题没算出最终数字只要公式和逻辑写清楚也会给分。SQL题写完顺手加注释比如过滤失败状态、按用户去重这会让阅卷人很快理解你的思路。如果题目有模糊条件比如统计交易总额没说明是否包含退款直接在答案里写假设不包含退款交易比留白好得多。案例题宁多勿少。把目标、数据、方法、评估、落地、监控都写一遍即使有些地方你觉得多余也比只丢一个模型名显得专业。阅卷人想在十几分钟里看完你的答案结构清晰比话术华丽更重要。我个人在辅导时发现很多候选人基础题目都能做对但一到开放题就露怯原因不是不会而是缺少把问题拆成目标、约束、行动、评估的思维习惯。这个习惯不是刷题刷出来的而是多看真实案例、多问几个然后呢练出来的。如果你现在准备面试不妨找一道风控场景题按照我上面说的框架写一遍过两天再拿出来改一遍你会明显感觉到思路变清晰。这份2017年的PayPal笔试卷看似过时其实是一面很好的镜子。它照出的不是某个框架的语法而是数据科学家最底层的能力。把底层能力打扎实无论去哪家公司都不怕题变。
PayPal数据科学家笔试题解析：统计、SQL与风控建模实战
最近帮一个学弟做校招辅导他扒出一份2017年PayPal暑期实习生笔试卷数据科学家方向跑来问我前几年的题现在刷还有意义吗我把整份试卷从题型到考察逻辑完整过了一遍答案是题型会变但PayPal想招的数据科学家应该具备什么能力和今天几乎没有差别。作为一家每天处理海量跨境支付的金融科技公司PayPal的数据科学家不是埋头调参的算法工程师而是要能在放行这笔交易和拦截这笔交易之间做决策的人。这份笔试卷最值得研究的恰恰是它如何用几道题把统计功底、工程能力、业务敏感度一次问透。下面我结合PayPal的业务场景把这份笔试卷的考点、解题思路和准备方法拆开聊聊对想投数据科学实习、校招的同学应该会有帮助。1. 这份笔试卷的底色支付公司的数据科学岗到底在招什么人1.1 从PayPal的业务场景反推笔试设计PayPal的业务本质是连接买卖双方的支付网络。你在海淘时用工行Visa卡绑定PayPal完成付款这背后会触发一串事件交易请求进来系统判断这笔交易是否可信资金从发卡行划到PayPal的备付金账户再结算给商户。整个过程以毫秒计而数据科学家要做的就是在这些事件数据里找到规律既降低欺诈损失又尽可能不影响正常用户的支付体验。所以笔试题目几乎都围绕这类场景设计概率统计题判断一个账户突然高频交易是不是被盗号SQL取数题从交易表里计算某渠道的真实欺诈率建模评估题在欺诈样本极少的情况下如何衡量一个模型的好坏案例分析题给你一个业务问题如何设计一套数据驱动的风控决策机制。你会发现这份试卷不考深度学习论文复现也不考花哨的框架。PayPal要招的不是模型调包侠而是能理解支付链路、能和工程师顺畅协作、能对业务结果负责的数据科学家。换句话说笔试从第一题就在筛选你懂不懂业务。1.2 2017年前后的数据科学面试当时的行业风向2017年时深度学习在图像、语音领域已经火了但在支付风控这种强解释性、强合规的场景里主流仍然是逻辑回归、梯度提升树和规则引擎。原因很简单风控决策必须能让业务人员听懂出了问题要能回溯监管来问要能讲清楚为什么拦截了这笔交易。黑盒模型在那个环境里很难直接落地。所以2017年的笔试卷比较朴素侧重点很明确数学基础要扎实SQL要熟练机器学习部分更看重对偏斜数据、代价敏感和特征工程的理解而不是看你会不会搭一个神经网络。你去看当时的笔试回忆贴几乎没有手动推导Transformer这种题更多的还是贝叶斯和假设检验。这和今天相比好像变了其实没变。变化的是工具栈现在大家动不动就上XGBoost、LightGBM还会聊因果推断、模型可解释性不变的是考察内核——数据科学家得能从数据里发现业务问题并且给出可落地的方案。下面我按模块拆解题型。2. 统计与概率题PayPal为什么反复考贝叶斯和假设检验2.1 贝叶斯公式是风控的第一性原理风控领域最基本的场景是系统报警了这笔交易真正是欺诈的概率有多大贝叶斯公式就是干这个的。笔试中常见的版本是给你欺诈先验概率、检测模型的召回率和误报率要你算后验概率。举个典型题目假设某支付场景的真实欺诈率是1%风控模型的召回率是98%误报率是2%。如果模型对某笔交易打了高风险警报那么这笔交易真正是欺诈的概率是多少很多人的第一反应是98%这就是经典的基础比率忽视。先验只有1%即便模型很准警报里绝大多数仍然来自正常交易。正确解法是p(欺诈|警报) p(警报|欺诈) * p(欺诈) / p(警报)其中p(警报) 0.98 * 0.01 0.02 * 0.99 0.0098 0.0198 0.0296。代入得到p(欺诈|警报) 0.0098 / 0.0296 ≈ 0.331也就是说在模型报警的交易里真正欺诈的只有三分之一左右。PayPal风控系统每天可能发出几十万条警报如果分析师不明白这个数字的含义把警报当实锤去处理大量正常用户会被拦下来体验损失巨大。这种题表面上考公式实际上考你能不能把概率直觉用在业务判断上。2.2 假设检验与A/B测试别只记p值要讲业务代价支付页面改版比如把立即支付按钮从蓝色改成绿色需要验证是否真的提升了支付率。数据科学家要会设计A/B测试包括样本量计算、显著性检验、效应量判断。真题考察点一般有三个。第一指标选什么。支付率、客单价、复购率不同指标对实验结论的影响很大。第二样本量够不够。需要知道baseline转化率和最小可检测提升套用样本量公式算最小样本量。第三怎么解释p值。p0.05不等于效应大也不代表业务上有价值更不代表下一批用户一定会复现这个结果。常见错误是忽略多重比较。一个实验同时看几十个指标总有一个会显著。我见过候选人直接说p0.04所以上线但没做过多重检验校正这就很扣分。PayPal这种体量的平台每天有无数实验在跑如果每次只看p值不看业务显著性迟早会做出错误决策。2.3 概率分布与期望把随机过程当成业务语言有时笔试题会结合泊松分布交易事件按一定速率到达计算某段时间内出现N笔交易的概率。或者结合几何分布若每笔交易欺诈概率为p首次出现欺诈的等待次数期望是1/p。这些题目的核心是让候选人理解随机过程的业务含义。PayPal的交易量足够大完全可以用泊松过程近似描述每秒到达的交易数量。如果某个渠道的日均交易量是1000笔那么某分钟到达5笔交易的概率是多少这种计算看起来是数学题实际上是容量规划、系统压测的基础。另一个更贴近风控的例子是如果某类欺诈事件的发生符合泊松过程那么下一次欺诈什么时候来就不是拍脑袋能回答的必须用分布去建模。这部分内容平时容易忽略但一旦考到区分度很高。3. 数据结构与SQL从交易流水里取数是数据科学家的基本功3.1 典型取数场景聚合、过滤、join要用得滚瓜烂熟PayPal笔试试卷一般会给三张表users(user_id, country, signup_date)transactions(txn_id, user_id, txn_time, amount, status, channel)fraud_labels(txn_id, is_fraud)第一题通常是统计2017年5月各渠道的交易总额和成功交易笔数。这就是考察聚合和条件计数。SELECT channel, SUM(CASE WHEN status SUCCESS THEN amount ELSE 0 END) AS total_amount, COUNT(CASE WHEN status SUCCESS THEN txn_id END) AS success_txn_cnt FROM transactions WHERE txn_time 2017-05-01 AND txn_time 2017-06-01 GROUP BY channel ORDER BY total_amount DESC;看起来很基础但很多人会踩坑忘了过滤status或者把退款交易也算进去导致金额被高估。PayPal的真实数据里status字段有SUCCESS、FAILED、REFUNDED、REVERSED等不同状态对业务含义完全不同。如果题目没明确说最好写上假设比如只统计成功交易这会让阅卷人觉得你有业务意识。第二题一般会加难度计算每个用户的首次成功交易时间距注册时间的平均时长。这需要先找出每个用户的首次交易时间再和注册时间做差。很多候选人会写一个很复杂的join其实用窗口函数更优雅。3.2 窗口函数在海量交易数据里写高效SQL的必备技能窗口函数在2017年的笔试卷里就已经是高频考点了因为PayPal的数据量大写得烂的SQL跑不出来而窗口函数能很大程度避免低效的自连接。高频题目找出每个用户交易金额最大的前3笔交易。SELECT user_id, txn_id, amount FROM ( SELECT user_id, txn_id, amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn FROM transactions ) t WHERE rn 3;这里有一个细节ROW_NUMBER、RANK和DENSE_RANK在对并列金额的处理上不一样。如果题目问的是金额排名前三有并列时该用哪种通常业务上希望至少保留3笔或者按唯一交易算这时候ROW_NUMBER更合适如果希望保留并列的所有交易会考虑DENSE_RANK。这个细节在面试中往往是加分点因为很多人背了窗口函数却不清楚差异。3.3 数据清洗和异常值处理笔试里最容易埋坑的地方SQL题不会只给你一张干干净净的表通常会埋几个坑。比如status字段大小写不统一直接用WHERE statussuccess会漏数据交易时间存的是UTC业务方要的是北京时间需要做时区转换同一个txn_id可能出现两次可能是重试请求不能直接按行数统计。我建议拿到SQL题先花一分钟浏览表结构先检查主键和空值再开始写代码。在真实工作中PayPal的数据来自全球同一笔交易在不同时区可能落在不同日期如果直接GROUP BY日期报表会天天对不上。笔试时能主动写出过滤测试交易、过滤失败状态、按date(txn_time at time zone UTC at time zone America/Los_Angeles)分组这种细节会让阅卷人觉得你不是第一次处理脏数据。4. 机器学习与模型评估别只会调包要懂业务代价4.1 分类模型里的不平衡问题准确率是风控的陷阱欺诈检测这个任务天然是极度不平衡的。真实交易里欺诈率通常低于1%如果在测试集上直接跑逻辑回归模型把所有样本都预测成正常交易准确率也有99%以上。笔试问你准确率这么高模型能不能上线就是让你识别出评估指标的问题。正确的思路是看混淆矩阵用召回率、精确率、F1、AUC、PR曲线来评估。尤其是不平衡场景下PR曲线比ROC曲线更有区分度。因为ROC曲线受到大量负样本的影响FPR会被稀释而PR曲线直接关注正样本的精确率和召回率更贴近风控的实际诉求。评估指标优点缺点Accuracy直观不平衡数据下容易虚高Precision关注被拦截的交易里有多少是真欺诈对阈值敏感Recall关注真欺诈抓到了多少阈值低时会误伤大量正常用户AUC不受阈值影响综合排序能力对不平衡数据不够敏感PR AUC不平衡场景下区分度更好业务解释性略差实际做风控模型时我更推荐同时报告召回率某个精确率阈值比如在误报率低于1%的时候召回率能做到多少这样才能直接和业务方沟通。4.2 代价敏感学习与阈值选择模型分数只是起点很多候选人会调模型却不知道怎么选阈值。PayPal风控里拦截一笔正常交易和放行一笔欺诈交易的代价完全不同。放行欺诈直接损失这笔交易的金额拦截正常用户可能造成用户投诉、客服成本、甚至流失。所以阈值不能只看模型分数分布要算清楚业务代价矩阵。举一个简化例子真实情况预测为正常预测为欺诈正常交易0-10元欺诈交易-100元0这里拦截一笔正常交易损失10元客服和用户体验成本放行一笔欺诈损失100元直接金额损失。那么只有当一笔交易被预测为欺诈的后验概率大于10/110≈9.1%时拦截才是划算的。如果把100元改成1000元阈值就变成10/1010≈1%意味着风控可以更激进地拦截。笔试卷里如果让你选择合适的阈值不要只回答在PR曲线上找拐点要把代价矩阵、先验概率、业务约束都摆出来。这种答题思路比公式本身更值钱。4.3 特征工程与过拟合防控时间顺序是风控的生命线数据科学家要能从交易数据里构造特征常见的有交易金额、历史交易频次、设备指纹、IP地理位置、短时间内多笔交易的速度特征。但有个非常关键的点——特征泄露。比如该用户是否被风控规则命中如果这个规则是用未来数据生成的或者直接用规则结果当标签训练出的模型上线后效果必然崩盘。在PayPal这种业务里时间特征尤其敏感。训练时必须按时间切分比如用前6个月的数据做训练集接下来1个月做验证集最后1周做测试集。如果随机抽样同一笔用户的历史交易会同时出现在训练集和测试集里造成数据泄露模型性能被严重高估。笔试中如果给出时间字段一定要在建模方案里提到按时间划分样本这几乎是金融风控岗位的政治正确。哪怕题目没有明说这也是一项非常有效的加分动作。5. 案例分析题用数据回答要不要放行这笔交易5.1 开放式风控案例题的答题框架最后往往有一道开放题可能长这样PayPal要减少欺诈损失但不想影响用户体验你怎么设计一个风控系统这种题没有标准答案但得分差异很大。我的答题框架一般是五步定义目标最小化总体损失欺诈损失误伤损失约束是用户体验指标不下降梳理数据交易金额、用户历史行为、设备、IP、商户类型、绑卡信息等设计方法先用规则引擎拦截明显欺诈再用机器学习模型打分设置双阈值高风险直接拒绝、中风险二次验证、低风险放行离线评估用历史数据回测看PR曲线和业务指标在线落地先做影子模式让模型和现有规则并行打分不实际拦截观察一段时间后再灰度上线。这个框架看起来简单但很多人写的时候会漏掉影子模式这一环。PayPal这类公司对线上系统极其谨慎任何模型直接切换到生产环境都是高风险操作所以答出shadow mode到灰度发布的完整链路说明你有真实落地意识。5.2 业务敏感度跨境支付里的用户差异和规则差异PayPal是跨境支付公司业务遍布全球。答题时如果能体现这一点会非常加分。比如提到我不可能对全球用户用同一个模型因为不同国家的支付习惯和欺诈模式差异很大。举个例子国内用户很多会用工行Visa卡绑定PayPal海淘这类交易通常发生在深夜或凌晨金额相对集中而欧美用户可能习惯用信用卡直接在线上订阅服务表现为小额高频。如果模型只看单笔金额很容易把海外大额订单误判成欺诈。更合理的方式是分层建模或者至少把国家、支付方式、卡组织作为重要特征。另外不同国家的合规要求也不同。有些地区允许基于风险的二次验证有些地区则要求必须在多少秒内给出决定。这些约束直接影响模型复杂度——你不能让用户等10秒再返回结果那等于主动放弃交易。5.3 常见错误和加分项阅卷人希望看到的细节很多候选人在开放题里只写我会用XGBoost或者我会构建一个评分卡完事。这不算答案因为没有回答业务问题。常见错误包括不定义评估指标、不考虑误伤代价、不聊上线后的监控、不聊数据质量问题。加分项则包括提到模型可解释性说清楚风控决策需要给客服和监管提供理由提到模型回退机制万一新模型表现异常怎么切回旧规则提到数据质量比如交易数据可能有延迟、缺失、被篡改怎么处理。这些细节不需要多复杂但能把你的答案和只会调包的候选人区分开来。6. 从现在回看这份试卷哪些会变哪些不会变6.1 题型演化和新考点从规则引擎到可解释AI如果我们把2017年的笔试卷放到现在会发现一些明显的变化。首先是题型更多样可能会加入因果推断题比如如何评估风控拦截对用户复购率的影响其次是会更重视可解释性比如问你如果模型上线后监管要求解释某笔交易为什么被拦截你会怎么做最近一两年有些团队甚至开始聊大语言模型在客服和规则生成里的应用。但回到这份笔试卷本身统计、SQL、机器学习评估和案例分析仍然是占比最大的模块。原因很简单这些能力是数据科学家的基础设施无论工具怎么变你都需要靠它们来发现问题、定义指标、验证想法。6.2 给准备金融科技类数据科学岗位的读者一些建议如果你现在要投PayPal或类似金融科技公司的数据科学岗位我建议分四步准备系统过一遍统计推断贝叶斯公式、假设检验、A/B测试、常见概率分布不要只背公式要能结合业务场景解释刷SQL题重点练窗口函数、分组聚合、条件统计刷LeetCode Database题库前30道就够用找一个风控类开源数据集完整走一遍探索性分析、特征工程、模型训练、阈值选择、离线评估的流程把它写成一个可讲清楚的项目多看支付风控的公开分享理解真实业务中的约束条件和落地流程。第四点经常被忽略。数据科学面试不只是考算法还要考你能不能和业务方聊天。你不需要成为支付专家但至少要理解交易链路上的关键节点和风险点。6.3 做题和写方案时的一些实操小经验最后分享几个我在看这份试卷和辅导学弟过程中总结的小经验比较琐碎但很实用。拿到试卷先别急着动手。花五分钟通读全卷先做自己最有把握的题把不会的题放一放避免在一道题上浪费太多时间。PayPal这类公司更看重思路哪怕某题没算出最终数字只要公式和逻辑写清楚也会给分。SQL题写完顺手加注释比如过滤失败状态、按用户去重这会让阅卷人很快理解你的思路。如果题目有模糊条件比如统计交易总额没说明是否包含退款直接在答案里写假设不包含退款交易比留白好得多。案例题宁多勿少。把目标、数据、方法、评估、落地、监控都写一遍即使有些地方你觉得多余也比只丢一个模型名显得专业。阅卷人想在十几分钟里看完你的答案结构清晰比话术华丽更重要。我个人在辅导时发现很多候选人基础题目都能做对但一到开放题就露怯原因不是不会而是缺少把问题拆成目标、约束、行动、评估的思维习惯。这个习惯不是刷题刷出来的而是多看真实案例、多问几个然后呢练出来的。如果你现在准备面试不妨找一道风控场景题按照我上面说的框架写一遍过两天再拿出来改一遍你会明显感觉到思路变清晰。这份2017年的PayPal笔试卷看似过时其实是一面很好的镜子。它照出的不是某个框架的语法而是数据科学家最底层的能力。把底层能力打扎实无论去哪家公司都不怕题变。