企业官网建设流程全解析

2023年的秋招，被很多人形容为“史上最卷”，这话一点都不夸张。作为亲历者，我在九月中下旬收到了小红书的第二批数据岗笔试邀约，投的是数据方向的岗位。在内容社区里，小红书的数据岗笔试一直很有自己的风格——题量不算特别大，但每道题都贴着业务场景出，尤其爱在SQL和统计推断上做文章，整体考察逻辑非常“商业化”。这篇文章不是官方真题的整理，而是基于我实际参加后的复盘和备考经验，把整场笔试的考察逻辑、题型分布、每类题目的应对思路都拆开聊一聊，希望能给后续准备数据岗笔试的同学一点参考。

1. 这场笔试在考什么：2023秋招小红书数据岗的整体画像

1.1 考试形式与时间分配

我当时是在牛客网平台完成的笔试，全程在线答题，摄像头监控，网页端有代码编辑器。第二批笔试安排在九月中下旬，时间跨度大约是一个周末内的多个场次，你可以根据自己的时间预约场次。整体时长我记得是120分钟，题量大概在20道左右，但涵盖的类型非常多：

• 选择题（单选+多选）：15道左右，覆盖统计学、概率论、机器学习基础、业务常识。
• SQL大题：2道，需要在编辑器里写完整SQL。
• Python或算法题：1道，考察数据处理能力或基础算法思维。
• 业务分析题：1-2道，以简答或论述的形式出现，要求写出完整的分析思路。

从分值分布来看，选择题单题分不高，但胜在数量多；SQL大题的占比最高，基本是半壁江山；业务分析题最考验综合能力，也是批卷时最拉开差距的部分。

提示：小红书数据岗的笔试分批之间，题目会有一定重叠，也会引入新题。不要指望背上一批的原题，重点是掌握每类题型的解法。

1.2 从岗位JD反推考察重心

在投递岗位时，我看到JD里反复出现几个关键词：“对社区内容生态有理解”“有数据敏感度”“熟悉AB实验”“熟练使用SQL和Python”。这几个词基本定调了笔试的方向。

数据岗在内容社区公司里，并不只是做报表，更多时候要回答“内容怎么分发”“用户为什么留存”“商业化如何增收”这一类业务问题。所以笔试题目不会考纯粹的计算机算法题，而是会把所有技术考察都包裹在业务场景里。比如同样是考窗口函数，标题可能会写成“分析某天发布笔记的用户次日留存情况”。

基于这一点，我的备考重点就调整为：SQL熟能生巧、统计概念查漏补缺、业务分析形成自己的框架。整个过程不是背题，而是围绕岗位需求做能力补齐。

2. SQL占半壁江山：窗口函数、留存与漏斗的实际操作

2.1 高频考点定位

小红书数据岗笔试的SQL题，不太会考“alter table”这种偏运维的语法，也不会考复杂的存储过程。它的重点非常突出：

• 多表关联（JOIN）：考察怎么把两到三张业务表关联起来。
• 聚合函数（GROUP BY）：结合业务维度做统计。
• 窗口函数：重点中的重点，rank、row_number、lag/lead出现的频率非常高。
• 留存率计算：典型的用户运营场景。
• 漏斗转化：从曝光到点击再到互动的路径分析。

备考时我统计了自己刷过的十套左右互联网公司数据岗笔试题，SQL部分出现“窗口函数”的概率几乎是百分之百。如果你还只会用简单的SELECT和WHERE，那基本很难应付这类题目。

2.2 留存率计算的完整解法

留存在内容社区的产品里是一个核心指标。笔试里常见的出题方式是这样的：

假设有一张浏览记录表，字段包括user_id、view_time、笔记id，需要计算某一天的新用户次日留存率。

这类题的难点在于“新用户定义”和“次日怎么算”。我先说标准解法：

-- 先找出某天的活跃用户 with active_data as ( select user_id, date(view_time) as active_date from view_log group by user_id, date(view_time) ), -- 找出每个用户首次活跃日期 first_data as ( select user_id, min(active_date) as first_date from active_data group by user_id ), -- 关联次日是否活跃 retention_data as ( select f.user_id, f.first_date, case when a2.active_date = date_add(f.first_date, interval 1 day) then 1 else 0 end as is_retained from first_data f left join active_data a2 on f.user_id = a2.user_id and a2.active_date = date_add(f.first_date, interval 1 day) ) -- 计算次日留存率 select first_date, count(distinct user_id) as new_users, sum(is_retained) as retained_users, round(sum(is_retained) / count(distinct user_id), 4) as retention_rate from retention_data group by first_date order by first_date;

这个解法里最容易出错的地方有三个：

1. 新用户的定义要用“首次活跃”，而不是“注册日期”，因为业务系统里注册时间和实际开始使用产品的时间往往不一致。
2. 次日活跃的判断必须用日期函数处理，比如date_add或datediff，不能直接用字符串比较。
3. 要用左关联（left join），否则没有次日行为的用户会被过滤掉，留存率会被虚高。

