看到这份“2017PayPal暑期实习生笔试卷-数据科学家”很多准备投数据分析或数据科学方向的同学可能都有点慌。网上能搜到的笔经往往只言片语要么是“考了SQL和概率”要么是“感觉凉了”根本拼不出完整的考察逻辑。我当年备考时也踩过类似的坑后来跟几个面过PayPal的朋友把题目复盘了一遍才发现这套笔试卷其实非常有代表性——它不考死记硬背而是用一套组合拳去筛选真正有业务sense和数据直觉的人。这篇文章我会以当年那套笔试卷为切入点拆解数据科学家实习生笔试的核心考点、答题思路和准备方法并且配上可以“抄作业”的实操框架。不管你是准备外企的数据岗还是想系统梳理自己的数据基本功这篇内容都值得认真看完。1. 笔试整体设计与核心考点拆解1.1 为什么PayPal的笔试题值得认真研究PayPal是做在线支付起家的老牌公司业务天然和数据紧密绑定。你可能觉得一家支付公司的数据科学家主要就是做做报表、跑跑回归但实际上完全不是这样。支付业务有几个非常独特的性质实时性极强每一笔交易都在毫秒级完成风控模型需要在交易发生的同时给出放行、拒绝或人工审核的判断这意味着数据科学家的模型要部署到生产环境实时打分。数据量巨大且噪声多每天数亿笔交易涉及用户行为、设备指纹、IP地址、历史交易序列等而且欺诈行为会有意伪装成正常交易信噪比很低。业务价值直接模型多拦一笔欺诈交易就是直接省钱少拦一笔正常交易就是直接损失收入所以模型的效果可以用非常明确的金额来衡量。正因为这种业务背景PayPal的笔试不会出那种“教科书式”的题目比如让你背一个算法公式或者默写贝叶斯定理。它更看重的是你面对一个真实业务问题时能不能把它转化成数据问题然后用合适的工具和模型去解决。我当时复盘完那套题最大的感受是这套卷子考察的是“从业务到数据”的完整思考链路而不是零散的知识点。1.2 四类题型背后的考察逻辑把网上能找到的笔经和我个人的记忆拼在一起2017年那套笔试大致可以分为四个板块板块考察内容目标能力概率统计期望值计算、条件概率、贝叶斯推断量化思维、不确定性判断SQL实操多表连接、聚合、窗口函数、留存计算取数能力、数据操作熟练度机器学习模型选择、特征工程、评估指标建模能力、算法理解深度案例分析风控策略设计、指标异动归因业务理解、结构化表达能力这个配比是很有讲究的。概率统计解决的是“不确定性”问题。数据科学家的日常就是跟不确定打交道——这个用户有多大概率会逾期这个策略上线后有多少比例的误杀没有扎实的概率直觉你连问题都定义不清楚。SQL解决的是“取数”问题。哪怕你模型建得再花哨拿不到数据、取错口径都是白搭。很多同学轻视SQL觉得“不就是select一下嘛”但实际笔试里SQL是刷人最多的地方因为题目往往藏了坑比如时区、去重逻辑、关联键的选择。机器学习解决的是“预测”问题。这一块考察的不是你会不会调参而是你面对一个业务场景时能不能选择合适的算法、构造有效的特征、并且用对的指标评估。案例分析解决的是“落地”问题。模型不是离线跑个AUC就行要能解释业务含义、要能上线、要能评估收益。这一题会直接反映你有没有真正做过项目。1.3 答题时间分配的隐藏信号笔试时间一般给2到3小时题量看起来不大但时间非常紧张。这里有个隐藏信号PayPal想考察你在时间压力下如何取舍。我观察到的规律是大部分人会卡在概率题然后在SQL题上死磕最后案例分析草草写几行字。这个策略其实很亏。从分值权重来看案例分析虽然只有一道题但评分比重往往不低于占三道小题的概率题。面试官看重的不是你每道题都答完而是你能否在有限时间内对分值高的题目做出足够深度的思考。一个合理的时间分配策略是概率统计25%的时间。会做的快速拿下完全没思路的果断跳过。SQL25%的时间。先跑通逻辑再写代码不要边写边想。机器学习20%的时间。重点写清楚思路和评估方案而不是堆模型名称。案例分析30%的时间。留足时间把框架搭完整。2. 概率统计与SQL的实战答题要点2.1 概率统计题别只会背公式要会“算账”概率统计部分是公认的“拦路虎”。这类题目往往不会直接问“抛硬币正面朝上的概率是多少”而是包了一层业务外衣。比如2017年卷子里有一类题目本质是在问一个风控系统拦截一笔交易已知欺诈交易占比为1%系统对欺诈交易的召回率是90%误报率是5%。现在某笔交易被系统拦截了问它确实是欺诈的概率是多少这题看着像是在考贝叶斯定理其实是在考你能不能把业务指标换算成概率术语。设欺诈事件为 F拦截事件为 IP(F) 0.01P(I|F) 0.9P(I|¬F) 0.05求 P(F|I)P(F|I) P(I|F) × P(F) / [P(I|F) × P(F) P(I|¬F) × P(¬F)]代入P(F|I) 0.9 × 0.01 / (0.9 × 0.01 0.05 × 0.99) 0.009 / (0.009 0.0495) 0.009 / 0.0585≈ 0.1538也就是说被拦截的交易里真正是欺诈的只有15%左右剩下85%是误伤的正常交易。这个结果非常反直觉很多人第一反应是“召回率90%那多半就是欺诈了”但把先验概率算进去之后结论就完全变了。这道题的核心考点在于做风控不能只看模型对欺诈的召回率还要看误报率带来的成本。在实际支付场景里如果误报率是5%意味着每拦截100笔交易会有大约5笔是正常的这会直接伤害用户体验和商家营收。面试官想看你能不能算清这笔账能不能用贝叶斯思维去解读模型输出而不是只会背一个公式。类似的题型还有期望值计算比如“两个策略方案一个成功率低但收益高另一个成功率高但收益低选哪个”。这种题目表面是算期望实际是考察你在不确定性下做决策的框架。回答时最好把期望值算出来再补充一下风险边界比如方差、最坏情况说明你不只会期望最大化还考虑到了风险控制。2.2 SQL实操题窗口函数和留存率是重头戏SQL部分出题方向非常稳定基本绕不开三件事多表连接、聚合统计、窗口函数。其中窗口函数是区分度最高的考点。2017年笔试里有一道典型的SQL题场景是有两个表一个交易表 transactionsuser_id, txn_date, amount, status一个用户表 usersuser_id, reg_date, country要求计算“每个国家2017年6月的GMV以及环比5月的增长率”。很多人第一反应是用WHERE把日期筛选到6月按国家GROUP BY求和然后发现“环比增长率”不知道怎么写。因为要同时算6月和5月的数据你得先把两个月份的数据都取出来再按国家汇总然后用LAG或者自连接来算增长率。一个看起来比较顺的写法是WITH monthly AS ( SELECT u.country, DATE_TRUNC(month, t.txn_date) AS month, SUM(CASE WHEN t.status completed THEN t.amount ELSE 0 END) AS gmv FROM transactions t JOIN users u ON t.user_id u.user_id WHERE t.txn_date DATE 2017-05-01 AND t.txn_date DATE 2017-07-01 GROUP BY u.country, DATE_TRUNC(month, t.txn_date) ) SELECT country, SUM(CASE WHEN month DATE 2017-06-01 THEN gmv END) AS gmv_jun, SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END) AS gmv_may, (SUM(CASE WHEN month DATE 2017-06-01 THEN gmv END) - SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END)) * 1.0 / NULLIF(SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END), 0) AS growth_rate FROM monthly GROUP BY country;这道题有三个考点状态过滤GMV一般只算成功交易的金额status字段需要过滤。时间口径DATE_TRUNC函数按月聚合避免字符串处理出错。环比计算用条件聚合把5月和6月的数据放在同一行再用NULLIF防止除零。写SQL的时候尤其要注意一个细节为什么WHERE条件要写成“ 5月1日 AND 7月1日”而不是直接写“BETWEEN 2017-05-01 AND 2017-06-30”因为BETWEEN是闭区间如果日期字段带时间戳比如2017-06-30 23:59:59你很可能漏掉或重复计入边缘数据。这是SQL题里最常见的坑也是面试官最喜欢埋伏笔的地方。另外一类高频题型是算留存率。核心思路是先构造每个用户的“活跃日期”表再按注册日对齐计算不同时间窗口的活跃用户数。流程上可以分成三步先找到每位用户的注册日期再关联用户后续的活跃记录最后按注册日期分组统计各时间窗口的留存人数和留存率。如果你对窗口函数比较熟还可以用ROW_NUMBER或DATEDIFF来计算“按首次活跃后的第N天留存”这类更细致的指标。对于这类题我建议你在笔试前把GROUP BY、CASE WHEN条件聚合、窗口函数ROW_NUMBER、LAG、LEAD、DATE_TRUNC这几个核心语法练到条件反射的程度。因为考场上没有时间让你现想。2.3 SQL答题的细节禁忌SQL题还有一个隐性扣分点很多人取数时口径对不上。比如一个表里同一个user_id下有多条交易记录你想算“下单用户数”直接COUNT(user_id)就会算成“订单数”。正确的做法是先搞清楚数据模型的粒度——那个表的每一行到底代表一笔订单还是一次操作如果要求用户数就要用COUNT(DISTINCT user_id)。还有一种情况是字段里有NULL值。比如amount字段为NULLSUM会直接跳过但COUNT会默认把它数进去如果没写DISTINCT。这些细节在本地跑数据的时候不觉得有什么但在笔试的在线测评环境里输出结果和预期不一致你就很难定位是哪一步出了问题。我的建议是写完SQL后别急着提交先做一次“自问”——每一行是我想统计的粒度吗每个JOIN的关联键会不会造成数据膨胀边界条件下结果是否符合预期花30秒做这个检查能救回很多分。3. 机器学习与案例题从建模到落地的完整答题框架3.1 机器学习题目写清楚思路比堆模型名称重要机器学习部分的笔试题通常不会让你手写代码而是给一个业务场景让你设计方案。比如2017年就有一道类似的题给定用户的交易记录和标签是否欺诈要求设计一个欺诈检测方案包括特征工程、模型选择、评估方法和上线方案。这种题没有标准答案但阅卷人会看你的思路是否完整。一个状态还不错的思路框架应该包含四层第一层特征工程。你要先列出能想到的特征类别用户历史行为过去30天交易笔数、金额均值、最大单笔金额、异常时间活跃度、交易本身属性金额、渠道、设备、IP、地理位置、序列特征间隔时间、金额突变率、图特征关联账户数量、设备共用情况。第二层模型选择。欺诈检测一般优先考虑梯度提升树模型因为表格数据上表现稳定能处理缺失值还能输出特征重要性。如果数据有明显的时间序列结构可以考虑引入LSTM或Transformer但需要足够的样本量和特征工程配合。不建议一上来就上深度学习因为在表格数据上树模型往往效果不差而且可解释性更好。第三层评估方法。欺诈场景下正负样本极不平衡准确率没有意义。应该重点看AUC、PR曲线下面积、召回率在特定误报率下的取值。同时要结合实际业务成本构造一个“代价矩阵”——拦一笔欺诈省多少钱、误杀一笔正常交易损失多少收入用这个代价矩阵去选择最优阈值。第四层上线监控。模型不是上线就完了。要设计好训练数据的时间窗口避免用到未来数据造成标签泄漏上线后要监控特征分布漂移、分数分布变化设置告警机制并设计好人工抽样的回流标签策略。这四层不是每层都要写几百字但必须都覆盖到。面试官最反感的是只写“我用XGBoost”然后没有下文的人——这只能说明你调过包不能说明你理解问题。3.2 样本不均衡的处理思路欺诈检测里正样本通常只有千分之几甚至更低直接训练模型会倾向于把所有样本预测为正常。这个问题几乎必考。常见的处理手段有采样法对少数类过采样SMOTE或对多数类欠采样。要注意不能直接在测试集上做任何采样否则验证结果虚高。代价敏感学习在损失函数里调高少数类的权重等价于给少数类更高的误分类代价。XGBoost里可以调scale_pos_weight参数。异常检测思路把欺诈看成异常点用孤立森林或自动编码器建模。这在欺诈模式未知、标签不完整时尤其有用。答题时要注意一点不要一上来就堆方法。面试官想看的是你的分析逻辑——在标签质量差、样本极不平衡的情况下你会怎么权衡我建议按“先保证标签质量再选基础模型最后针对性处理不平衡”这个顺序来组织答案逻辑会清晰很多。3.3 案例题结构化表达是拿分关键案例题通常是整套卷子分值最高的题目往往是一个相对开放的商业问题。2017年的题目大概率和支付业务相关比如某地区的交易量突然下降了15%你作为数据科学家如何分析这个问题这道题没有数据没有背景全靠你结构化思考的能力。我的答题框架是先拆解问题再列数据需求最后给出分析路径。拆解问题要分成三个维度。一是“地区维度”——是整个国家下降了还是集中在某个城市/省份二是“时间维度”——是突然断崖式下跌还是连续几周持续走低三是“产品维度”——是App端、Web端、还是某个支付方式下降然后列出需要的数据各渠道、各地区的日交易额和订单量关键漏斗的转化数据曝光→点击→下单→支付风控策略变更记录竞品动态和市场信息分析路径上要先用数据定位问题再用假说驱动验证。比如先按地区拆解找到贡献度最大的下跌区域然后看那个区域的转化漏斗哪一步掉了再核对风控策略和产品变更记录。重点在于你不能只给出一个原因而要展示一套排查方法。哪怕你的假说最后不成立只要方法对就能拿分。4. 常见问题与排查技巧实录4.1 概率题算不出来怎么办考场上最怕的就是一道概率题卡了二十分钟还算不出结果。我的建议是先跳过去做完其他题再回头。如果实在算不出来也尽量写出“能算的中间步骤”比如先设变量、写出条件概率的表达式这至少能让阅卷人看到你思路是清晰的不会直接零分。4.2 SQL题结果不对别急着重写在本地数据库练习的时候我也犯过这个毛病查询结果和预期不一致就直接把整个SQL删了重写。结果越写越乱最后连原本正确的部分都丢了。更好的排查顺序是先查关联条件。是不是有一对多或多对多的情况导致行数膨胀。再查过滤。是不是有权限或状态的硬条件漏掉了。最后查聚合。GROUP BY的键是否和SELECT中的非聚合字段一致。排查时把SQL拆成CTE逐段执行定位到具体哪一步结果不对再针对性修改效率会高很多。4.3 案例分析没思路默认按“先指标后原因再建议”走如果你在笔试现场对案例题完全没思路不要慌。记住一个万能模板先明确核心指标再拆解维度再列可能原因最后给解决方案。就算是硬套模板也会比空白卷子拿分多得多。因为阅卷人想看的就是你有没有结构感。但如果你想让答案更有区分度可以加一个“反向验证”的环节。比如你说“可能是竞争对手推出新活动导致用户流失”那你要加上“可以通过某渠道的DAU趋势、搜索热度、用户访谈数据验证这个假设”。这个细节能体现你有真实分析经验而不是纸上谈兵。4.4 笔试题里的“送命题”与“送分题”识别很多人上了考场分不清哪道题是“送分题”哪道是“送命题”。结果在难题上耗太久简单题反而没时间写完整。根据我的经验PayPal笔试的难度分布是简单计算题期望值、条件概率是送分题尽量全拿。SQL窗口函数题是送命题写不出来也别慌写出前半部分的SELECT和FROM也能拿部分分。机器学习方案设计是“区分题”考察深度。案例分析是“综合题”决定你的上限。4.5 关于工具和环境准备的建议笔试环境通常是线上的比如HackerRank或者公司自己的平台提前一两天熟悉一下编译环境很重要。有些平台对SQL的方言支持不一样比如PostgreSQL和MySQL的某些函数有差异去重和日期处理的写法也有不同。如果你平时用的是本地Jupyter Notebook建议考前做一次“全流程脱稿”模拟从读懂题目、写代码、到调试运行全程不查资料。这样能暴露很多问题比如快捷键不熟、函数名记错、时间分配不合理。5. 我踩过的坑与补全能力的训练方法回头想一下当时准备这类笔试时我走了不少弯路总结下来有三个典型误区第一个误区是“题海战术”。刷了二三十道LeetCode SQL题结果到了考场上发现题型根本不对路因为LeetCode偏算法而PayPal偏业务。后来我换了思路用真实业务场景来练手比如“算一下过去30天每个渠道的支付转化率环比变化”这种题练多了才能适应。第二个误区是“重模型轻特征”。早期做机器学习题时把精力全放在算法选型上觉得XGBoost比逻辑回归高级用出来就很厉害。实际上面试官要的是你能讲清楚特征的含义、数据怎么清洗、标签怎么定义。特征工程才是决定模型上限的环节。第三个误区是“不重视表达”。笔试虽然是写答案但阅卷人会在十几秒内扫完你的答案。如果你写了一大段没有分点的文字他很难抓到你的重点。后来我学乖了所有的案例分析答案都分点写、加粗关键词并且用小标题分隔。在准备补全能力的时候我建议你按这个顺序训练概率统计把贝叶斯定理、期望、方差、常见分布二项、泊松、正态吃透能做简单的推导和计算。SQL练熟窗口函数和CTE真实业务场景题型多刷几套。机器学习掌握“数据—特征—模型—评估”全链路重点理解评估指标的业务含义。业务思维每天都看一些支付、电商、广告行业的案例练习“用数据解释业务”的表达方式。做完这一步你不仅是在准备一场笔试而是真正补齐了数据科学家所需的基本功。6. 写在最后的一点心得准备数据科学家岗位的笔试本质上不是在准备一场考试而是在检验你有没有建立数据思维。PayPal这套题即使放到今天来看依然不过时因为它的核心考察点——用数据回答业务问题——是数据岗位永远不会变的能力。我最大的感受是笔试中你不需要在每个知识点上都做到顶尖但你要让面试官看到你解决问题的完整链路从理解业务问题到设计数据方案到建模评估再到落地建议。这条链路缺了任何一环都会在评分时被打折扣。如果你正准备投这类岗位最后再分享一个小技巧笔试前花半小时写一张“知识清单”把SQL常用语法、概率公式、模型评估指标、案例分析框架列在一张纸上。不用背就放在旁边。写这个过程本身就是一次高效的复习能帮你在考场上更快地检索思路。祝你在笔试中能沉住气把思路写清楚结果自然不会差。
看到这份“2017PayPal暑期实习生笔试卷-数据科学家”很多准备投数据分析或数据科学方向的同学可能都有点慌。网上能搜到的笔经往往只言片语要么是“考了SQL和概率”要么是“感觉凉了”根本拼不出完整的考察逻辑。我当年备考时也踩过类似的坑后来跟几个面过PayPal的朋友把题目复盘了一遍才发现这套笔试卷其实非常有代表性——它不考死记硬背而是用一套组合拳去筛选真正有业务sense和数据直觉的人。这篇文章我会以当年那套笔试卷为切入点拆解数据科学家实习生笔试的核心考点、答题思路和准备方法并且配上可以“抄作业”的实操框架。不管你是准备外企的数据岗还是想系统梳理自己的数据基本功这篇内容都值得认真看完。1. 笔试整体设计与核心考点拆解1.1 为什么PayPal的笔试题值得认真研究PayPal是做在线支付起家的老牌公司业务天然和数据紧密绑定。你可能觉得一家支付公司的数据科学家主要就是做做报表、跑跑回归但实际上完全不是这样。支付业务有几个非常独特的性质实时性极强每一笔交易都在毫秒级完成风控模型需要在交易发生的同时给出放行、拒绝或人工审核的判断这意味着数据科学家的模型要部署到生产环境实时打分。数据量巨大且噪声多每天数亿笔交易涉及用户行为、设备指纹、IP地址、历史交易序列等而且欺诈行为会有意伪装成正常交易信噪比很低。业务价值直接模型多拦一笔欺诈交易就是直接省钱少拦一笔正常交易就是直接损失收入所以模型的效果可以用非常明确的金额来衡量。正因为这种业务背景PayPal的笔试不会出那种“教科书式”的题目比如让你背一个算法公式或者默写贝叶斯定理。它更看重的是你面对一个真实业务问题时能不能把它转化成数据问题然后用合适的工具和模型去解决。我当时复盘完那套题最大的感受是这套卷子考察的是“从业务到数据”的完整思考链路而不是零散的知识点。1.2 四类题型背后的考察逻辑把网上能找到的笔经和我个人的记忆拼在一起2017年那套笔试大致可以分为四个板块板块考察内容目标能力概率统计期望值计算、条件概率、贝叶斯推断量化思维、不确定性判断SQL实操多表连接、聚合、窗口函数、留存计算取数能力、数据操作熟练度机器学习模型选择、特征工程、评估指标建模能力、算法理解深度案例分析风控策略设计、指标异动归因业务理解、结构化表达能力这个配比是很有讲究的。概率统计解决的是“不确定性”问题。数据科学家的日常就是跟不确定打交道——这个用户有多大概率会逾期这个策略上线后有多少比例的误杀没有扎实的概率直觉你连问题都定义不清楚。SQL解决的是“取数”问题。哪怕你模型建得再花哨拿不到数据、取错口径都是白搭。很多同学轻视SQL觉得“不就是select一下嘛”但实际笔试里SQL是刷人最多的地方因为题目往往藏了坑比如时区、去重逻辑、关联键的选择。机器学习解决的是“预测”问题。这一块考察的不是你会不会调参而是你面对一个业务场景时能不能选择合适的算法、构造有效的特征、并且用对的指标评估。案例分析解决的是“落地”问题。模型不是离线跑个AUC就行要能解释业务含义、要能上线、要能评估收益。这一题会直接反映你有没有真正做过项目。1.3 答题时间分配的隐藏信号笔试时间一般给2到3小时题量看起来不大但时间非常紧张。这里有个隐藏信号PayPal想考察你在时间压力下如何取舍。我观察到的规律是大部分人会卡在概率题然后在SQL题上死磕最后案例分析草草写几行字。这个策略其实很亏。从分值权重来看案例分析虽然只有一道题但评分比重往往不低于占三道小题的概率题。面试官看重的不是你每道题都答完而是你能否在有限时间内对分值高的题目做出足够深度的思考。一个合理的时间分配策略是概率统计25%的时间。会做的快速拿下完全没思路的果断跳过。SQL25%的时间。先跑通逻辑再写代码不要边写边想。机器学习20%的时间。重点写清楚思路和评估方案而不是堆模型名称。案例分析30%的时间。留足时间把框架搭完整。2. 概率统计与SQL的实战答题要点2.1 概率统计题别只会背公式要会“算账”概率统计部分是公认的“拦路虎”。这类题目往往不会直接问“抛硬币正面朝上的概率是多少”而是包了一层业务外衣。比如2017年卷子里有一类题目本质是在问一个风控系统拦截一笔交易已知欺诈交易占比为1%系统对欺诈交易的召回率是90%误报率是5%。现在某笔交易被系统拦截了问它确实是欺诈的概率是多少这题看着像是在考贝叶斯定理其实是在考你能不能把业务指标换算成概率术语。设欺诈事件为 F拦截事件为 IP(F) 0.01P(I|F) 0.9P(I|¬F) 0.05求 P(F|I)P(F|I) P(I|F) × P(F) / [P(I|F) × P(F) P(I|¬F) × P(¬F)]代入P(F|I) 0.9 × 0.01 / (0.9 × 0.01 0.05 × 0.99) 0.009 / (0.009 0.0495) 0.009 / 0.0585≈ 0.1538也就是说被拦截的交易里真正是欺诈的只有15%左右剩下85%是误伤的正常交易。这个结果非常反直觉很多人第一反应是“召回率90%那多半就是欺诈了”但把先验概率算进去之后结论就完全变了。这道题的核心考点在于做风控不能只看模型对欺诈的召回率还要看误报率带来的成本。在实际支付场景里如果误报率是5%意味着每拦截100笔交易会有大约5笔是正常的这会直接伤害用户体验和商家营收。面试官想看你能不能算清这笔账能不能用贝叶斯思维去解读模型输出而不是只会背一个公式。类似的题型还有期望值计算比如“两个策略方案一个成功率低但收益高另一个成功率高但收益低选哪个”。这种题目表面是算期望实际是考察你在不确定性下做决策的框架。回答时最好把期望值算出来再补充一下风险边界比如方差、最坏情况说明你不只会期望最大化还考虑到了风险控制。2.2 SQL实操题窗口函数和留存率是重头戏SQL部分出题方向非常稳定基本绕不开三件事多表连接、聚合统计、窗口函数。其中窗口函数是区分度最高的考点。2017年笔试里有一道典型的SQL题场景是有两个表一个交易表 transactionsuser_id, txn_date, amount, status一个用户表 usersuser_id, reg_date, country要求计算“每个国家2017年6月的GMV以及环比5月的增长率”。很多人第一反应是用WHERE把日期筛选到6月按国家GROUP BY求和然后发现“环比增长率”不知道怎么写。因为要同时算6月和5月的数据你得先把两个月份的数据都取出来再按国家汇总然后用LAG或者自连接来算增长率。一个看起来比较顺的写法是WITH monthly AS ( SELECT u.country, DATE_TRUNC(month, t.txn_date) AS month, SUM(CASE WHEN t.status completed THEN t.amount ELSE 0 END) AS gmv FROM transactions t JOIN users u ON t.user_id u.user_id WHERE t.txn_date DATE 2017-05-01 AND t.txn_date DATE 2017-07-01 GROUP BY u.country, DATE_TRUNC(month, t.txn_date) ) SELECT country, SUM(CASE WHEN month DATE 2017-06-01 THEN gmv END) AS gmv_jun, SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END) AS gmv_may, (SUM(CASE WHEN month DATE 2017-06-01 THEN gmv END) - SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END)) * 1.0 / NULLIF(SUM(CASE WHEN month DATE 2017-05-01 THEN gmv END), 0) AS growth_rate FROM monthly GROUP BY country;这道题有三个考点状态过滤GMV一般只算成功交易的金额status字段需要过滤。时间口径DATE_TRUNC函数按月聚合避免字符串处理出错。环比计算用条件聚合把5月和6月的数据放在同一行再用NULLIF防止除零。写SQL的时候尤其要注意一个细节为什么WHERE条件要写成“ 5月1日 AND 7月1日”而不是直接写“BETWEEN 2017-05-01 AND 2017-06-30”因为BETWEEN是闭区间如果日期字段带时间戳比如2017-06-30 23:59:59你很可能漏掉或重复计入边缘数据。这是SQL题里最常见的坑也是面试官最喜欢埋伏笔的地方。另外一类高频题型是算留存率。核心思路是先构造每个用户的“活跃日期”表再按注册日对齐计算不同时间窗口的活跃用户数。流程上可以分成三步先找到每位用户的注册日期再关联用户后续的活跃记录最后按注册日期分组统计各时间窗口的留存人数和留存率。如果你对窗口函数比较熟还可以用ROW_NUMBER或DATEDIFF来计算“按首次活跃后的第N天留存”这类更细致的指标。对于这类题我建议你在笔试前把GROUP BY、CASE WHEN条件聚合、窗口函数ROW_NUMBER、LAG、LEAD、DATE_TRUNC这几个核心语法练到条件反射的程度。因为考场上没有时间让你现想。2.3 SQL答题的细节禁忌SQL题还有一个隐性扣分点很多人取数时口径对不上。比如一个表里同一个user_id下有多条交易记录你想算“下单用户数”直接COUNT(user_id)就会算成“订单数”。正确的做法是先搞清楚数据模型的粒度——那个表的每一行到底代表一笔订单还是一次操作如果要求用户数就要用COUNT(DISTINCT user_id)。还有一种情况是字段里有NULL值。比如amount字段为NULLSUM会直接跳过但COUNT会默认把它数进去如果没写DISTINCT。这些细节在本地跑数据的时候不觉得有什么但在笔试的在线测评环境里输出结果和预期不一致你就很难定位是哪一步出了问题。我的建议是写完SQL后别急着提交先做一次“自问”——每一行是我想统计的粒度吗每个JOIN的关联键会不会造成数据膨胀边界条件下结果是否符合预期花30秒做这个检查能救回很多分。3. 机器学习与案例题从建模到落地的完整答题框架3.1 机器学习题目写清楚思路比堆模型名称重要机器学习部分的笔试题通常不会让你手写代码而是给一个业务场景让你设计方案。比如2017年就有一道类似的题给定用户的交易记录和标签是否欺诈要求设计一个欺诈检测方案包括特征工程、模型选择、评估方法和上线方案。这种题没有标准答案但阅卷人会看你的思路是否完整。一个状态还不错的思路框架应该包含四层第一层特征工程。你要先列出能想到的特征类别用户历史行为过去30天交易笔数、金额均值、最大单笔金额、异常时间活跃度、交易本身属性金额、渠道、设备、IP、地理位置、序列特征间隔时间、金额突变率、图特征关联账户数量、设备共用情况。第二层模型选择。欺诈检测一般优先考虑梯度提升树模型因为表格数据上表现稳定能处理缺失值还能输出特征重要性。如果数据有明显的时间序列结构可以考虑引入LSTM或Transformer但需要足够的样本量和特征工程配合。不建议一上来就上深度学习因为在表格数据上树模型往往效果不差而且可解释性更好。第三层评估方法。欺诈场景下正负样本极不平衡准确率没有意义。应该重点看AUC、PR曲线下面积、召回率在特定误报率下的取值。同时要结合实际业务成本构造一个“代价矩阵”——拦一笔欺诈省多少钱、误杀一笔正常交易损失多少收入用这个代价矩阵去选择最优阈值。第四层上线监控。模型不是上线就完了。要设计好训练数据的时间窗口避免用到未来数据造成标签泄漏上线后要监控特征分布漂移、分数分布变化设置告警机制并设计好人工抽样的回流标签策略。这四层不是每层都要写几百字但必须都覆盖到。面试官最反感的是只写“我用XGBoost”然后没有下文的人——这只能说明你调过包不能说明你理解问题。3.2 样本不均衡的处理思路欺诈检测里正样本通常只有千分之几甚至更低直接训练模型会倾向于把所有样本预测为正常。这个问题几乎必考。常见的处理手段有采样法对少数类过采样SMOTE或对多数类欠采样。要注意不能直接在测试集上做任何采样否则验证结果虚高。代价敏感学习在损失函数里调高少数类的权重等价于给少数类更高的误分类代价。XGBoost里可以调scale_pos_weight参数。异常检测思路把欺诈看成异常点用孤立森林或自动编码器建模。这在欺诈模式未知、标签不完整时尤其有用。答题时要注意一点不要一上来就堆方法。面试官想看的是你的分析逻辑——在标签质量差、样本极不平衡的情况下你会怎么权衡我建议按“先保证标签质量再选基础模型最后针对性处理不平衡”这个顺序来组织答案逻辑会清晰很多。3.3 案例题结构化表达是拿分关键案例题通常是整套卷子分值最高的题目往往是一个相对开放的商业问题。2017年的题目大概率和支付业务相关比如某地区的交易量突然下降了15%你作为数据科学家如何分析这个问题这道题没有数据没有背景全靠你结构化思考的能力。我的答题框架是先拆解问题再列数据需求最后给出分析路径。拆解问题要分成三个维度。一是“地区维度”——是整个国家下降了还是集中在某个城市/省份二是“时间维度”——是突然断崖式下跌还是连续几周持续走低三是“产品维度”——是App端、Web端、还是某个支付方式下降然后列出需要的数据各渠道、各地区的日交易额和订单量关键漏斗的转化数据曝光→点击→下单→支付风控策略变更记录竞品动态和市场信息分析路径上要先用数据定位问题再用假说驱动验证。比如先按地区拆解找到贡献度最大的下跌区域然后看那个区域的转化漏斗哪一步掉了再核对风控策略和产品变更记录。重点在于你不能只给出一个原因而要展示一套排查方法。哪怕你的假说最后不成立只要方法对就能拿分。4. 常见问题与排查技巧实录4.1 概率题算不出来怎么办考场上最怕的就是一道概率题卡了二十分钟还算不出结果。我的建议是先跳过去做完其他题再回头。如果实在算不出来也尽量写出“能算的中间步骤”比如先设变量、写出条件概率的表达式这至少能让阅卷人看到你思路是清晰的不会直接零分。4.2 SQL题结果不对别急着重写在本地数据库练习的时候我也犯过这个毛病查询结果和预期不一致就直接把整个SQL删了重写。结果越写越乱最后连原本正确的部分都丢了。更好的排查顺序是先查关联条件。是不是有一对多或多对多的情况导致行数膨胀。再查过滤。是不是有权限或状态的硬条件漏掉了。最后查聚合。GROUP BY的键是否和SELECT中的非聚合字段一致。排查时把SQL拆成CTE逐段执行定位到具体哪一步结果不对再针对性修改效率会高很多。4.3 案例分析没思路默认按“先指标后原因再建议”走如果你在笔试现场对案例题完全没思路不要慌。记住一个万能模板先明确核心指标再拆解维度再列可能原因最后给解决方案。就算是硬套模板也会比空白卷子拿分多得多。因为阅卷人想看的就是你有没有结构感。但如果你想让答案更有区分度可以加一个“反向验证”的环节。比如你说“可能是竞争对手推出新活动导致用户流失”那你要加上“可以通过某渠道的DAU趋势、搜索热度、用户访谈数据验证这个假设”。这个细节能体现你有真实分析经验而不是纸上谈兵。4.4 笔试题里的“送命题”与“送分题”识别很多人上了考场分不清哪道题是“送分题”哪道是“送命题”。结果在难题上耗太久简单题反而没时间写完整。根据我的经验PayPal笔试的难度分布是简单计算题期望值、条件概率是送分题尽量全拿。SQL窗口函数题是送命题写不出来也别慌写出前半部分的SELECT和FROM也能拿部分分。机器学习方案设计是“区分题”考察深度。案例分析是“综合题”决定你的上限。4.5 关于工具和环境准备的建议笔试环境通常是线上的比如HackerRank或者公司自己的平台提前一两天熟悉一下编译环境很重要。有些平台对SQL的方言支持不一样比如PostgreSQL和MySQL的某些函数有差异去重和日期处理的写法也有不同。如果你平时用的是本地Jupyter Notebook建议考前做一次“全流程脱稿”模拟从读懂题目、写代码、到调试运行全程不查资料。这样能暴露很多问题比如快捷键不熟、函数名记错、时间分配不合理。5. 我踩过的坑与补全能力的训练方法回头想一下当时准备这类笔试时我走了不少弯路总结下来有三个典型误区第一个误区是“题海战术”。刷了二三十道LeetCode SQL题结果到了考场上发现题型根本不对路因为LeetCode偏算法而PayPal偏业务。后来我换了思路用真实业务场景来练手比如“算一下过去30天每个渠道的支付转化率环比变化”这种题练多了才能适应。第二个误区是“重模型轻特征”。早期做机器学习题时把精力全放在算法选型上觉得XGBoost比逻辑回归高级用出来就很厉害。实际上面试官要的是你能讲清楚特征的含义、数据怎么清洗、标签怎么定义。特征工程才是决定模型上限的环节。第三个误区是“不重视表达”。笔试虽然是写答案但阅卷人会在十几秒内扫完你的答案。如果你写了一大段没有分点的文字他很难抓到你的重点。后来我学乖了所有的案例分析答案都分点写、加粗关键词并且用小标题分隔。在准备补全能力的时候我建议你按这个顺序训练概率统计把贝叶斯定理、期望、方差、常见分布二项、泊松、正态吃透能做简单的推导和计算。SQL练熟窗口函数和CTE真实业务场景题型多刷几套。机器学习掌握“数据—特征—模型—评估”全链路重点理解评估指标的业务含义。业务思维每天都看一些支付、电商、广告行业的案例练习“用数据解释业务”的表达方式。做完这一步你不仅是在准备一场笔试而是真正补齐了数据科学家所需的基本功。6. 写在最后的一点心得准备数据科学家岗位的笔试本质上不是在准备一场考试而是在检验你有没有建立数据思维。PayPal这套题即使放到今天来看依然不过时因为它的核心考察点——用数据回答业务问题——是数据岗位永远不会变的能力。我最大的感受是笔试中你不需要在每个知识点上都做到顶尖但你要让面试官看到你解决问题的完整链路从理解业务问题到设计数据方案到建模评估再到落地建议。这条链路缺了任何一环都会在评分时被打折扣。如果你正准备投这类岗位最后再分享一个小技巧笔试前花半小时写一张“知识清单”把SQL常用语法、概率公式、模型评估指标、案例分析框架列在一张纸上。不用背就放在旁边。写这个过程本身就是一次高效的复习能帮你在考场上更快地检索思路。祝你在笔试中能沉住气把思路写清楚结果自然不会差。
