作为一名把几年时间都耗在数据分析这条路上的从业者，看到"京东2018秋招数据分析工程师笔试题"这个标题，第一反应不是去回忆当时的考题，而是感慨那几年正好是互联网数据分析岗从"会用Excel的运营"向"懂统计会写SQL的工程师"转型的分水岭。京东这场笔试在当时算得上是风向标式的存在，题型覆盖了SQL、概率统计、业务分析和基础算法，难度不算变态，但筛人效果极其明显。很多没准备的人挂在第一轮，不是不会做，而是完全没搞懂这场笔试在考什么。
这篇文章不打算给你逐题报答案，那些题目在牛客网和各类面经里都能翻到。我更想做的，是把这套笔试题背后的考察逻辑、每类题型的解题套路、以及当时的考生（包括我自己）踩过的坑完整复盘一遍。如果你是准备电商、零售、供应链方向数据分析岗的求职者，这篇文章能帮你省下大量盲目刷题的时间。
1. 这场笔试的出题逻辑：它到底在筛什么人
先说一个很多人忽略的事实：京东2018秋招数据分析工程师笔试，名义上是考"数据分析"，但它的筛选逻辑明显偏向于"懂业务的工程师"，而不是"会写报告的纯分析师"。这个定位从题型分布就能看出来。
1.1 题型分布与分值结构里藏着的用人偏好
根据当年的考后复盘和牛客网上的讨论，整套卷子大致包含三个部分：第一部分是行测逻辑题，大概占20%到25%的分值，包括数字推理、图形推理和言语理解；第二部分是专业题，以SQL查询、概率统计、数据结构和少量机器学习基础为主，占大头；第三部分是开放性业务分析题，通常是一到两道，要求针对电商场景给出分析思路。
这里面的信号很明显：行测题是用来快速过滤"没有基本逻辑能力"的候选人，专业题用来确认你是否具备干活的基本功，业务题则是为了区分"只会做题"和"真能落地"的差别。很多人复习时只盯着SQL和概率题刷，结果挂在行测上，非常可惜。
1.2 为什么这套题在当年有代表性
2018年前后，各大厂的数据分析笔试普遍处于"摸索期"。早几年的笔试题经常是纯粹的统计计算和Excel操作题，但从那年开始，SQL比重明显提升，业务场景题开始围绕"用户增长、GMV拆解、促销效果评估"这类电商核心话题展开。京东这场笔试算是那个趋势的代表：它要求你既会写代码取数，又能理解数据背后的业务含义。
举个例子，卷子里有一类很典型的题：给你一张订单表，让你统计"618大促期间，新用户的首单转化率环比提升了多少"。这类题表面考SQL，实际上在考你对"新用户""首单""转化率"这些口径的理解——如果连业务指标口径都定义不清楚，SQL写得再溜也白搭。
提示：如果你现在准备的是其他大厂的数据分析岗，这套"业务口径+SQL取数+统计基础"的三角结构依然是主流，只是难度和场景会换一换。
1.3 时间分配是第一批淘汰的分水岭
整套题大约90分钟，题量不算小，尤其是行测部分非常耗时间。我当时的策略是：先花5分钟通读全卷，把业务分析题放在最后写，因为它的分值虽然高，但思考成本也高；行测里的数字推理如果30秒内没思路，直接跳过，不恋战；SQL题留在中间段集中火力解决。
这个策略帮我避开了最大的坑：很多人在前面行测的逻辑题上死磕，到后面发现SQL题根本来不及写。要知道，SQL题的分值是实打实的，而且答案相对唯一，比行测那种"找规律"的主观题靠谱得多。
2. SQL题是全场送分题还是送命题，取决于你踩没踩过这些坑
SQL在整套卷子里的地位，怎么说都不为过。当年有好几道题直接就是给表结构、写查询语句，考察点非常集中：JOIN的底层逻辑、聚合函数与GROUP BY的配合、窗口函数的典型用法、以及子查询的性能意识。但真正让大批人翻车的，不是语法，而是细节。
2.1 JOIN全家桶：成绩单表关联这道题的经典陷阱
当时有一道题特别典型：有两张表，一张是学生信息表，一张是成绩表，让你统计"每个班级的及格率"。听起来很简单对吧？但实际写起来，很多人挂在两个地方：第一，用INNER JOIN还是LEFT JOIN？如果成绩表里没有某个学生的记录，这个学生算不算"不及格"？第二，及格率的分子分母口径到底是什么——是"及格人数/班级总人数"还是"及格人数/参加考试人数"？
正确的做法是先明确口径。在很多电商场景里，这两个口径的差异直接决定了分析结论。比如算"优惠券核销率"，分子是核销订单数，分母到底是领取人数还是曝光人数？不同口径下，这个率可以差出好几倍。回到那道题，如果题目没有明确说明，默认应该用"班级总人数"做分母，对应的就是LEFT JOIN保证所有学生都保留，再用CASE WHEN把缺成绩的记录归为不及格。
-- 思路示意：LEFT JOIN + CASE WHEN 处理缺失成绩 SELECT c.class_name, COUNT(DISTINCT s.student_id) AS total_students, SUM(CASE WHEN sc.score >= 60 THEN 1 ELSE 0 END) AS pass_students, SUM(CASE WHEN sc.score >= 60 THEN 1 ELSE 0 END) * 1.0 / COUNT(DISTINCT s.student_id) AS pass_rate FROM class_info c LEFT JOIN student_info s ON c.class_id = s.class_id LEFT JOIN score_table sc ON s.student_id = sc.student_id GROUP BY c.class_name;我当时在复盘时专门研究过这类题目，发现出题人特别爱在"关联键是否有重复值"上埋雷。比如用订单表和商品表做关联，如果商品表里一个商品ID对应多条记录（比如不同类目维度），那关联出来的订单行数就会翻倍，聚合结果直接出错。这种问题在笔试里不会给你报错，但结果对不上，阅卷人一眼就能看出来。
2.2 窗口函数：从"会写"到"用得对"的差距
2018年那会儿，窗口函数已经不算冷门了，但在笔试里能写对的人并不多。京东的题里出现过一类典型需求：取每个品类下销量排名前3的商品。用GROUP BY子查询硬做也能出来，但写起来很绕，而且容易错。用窗口函数就清爽得多：
-- ROW_NUMBER + 分区排序，取每个品类销量前三 SELECT category_id, product_id, sales_volume FROM ( SELECT category_id, product_id, sales_volume, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sales_volume DESC) AS rn FROM product_sales ) t WHERE rn <= 3;这个考点背后考察的是你对"分组取TopN"这类高频需求的理解。在电商数据分析里，"每个类目下卖得最好的商品""每个城市活跃度最高的用户"都是每周都要跑的数据，窗口函数基本是居家必备。如果你当时只会写GROUP BY，虽然在笔试里也能凑合出答案，但代码的可读性和扩展性差很多，面试官看到你的写法，心里对你的评价会低一个档位。
注意：窗口函数里PARTITION BY和GROUP BY的语义不能搞混。GROUP BY会折叠行数，窗口函数不会。如果你需要在窗口函数的结果上再做过滤，必须包一层子查询，因为WHERE的执行顺序在窗口函数之前，直接加条件会报错。
2.3 子查询与临时表的性能意识
还有一道题让我印象很深：统计最近30天每天的下单用户数。数据量不大，怎么写都能跑出来，但出题人特意在题目最后加了一句"请写出你认为最优的写法"。这就不是在考语法了，而是在考性能意识。
最直观的写法是每天去子查询里扫一遍全表，写成30个UNION ALL。这种写法逻辑没错，但每扫一次全表就是一次全量IO，数据量上来以后基本跑不动。更合理的思路是先把日期过滤条件推到最内层，缩小数据范围后再聚合，或者利用日期维表一次性把30天的数据都算出来：
-- 推荐：日期过滤推入子查询，避免重复全表扫描 SELECT dt, COUNT(DISTINCT user_id) AS active_users FROM user_orders WHERE dt BETWEEN DATE_SUB(CURRENT_DATE, INTERVAL 29 DAY) AND CURRENT_DATE GROUP BY dt;这道题给我的启发是：笔试里的SQL题，答案"能跑"只是及格线，"跑得高效"才是加分项。很多科班出身的人在学校里写SQL都是玩具数据，几千行怎么折腾都行，但到了京东这种量级的数据环境，一句烂SQL可能把整个任务队列拖垮。面试官通过这么一个小问题，就能判断出你有没有真实处理过大规模数据的经验。
3. 概率统计题的隐性门槛：不是算不出来，是看不懂题在问什么
概率统计部分在整套专业题里的占比不算最高，但它是区分"科班统计出身"和"半路转行"的关键阵地。京东这套卷子里涉及的知识点包括条件概率、贝叶斯公式、期望计算、常见分布（二项分布、泊松分布）、假设检验和简单的AB测试分析。乍看都是大学概率论的基础内容，但结合电商场景以后，很多人就懵了。
3.1 贝叶斯公式那道题：先验概率怎么定，决定了答案方向
有一道题我记得特别清楚，题干大概是：某商品页面的点击率是10%，在点击用户中，有20%会加购；在未点击用户中，有5%会直接通过其他入口加购。问：已知一个用户加购了，他点击过该商品页面的概率是多少？
这道题其实就是标准的贝叶斯公式应用。设A为"点击过页面"，B为"发生过加购"，已知P(A)=0.1，P(B|A)=0.2，P(B|¬A)=0.05。要求的P(A|B) = P(B|A) * P(A) / P(B)。其中P(B) = P(B|A) * P(A) + P(B|¬A) * P(¬A) = 0.2×0.1 + 0.05×0.9 = 0.065。最终P(A|B) = 0.02 / 0.065 ≈ 30.77%。
算本身不难，但很多人的问题在于：把"点击用户中加购的比例"和"加购用户中点击过的比例"搞混了。这两个条件概率方向正好相反，混在一起，结果自然错得离谱。这个坑在现实业务里也特别常见——比如分析"看过直播的用户购买率更高"，到底是直播促成了购买，还是本来就爱买的用户更爱看直播？这就是典型的因果方向混淆问题，笔试考的是基础，但其实现场面试里的业务题也一直在考同一件事。
3.2 期望值计算："多少个用户进来，才能等到一个下单"这类题
另一类高频题是算期望。比如：某活动的用户转化率是1%，请问平均需要多少用户访问，才能等到1个下单用户？答案不是100，而是需要用到几何分布的期望公式，E = 1/p = 100。但如果追问"等到第3个下单用户的期望访问量"，答案就得把三个几何分布相加，得到300。
这类题考的是对"等待时间"类问题的直觉。如果你只是记住了公式，但没理解几何分布"独立重复试验直到首次成功"的语义，遇到变体就容易翻车。我当时复习时特意把这类题的变形都整理了一遍，包括"至少需要n个用户才能有95%概率产生至少一单"这种，用1-(1-p)^n ≥ 0.95反推n。这种计算看起来偏理论，但做业务预估时特别实用，比如广告投放的预算测算、活动页面流量预估，本质上都是这个逻辑。
3.3 AB测试与假设检验：显著性到底在说什么
2018年的笔试卷子里已经出现了AB测试相关的概念题，比如"p值为0.03，能否说明实验组显著优于对照组？"很多人的第一反应是"能"，因为0.03 < 0.05。但出题人想考察的是：p值的定义是"在原假设为真的前提下，观察到当前或更极端结果的概率"，它不等于"实验组有效的概率"，更不等于"效果大小"。p值小只代表"统计显著"，不代表"业务显著"——如果样本量足够大，一个0.1%的提升也能p<0.05，但这在业务上根本无足轻重。
这类题在笔试卷子里占比不大，但在面试环节基本是必问项。我当时在复盘笔记里专门写了一句总结：看到p值先别急着说显著，先问样本量多大、效果量多少、这个提升能不能覆盖实验成本。这个思维习惯一直用到现在，无论是做推荐策略的灰度实验还是营销活动的AB测试，都非常受用。
4. 业务分析题：你的答案能不能落地，面试官一眼就能看出来
业务分析题是整套卷子中最开放、也是最难临时抱佛脚的部分。京东的笔试里出现过一类很典型的问题：假如618大促期间，某品类的销售额同比下滑了20%，你会如何分析原因？这种题没有标准答案，但阅卷人心里有一套"好答案"的画像。
4.1 拿到一道业务分析题，先说框架，再谈数据
很多人拿到这种题的第一反应是"先去看数据"，然后就开始枚举各种可能的原因：价格问题、竞品问题、流量问题、天气问题……这种回答最大的毛病是零散，没有结构，让阅卷人觉得你缺乏系统性的分析思维。
正确的打开方式是先搭框架。我当时用的是一个经典的电商分析框架：销售额 = 流量 × 转化率 × 客单价。先把指标拆到这层，再逐层下钻。
- 流量层面：是总UV下降了，还是来源结构变了？自然流量、付费流量、活动流量各自贡献多少？
- 转化率层面：是详情页转化率跌了，还是加购到下单的转化率跌了？中间每一步的流失是否异常？
- 客单价层面：是消费者买了更便宜的商品，还是促销折扣力度加大导致实付金额下降？
- 品类内部结构：是主力单品下滑，还是整个品类都在下滑？有没有新品接不住流量的问题？
这套拆法不是我的原创，但它几乎是所有大厂业务面试题的标准回答姿势。原因很简单——可执行。你把销售额拆成流量、转化率、客单价三个因子，每个因子都能对应到具体的团队去跟进：流量问题找增长/投放，转化率问题找产品/运营，客单价问题找 merchandising（品类规划）。
4.2 区分"同比口径"和"环比口径"，别一头扎进数据里
那道品类下滑的题，还有一个非常隐蔽的考察点：同比下滑20%，但去年同期是什么情况？大促的日期在不同年份可能是错位的，比如去年618的第一波活动从5月25日开始，今年从5月28日开始，比较时间段不一致，算出来同比自然失准。
这种"口径陷阱"在笔试卷子里出现，其实是在考察候选人有没有真实业务经验。我在实际工作中处理过太多类似的坑：有一次分析季度销售额变化，发现华东区跌得特别厉害，才想起去年同期的华东区数据里混入了一笔大型企业团购订单，那个大单根本不是常规零售，硬是让增长率看起来很夸张。如果不做口径清洗，分析结论会严重偏离事实。
所以，写业务分析题时，我养成了一个习惯：不管题目给不给数据，都在答案开头先声明"需要先确认口径"，包括时间范围、业务边界、异常数据处理方式。这个习惯在笔试里很加分，因为大多数人都会直接埋头分析，只有少数人会先质疑数据本身。
4.3 对比分析和归因：给结论，但也给出"怎么做"的建议
回到那道品类下滑题，一个高分的答案不应该止步于"找到原因"，还要给出下一步的动作建议。比如：
- 如果发现是付费流量成本上涨导致ROI下降、投放量收缩，建议是调整投放策略，把预算倾斜到转化率更高的渠道，同时补充品牌词投放防守。
- 如果发现是核心单品缺货，导致大量流量涌入后无货可卖，那就不只是运营问题，还是供应链问题，需要联动补货计划。
- 如果发现是竞品大促力度更强，可以针对性设计品类专属券、组合套装或赠品策略来对冲。
这会让阅卷人觉得，你不是一个只会"分析"的人，而是一个能"推动决策和落地"的人。数据分析岗的终极价值从来不是出一份报告，而是让报告里的结论能变成业务动作。
5. 算法与工具题：Python、Excel，还有藏在题目里的机器学习基础
除了SQL和概率统计，这套笔试题里还有一部分会让人措手不及的内容：简单的编程题和机器学习概念题。说实话，2018年那会儿，"数据分析工程师"和"算法工程师"的边界还比较模糊，笔试题里出现Python编程和基础模型概念并不意外。
5.1 手写代码题：不是考你写多快，而是考你会不会"结构化思考"
有一类很常见的题：给定一个列表，统计每个元素出现的次数，并按次数从高到低排序。这种题在LeetCode上属于easy级别，但笔试现场手写时，很多人会写得乱七八糟——不是跑不出来，而是代码风格和边界处理暴露了底子。
用Python写的话，标准解法是利用collections.Counter：
from collections import Counter items = [1, 3, 2, 3, 1, 2, 1, 4, 5, 4] counter = Counter(items) sorted_items = sorted(counter.items(), key=lambda x: x[1], reverse=True) print(sorted_items) # 注意：当次数相同时，可以再加一个规则，比如按元素大小升序 sorted_items_with_tiebreak = sorted(counter.items(), key=lambda x: (-x[1], x[0]))笔试题里这类题考的不是你记得多少API，而是你能否处理并列排序的tie-break问题。很多人只按次数排，忽略了次数相同的情况，这种细节在真实的工作里直接决定报表排序的稳定性。类似的小细节还包括：列表为空时会不会报错、输入数据里有没有None值等。写出一个处理了这些边界的函数，和写出一个"所有测试用例恰好能过"的函数，阅卷人一眼就能分清。
5.2 机器学习基础题：逻辑回归和决策树的高频问答
笔试题里还出现过一些机器学习的基础概念题，比如逻辑回归为什么用sigmoid函数、决策树如何选择最优划分特征、什么是过拟合以及常用的缓解办法。这些题不需要你手推公式，但至少得说出个所以然来。
举个例子，问"逻辑回归的损失函数为什么不用均方误差"，很多人一下子卡住。其实答案核心在于：逻辑回归的最终输出是一个概率值，如果我们用均方误差做损失，优化目标就变成了一个非凸问题，梯度下降很容易陷入局部最优；而用交叉熵损失函数，函数是凸的，优化过程稳定，并且交叉熵的梯度形式也更好算。
我当时复习这部分内容时，没有死记硬背，而是把"模型的损失函数为什么这样设计"这个逻辑链完整走了一遍。这样即使笔试时的具体问法换了，我依然能从原理出发给答案，而不是背一套答案上去。
5.3 Excel和工具题：低门槛但高区分度
还别笑，Excel在整套卷子里也占了一席之地。有一类问题是给出一张数据截图，让你描述用Excel做数据透视表或者VLOOKUP的步骤。这种题在科班出身的候选人眼里显得太初级，但出题人显然知道：真实业务场景里，不少需求方发来的数据表就是Excel格式，分析师如果连Excel的数据处理技巧都不熟练，日常协作会非常吃力。
如果你的基础比较薄弱，我建议至少掌握VLOOKUP、数据透视表、条件格式和基础的图表制作。不需要成为Excel大师，但"别人发来一张杂乱的大宽表，你能快速清洗成可分析的结构化数据"这个能力，在任何公司都是硬通货。
6. 考后复盘：那些我在笔试之后才想明白的事
笔试结束之后，很多人会陷入"对答案"的焦虑中。但以过来人的经验看，比"对完答案对错"更重要的，是把整场笔试当成一次免费的模拟测试，复盘自己的知识盲区和时间分配问题。
6.1 错题本比刷题量更重要
我当时刷题的习惯是：每套卷子做完，不急着做下一套，而是把错题按知识点分类整理。比如：
- SQL类：右连接和左连接使用场景混淆
- 概率类：条件概率方向颠倒
- 业务类：分析缺少框架，想到哪说到哪
- 行测类：数字推理规律积累不足
整理完后再针对薄弱项做专项练习。这个方法的效率远高于盲目刷题，因为笔试的考点其实高度集中，你把每个知识点的常见坑都踩过一遍，考场上遇到任何变体都不会慌。
6.2 学会"用输出倒逼输入"
复盘时还有一个很有用的技巧：把每道题用自己的话讲一遍，讲到一个完全不懂数据分析的朋友也能听懂为止。这个过程能逼你把模糊的理解转化成清晰的知识结构。我当时就发现自己对"假设检验的p值"理解得模棱两可，能背定义但没法解释为什么p<0.05不能直接下结论。正是通过"讲解"这个动作，我才把这块的思维理顺了。
这个习惯一直保留到现在，无论是做技术分享还是写文档，我都很看重"能不能用大白话把事情讲清楚"。数据分析这个岗位，一半的功夫在"算"，另一半在"说"，两者缺一不可。
6.3 笔试只是第一步，面经里才有真正的实战经验
最后说一个很多人容易忽略的点：笔试结束后的面试环节，才是真正拉开差距的地方。京东数据岗的面试基本会围绕简历项目深挖，比如你处理过的分析项目里，为什么选这个指标、怎么处理异常值、分析结论如何落地。这些在笔试题里能体现一部分，但主要是靠平时的项目积累。
如果你手头没有拿得出手的数据分析项目，建议先做一个端到端的完整项目，哪怕数据是自己爬的或从公开数据集里找的，过程也要完整走一遍：数据清洗、探索性分析、特征构造、可视化、结论输出。面试官看重的不是你项目有多高级，而是你有没有踩过真实的坑、能不能说清楚每个步骤背后的取舍。
说到底，京东2018秋招这套笔试题，考的不是你"知道多少"，而是你"能不能用它来解决真实问题"。这种考察思路，即使在今天的数据分析师招聘里也依然成立。把上面这些考点和解题思路吃透，再去应对其他电商或互联网公司的笔试，你会发现自己像是拿到了同一条巷子的地图——每道题的长相在变，但那些门牌号你早就记住了。
我在复盘这套题时最大的体会是：笔试不是终点，它只是一个筛选机制，真正决定你能否拿到offer的，是你对业务的理解深度和解决实际问题的能力。与其焦虑地刷一百套题，不如花时间把十套题里的每道题都吃透，把每类题的思维方式内化成自己的分析框架。这套方法论，比任何题库都值钱。
