聊聊数据岗校招笔试唯品会2018年这套题在校招圈里流传度相当高。不管是准备电商方向的数据分析、数据挖掘还是数据仓库岗位拿这套题当“体检”都很合适——它不像一些互联网大厂那样题目偏怪偏难整体比较贴近真实业务场景既能看出候选人的SQL功底也能看出对电商业务的理解深度。网上有零零散散的回忆版和讨论帖但缺一份完整的拆解和分析这篇文章我就以过来人的视角把这套题涉及的考察点、答题思路、易踩的坑一次性整理出来。如果你正在准备数据岗校招尤其是目标锁定电商领域这篇内容能帮你省下不少自己摸索的时间。我会结合当年和后来几届同学的实战反馈把每个考点背后的考察意图也讲清楚——毕竟笔试不只是为了过筛子更是一次和面试官进行“业务对话”的起点。哪怕你不面唯品会这套题背后的逻辑也适用于绝大多数电商公司的数据岗位笔试。1. 数据岗笔试的整体定位与考察逻辑1.1 电商数据岗到底想招什么样的人先聊一个大前提电商数据岗笔试和开发岗笔试有本质区别。开发岗笔试考的是代码能力和算法思维题做对了基本就过了数据岗笔试则更偏向“业务 技术”的交叉验证。唯品会这套题给我的直观感受是它不追求你在某一道题上做到极致而是用一套组合拳看你有没有完整的数据分析思维链条。这个链条大致是理解业务问题 → 明确分析目标 → 拆解所需数据 → 用SQL/统计手段取数或验证 → 把结果翻译回业务语言。所以笔试过程中你会发现有的题表面在考SQL实际是在考你“懂不懂电商的订单表和用户表是怎么关联的”有的题表面在考统计实际是在考你“知不知道什么场景该用什么检验方法”。这也是为什么很多刷完LeetCode的同学反而会在这种笔试题上栽跟头——题目不是不会做是没看懂它在问什么。1.2 笔试考察的四个核心维度结合那几年唯品会数据岗笔试的情况来看考察点可以归为四个维度。第一个维度是数据工具能力主要是SQL和PythonSQL比重最大基本上所有取数逻辑都得用SQL表达。第二个维度是统计与概率基础比如假设检验、贝叶斯、分布、期望方差这些要求不高但覆盖面广。第三个维度是业务理解与指标拆解这是拉开差距的地方涉及电商核心指标的定义、归因逻辑、A/B测试设计等。第四个维度是逻辑推理与场景应变通常以开放式题目的形式出现考察你面对不完整信息时的分析和表达能力。这里要多说一句不同方向的数据岗在这四个维度上的权重差异很大。数据分析岗更偏业务理解和指标拆解数据挖掘岗更偏统计基础和模型思维数据仓库岗更偏SQL和数据建模。当年不少同学在准备时没有区分方向导致在弱项上花了大量时间强项反而没来得及精进。建议你在刷这套题之前先明确自己的目标岗位再按权重分配复习精力。2. 高频考点SQL与统计基础2.1 SQL题电商数据场景的查询与分析SQL在唯品会数据岗笔试里占比相当可观题型也基本覆盖了日常工作中最常用的几个场景。先说我总结出来的三大类多表关联查询、聚合与开窗函数、数据清洗与去重逻辑。多表关联是最基础也是最重要的。电商数据环境里订单表、用户表、商品表、活动表之间的关系错综复杂笔试题目一般会给你几张简化后的表结构让你写出满足条件的查询。这里要特别注意表的粒度问题。比如订单表是一行一笔订单还是一个订单多行商品明细这直接决定了JOIN的时候要不要先聚合否则很容易出现数据膨胀导致结果偏大。我记得有一套比较典型的题目是“统计每个用户的首次下单时间、最近下单时间和累计下单金额。”这道题看着简单但考察了两三个关键点窗口函数或者自关联取最小值/最大值、聚合运算、以及时间字段的格式处理。用窗口函数写的话大概是这个思路SELECT user_id, MIN(order_time) AS first_order_time, MAX(order_time) AS last_order_time, SUM(order_amount) AS total_amount FROM orders WHERE order_status success GROUP BY user_id;很多同学一上来就直接GROUP BY忽略了订单状态的过滤——已取消的订单要不要算进累计金额里这个在题目里通常会以“有效订单”或“支付成功订单”的方式给出读题时就要圈出来。关于金额的计算也有讲究电商里常见的都是“实付金额”而非“商品原价”因为涉及优惠券、满减等营销工具做题时优先使用实付金额字段。2.2 窗口函数拉开差距的关键考点窗口函数是电商数据岗笔试的常客也是很多零基础同学觉得难的地方。它和普通聚合最大的区别是聚合会把多行合并成一行窗口函数却保留每一行原始记录只是在每一行上额外计算出一个汇总值。这个特性在计算“累计值”“排名”“同比环比”“N日留存”时非常有用。拿“计算每个用户按订单时间排序后的订单序号”来说用普通SQL很难写用窗口函数就是一句话的事SELECT user_id, order_time, order_amount, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_time) AS order_seq FROM orders;这里ROW_NUMBER、RANK、DENSE_RANK三个函数的区别也经常被拿出来考。简单记ROW_NUMBER给每个记录一个唯一序号遇到相同排序值会随机分配RANK遇到相同值会并列但后续序号会跳DENSE_RANK并列之后序号不跳。在一个具体的题目场景里比如“找出每个品类下成交金额排名前3的商品”你用RANK还是DENSE_RANK会直接影响结果里包含的记录数。实际笔试中窗口函数一般会和聚合函数混着用。比如“计算每个用户近30天的消费金额并要求输出每一天的滚动累计”这种就需要在PARTITION BY里用日期维度做范围筛选SQL写法类似SELECT user_id, order_date, SUM(order_amount) OVER( PARTITION BY user_id ORDER BY order_date ROWS BETWEEN 29 PRECEDING AND CURRENT ROW ) AS last_30d_amount FROM orders;这里最要命的是别定义错窗口的边界。是ROWS还是RANGE、PRECEDING还是FOLLOWING搞错了算出来的数就完全不对。当年我记得有不少同学把这道题想成了GROUP BY按月汇总完全跑偏丢分很可惜。2.3 统计学基础假设检验与概率分布统计题在唯品会这套笔试题里出现的频率也不低但整体难度比数理统计专业课要低更偏应用层面。高频考点有这么几个假设检验的基本流程p值、显著性水平的含义、常见概率分布正态分布、二项分布、泊松分布的适用场景、条件概率与贝叶斯公式。假设检验几乎是必考。常见的题目切口是给你两个版本的活动页面一个转化率2.1%一个转化率2.4%样本量各自给出问你怎么判断第二个版本是不是真的更好。这道题考的核心不是让你手动算z检验而是看你能不能说出正确的分析框架先提出原假设和备择假设→选统计量→定显著性水平一般0.05→计算p值→下结论。同时你还要能指出“转化率差异在统计上显著”和“业务上有显著提升”是两个层面的问题后者还需要考虑样本量、置信区间、实施成本等多种因素。概率题方面贝叶斯公式是一个高频考点因为它和“用户分类”“垃圾邮件识别”“推荐系统”等场景天然贴合。比如给你某个行为在不同用户群里的概率分布反推一个用户发生该行为后属于某类用户的概率直接套贝叶斯公式就能解但前提是搞清楚哪个是先验概率、哪个是似然概率。我在帮学弟学妹们模拟面试时发现概念单独拿出来都懂一放到题目场景里就分不清建议碰这类题时先在草稿纸上把事件用A和B标出来再套公式。3. 业务分析题电商指标的拆解逻辑3.1 电商指标体系从GMV到用户价值业务分析题是唯品会数据岗笔试题里最有“店招”风味的部分也是面试官筛选候选人业务敏感度的主要手段。这类题不会给你现成的数据和表结构而是给你一个业务现象让你提出分析思路。电商领域的指标体系说来说去就是“人货场”三个字。围绕人是用户生命周期相关的指标新客数、活跃用户数、留存率、复购率、客单价、LTV用户生命周期价值。围绕货是商品表现相关的指标SKU数、动销率、售罄率、毛利、退货率。围绕场是流量和转化相关的指标曝光量、点击率、转化率、GMV、订单量。笔试题目往往是给一个“结果指标异常”让候选人来拆。比如“某品类GMV环比下降了10%请分析可能的原因”。这里有个答题模板可以套先拆公式GMV 流量 × 转化率 × 客单价然后对每个因子做下钻流量是掉了还是涨了转化率有没有波动客单价是因为折扣力度变大还是高价商品出货占比下降再横向看品类内部结构是普遍下跌还是某个头部商品垮了最后交叉验证比如看同比、看不同渠道的差异、看竞品动作。千万别一上来就只说“可能跟天气有关”“可能跟活动有关”这种拍脑袋的话面试官不会认可。3.2 三种高频题型归因分析、漏斗分析、A/B测试业务题翻来覆去就那几类先说说归因分析。核心是“结果异常了怎么层层下钻找到原因”。我一般建议用“先确认再拆解”的思路第一步确认数据口径没问题第二步拆公式找主要矛盾第三步从渠道、地区、用户分层等维度交叉验证第四步结合业务动作给出结论。漏斗分析相对直接主要考察候选人对用户路径的理解。比如“从曝光到支付的转化漏斗中哪一步流失最大如何定位问题”这种题不复杂但要注意不同品类的用户决策路径差异。买手机和买零食的转化漏斗绝对不是同一套前者用户会在商品详情页反复比较后者可能从加购到下单只需要几分钟。答这类题时如果能顺便提一句“先用行为日志确认漏斗步骤的顺序和时间窗口再去看流失集中点”会比单纯说“看哪步转化率低”高一个层次。A/B测试是另一个高频考察点。这里要注意的是很多同学张嘴就能说“随机分组、控制变量、算显著性”但落到具体业务场景里就漏洞百出。比如做促销活动A/B测试时你要考虑用户是否在测试期间跨组流动还要注意分组是基于用户粒度还是设备粒度不同的划分方式会影响结论的可靠性。再比如样本量的确定事先要用功效分析和基线转化率估算而不是测试做完后再来算显著性。3.3 案例分析销售下降归因类题目的作答思路我用一道比典型的“销售下降归因”题来演示一下完整作答过程。题目大意是某品类近7天销售额较之前7天下降了20%你作为数据分析师如何分析我的答题框架分四步第一步确认数据口径。先问清楚“销售额”是实付口径还是下单口径是否排除了退款、虚假交易时间窗口是否一致有没有节假日和促销错位的影响。这一步很关键因为数据口径错了后面分析全都白费。第二步拆解公式。销售额 流量 × 转化率 × 客单价。用SQL分别拉出两个时间窗口的这三个指标看谁是主要拖累项。假设发现转化率正常、客单价正常流量降了那核心矛盾就在流量。第三步下钻流量。流量可以按来源渠道拆区分自然流量、付费流量、活动流量也可以按端拆看是App端还是小程序端下降明显还可以看是否受头部竞品投放、行业淡旺季等因素影响。这里我通常会建议要看需求是否真实——如果自然搜索流量跌了可能是商品标题和类目匹配出了变化这属于运营侧问题。第四步交叉验证与建议。结合品类内部结构头部商品销量变化是否和某个断货SKU有关、用户分层新客还是老客降幅更大来锁定真正的原因最后给出可落地的动作建议比如提醒运营追投、补充库存、调整搜索关键词等。这套思路看起来不复杂但要在笔试环境下快速组织出来还是需要平时积累。我的建议是考前把“流量×转化率×客单价”这套公式和“渠道/端/品类/用户分层”的下钻维度背得滚瓜烂熟。4. 实操演练还原一道综合题的完整答题过程4.1 从读题到拆需求的思考过程唯品会这套笔试题里有一道综合题大致是给你两张表用户维表user_id, age, gender, city_level, register_time和订单事实表order_id, user_id, order_date, order_amount, category_id。要求是“统计不同年龄段的复购率”并且给出分析结论。这个题看着简单实际上坑不少。第一步读题要明确“复购率”的定义是指“有多次购买行为的用户数 ÷ 有购买行为的用户总数”还是指“购买次数≥2的订单量占总订单量的比例”不同口径算出来的数差别很大。业内通常用的是前一种即人群口径按用户去重复。然后就要判断年龄段怎么划分。是直接用用户注册信息里的birth字段还是用购买时的年龄考虑数据的时效性通常建议用“分析截止日期时用户的实际年龄”来划分。如果表里只有birthday就要写函数算年龄如果只有age字段就要确认它是静态值还是动态更新的。经过拆解之后SQL逻辑就变成分三步找出有效购买用户及其购买次数→计算每个用户的年龄→按年龄段分组统计复购率。4.2 手写SQL时最容易犯的细节错误取数逻辑定了接下来就是把思路落到SQL上。这个环节我最想强调的是细节。很多同学算法思路完全没问题最后却因为一些小错误丢分非常可惜。第一个高频错误是JOIN之前不确认是否会产生笛卡尔积。用户表和订单表是一对多的关系如果先在两张表之间做了JOIN再聚合统计复购次数就可能被重复计算。正确的做法是先对订单表按user_id聚合算出每个用户的购买次数再和用户表关联或者使用子查询。第二个坑是时间过滤条件的边界。统计“最近90天复购用户”如果写成WHERE order_date DATE_SUB(CURDATE(), INTERVAL 90 DAY)那正好卡在第90天当天下单的数据会被漏掉因为DATE_SUB算出的是90天前那天的零点。严谨的做法是用和把边界框住比如order_date DATE_SUB(CURDATE(), INTERVAL 90 DAY) AND order_date CURDATE()。第三个坑是NULL值处理。用户表里age字段可能有空白gender字段可能有异常值如果在分组统计时不处理最后的分析结论可能会被带偏。笔试题虽然通常不会在这些地方设置魔鬼细节但你在SQL里主动加一层COALESCE或CASE WHEN会给阅卷人留下严谨的好印象。4.3 一份可以直接模仿的SQL参考答案完整的解题SQL可以这样组织WITH user_orders AS ( SELECT user_id, COUNT(DISTINCT order_id) AS order_cnt FROM orders WHERE order_status paid GROUP BY user_id ), user_age_group AS ( SELECT u.user_id, CASE WHEN DATE_FORMAT(u.birthday, %Y) 1990 THEN 30岁及以上 WHEN DATE_FORMAT(u.birthday, %Y) 1997 THEN 23-29岁 ELSE 23岁以下 END AS age_group FROM users u ) SELECT g.age_group, COUNT(DISTINCT o.user_id) AS buyer_cnt, SUM(CASE WHEN o.order_cnt 2 THEN 1 ELSE 0 END) AS repeat_buyer_cnt, SUM(CASE WHEN o.order_cnt 2 THEN 1 ELSE 0 END) / COUNT(DISTINCT o.user_id) AS repeat_rate FROM user_orders o LEFT JOIN user_age_group g ON o.user_id g.user_id GROUP BY g.age_group;这个写法有几处值得说明。第一我在订单表里加了order_status paid的过滤排除了未支付订单确保只统计有效购买行为。第二COUNT(DISTINCT order_id)比COUNT(order_id)稳妥因为同一个订单号在明细表里可能出现多行。第三先聚合再JOIN把数据膨胀的可能性提前消灭掉。4.4 如何呈现分析结论让阅卷人眼前一亮笔试不只是写SQL还得把分析结论表达好。很多同学的答案止步于跑出一个数字比如“30岁及以上用户复购率最高”。这种表达几乎拿不到高分因为数据岗的核心价值不是跑数是把数变成能让业务方行动的洞察。补充分析结论时可以考虑加两层。第一层是对比不同年龄段的复购率差异有多大差距的主要来源是什么。比如23-29岁用户复购率高于30岁以上用户是否因为前者更习惯移动购物、更容易被新品触达。第二层是建议动作针对复购率偏低的年龄段可以做什么。比如对23岁以下用户做更频繁的新品推送对30岁以上用户侧重满额减和会员积分。笔试时间有限不需要面面俱到但至少要有“数据异常/差异现象 → 可能原因 → 行动建议”的完整链条这样阅卷人就能直观感受到你有业务分析的感觉。5. 常见易错点与备考建议5.1 数据岗笔试三大坑从刷题到心态提前把坑指出来能让后续复习少走弯路。第一个大坑是只刷题不总结。刷了几十道SQL题每道题的知识点都零散地堆在脑子里没有形成“遇到什么场景用什么解法”的条件反射结果一到笔试就卡壳。正确的做法是每做完一道题强迫自己归纳一下考察的知识点和适用场景比如“窗口函数用在排名、累加、N日留存”“自关联用在连续登录、会话切分”。第二个大坑是不对答案就开下一题。笔试练习最容易陷入自嗨模式以为自己写出来的SQL是对的结果和参考答案一对比才发现少了一个过滤条件或JOIN顺序不对。我的建议是每道题至少核对两遍一遍是逻辑正确性再看一遍边界条件和性能。特别是那种数据量很大的场景有没有考虑用子查询先过滤、减少JOIN的运算量这些细节都值得反复琢磨。第三个大坑是情绪管理不到位。笔试现场遇到一道不会的题当场慌了神然后影响后面所有题目的发挥。建议考前把心态调整好笔试题量大、时间紧遇到不会的题先跳过把能拿的分都拿到再回头啃硬骨头。一道大题就算只写出一半的分析框架也比空着强因为阅卷人能看到你的思路。5.2 高效备考路径四到六周突击攻略如果是准备校招笔试我给的建议是提前四到六周开始系统复习不建议战线拉太长也不建议裸考硬冲。先把基础打牢再针对目标公司做专项突破。第一周重点是SQL基础回顾。把SELECT、JOIN、GROUP BY、HAVING、ORDER BY这些基础用法理一遍确保能熟练写出单表查询和多表关联。第二周重点练窗口函数和复杂查询比如排名类、累计类、分组TopN、同比环比。这两周可以借助网上的SQL练习题每天固定刷五道题保持手感。第三周进入统计知识复习重点看假设检验、置信区间、贝叶斯公式、常见分布的使用场景。第四周开始做业务分析题模拟找历年的校招笔试题尝试用标准框架口述答题有条件的话可以找同学互相模拟面试。最后的两周就是真题模拟和查漏补缺。建议模拟笔试环境严格控制时间让自己适应考场的节奏。真题刷完之后要仔细分析自己的丢分点是SQL语法不熟、业务题没思路还是时间分配不合理针对丢分点做专项训练比盲目刷新题更有效。5.3 应试技巧时间分配、草稿纸的妙用笔试时间分配直接影响总分。一般建议按分值比例分配时间分值大的综合题至少要留出30%以上的时间。遇到简单题快速作答不要恋战遇到中等难度的题先给十分钟思考时间超过十分钟没思路就先跳过把后面的题做了再回来看。草稿纸是笔试中非常被低估的工具。我建议拿到草稿纸先别急着写代码先用一分钟把每道题的题号、考点、预估用时列出来形成一个简单的任务清单。做题时先把复杂的业务分析题的框架思路写在草稿纸上再动笔写正文。这样写出来的答案会更饱满也不会写着写着跑偏。纸上还应该留一块地方专门记录每道题的时间防止不知不觉在一道题上耗费过久。另外一个小技巧是答案格式要按照“读题理解 → 分析思路 → 核心SQL/结论 → 业务建议”的结构来组织。很多时候阅卷官在批改时会快速浏览你的答案框架结构清晰比堆砌一堆SQL代码更有优势。5.4 除了笔试题本身校招数据岗还需要准备什么笔试只是校招流程中的一环很多同学在笔试前忽略了简历和项目经历的梳理结果面试时讲不清自己做过什么。我在之前的辅导经验中发现一个比较理想的状态是笔试证明你的基本功过关面试时的项目经历证明你能把基本功用在真实问题上。项目经历的描述可以按照“背景 → 目标 → 动作 → 结果”的逻辑组织和数据分析报告的写法一脉相承。举个例子不要只说“用SQL分析过用户复购”要具体到“通过RFM模型对某季度购买用户分层锁定高价值流失人群并向运营输出定向召回策略使得该人群次月召回率提升15%”。数据有没有这么精确另说关键是表达方式要让面试官觉得你有数据思维和业务闭环意识。如果你是跨专业或零实习背景也可以从Kaggle、天池这类竞赛项目切入或者自己找一份公开的电商数据集做完整的数据分析报告效果不亚于一段普通实习经历。笔试题当场能写好说明你有基础项目经历能讲好说明你真的理解这个岗位在做什么这两者一起构成了校招数据岗的完整竞争力。写在最后的一些体会回过头来看唯品会2018年这套笔试题它不算是市面上最难的但确实是一套很有“电商味”的题目。它不会让你去默写某个冷门算法的推导过程而是把业务分析和SQL取数糅合在一起考察你是否具备一个数据岗从业者的基本功。我个人这几年在带校招新人时也会沿用这套题作为入门培训的测评材料因为它出的那些坑——复购率口径、订单状态过滤、时间边界、分组维度——恰恰是真实工作中天天会遇到的问题。最后再分享一个小建议笔试前两周除了刷题每天花十分钟看看电商行业的数据分析案例或者围绕一个自己常用的App想想它的核心指标有哪些、近期某个功能改动会影响哪个指标、你怎么验证这次改动是否有效。这种“日常思维训练”看起来和笔试无关实际上是最能提升业务分析题得分的方式。校招这条路挺熬人的但每次踩坑都是在给未来攒经验祝你在笔试和面试里都能把自己的真实水平发挥出来。