JD.com数据科学家面试真题与SQL编程2026
一句话总结
JD.com的数据科学家面试不是在考你会不会写SQL，而是在测试你能否用数据驱动商业决策。大多数人把精力放在刷题和语法记忆上，最终却倒在了对业务逻辑的理解偏差上。真正的筛选标准不是你能否写出窗口函数，而是你能否在库存周转率下降0.3%时，主动识别出是华东仓的家电品类出现了滞销，并用数据证明该问题与促销节奏错配的相关性。这场面试本质上是一场微型战略推演，SQL只是表达逻辑的工具，不是目的本身。
JD.com的面试官从不关心你是否背过“Top N”题型模板，他们只在意你能否在15分钟内构建出一个可验证的假设框架，并用真实表结构还原出关键路径。这不是一场技术考试，而是一次业务洞察的压力测试。你之前准备的方向，大概率是错的。
适合谁看
如果你正在准备京东数据科学家岗位的面试，且目标职级为D5或D6（相当于硅谷L4-L5），这篇文章就是为你写的。你可能已经刷完了LeetCode中等难度的SQL题，收集了网上流传的“高频真题”，甚至模拟过几轮行为面试。但你依然不确定京东到底想听什么——因为他们的面试从不照搬标准题库，每一轮都嵌套着真实的业务场景。你更不清楚京东内部对“数据科学家”的定义与其他公司有本质差异：他们不要纯建模工程师，也不要只会画图的分析员，而是要求你在供应链、履约效率、用户增长三个核心领域中至少精通一个，并能用数据推动跨部门落地。
你可能是有2-5年经验的候选人，来自电商、零售或物流行业，熟悉MySQL、Hive或Spark SQL，但对京东复杂的仓库层级结构、SKU动态分层机制、以及促销周期与库存联动模型缺乏系统认知。你也可能是海外背景的申请者，虽然技术扎实，但对“618大促峰值预测”、“城市仓配路径优化”这类本土化问题感到陌生。这篇文章将替你完成最关键的判断：哪些知识点值得深挖，哪些准备方向纯属浪费时间。
面试到底在考什么？不是SQL能力，而是商业推理
JD.com的数据科学家面试第一轮通常是45分钟的技术面，表面看是在考SQL，实则是在测试你的商业推理链条是否完整。面试官不会直接说“请写一个Top 3销量品类查询”，而是会抛出一个模糊问题：“上个月华北区大家电GMV同比下降8%，你如何用数据定位问题？”多数候选人立刻开始构思SQL结构：SELECT category, SUM(gmv) FROM sales WHERE region = '华北' GROUP BY category ORDER BY gmv DESC LIMIT 3。这看起来合理，但已经错了。问题不在于语法，而在于你跳过了最关键的一步：定义“正常”与“异常”的基准。京东内部的分析逻辑是先建立预期模型——比如基于历史增长率、季节系数、促销排期推算出“应有GMV”，再计算偏差。真正的SQL不是从sales表开始，而是从forecastactualgap表切入。我曾旁听过一场hiring committee（HC）讨论，一位候选人在写完基础聚合后补充了一句：“我需要先确认去年同期是否有618大促，因为去年是6月1日启动，今年是6月5日，这5天的预售流失可能占整体跌幅的60%。
”这句话直接让他进入下一轮。面试官事后在debrief会上说：“他没急着写代码，先质疑了比较基准的合理性——这才是我们想要的思维。”另一个案例发生在2024年Q3的一场面试中，候选人被问及“新用户次日留存下降”，他立刻提出要检查“注册时段分布是否偏移”，因为京东发现晚8点到10点注册的用户次日打开率比早6点高22%，而近期市场部把投放预算从晚间转移到清晨。这种对数据背后行为动因的敏感度，远比写出ROW_NUMBER()更重要。不是你在展示SQL熟练度，而是你在用SQL构建一个可证伪的商业假设。不是你能否执行查询，而是你能否定义问题。不是语法正确，而是逻辑闭环。
SQL题的真实形态：不是刷题能覆盖的复合结构
京东的SQL题目从来不是LeetCode上那种孤立的“查找第N高的薪水”。真实题目往往涉及至少三张表的关联、时间窗口的嵌套处理，以及业务规则的显式编码。例如一道2025年真实出现的题目：“计算每个城市仓在过去30天内，SKU动销率低于30%且库存天数超过15天的商品清单，并标记其是否处于‘促销保护期’。”这道题的关键不在于JOIN语法，而在于你能否准确还原京东的业务规则。首先，“动销率”在京东定义为“有销售记录的天数 / 总天数”，不是“销售SKU数 / 总SKU数”——这是常见误解。其次，“库存天数”需要用“当前库存量 / 近7天日均销量”估算，但若近7天销量为0，则需回溯至最近一次销售周期。更复杂的是“促销保护期”：某些品牌商签约要求，在大型促销（如618）前30天内不得对指定SKU降价清仓。这意味着你需要从promotionschedule表中提取protectedsku列表，并结合campaigntype字段过滤。一位候选人在面试中写出了完整的JOIN结构，但在判断保护期时用了WHERE startdate >= CURRENTDATE - 30，被面试官当场指出错误：正确的逻辑是WHERE CURRENTDATE BETWEEN startdate AND enddate，因为保护期是活动期间有效，不是活动前有效。
这种细节只有真正参与过促销策略分析的人才会注意。另一个真实案例是“计算京东小时达订单的履约时效达标率”。题目要求：“统计每日95分位订单履约时长，并判断是否小于30分钟。”候选人通常能写出PERCENTILE_CONT(0.95)，但在处理“履约完成时间”时忽略了“用户取消订单”的情况。京东的口径是：仅统计成功交付订单，取消单不计入分母。但在库存预占逻辑中，取消单仍占用过仓储资源，因此在资源效率分析中必须单独建模。不是你在写SQL，而是在编码京东的业务协议。不是你能否聚合数据，而是你能否还原系统规则。不是语法正确，而是语义对齐。
每一轮面试的真正考察点与时间分配
京东数据科学家面试共四轮，每轮严格计时，考察重点层层递进。第一轮是45分钟技术面，由一线数据团队工程师主持，重点考察SQL与基础统计能力。但这里的“技术”不是指算法复杂度，而是指你能否在有限时间内构建出可落地的查询框架。典型流程是：前5分钟面试官描述业务场景，如“大促后退货率异常上升”；中间30分钟候选人写SQL并口述逻辑；最后10分钟讨论优化与边界 case。第二轮是60分钟业务分析面，由D7级数据科学家或产品经理主持，考察你对京东核心业务的理解深度。题目如：“京东正在试点‘预售+前置仓’模式，如何设计AB测试评估其对履约成本的影响？”这里要求你定义核心指标（如单均履约成本、缺货率）、识别混淆变量（如天气、促销重叠）、并设计分层抽样方案。我曾参与一场debrief会议，一位候选人提出“按城市等级+历史订单密度”分层，被评价为“达到内部PM提案水平”。第三轮是45分钟建模与统计面，由算法团队主持，考察A/B测试设计、p值误用识别、因果推断基础。
典型问题如：“两个组的转化率差异显著，但ITT分析与PP分析结果相反，如何解释？”这要求你理解依从性偏差与工具变量概念。最后一轮是30分钟HR面，看似软性实则关键。HR会问“如果业务方坚持使用有偏样本做决策，你如何应对？”真实答案不是“坚持原则”，而是“提供有偏结果的同时，附上偏差模拟报告，并建议补采数据”。京东看重的是影响力而非对抗性。值得注意的是，所有轮次都不允许使用外部工具，白板手写代码。时间压力本身就是测试的一部分。不是你在展示知识广度，而是在证明在压力下仍能保持逻辑清晰。不是你回答了多少问题，而是你在限定时间内完成了多少有效推理。不是你是否完美，而是你是否可控。
薪资结构与职级对标：base、RSU、bonus的实际数字
京东D5级数据科学家的总包通常在85万-110万人民币之间，具体构成如下：base月薪50K-60K（即年base 60万-72万），年度奖金（bonus）为3-6个月base，取决于个人绩效与部门达成率，通常落在15万-30万区间；限制性股票（RSU）部分为每年40万-60万，分四年归属，每年兑现25%。以一位绩效B+的D5为例，其第一年总包约为：66万（base）+ 19.8万（bonus，按3个月计）+ 15万（RSU第一年归属），合计约100.8万。D6级则更高，base通常在70K-80K/月（年base 84万-96万），bonus为4-8个月，RSU年授予额60万-100万。值得注意的是，京东的RSU授予在2023年后改为“等额分批+绩效加权”模式：基础部分每年归属25%，但额外10%的浮动RSU取决于团队年度OKR完成度。例如，若供应链优化项目达成成本下降5%，则相关数据团队可额外获得5%-8%的RSU兑现。这种设计强化了数据岗位与业务结果的绑定。
相比之下，纯技术岗的RSU兑现更稳定但上限低。一位D6数据科学家若连续两年绩效A，其第三年总包可突破150万。但必须指出，京东的bonus波动较大——2022年部分部门因外部环境仅发放1个月bonus，而2024年零售业务线因利润超预期发放了7个月。不是你拿到offer就锁定收入，而是你的薪酬持续与业务表现挂钩。不是薪资数字本身，而是其背后的激励机制。不是你值多少钱，而是你能持续创造什么价值。
准备清单
- 熟悉京东核心业务指标定义：GMV、NOP（净订单利润）、履约成本、库存周转天数、动销率、缺货率、用户LTV。这些不是通用术语，在京东有明确定义。例如，GMV不包含取消订单，而行业常统计包含取消的“毛销售额”。
- 掌握至少一个核心业务域的完整链路：如从用户点击→下单→仓库分拣→配送→签收→售后的全路径数据建模。能画出各环节的关键表与字段，如orderfact、warehousestock、deliverylog、aftersales。
- 精通时间窗口处理：熟练使用窗口函数计算移动平均、同比环比、累计值。特别注意京东的“大促周期”定义：618为5月21日至6月20日，双11为10月20日至11月13日，这些日期直接影响同比计算的基准。
- 理解AB测试的京东实践：知道“流量分层”与“实验正交性”的实现机制，能识别常见陷阱如学习效应、季节干扰。例如，新功能上线若跨越618，则必须分段评估。
- 准备3个深度项目复盘：每个项目需包含业务背景、指标设计、数据挑战、模型选择、落地效果。避免泛泛而谈“我用随机森林预测销量”，而要说“我在大家电品类使用XGBoost，特征包含历史退货率、安装服务覆盖率、竞品价格差，最终MAPE降至12%，支持了华北仓备货决策”。
- 模拟压力测试：找同伴扮演面试官，给一个模糊问题如“用户活跃下降”，在15分钟内完成假设生成、数据验证路径设计、SQL框架搭建。重点训练在信息不全时的决策能力。
- 系统性拆解面试结构（PM面试手册里有完整的电商数据科学家实战复盘可以参考）——包括如何应对“临时变更问题”、“面试官故意沉默”等非技术场景。
常见错误
错误一：直接写SQL，不定义问题边界
BAD版本：面试官问“如何分析用户流失”，候选人立刻说“SELECT userid FROM loginlog WHERE lastlogin < CURRENTDATE - 30”。这忽略了“流失”的定义权。在京东，流失用户分为“自然流失”（无促销触达也未登录）与“可挽回流失”（有触达但未响应），处理策略完全不同。
GOOD版本：候选人先问：“您指的是连续30天未登录的所有用户，还是排除了已发push但未打开的用户？因为后者涉及触达效率问题，可能需要结合消息中心日志分析。”
错误二：忽略业务规则的显式编码
BAD版本：计算“促销期间销量增长率”时，直接用（促销期GMV - 基准期GMV）/ 基准期GMV。但未考虑基准期是否包含小促，如京东每周的“品牌日”也会带来5%-8%的增量。
GOOD版本：候选人说明：“我会先排除基准期内的所有小型促销日，使用纯自然流量日作为分母，否则会低估真实促销 uplift。”
错误三：模型优先，场景后置
BAD版本：被问“如何提升复购率”，回答“我用协同过滤做推荐系统”。这跳过了最关键的一步：京东的复购驱动因素中，家电是服务驱动（安装体验），快消是库存驱动（自动购），策略完全不同。
GOOD版本：候选人说：“我先按品类拆解复购模式。对于纸巾类商品，我会分析‘购买间隔’与‘库存预警’的相关性，推动上线‘自动补货’功能；对于手机壳，则检查‘换机周期’与‘配件推荐’的匹配度。”
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：是否需要准备机器学习算法题？京东数据科学家是否常做建模？
A：极少。除非你应聘的是“算法工程师-推荐系统”岗位，否则D5-D6级数据科学家的主要工作不是调参。我曾在一场hiring manager对话中听到明确说法：“我们招的是能用Excel和SQL解决80%问题的人，不是非要上GBDT的。” 2025年京东零售数据团队的OKR中，只有12%的项目涉及复杂建模，其余均为AB测试设计、指标体系搭建、自动化报表开发。真实工作中，一个“用户分层看板”的使用频率远高于“下一个商品推荐模型”。
面试中若被问及模型，通常也是考察基础理解，如“ROC曲线如何解读”、“过拟合的业务表现是什么”。更常见的问题是：“如果逻辑回归显示价格弹性为正，你如何排查？”正确回答不是“检查共线性”，而是“检查是否混淆了促销场景——低价商品常出现在高需求时段，导致表面正相关”。你不需要背诵XGBoost公式，但必须能识别数据背后的因果陷阱。
Q：是否必须有电商或物流行业经验？跨行业候选人有机会吗？
A：有机会，但必须快速建立业务映射。一位前医疗数据分析候选人成功入职的关键，是他将“药品库存周转”类比为“家电库存周转”，指出两者都存在“高价值、低频次、服务依赖”特征，并引用京东年报中“大家电自营仓覆盖率提升至85%”的数据，说明服务网络对库存效率的影响。面试官在debrief中评价：“他没做过电商，但他用医疗供应链的逻辑还原了我们的业务痛点。
” 相反，一位快消行业候选人失败的原因是，他把“铺货率”直接套用到京东，忽略了京东的“入仓率”与“可售率”是两个独立指标——某SKU可能已入仓但因合规问题未上架。不是行业背景决定一切，而是你能否将已有经验转化为对京东业务的洞察。跨行业者必须准备一个“业务翻译框架”，把原领域的核心指标映射到京东的三大主线：增长、效率、体验。
Q：SQL测试是否允许使用子查询或CTE？是否有性能要求？
A：允许，但必须解释选择理由。在一场真实面试中，候选人使用CTE分步构建“用户生命周期阶段”：先定义首次购买日，再计算复购间隔，最后打标签。面试官追问：“为什么不用嵌套子查询？”候选人回答：“CTE更易调试，且京东Hive环境对CTE有优化，执行计划显示与子查询无性能差异。” 这个回答被记为“加分项”。
但另一位候选人写了一个五层嵌套子查询，面试官直接问：“如果业务方要求新增一个过滤条件，你如何修改？”候选人卡住，暴露了可维护性问题。京东的SQL评估标准有三层：正确性（是否得出准确结果）、可读性（能否让同事快速理解）、可维护性（是否支持后续迭代）。性能虽重要，但在面试中更看重逻辑清晰。实际生产环境中，超过3秒的查询会被自动拦截，因此必须使用分区剪裁、谓词下推等优化手段，但这通常在onsite后才深入考察。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。