企业官网建设流程全解析

1. 2023秋招小红书数据岗第三批笔试：整体情况与题型概览

先交代一下背景。我是2023年秋招投的小红书数据岗，第三批笔试，岗位方向偏数据分析，base北京。当时投完简历大概过了一周收到笔试通知，邮件里没有给太多信息，就说“在线笔试，请预留2小时”，进了系统才知道是分模块限时作答。

那批笔试一共四个部分：第一部分是行测类的逻辑推理和数字推理，大概15道题；第二部分是SQL和Python编程题；第三部分是概率统计和业务案例分析；第四部分是主观题，给一个业务场景让你写分析思路。难度整体中等偏上，比字节的笔试题量少，比美团的题目更偏业务，和快手的笔试风格有点像。

有一点值得先说清楚：小红书的笔试不是所有批次都一样的题。第一批和第二批我听说过一些反馈，第二批的SQL题偏难，重点是窗口函数和复杂join，第三批反而更重业务思维。这也在意料之中，数据岗笔试向来是这样——考察的是候选人能不能用数据和业务对话，而不只是写代码。所以我建议后面要投小红书数据岗的同学，别只闷头刷LeetCode和SQL题，业务题的分析框架才是拉开差距的地方。

2. 六道核心真题复盘：SQL、Python与概率统计

2.1 SQL题：围绕内容社区的互动数据出题，窗口函数跑了三连问

第三批笔试的SQL题我记得很清楚，是围绕小红书的“笔记-用户-互动”数据模型出的。题目大概是这样的：有三张表，一张是笔记维度表（笔记id、作者id、发布时间、类目），一张是互动行为表（用户id、笔记id、行为类型、时间戳），一张是用户维度表（用户id、注册时间、手机品牌）。三道小题分别是：

• 第一问：统计每个类目下近30天有互动行为的笔记数，以及这些笔记的人均互动次数。
• 第二问：找出每个类目下互动次数排名前10的笔记，并输出对应的作者id。
• 第三问：统计发布后24小时内互动次数超过100的笔记中，作者的手机品牌分布。

这三问其实是层层递进的。第一问是基础聚合，用count(distinct)和sum配合case when就能解；第二问是典型的窗口函数row_number()或者rank()，按类目分区、按互动次数排序；第三问要先把时间差算出来，再关联用户表取手机品牌。

我当时的解法是：第一问用left join把笔记表和互动表关联起来，注意要限定互动时间在发布后30天内，避免把发布前的记录也算进去。这里其实有个坑，互动行为发生在笔记发布前是不可能的，但数据清洗不到位时会有脏数据，所以建议加一个where条件把时间差为负的记录过滤掉。第二问的SQL写起来也很常规，但要注意“互动次数前10”在并列情况下怎么处理——如果用row_number()，并列时会随机截断；如果用rank()，可能出现超过10条的情况。我选了rank()，然后在评论区标注了并列处理的逻辑，后来复盘觉得这个细节应该是加分项。

第三问是我做得最纠结的一道。它要求“发布后24小时内互动次数超过100”，我当时写的是：先按笔记id做聚合，只保留count(行为) >= 100的笔记，再left join用户表取手机品牌。但是我当时犹豫的是：要不要限定行为时间戳在发布后24小时内？需求描述里写的是“发布后24小时内互动次数超过100”，那当然应该限定。所以我又加了一个case when表达式，让时间差小于86400秒才计入互动次数，否则记为0。这题的考察点其实是审题，而不是SQL本身的难度。

提示：小红书的笔试SQL题都在他们自己的在线编辑器里跑，不提供真实数据，只校验结果集。所以练习的时候不要再依赖本地数据库环境，多用Hive或Spark SQL的语法练习，因为他们的编辑器对标准SQL的支持比较有限，特别是limit语法的位置和substring函数的下标，和MySQL有差异。

2.2 Python编程题：数据清洗和外呼触达模拟，幂等设计是隐藏考点

Python题有两道。第一道是给了用户行为日志，要求写一个函数，输入是原始日志列表，输出是清洗后的结构化数据。具体清洗规则包括：去掉时间戳为空的记录、去重（同一用户在同一秒内的重复行为只保留一条）、并把行为类型里的英文标签映射成中文。这道题本身不难，就是常规的pandas处理，但题目要求用纯Python实现，不能用pandas，几个候选人出来之后对这题的反馈都差不多——不让你用pandas这件事本身，才是真正的考点。

我当时的思路是先用defaultdict按用户id把日志分组，再对每个分组内部做时间排序和去重。去重逻辑用了一个set来存“用户id+时间戳+行为类型”的复合key，这个方案在哈希冲突率上表现还可以，但有个问题是内存占用偏高。后来想了一下，其实数据量是可控的，这种简单方案完全够用。需要注意的一点是，题目里的时间戳是带时区的ISO格式字符串，直接用字典去重时如果时区不统一会有问题，所以我在解析时统一转成了UTC时间再格式化。

