ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

小红书数据分析笔试复盘:SQL、业务分析与备考路线

小红书数据分析笔试复盘:SQL、业务分析与备考路线 每年校招季我都会被问到同一类问题数据分析岗笔试到底考什么尤其是内容社区类公司业务逻辑和电商、金融都不一样题目风格差别很大。前段时间整理旧资料翻到一份小红书2020校招数据分析笔试题的复盘笔记当时我带过几个学员考过这个岗位印象很深。这里说明一下各家笔试题都是动态更新的网上流传的所谓“真题”很多也是面试者回忆的片段我不保证下面这些题目和真实试卷逐字一致但题型分布、考察重点、难度层次是可以复盘的。这篇文章就把我当时带人备考时总结的完整思路、解题过程和踩坑经验写出来给准备投递数据分析岗的同学做个参考。先说结论小红书的数据分析笔试难度中等偏上但真正刷人的不是题目本身而是两类问题——第一类是SQL写得太慢第二类是业务分析题答不到点子上。前者靠刷题能解决后者需要理解内容社区的数据逻辑。1. 笔试整体结构与考点分布先说整体感受。2020年那会儿小红书校招数据分析岗位的笔试大概在90分钟到120分钟之间题型分成四个模块SQL题、概率统计题、业务分析题、机器学习基础题。有的批次还会加性格测试或行测类的逻辑题但核心权重还是落在前三块。从分值占比来看我按当时的回忆和多个渠道的成绩反馈做了个大致的估算模块题型分值占比建议用时SQL与数据处理手写SQL、表关联、窗口函数20%-25%20-25分钟概率统计分布、期望、假设检验、贝叶斯20%-25%20-25分钟业务分析指标拆解、案例归因、估算题35%-40%35-40分钟机器学习基础模型原理、评估指标、场景选型10%-15%10-15分钟这个结构其实代表了内容社区公司考察数据分析师的核心思路不会让你去证明复杂的数学定理但你必须能快速处理数据并且能从数据里读出业务含义。尤其是业务分析题的比重比很多电商公司都要高这和小红书“社区种草”的商业模式直接相关。1.1 为什么小红书特别重视业务题小红书的数据分析师不是纯技术岗日常工作中很大一部分精力要跟产品经理、运营同学对接用数据回答“笔记曝光为什么跌了”“搜索点击率为什么涨了”“这个活动到底有没有带来增量”之类的问题。笔试里的业务题就是提前筛选你有没有数据分析的思维框架能不能把模糊的问题转化成可执行的量化方案。很多同学在准备时容易犯一个错误把所有精力都花在刷SQL和概率题上觉得业务题“随便说说”就行。实际情况是SQL和概率题大家分差不大真正拉开差距的就是那几道业务分析题。我见过太多候选人技术题答得漂亮业务题写了两三行空话最后笔试被挂。所以这篇文章的业务题部分我会写得更细。2. SQL与数据处理题内容社区的表关联逻辑SQL题在笔试里属于送分题但也是最容易“阴沟翻船”的模块。原因在于2020年前后不少候选人还在用传统的JOIN思路硬解窗口函数类问题而小红书这类内容平台的业务数据大多是用户行为日志考察点集中在留存计算、漏斗转化、TopN排行、连续活跃这几类场景。2.1 高频考点留存、漏斗、TopN我当时整理过一份高频SQL题型清单和面试反馈对照下来命中率很高计算某日新增用户在次日、7日、30日的留存率统计每个笔记id的曝光、点击、收藏、评论转化漏斗找出每个用户发文数排名前三的笔记计算连续N天发布笔记的用户数计算人均曝光量、中位数曝光量等相关指标这些题目单看难度不大但笔试题会把表结构设计得比较“脏”比如有的表包含重复记录、有的字段存在空值、时间字段是字符串格式考察的就是你在真实场景下的数据清洗能力。2.2 例题拆解近30日发布笔记用户的次日留存拿一道典型的留存题举例。假设有两张表-- 用户信息表 CREATE TABLE user_info ( user_id BIGINT COMMENT 用户ID, reg_date STRING COMMENT 注册日期, yyyy-mm-dd ); -- 笔记发布记录表 CREATE TABLE note_publish_log ( note_id BIGINT COMMENT 笔记ID, user_id BIGINT COMMENT 发布用户ID, publish_date STRING COMMENT 发布日期, yyyy-mm-dd );题目要求计算2020年6月1日发布笔记的用户中在6月2日依然有活跃行为的用户占比。活跃行为定义为点赞、收藏、评论、发布笔记任意一种。这里有一个关键点题目给的活跃行为往往分散在好几张行为日志表里你需要先把这些表UNION起来再去重统计。WITH active_users AS ( SELECT DISTINCT user_id FROM ( SELECT user_id, action_date FROM like_log WHERE action_date 2020-06-02 UNION ALL SELECT user_id, action_date FROM collect_log WHERE action_date 2020-06-02 UNION ALL SELECT user_id, action_date FROM comment_log WHERE action_date 2020-06-02 UNION ALL SELECT user_id, action_date FROM note_publish_log WHERE publish_date 2020-06-02 ) t WHERE user_id IS NOT NULL ), publish_users AS ( SELECT DISTINCT user_id FROM note_publish_log WHERE publish_date 2020-06-01 ) SELECT COUNT(DISTINCT p.user_id) AS publish_user_cnt, COUNT(DISTINCT a.user_id) AS active_next_day_cnt, ROUND(COUNT(DISTINCT a.user_id) / COUNT(DISTINCT p.user_id), 4) AS next_day_retention_rate FROM publish_users p LEFT JOIN active_users a ON p.user_id a.user_id;这个答案看着不复杂但实际笔试里错误率很高。常见坑有三个一是UNION ALL之后没有去重导致同一个用户因为多种活跃行为被重复计数二是LEFT JOIN之后没有用COUNT(DISTINCT)而是直接COUNT结果被NULL值影响三是日期过滤条件写错2020年6月1日是周一有人习惯性写了“上周一”导致数据为空。2.3 统计口径是SQL题的隐藏扣分点除了写对SQL笔试还经常在“统计口径”上挖坑。比如让你计算“笔记曝光率”题目可能在题干里定义“曝光”是“笔记出现在信息流中”但也可能在下一行补充“排除自己发布的笔记在自己首页的曝光”。很多同学不看细节直接按字面统计最后答案和标准答案完全对不上。这类问题没有捷径只能靠平时养成读题划重点的习惯。我在备考时给学员的统一要求是所有指标计算题先写出“分子分母定义”再写SQL。哪怕你最后SQL没跑通阅卷老师也能看到你的思路印象分会高很多。这个习惯在我后来带团队面试时也是加分项因为它代表你具备业务分析师最基本的严谨度。3. 概率统计题均值与中位数的“小红书陷阱”概率统计在笔试里不会出纯数学推导题考察重点集中在几个方向期望计算、条件概率、贝叶斯更新、假设检验、均值与中位数的业务含义、辛普森悖论。和小红书业务结合得最紧密的是均值与中位数那道题几乎每轮笔试都会出现变形。3.1 经典题目博主收入均值为何远高于中位数题目大概是这样的某平台调研博主收入发现收入均值是30000元但中位数只有5000元你怎么解释这个现象对平台运营有什么启示这个问题的标准答法包含三个层次。第一层说明分布形态收入是典型的右偏分布长尾分布少数头部博主赚走了大部分收入大部分博主收入较低导致均值被极端值拉高。第二层解释业务含义如果是做商业化定价或者激励策略用均值会高估普通博主的收入水平应该参考分位数P50、P90、P99或者直接用对数变换后的均值。第三层落到行动建议平台在设计创作者激励计划时可以针对中位数以下的普通创作者设计不同层级的扶持策略而不是一刀切按均值对标。这道题看似简单但高分答案的关键就在第三层。我见过很多同学答完前两层就停了其实面试官真正想听的是你能否把统计指标转化成运营动作。这也是数据分析师和统计学家最大的区别。3.2 辛普森悖论分组对比的反直觉另一类高频概率题是辛普森悖论。小红书笔试里有个变种比较两类笔记的点击率全部数据下笔记A点击率高于笔记B但按内容分类美妆、美食、旅行分别统计时笔记B在每一类里都更高。问可能的原因是什么以及如何避免误判。答案核心是“混杂变量”笔记内容分类和点击率呈正相关而且两类笔记在不同分类下的分布很不均匀。例如笔记A大量集中在美妆类点击率整体偏高笔记B集中在旅行类点击率整体偏低汇总后就会出现整体和分组结论相反的情况。解法是先对分类变量做分层分析或者卡方检验再决定是否采用加权平均。这个知识点本身不难但能灵活答出来的人不多。我在备考时会让学员用真实的AB实验数据去算一遍手动构造一个辛普森悖论的例子做完之后印象会非常深刻。3.3 假设检验KOL笔记和小博主笔记的表现差异概率统计里还有一类题考假设检验常见问法是想验证KOL发布的笔记互动率是否显著高于普通用户应该用什么方法注意哪些坑。回答框架是原假设H0为两者互动率无差异备择假设H1为KOL互动率更高选择双样本比例z检验如果是比值类指标或t检验如果是均值类指标注意样本独立性、样本量是否足够、方差是否齐性如果样本量差异悬殊要考虑是否用bootstrap方法替代。最后补一句统计显著不等于业务显著还要看效应量大小。这类题目考察的不是计算能力而是你对“假设检验流程”的整体把握。笔试答题时按“假设—方法—前提条件—结论解释”四步写基本不会丢分。4. 业务分析题一篇笔记从曝光到转化的归因拆解业务分析题是整个笔试的核心也是小红书区别于其他公司笔试的最大特色。这类题没有标准答案但存在明显的“答题层次”差异。低分答案泛泛而谈“刷量”“改版”之类的猜测高分答案会给出结构化的拆解框架。4.1 指标体系内容社区的五层漏斗拿到任何一道业务分析题第一步是建立指标漏斗。小红书内容社区的核心路径可以拆成五层曝光量信息流推荐/搜索展示→ 点击量用户点进笔记详情→ 阅读完成量 → 互动量点赞、收藏、评论、转发→ 关注/转化行为关注博主、跳转商品页、下单笔试里如果遇到“某指标下降”的问题首先把问题锚定在漏斗的某一层再逐层排查。比如问“笔记曝光量下降了20%怎么分析”你需要先确认是整体曝光下降还是某个内容类目下降是推荐流量下降还是搜索流量下降是新用户下降还是老用户下降。把问题拆到这个粒度再谈原因和方案思路就清晰了。4.2 案例拆解曝光量下降的归因框架这类题的完整答题框架我总结成四个步骤笔试时按这个顺序写基本不会乱。第一步确认数据口径。曝光量统计的是Feed流曝光还是搜索曝光是否排除了自己看自己的笔记统计周期是自然日还是活跃日这些都会影响结论。第二步维度下钻。把曝光量按流量来源推荐、搜索、关注页、内容类目美妆、美食、旅行、学习、博主粉丝量级头部、腰部、尾部、用户新老新用户、老用户分别拆分找到下降最集中的维度。第三步原因假设。常见原因包括推荐算法策略调整、内容供给数量下降、低质内容导致用户时长下降、竞品分流、节假日因素、疫情等外部环境影响。每个假设都要对应可验证的数据指标。第四步验证与建议。用数据验证假设缩小到2到3个最关键原因再给出针对性建议。比如发现腰部创作者内容供给下降导致推荐池变小那么建议就是加大对腰部创作者的扶持并配合流量激励策略。这套框架在笔试里非常实用不仅因为它是结构化的还因为阅卷老师能顺着你的逻辑给分。4.3 AB实验题实验组和对照组怎么分才靠谱业务分析题里另一大高频考点是AB实验。常规问法有设计一个实验验证“新推荐策略是否提升了用户互动率”你会怎么做实验组和对照组怎么分组实验周期怎么定什么时候可以看结果。答题时要覆盖几个关键点样本量计算根据预期提升幅度和方差推算、随机分组用户维度而非请求维度避免同一个用户同时进入两组、实验周期至少覆盖一个完整的用户使用周期且包含周末、指标选取同时关注核心指标和护栏指标比如互动率提升但人均时长大幅下降也需要警惕、显著性检验方法。如果能提到AA实验空实验验证分组的均匀性会是不错的加分项。4.4 估算题小红书日均产生的笔记数量业务分析题还常混一道Market Sizing题比如“估算小红书一天产生多少篇笔记”。这种题没有标准答案考察的是逻辑拆解能力。我的估算思路是用DAU乘以“发布渗透率”。假设DAU在2020年大约是3000万每天会发笔记的用户占比为8%那么单日产出约240万篇笔记再考虑部分用户一天发布多篇按人均发文1.2篇算总计约288万篇。这里的关键不是数字准不准而是每个假设都有依据并且能在不同假设下快速调整结果。如果面试官追问“如果渗透率只有3%呢”你要能立刻重新计算顺带解释不同假设对应的业务含义比如渗透率低说明发布门槛高需要在创作工具或激励上做改进。5. 机器学习基础与“简历深挖题”机器学习基础在笔试里占比不大但属于“不做准备就会翻车”的模块。常见考点包括分类模型和回归模型的评估指标、过拟合与欠拟合、正则化、特征工程、常见模型的适用场景。5.1 常见模型场景题比如给出一个场景要预测用户未来7天是否会再次打开App该选什么模型合理的回答是先用逻辑回归或者XGBoost作为baseline特征包括用户历史活跃天数、互动行为、内容偏好类别、最近一次打开距今天数等评估指标用AUC因为正负样本不平衡准确率意义不大如果追求可解释性就选逻辑回归如果追求效果就上GBDT类模型。再比如问“如何评估一个推荐算法的效果”答题要点是离线指标用AUC、GAUC、召回率、精确率在线指标用点击率、人均停留时长、人均互动数、留存率离线指标和在线指标有时候会背离最终以在线实验为准。回答时如果能提到“ 长短期指标兼顾”比如同时观察次日留存和7日留存加分效果明显。5.2 简历深挖题的应对思路笔试结束后的面试环节面试官会围绕简历里的项目经历深挖。常见追问方式包括这个项目的数据量有多大特征怎么处理的模型怎么选型为什么不用其他模型效果怎么评估如果给你更多时间你会怎么改进。这里我发现一个普遍问题很多候选人简历上写了“用XGBoost搭建用户流失预警模型”但被问到缺失值处理策略、类别特征编码方式时却支支吾吾。原因在于项目是自己“跑通”的但每一步的“为什么”没有想清楚。备考阶段的建议是把自己简历里每个项目都写成“业务背景—数据描述—分析思路—模型方案—效果评估—优化方向”六段式每个细节都能展开讲三分钟这样面试基本不会冷场。6. 备考建议从笔试到offer的实操路线最后说点实际的备考路线这些是我带人备考几年下来验证过的方法不一定适合所有人但方向可以参考。时间规划方面提前8到10周开始系统性准备。前两周过SQL基础重点练窗口函数和复杂JOIN题目来源可以在牛客网和LeetCode数据库题库里找每天保持3到5道题的手感。第三、四周集中看概率统计对应《概率论与数理统计》教材的前五章配合面试题练习。第五、六周重点是业务分析题把自己想象成小红书的数据分析师找公司财报、公开分享和行业分析报告来练习拆解能力。最后两周做模拟笔试严格计时训练做题速度。工具方面SQL建议直接在本地装一个MySQL或者用SQLite练手不依赖在线平台的自动判题Python方面至少要会pandas的筛选、分组、合并、透视表操作因为笔试里如果考到Python处理csv日志文件的题目这些就是基本功。Excel也不要扔有些线下笔试环节会给一个Excel文件让你现场做透视表和图表这个场景在真实工作中太常见了。踩坑教训方面最典型的是做题顺序。笔试时间有限别在SQL题上追求写出“最优雅”的方案先保证AC概率统计题如果第一遍没思路先跳过把后面业务题的框架分拿到业务题千万不要留白即使不会写完整方案也要把分析维度列出来。其次笔试环境通常没有自动补全函数名拼写错误会导致前功尽弃练习时就尽量手写SQL不要依赖IDE提示。回想我带过的那些成功拿到小红书数据分析offer的学员他们有一个共同特点不把笔试当成“考试的终点”而是当成“业务思考的预演”。同一道题别人只求答完他们会追问一层“如果数据表现和预期相反怎么办”“如果样本量不够怎么办”。这种追问的习惯才是数据分析师在真实工作中最值钱的能力。
返回列表