Grab数据科学家面试真题与SQL编程2026
一句话总结
Grab数据科学家岗位的核心筛选标准不是SQL写得多快，而是能否用数据重构业务逻辑——大多数候选人花三小时准备窗口函数，却在第一轮就被淘汰，因为他们根本没搞清Grab要的是能定义问题的人，而不是只会执行查询的人。真正通过的人，往往在简历阶段就展示了对东南亚出行供需失衡的建模理解，而不是堆砌“用Python做过回归”。
这不是一场技术考试，而是一次产品思维的现场推演：面试官要的不是“我跑了AB测试”，而是“我重新定义了留存指标，因为它在Grab的场景下根本无效”。
适合谁看
这篇文章适合三类人：第一类是正在准备Grab数据科学家岗位的候选人，尤其是那些已经刷完LeetCode SQL题却在模拟面试中屡屡卡壳的人。你缺的不是语法熟练度，而是对Grab业务场景的穿透力——比如你能写出Ride ETA偏差的计算SQL，但你是否知道在吉隆坡雨季，这个指标的分布会因摩托车占比上升而产生系统性偏移？第二类是转行者，特别是从传统行业或国内大厂跳槽到东南亚科技公司的人。你在阿里做过千万级用户分析，但在Grab，一个吉隆坡司机端补贴策略的AB测试，样本量可能只有800人，你要面对的是高噪声、低信号的现实，而不是理想化的数据集。
第三类是内部转岗者，比如从Grab Financial Solutions想转到Rides团队的数据分析师。你熟悉公司系统，但如果你还用金融风控的思维去建模司机流失，你会在debrief会上被直接质疑：“你考虑过司机在雨天宁愿损失补贴也要回家接孩子吗？” 这篇文章就是为这些“看似匹配实则错位”的人准备的纠偏手册。
SQL真题到底在考什么？
Grab的SQL面试题从来不是孤立的技术题，而是业务逻辑的切片。2026年Q1的一道真题是：“计算过去30天内，每个城市司机接单率低于60%的天数占比，并按周聚合。” 表面看是 GROUP BY 和条件聚合，但实际考察的是对“接单率”定义的敏感度。大多数候选人直接用 COUNT(completedrides) / COUNT(requestssent) 计算，但这是错误的。
面试官期待你追问：“司机在线但未收到订单的时段是否计入分母？” 因为在雅加达，高峰期系统会因负载限制减少派单频率，这会导致接单率被低估。正确的做法是先确认业务定义：接单率是否只针对“有订单曝光的司机”？如果答案是是，那么你的WHERE条件必须先筛选出“至少收到一个订单推送的司机-天”组合。
另一个真题：“分析促销活动对乘客7日留存的影响，排除自然流失用户。” 候选人常犯的错误是直接用活动期间新用户做分组对比。但2025年11月一次真实面试中，一位候选人被追问：“如果活动只推送给信用分>700的用户，你如何处理选择偏差？
” 他立刻重构了SQL，用PSM（Propensity Score Matching）预计算匹配组，再用JOIN关联留存表。这正是面试官想要的——不是你能不能写JOIN，而是你是否意识到“促销用户”本身就是一个非随机样本。最终他在debrief中被评价：“虽然SQL语法有小错，但对混淆变量的识别能力达到了L5标准。”
更深层的考察是数据完整性判断。一道题要求“计算每辆车的平均载客里程”，但数据中存在大量缺失vehicleid。多数人直接用 AVG() IGNORE NULL，但正确做法是先做缺失模式分析：这些缺失是随机分布，还是集中在某个车型或城市？2026年2月一次HC会议中，一位面试官提到：“有个候选人用COALESCE(vehicleid, 'unknown')然后分组，我们当场否决。
这不是技术问题，是数据伦理——你不能把未知当作一个合法分类。” 真正的解法是先输出缺失率报告，再建议补数策略，比如用注册信息反推。SQL在这里不是终点，而是你思考过程的载体。
业务建模题：不是写代码，而是定义问题
Grab的数据科学面试中，80%的失败发生在业务建模环节，而不是SQL执行。典型题目是：“如何衡量GrabPay在便利店场景的渗透效果？” 多数候选人跳进“计算使用GrabPay支付的交易占比”，但这是错误的起点。面试官真正想看的是你能否拆解“渗透”的定义：是用户渗透（多少人用过）？交易渗透（多少笔交易用）？
还是商户渗透（多少店支持）？2025年Q4一场面试中，候选人A直接写SQL算比例，候选人B则先反问：“我们想提升的是交易规模，还是用户习惯养成？” 前者被挂，后者进入终面。因为B意识到，在印尼，GrabPay在便利店的主要竞争对手不是现金，而是GoPay的红包补贴——所以单纯的使用率无法反映竞争态势。
另一个案例：“优化GrabMart的配送时效。” 候选人常从“预测配送时间”入手，但2026年1月一次面试中，面试官突然问：“如果数据显示，平均ETA是38分钟，但用户取消订单的阈值是25分钟，你怎么调整策略？” 这是在测试你能否跳出描述性分析，进入干预建模。
正确反应是提出“动态ETA重估”：不是固定预测，而是根据实时路况和司机位置，每5分钟更新一次ETA，并在超过用户忍耐阈值时触发优先派单。这个逻辑必须在SQL中体现为窗口函数嵌套条件判断，但更重要的是你能否在对话中构建这个业务逻辑。
最致命的误区是“用技术复杂度代替业务洞察”。一位L4候选人花了20分钟写了一个三层嵌套的SQL，用机器学习预估每个订单的流失概率，然后做归因分析。面试官问：“这个模型上线后，运营团队能做什么？” 他答不上来。
而另一位候选人用简单SQL分组比较“有补贴 vs 无补贴订单的取消率”，然后建议：“在高峰时段对预计ETA>30分钟的订单自动叠加2万印尼盾补贴。” 这个方案可执行、可测试，最终被团队采纳为试点策略。面试不是Showroom，是作战室——你要给出能明天就用的方案，而不是学术论文。
面试流程拆解：每一轮的生死线在哪？
Grab数据科学家面试共五轮，每轮都有明确的淘汰标准。第一轮是30分钟的HR Screening，重点不是你做过什么，而是你为什么做。典型问题是：“你最近一个项目中，哪个决策是反直觉的？
” 多数人回答“我们发现用户更喜欢深色模式”，这是无效答案。正确回答应如：“我们发现提高补贴反而降低司机上线率，因为高补贴吸引低质量司机，导致订单分配不均，形成负反馈循环。” HR在记分卡上标记“是否有因果思维”，这是进入下一轮的关键。
第二轮是60分钟的SQL与数据分析，由中级数据科学家主面。考察重点是“数据完整性意识”。2026年标准题库中有一题：“计算每日活跃司机数（DAD），排除测试账号。” 候选人必须主动追问测试账号的识别方式——是通过邮箱后缀？
还是行为模式（如连续接单10次且里程为0）？在2025年12月一次面试中，一位候选人直接用WHERE email NOT LIKE '%@grabtest.com'，被评价为“缺乏防御性思维”。正确做法是建议多维度识别，并在SQL中用注释说明潜在误判风险。这轮淘汰率高达65%，主要因为候选人把数据当作完美输入。
第三轮是45分钟的业务案例，由资深数据科学家（L5）主持。题目如：“如何评估在曼谷推出GrabScooter的可行性？” 考察的是“约束条件建模能力”。面试官不期待完整方案，而是看你如何拆解：是先算市场规模？
还是先看竞品定价？正确路径是先定义成功指标——比如“单辆车日均收入超过摩托车购置成本的1%”，然后反向推导需要多少订单密度。2026年1月一次debrie会议记录显示：“候选人提出先做小规模试点，用贝叶斯更新需求预测，这个框架被认可，尽管细节有误。”
第四轮是跨部门模拟会议，与产品、运营各一人对话60分钟。典型场景：“你发现夜间订单取消率上升，如何推动改进？” 失败者直接说“建议提高司机补贴”，成功者则先展示数据：“取消率上升集中在22:00-24:00，且80%发生在酒吧区，司机反馈安全顾虑。
建议试点‘夜间护送模式’：自动匹配同路线订单，减少空驶。” 这轮考察“影响力建模”——你能把数据转化为他人行动的动力吗？
最后一轮是Hiring Manager面，45分钟。不问技术，只问判断。问题如：“如果CEO要求下周提升10%司机留存，你会怎么做？” 答案不是执行计划，而是风险揭示：“短期内提升留存可能牺牲质量，比如放宽司机准入。我建议先定义‘优质留存’，再设计策略。” 这轮通过者在HC会上被描述为“有产品所有者心态”。
薪资结构与职级对应关系
Grab数据科学家职级从L3到L6，薪资结构清晰。L3（初级）base $85,000，RSU $40,000/年（分4年归属），bonus 10%（约$8,500），总包约$133,500。这个级别通常要求1-3年经验，能独立完成SQL查询和基础AB测试分析。2026年招聘重点在印尼和越南本地人才，远程比例提高至40%。
L4（中级）base $110,000，RSU $70,000/年，bonus 15%（$16,500），总包约$196,500。这是主力级别，要求能主导一个功能模块的数据分析，比如优化GrabFood的推荐排序。典型任务是设计并分析一个“新餐厅曝光策略”的AB测试，需处理网络效应和样本污染问题。面试中必须展示对CUPED等方差缩减技术的理解。
L5（高级）base $145,000，RSU $120,000/年，bonus 20%（$29,000），总包约$294,000。要求能定义问题域，比如重构“城市运营健康度”指标体系。2025年新加坡团队一位L5提出用“司机-乘客双边满意度乘积”代替单边NPS，被推广至全区域。这个级别必须有跨团队项目领导经验。
L6（首席）base $180,000，RSU $200,000/年，bonus 25%（$45,000），总包约$425,000。全球不超过5人，直接向数据科学主管汇报。负责如“东南亚出行需求预测大模型”等战略项目。面试中会模拟董事会问答，要求用三页PPT解释复杂模型的商业影响。
值得注意的是，2026年起Grab将RSU发放与ESG指标挂钩。例如，若所在团队的碳排放计算模型被用于政府合作项目，额外发放10% RSU。这反映公司战略从增长优先转向可持续运营。
准备清单
- 精读Grab近三年的公开技术博客，特别是关于动态定价和供需平衡的论文。重点理解“Surge Pricing with Spatial-Temporal Graph Networks”中的特征工程设计，这不是为了背诵，而是为了在面试中能说：“我注意到你们用道路拓扑作为GNN输入，这在曼谷窄路场景下是否会导致过平滑？”——这种提问能立刻建立专业可信度。
- 重写你的项目经历，确保每个案例都包含“问题定义-约束识别-方案迭代-商业影响”四段结构。避免“我用随机森林预测了流失”这种描述，改为“我们发现传统流失定义在高流动市场失效，于是重构为7日无交易且未打开App，新指标使干预准确率提升22%”。
- 掌握至少三个东南亚市场的基础数据：雅加达平均通勤时间47分钟，吉隆坡摩托车占出行工具38%，曼谷便利店密度每平方公里2.3家。这些数字要能自然融入案例分析，比如在讨论配送时效时说：“考虑到雅加达47分钟的平均通勤，30分钟送达承诺可能需要重新校准。”
- 准备两个“反共识”观点，用于HM面试。例如：“我认为DAU不是衡量GrabMart健康度的核心指标，因为复购周期受天气和促销强影响。我们应跟踪‘周活跃购物篮’——每周完成至少两次购买的用户。” 这种观点展示独立思考。
- 系统性拆解面试结构（PM面试手册里有完整的Grab业务建模实战复盘可以参考），重点学习如何将模糊业务问题转化为可计算指标。例如“提升用户体验”要拆解为“降低关键路径耗时”、“减少异常流程跳出率”等具体维度。
- 模拟跨部门会议，找朋友分别扮演产品和运营，练习用数据推动决策。关键不是展示图表，而是设计“触发点”——比如“当司机满意度低于4.2分且连续3天取消率>15%时，自动启动调查问卷”。
- 更新LinkedIn，明确标注技术栈与业务领域。不要写“精通Python”，而是写“用Python构建吉隆坡司机补贴响应弹性模型，MAE=0.18”。招聘团队会用内部工具扫描关键词，精准匹配需求。
常见错误
错误一：把SQL当作独立技能准备
BAD案例：一位候选人准备了50道LeetCode中等题，面试时流畅写出“计算月留存率”的SQL，使用标准的LAG窗口函数。但当面试官问：“如果用户在月底最后一天注册，你的分母会包含他吗？” 他愣住，无法回答。
问题在于，他把“月留存”当作固定公式，而不是可辩论的业务定义。在Grab的实际场景中，新用户常在月底促销涌入，立即计算留存会产生大量“0日留存”噪声，正确做法是设置最小观察期。
GOOD版本：另一候选人写完基础SQL后主动说：“我假设新用户需有至少7天观察期才计入分母，因为东南亚用户首单后沉默期较长。如果业务要求包含所有用户，我需要调整过滤条件。” 这展示了定义权意识——数据科学家的首要任务是界定问题边界。
错误二：忽视数据生成机制
BAD案例：题目要求“分析司机奖励计划的效果”，候选人直接对比参与和未参与司机的收入。但未考虑：奖励计划是主动报名还是系统邀请？如果是高活跃司机被优先邀请，就会产生正向选择偏差。一位候选人因此被拒，debrief记录写道：“未能识别内生性问题，结论不可信。”
GOOD版本：候选人先用PSM匹配司机，用历史上线天数、平均评分等协变量计算倾向得分，再做ATT估计。他解释：“即使我们不能做RCT，也要用可观测变量逼近实验条件。” 这正是Grab在2025年司机补贴迭代中实际采用的方法。
错误三：追求模型复杂度而非可执行性
BAD案例：面试题“预测GrabFood订单取消”，候选人构建XGBoost模型，特征包括天气、路况、餐厅评分等，AUC达0.82。但当问“模型上线后，运营能做什么？” 他答：“提醒餐厅注意。” 面试官追问：“如果模型预测某餐厅取消率高，是因为出餐慢还是骑手等待久？” 他无法拆解。结果被淘汰。
GOOD版本：候选人用简单逻辑回归，但将特征显性化：“出餐时间>15分钟的系数为0.7，骑手等待>5分钟为0.3。建议运营对出餐慢的餐厅提供厨房优化培训，对等待久的区域增加骑手调度。” 模型AUC只有0.75，但方案可落地，被评价为“用适度技术解决实际问题”。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：没有东南亚经验，能过Grab数据科学面试吗？
能，但必须证明你能快速建立场景感知。2026年一位通过的候选人来自美国零售公司，他在准备时做了三件事：第一，下载Grab App，记录一周内早高峰的ETA波动，发现雨天预测偏差达22分钟；第二，分析印尼央行发布的移动支付报告，指出GoPay在25岁以下用户中占比68%；第三，在面试中提出：“你们的补贴策略是否考虑了用户现金持有习惯？
在越南，周薪制工人可能在发薪日第二天才有消费能力。” 这些洞察让他在HM面获得加分。关键不是经验本身，而是你能否用数据重构陌生市场的逻辑。公司不期待你懂所有文化细节，但要求你有“快速建模陌生环境”的能力——这才是数据科学家的核心竞争力。
Q：SQL手写一定要最优解吗？
不。Grab面试中，正确性优先于性能。一道题要求“找出连续三天下单的用户”，有人写三层JOIN，有人用ROW_NUMBER()做差值分组。两种都接受。但如果你写嵌套子查询导致O(n²)复杂度，且数据量明确是十亿级，就会被质疑工程意识。
2025年一次面试中，候选人用递归CTE解连续登录问题，面试官问：“在我们的Redshift集群上，递归深度超过10会怎样？” 他答：“可能栈溢出，建议改用窗口函数。” 这个回答反而加分——他展示了系统约束认知。真正致命的是忽略业务逻辑，比如用LEFT JOIN时不考虑NULL值对聚合的影响。面试官要的不是炫技，而是稳健、可维护的代码思维。
Q：业务案例题有没有标准框架？
有，但不是MECE或SCQA这类通用模型。Grab内部使用“Impact-Feasibility-Adaptability”（IFA）框架。Impact指方案对核心指标的理论提升空间，比如“预计可提升司机周活跃度5%”；Feasibility评估工程和运营成本，如“需要新增两个API接口，开发周期3周”；
Adaptability关注方案在不同市场的可复制性，例如“该策略在摩托车主导的雅加达可能失效，因接单半径更小”。2026年HC会议中，一位候选人用此框架分析“动态定价扩展到货运业务”，被评价为“具备平台级思维”。你不需要背诵框架名称，但必须在回答中自然体现这三个维度。没有框架的讨论被视为“直觉驱动”，无法进入高阶评估。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。