第二道Python题更有意思，模拟的是外呼触达。场景是：平台需要对一些低活跃用户做push触达，触达策略是按用户活跃度分为A、B、C三档，不同档位有不同的触达次数上限和间隔要求。要求写一个调度函数，输入是所有需要触达的用户列表和他们的活跃度档位，输出是一份可执行的触达计划表，约束是同一用户两次触达之间的间隔必须超过规定值。

这道题的本质是一个资源调度约束问题。我一开始用贪心算法写：按用户分组，然后每个用户的触达时间点按档位间隔均匀排开。写成代码之后发现边界条件很多，比如用户可触达的时间窗口是早上8点到晚上10点，跨天之后间隔怎么算，C档用户隔了3天之后如果落在周末要不要跳过。我当时的方案是引入了一个next_available_time字典，每次排完一次触达就更新用户的下次可触达时间，按时间线循环扫描。这样做能通过基本用例，但时间复杂度偏高，如果用户量再翻十倍可能会卡。

后来复盘的时候，我想到了幂等设计这个隐藏考点。题目虽然只要求输出触达计划，但如果触达链路里出现了重复调用，你把同一用户在同一个时间点排了两次，生产上就是一次资损事故。所以我在答案结尾加了一个去重断言，保证输出计划表里不存在同一个用户同一个时间戳的两条记录。这是真实业务里必须考虑的问题，笔试考这个，比单纯考算法要贴近实战得多。

2.3 概率统计题：三门问题变体和置信区间计算，笔算是最大障碍

概率统计部分一共三题，我印象比较深的是两道。第一道是经典的三门问题变体：有三个盒子，一个盒子里面有两个红球，一个盒子里面有两个蓝球，一个盒子里面是一红一蓝。随机摸出一个盒子再从中摸出一个球，发现是红球，问这个盒子是“两个红球”的概率。

这题不是标准三门问题，而是贝叶斯推断。标准的解法是设事件A为选中双红盒，事件B为摸出红球。P(A) = 1/3，P(B) = (2/3) * 1 + (1/3) * 1/2 = 5/6。其实仔细算一下是对的——双红盒摸出红球概率为1，双蓝盒为0，一红一蓝盒为1/2。然后P(A|B) = P(A) * 1 / P(B) = (1/3) / (5/6) = 2/5。

按这个思路，把实际数字代进去，P(A|B) = (1/3) * 1 / 5/6 = 2/5，所以答案是0.4。这个结果如果只背公式不看条件，很容易算成1/2，我估计很多候选人就栽在这里。当时我在草稿纸上验算了一遍这个条件概率才填的答案，后来跟一起笔试的同学对答案，有人就直接写了0.5，这就是典型的没有理解“摸出红球”这个证据对先验概率的修正作用。

第二道题是给了一组用户次日留存率数据，共30天，均值为40%，样本标准差是5%，要求计算总体均值的95%置信区间。这个直接用t分布或者正态近似算就行，n=30可以用t分布的临界值2.045，也可以用z分布的1.96近似，题目没有给t分布表，直接用1.96也不会被算错。算出来区间大概是[38.21%, 41.79%]。我在这道题上花的时间比预期多，因为要在网页表单里手算，没有一个像样的计算器，一个小数点错了就全错。我的经验是这种题先把标准误算出来（样本标准差除以根号n），再乘临界值，最后再跟均值做加减，分步写在草稿纸上可以明显减少计算失误。

3. 业务案例分析题：答题框架、我的答卷与复盘反思

3.1 “笔记搜索无结果”问题：怎么拆解归因，怎么设计漏斗

这部分有一道题是：小红书App内搜索一个关键词，发现搜索无结果的比例连续三天上升，从3%涨到5%，如果你是负责搜索业务的数据分析师，你会怎么分析这个问题，要求给出分析框架和落地步骤。

这道题没有标准答案，但踩分点非常明确。我当时是有意识地把归因分成两个方向去写的：一个方向是供给问题，另外一个方向是匹配问题。这两个方向的差别是：供给问题是指搜索词对应的笔记确实不存在，或者数量太少无法展示；匹配问题是指站内明明有相关内容，但因为召回或者排序的链路出了问题，导致结果集为空或者被过滤掉。

在供给方向上，我写了三个子假设：第一是搜索词本身是长尾词，笔记库中匹配文本内容的笔记确实很少；第二是搜索词背后对应的品类近期有供给流失，比如某个头部创作者停更，导致该关键词下的笔记密度显著下降；第三是搜索词的热度骤增，比如某条热点新闻带火了一个生僻词，用户集中搜索但站内供给没跟上。