注意：笔试里时间字段通常很脏，可能包含时分秒。建议第一步就先date()把时间截断到天，再参与计算，否则后续的关联会出现大量空值。

2.3 窗口函数在排名类题目中的应用

第二类常见题是排名题，比如“找出每个类目下笔记互动量排名前三的内容”。这里核心就是要用row_number或dense_rank。

select category_id, note_id, interact_cnt, rk from ( select category_id, note_id, interact_cnt, row_number() over(partition by category_id order by interact_cnt desc) as rk from note_interact ) t where rk <= 3;

如果对窗口函数的执行逻辑不够熟悉，很容易纠结“为什么不能在where里直接写row_number”。窗口函数是在WHERE之后执行的，所以必须用子查询包一层。这个知识点几乎是笔试必考。

延伸来看，rank和row_number的区别也要心里有数。考试中遇到“并列排名”的要求时，用dense_rank还是rank，要看题目的具体描述，千万别默认用同一种函数。

3. 统计与概率：选择题里的隐形杀手

3.1 假设检验与AB实验的底层逻辑

统计题在选择题里占的比例很高，尤其是AB实验相关的内容。小红书这种依赖社区推荐机制的产品，任何策略上线前都要做实验验证，数据岗必须理解显著性检验。

常考的点包括：

• p值的含义（p值不是“原假设为真的概率”，而是“在原假设为真时，得到当前或更极端结果的概率”）
• 置信区间的计算
• 第一类错误和第二类错误
• 样本量的确定与统计功效

我印象比较深的一道题是关于“实验组显著优于对照组但涨幅很小，是否需要上线”，其实是在考察业务思维和统计思维结合的能力。如果你只懂统计学，会选择按结果上线；但如果懂业务，就会考虑到成本、长期影响和实验周期。答案往往需要做综合判断。

3.2 常见的场景化概率题

除了统计推断，概率题也会换着花样出现。我备考时整理了几类高频题型：

• 条件概率和贝叶斯公式：给出某个行为的概率，求这个行为发生后的后验概率。
• 期望值计算：比如计算一个运营活动的预期收益。
• 随机变量分布：二项分布、泊松分布在不同场景下的应用。

举个例子，考场上有一类常见题：某个功能改版后，用户点击率从5%提升到6%，假设每天有10万用户看到该功能，问这个提升在一天内带来的额外点击量期望是多少。这类题不算难，但考场上很容易因为单位换算或百分比理解出错。

我的建议是备考时把《概率论与数理统计》的核心公式重刷一遍，特别注意贝叶斯公式和正态分布标准化，这两块在选择题里经常换着考。

4. 业务分析题：从面试官视角拆解答题框架

4.1 指标异常分析类题目

业务分析题是小红书笔试里的压轴项，考察的是“拿到一个业务问题，你会怎么拆解”。这类题没有标准答案，但评卷人心里有一套好的答题逻辑。

我遇到的题型之一是“某天社区互动量明显下滑，请分析可能的原因”。答题时切忌只列一个原因，而是要按维度拆解：

• 数据真实性排查：先确认数据口径有没有变，埋点有没有漏，统计任务是不是延迟了。这是分析的第一步，也是很多人容易忽略的一步。
• 外部因素：是否有节假日、大促、竞品异动等外部环境变化。
• 内部因素：推荐策略是否调整、内容供给是否减少、产品功能是否出bug。
• 用户分层：把异常按新用户/老用户、不同活跃度用户拆分，定位是哪部分人群出了问题。

我在答题时选择了“先外后内、先整体后分层”的结构，每一层都给出对应的验证方法和数据指标，而不是空谈。

4.2 指标体系设计类题目

另一种常见题型是“帮某功能设计一套指标体系”。比如给一个“笔记搜索功能”，让你设计指标体系。

我当时采用的框架分三层：

• 规模层：搜索UV、搜索PV、人均搜索次数。
• 效率层：搜索结果点击率、搜索后停留时长、搜索结果页到笔记详情页的转化率。
• 质量层：搜索后的互动率（点赞、收藏）、搜索无结果率、用户搜索满意度。

设计指标时，面试官看重的不只是“指标列得全”，而是你有没有优先级意识。我特意在最后标注了“北极星指标”和“护栏指标”，并且说明了为什么这两个维度不能只看单一指标。这种表达方式会让答题更有条理，也贴近实际工作的思考方式。

4.3 AB实验评估类题目

很多数据岗笔试都会考AB实验评估，小红书也不例外。常见的形式是：“某功能改版后做了AB实验，实验组显著优于对照组，请你说明评估过程和需要注意的问题。”

答题框架可以这样组织：

1. 确认实验设计是否合理：分流是否均匀、样本量是否足够、实验时间是否覆盖一周完整周期。
2. 确认指标选择是否科学：主指标、次要指标、护栏指标分别是什么。
3. 看显著性：采用什么样的显著性水平、是否做了多重比较校正。
4. 做分层分析：看不同用户群体里的实验效果是否一致。
5. 判断是否上线：结合提升幅度、实现成本和长期影响做综合决策。

整个答题过程最好用“先说结论再展开理由”的结构，因为阅卷人不太可能逐字细读，重点看你的逻辑脉络是否清晰。

5. Python与算法：内容社区里的数据处理题

5.1 pandas场景题是主要考察方向

笔试里的Python题相对基础，但也不会脱离数据岗的日常工作。我遇到的是关于数据清洗和统计的题目，给定一个DataFrame，需要完成若干操作：去重、缺失值填充、分组统计、排序取TopN。

这种题用pandas写起来很快，比如按分组排序取TopN：

import pandas as pd # 示例df包含字段：user_id, city, spend_amount df = pd.read_csv('user_spend.csv') # 去重 df = df.drop_duplicates(subset=['user_id'], keep='last') # 缺失值处理 df['spend_amount'] = df['spend_amount'].fillna(0) # 按城市分组，计算每个城市用户的平均消费 city_mean = df.groupby('city')['spend_amount'].mean().reset_index() # 按城市分组，取每个城市消费金额最高的3个用户 top_users = ( df.sort_values('spend_amount', ascending=False) .groupby('city') .head(3) )

这类题目的关键不是算法多复杂，而是pandas的API是否熟练。考场上时间有限，如果你还要反复翻文档，基本就来不及。

5.2 算法题：难度不高但考察边界条件

除了pandas题，还会出现一道中等偏简单的算法题。我当时遇到的是“给定一个list，找出其中出现次数最多的元素，如果有多个则返回最小的那个”，这类题用字典加排序就能解决。

from collections import Counter def most_frequent(nums): counter = Counter(nums) max_count = max(counter.values()) candidates = [num for num, count in counter.items() if count == max_count] return min(candidates)

这种题想拿满分，关键在于处理边界条件：空列表、只有一个元素、所有元素都不同、多个元素频率相同。笔试的判题系统会包含这些边界用例，如果你没考虑周全，很容易被扣分。

准备Python部分时，我建议把常见的输入输出写法、切片技巧、字典和集合的常用操作都练熟，不需要刷硬核算法题，但一定要能又快又稳地写出正确代码。

6. 备考时间线与答題策略的复盘

6.1 考前一周的安排

收到笔试通知后，我只剩一周时间准备，这里分享一下我的安排。

• 前三天：集中刷SQL窗口函数、留存计算、漏斗转化这类高频SQL题，每天至少写5道完整SQL并跑通。
• 第四天到第五天：回顾统计学核心概念，尤其是AB实验评估、假设检验、置信区间，凡是概念模糊的都用纸笔写一遍。
• 第六天：整理业务分析题的答题框架，按“指标异常分析”“指标体系设计”“实验评估”三类各准备一个通用模板。
• 最后一天：调整状态，把重点放在看错题总结上，不再做新题。

这个时间表可能不适合所有人，但对数据岗笔试来说，性价比最高的准备顺序是：SQL优先，统计次之，业务框架最后。因为SQL是硬通货，熟练度决定你能不能做完；统计决定选择题的正确率；业务分析决定你能否进入下一轮。

6.2 考场上的答题顺序和心态

我个人的经验是，上来先快速浏览全部题目，标记出SQL大题和业务题的难易程度，然后按“先会做的选择题、再SQL、再Python、最后业务题”的顺序推进。原因很简单：选择题是基础分，先拿稳；SQL和Python是硬分数，务必留足时间；业务题主观性强，放在最后不容易影响心态。

如果在SQL题上卡住超过15分钟，我会果断跳过，先做后面的题，避免因小失大。实际考场上，确实有一道SQL我第一遍读题没什么思路，后来做完Python再回头看时，反而在重新读题的过程中找到了突破口。

提示：笔试过程中不要在大量思考时发呆看屏幕，编辑器有自动保存功能，记得边写边梳理思路，哪怕代码不完整，也要把注释和逻辑写清楚。部分阅卷会关注你的解题意图。

6.3 从笔试到面试的准备衔接

笔试结束后，不要等着出结果再做准备。我在笔试完的当天就开始准备面试可能问到的问题：为什么报考小红书的数据岗、怎么理解内容社区的产品逻辑、手头有什么数据分析的项目经历。因为数据岗的面试通常会在笔试通过后一周内安排，提前准备能让你在时间窗口里从容很多。

另外一个容易被忽略的点是，笔试里的SQL题目和业务分析题很可能成为面试官追问的材料。我面试时就被问到“你笔试里留存率计算是用的什么口径？如果活跃用户定义变了，结果会怎么变化？”这说明笔试不只是筛选工具，也是后续面试的参考素材。平时做题时多思考一步“为什么这么设计”，对后续环节帮助很大。

回看整场笔试，让我最有感触的一点是：小红书数据岗考察的内容并不偏难怪，而是把数据工程师和数据分析师日常工作中最常打交道的东西全都拿了出来。如果你在SQL上能做到熟练，在统计上概念清晰，在业务分析上有自己的框架，通过笔试的概率就会大很多。对大多数人来说，不是不够聪明，而是练得太少，思考得不够深。希望这篇复盘能给你一个明确的准备方向。