在匹配方向上，我的子假设包括：搜索引擎的Recall阶段如果最近上线了新模型或者改了词权重，可能导致部分词匹配不上索引；平台策略上如果近期调整了审核过滤规则，一些带有特定词汇的笔记被过滤进入不了搜索结果，也会表现为无结果率上升；还有一个容易被忽略的点是query分词的问题，同一个词在不同版本上的分词策略如果发生变化，结果集会完全不同。

然后我补了一个验证顺序的思路：先看变化是平台整体性的还是场景局部性的。如果整体上升，优先查引擎配置和策略变更；如果只是部分渠道或者部分版本上升，优先查版本差异和用户画像差异。同时在验证时区分新老用户，因为老用户的历史搜索行为会给个性化排序提供更多信息，新用户搜索无结果中的“无”很可能是真的供给不足。

3.2 我当时的分析框架拆解：拆到策略层，再往技术层收

下面把我当时写到答卷上的内容整理一下，给出一个可以直接套用的分析框架。这个框架不仅适用于搜索无结果，任何指标异动分析都可以用类似的思路。

第一，定义问题口径。无结果率的分母到底是总搜索次数，还是去重后的搜索词数，还是只统计有结果的搜索词？这三种口径下数据可能差两三倍。如果这个指标是最近才接的新口径，可能根本不是业务变动，而是数据口径变了。我在笔试里写了“先检查指标口径是否一致”，这既是表态度也是给后续的所有分析步骤做铺垫。

第二，趋势分层拆解。把无结果率分成新词首次搜索无结果和存量词搜索无结果。存量词无结果是更严重的问题，因为它代表原本能搜到的东西现在搜不到了。如果只有新词无结果率上升，大概率是热点事件带来的新词供给缺失，处理优先级较低；如果存量词也在上升，就要马上排查引擎链路。

第三，归因交叉验证。用维度拆解和假设验证结合，维度包括：版本（客户端版本、搜索引擎版本）、渠道（首页搜索、顶部搜索、搜索联想词跳转）、类目（视频类、图文类）、用户层级（新老用户、活跃度）。每个维度上对应上面的子假设做验证，比如“策略变更”假设可以通过对比上线前后的数据变化来验证。

第四，和产品、算法、运营的对齐动作。数据侧先产出归因结论，再把建议同步给搜索策略团队做case抽取，给内容运营团队看是否需要补充供给。我在复盘后发现，这类题目考官真正想看的不是你能排查得多深，而是你有没有从数据结论走到业务动作的意识。很多候选人写了十几条分析维度，但就是没有“找谁去落地”的部分，分数就上不去。

3.3 主观题里隐藏的商业sense考察：不是数据分析题，是产品运营题

笔试最后还有一道大主观题，题目大概意思是：小红书最近发现收藏量很高但点赞量偏低的笔记类型，让你分析背后的用户动机，并提出运营策略。

这道题猛一看像内容分析题，其实是一道产品运营题。我当时写了三层理解。第一层是数据表现上的原因：收藏是一个“高成本、高意图”的行为，用户收藏笔记往往是为了之后回看，比如攻略类、教程类、清单类的内容天然具备高收藏低点赞的属性，这是内容品类属性导致的。第二层是用户状态的差异：点赞是即时的情绪反馈，收藏是延迟的需求沉淀。如果一类笔记的收藏远高于点赞，说明用户需要它但不是现在马上需要，它可能非常实用但不那么“上头”。第三层是可以引导的产品策略：在收藏后的回访路径里加一个轻量互动引导，比如“这篇笔记帮到你了吗”，或者分享一个整理好的收藏夹给关注者，让收藏行为之后能够自然转化为点赞和关注。

这道题我在复盘时意识到自己答得中规中矩，虽然思路完整，但缺少一个亮点——运营策略里没有提到创作者侧的正反馈闭环。正确的做法应该强调收藏率高的笔记创作者得到的反馈是“延时的、不明显的”，所以他们可能并不知道自己发的内容到底有没有用，应该把收藏回访率、收藏转赞率这类数据指标也返还给创作者，让创作者感知到内容价值。这个角度如果能在笔试里写出来，会明显区别于其他人。

4. 从笔试看秋招数据岗的准备逻辑：踩坑与建议

4.1 时间分配失误：我在概率统计题上超时，导致主观题仓促

我这次笔试最大的失误是时间分配。全程120分钟，我大概用了35分钟做行测，45分钟做SQL和Python，这个节奏本来是适应的。但概率统计的那三道题我花了差不多25分钟，尤其是那个贝叶斯和置信区间，笔算的时候特别容易卡顿，写写划划就过了二十多分钟。等到最后看到那道大主观题时，只剩不到15分钟，我几乎是用了最快的速度在打字，但答完回头看，论述的深度和层次感明显不如前面做得从容的那些题。

现在复盘，正确的时间分配应该这样：行测控制在25分钟内，不会的题直接蒙一个别再回头；SQL和Python控制在40分钟内，因为这部分只要会写基本就能过，耗时间的点主要在于调试；概率统计控制在20分钟内，实在算不出来的先跳过，别恋战；主观题至少留30分钟，因为这部分分值是最重的，而且阅卷的差别感往往体现在这里。笔试的时候时间进度条是在页面上方的，我建议每做完一个模块就低头看一眼时间，比在心里估算要准得多。

4.2 常见备考误区和取舍建议：SQL刷题之外，业务sense才是分水岭

我见过很多人准备数据岗笔试，就只刷SQL题和Python题，算法题刷得不亦乐乎，结果一到业务案例题就懵住。小红书的数据岗笔试其实传递了一个很明确的信号：SQL和Python只是基本功，这些题大家都能拿分，真正区分度高的题目永远是业务分析题和主观题。2023年秋招小红书数据岗笔试整体比前一年更偏业务，我认为这个趋势在未来一两年内不会改变。

我建议备考时分三个阶段来准备。第一阶段是扎实SQL基本功，特别是窗口函数、多表关联、去重逻辑和子查询，不用追求太难的优化，但凡是笔试出现的SQL题都能第一眼看出思路。第二阶段是搞懂概率统计的基础概念，贝叶斯公式、置信区间、假设检验、常见分布，这些都能用自己的话解释清楚，并且能做手算练习。第三阶段是业务案例积累，去把真实产品里可能出现的指标异动、实验评估、画像分析、策略归因这四类场景各准备一套分析框架，每种场景自己动手在纸上写一遍答题结构，然后找一个朋友互相批改，或者拿小红书的真题来演练。

我个人不太推荐为了笔试去背大而全的面经，那些整理出来的两百道题里至少有一半是不常考的。更有效的做法是准备一个自己的“分析模板库”，每个模板包含“问题拆解方法”“分析维度枚举”“验证步骤”“落地动作建议”这四个板块，遇到任何业务题都往这个框架里套，再根据具体场景做调整。这个方法我在后续其他公司的面试里也用了，效果比临时起意的答题方式好很多。

4.3 关于小红书数据岗投递，我自己踩过的一些真实细节

有几个笔试之外的细节，也值得拿出来说一下。第一是笔试链接的邮箱一定要检查垃圾箱，我当时就是在垃圾箱里翻到的笔试通知，差点错过48小时内的考试窗口。第二是笔试过程是全程录屏监控的，浏览器不能切换页面，最好提前把本地代码编辑器关掉，只留一个浏览器窗口。第三是小红书笔试题目可以往回翻，但每个模块的倒计时在进入时就开始走了，我当时不知道这一点，在模块一的行测上浪费了不少时间，导致后续模块的节奏全乱。

还有一个细节是关于简历的。因为小红书数据岗的简历筛选比很多公司要严格，我当时是等了一个多星期才收到笔试邮件，一度以为简历挂了。如果你的简历里有一段和内容社区相关的项目经验，被捞起来的概率会大很多。我在项目一栏写了一个关于内容消费行为分析的小项目，用的是爬虫获取的公开数据，但这里我不建议任何人去绕过平台限制采集数据，更好的方式是用平台提供的开放数据接口，或者用公开数据集做分析。GitHub上确实有很多数据岗笔试的复盘仓库，去翻一翻小红书的真题回忆贴，再对照自己的薄弱点做针对性训练，比闷头刷题效率高很多。

4.4 这类笔试背后的考察逻辑：数据岗不只找“写SQL的人”

最后再聊一个复盘时才想通的点。小红书数据岗笔试考了那么多代码和统计，但打分权重最高的其实是那两道主观题和业务案例题，原因在于数据岗在业务团队里的角色是“用数据推动决策”，而不只是“把数据取出来给产品看”。秋招进来的应届生，SQL写得再快，业务sense不够，在团队里其实是跑不动的。

所以如果你问我，第三批笔试到底难不难，我的回答是：SQL和Python的部分，任何一个认真刷过题的人都能过；概率统计的部分，学过概率论但基础不牢的人会丢分；真正把分数拉开的是业务案例和主观题，这个没办法靠刷题速成，需要在平时就有意识地训练自己看数据的角度——看到一个指标波动，先问自己三个问题：这个数字是怎么算出来的？这个数字变了说明什么？这个数字变了之后应该谁来做什么。能把这三个问题想明白，笔试的主观题基本就能稳稳过线了。

我当时在主观题部分写了收藏和点赞的分析思路，但写得并不算好。如果让我重来一次，我会把回答的结构改成：先判断数据可信度，再拆解内容品类特征和用户动机，最后落到创作者激励策略和产品功能优化上，每一步都用一小段话说清楚背后逻辑。这种结构化的答题方式，远比堆砌各种分析维度更能让阅卷人看出你的思路。