1. 2023秋招小红书数据岗第二批笔试先弄清楚它到底考什么2023年秋招的小红书数据岗第二批笔试是很多应届生和初级数据从业者绕不开的一道坎。相比第一批笔试第二批的题量更大、题型更杂而且部分题目会故意设置一些“看起来能做、上手就错”的坑。当时我在准备这批笔试时最强烈的感受是它不像传统互联网大厂那种“两道算法题定生死”的风格而是把数据处理全流程拆成选择题、SQL题、Python题、业务分析题放在同一套卷子里时间还压得比较紧。正因如此很多人不是败在知识储备上而是败在时间分配和答题节奏上。这篇复盘想解决的核心问题是第二批发数据岗笔试到底在考什么以及应该按什么优先级复习。不管你是刚投完简历准备笔试的应届生还是想跳槽到社区类产品做数据分析的初级打工人这篇文章都会尽量按照我当时“踩过坑之后整理出来的复习框架”来讲尽量少说废话多给能直接落地的思路。先说结论这类笔试复习真正的权重排序应该是——SQL 数据结构与算法 Python数据处理基础 业务分析思维 数据治理等概念题。不是说你每个岗位都要按这个顺序而是从“投入产出比”来看SQL是单位时间内提分最快的算法题决定了你能不能过系统筛选Python题则直接影响你在面试官印象里的专业度。接下来的章节就把这些模块逐一拆开结合具体的场景和题型来说。2. 核心考点拆解从数据结构到业务题的复习优先级2.1 数据结构与算法题该刷到什么程度数据岗的算法题没有纯后端岗那么硬核但也不能完全不准备。我观察到的普遍情况是小红书这类偏业务和内容生态的公司笔试里的算法题会刻意“场景化”。比如给你一段用户日志让你统计连续登录天数给你一批订单记录让你找出金额最大的Top N用户。这些题本质上还是在考察数组、哈希表、排序、双指针、动态规划等基础能力但包装了一层业务外衣。我当时给自己定的目标是 LeetCode 前 200 题里简单题稳定过关中等题能写出暴力解并尽可能优化。尤其是哈希表这种数据结构在数据岗笔试里出现频率极高因为很多题最后都会落到“去重”或“计数”上哈希表是最直接的工具。图的遍历虽然出现频率不高但一旦出现就会很致命。像“判断两个用户是否是好友关系链上的闭环”这类题如果没复习过 BFS/DFS现场很容易卡住。为什么不建议花大量时间刷 hard 题因为数据岗笔试时间有限算法题往往只占 30% 左右的分数你把 90 分钟全耗在一道 hard 题上后面的 SQL 题可能连题面都没看。我当时就犯过这个错误在第一道算法题上硬刚了 40 分钟结果后面有两个 SQL 表结构题没写完直接拉低了整体得分。复盘之后我才意识到算法题的目的是“筛掉完全不会写代码的人”而不是“筛出竞赛选手”。2.2 SQL数据提取窗口函数练到条件反射SQL 是数据岗笔试里的绝对大头。如果给各模块估分我倾向于认为 SQL 题能占 30% 到 40%比算法题更重。小红书这类以内容和社区为基本盘的平台业务场景天然适合出 SQL 题用户发布的笔记、浏览记录、点赞评论、订单转化、直播互动等每个场景都能衍生出一堆查询题。考察重点集中在几类分组聚合、条件筛选、多表关联、子查询以及最重要的窗口函数。窗口函数几乎成了互联网数据岗笔试的标配考点尤其是 ROW_NUMBER()、RANK()、DENSE_RANK()、LAG()、LEAD()、SUM() OVER(PARTITION BY ...) 这类写法必须练到能盲写的程度。举一个很典型的例子假设题目是“统计近30天内连续3天以上发布笔记的用户数量”你会怎么做很多人的第一反应是用自连接或者子查询但更高效的思路是用 LAG() 函数构造出每个用户的前两次发布日期再判断当前日期和这两个日期之间是否连续。代码大概是这样的WITH t AS ( SELECT user_id, publish_date, LAG(publish_date, 1) OVER(PARTITION BY user_id ORDER BY publish_date) AS prev_date_1, LAG(publish_date, 2) OVER(PARTITION BY user_id ORDER BY publish_date) AS prev_date_2 FROM user_publish_log WHERE publish_date DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY) ) SELECT user_id FROM t WHERE DATEDIFF(publish_date, prev_date_1) 1 AND DATEDIFF(publish_date, prev_date_2) 2;这类题看起来不难但考场上容易漏掉去重环节也就是同一个用户同一天发布多条笔记时应先聚合一次。这个细节我需要重点提醒因为我在练习时就踩过如果不加DISTINCT结果会多出一堆重复行最后的计数自然就偏了。SQL 题给分往往看最终结果一道题结果不对中间过程写得再漂亮也拿不到多少分。2.3 Python与pandas数据清洗与处理实操题重灾区pandas 数据清洗和处理是笔试里比较能拉开分差的模块。有的同学觉得 SQL 好写Python 难写有的同学正好相反。但小红书这批笔试的画像更偏向“数据分析和数据运营候选人”所以 pandas 题目的难度一般控制在拿到一个 DataFrame做缺失值填充、重复值去除、字段类型转换、时间处理、多表合并等操作。我当时遇到过一类很典型的题型给你一份用户表和一份订单表订单表里有一些下单时间为空、用户ID重复、金额字段是字符串类型的数据需要你把两份表合并成一份宽表再按用户维度统计每个用户的订单数、订单总额、最近一次下单时间。这个题有完整的操作链条每一个中间步骤都有明确的分数点。其中最重要的心法不是背 API而是理解每一步在做什么。缺失值填充用fillna不稀奇但什么时候用methodffill什么时候用中位数填充是根据业务含义决定的。用户ID重复时要用drop_duplicates但也要注意是保留第一个还是保留最后一个这会影响统计口径。字段类型转换用astype但不能硬转遇到异常值要先处理。时间处理用pd.to_datetime但很多笔试环境里的 pandas 版本可能不支持新参数建议优先用最基础的方法比如df[order_time] pd.to_datetime(df[order_time], errorscoerce) df df.dropna(subset[order_time]) df[order_date] df[order_time].dt.date这种写法简洁、兼容性好也能清楚表达你的处理逻辑。我个人的经验是不要在这种题里写“过于聪明”的代码比如用一堆高阶函数或者列表推导式阅卷人或者自动判分脚本更看重的是你能不能把逻辑写清楚而不是炫技。3. 从热词反推笔试考点数据治理、数据集与业务分析的隐藏分3.1 数据治理与数据质量概念题也能看出工程素养很多人在准备数据岗笔试时会忽略数据治理和数据质量这类偏“工程规范”的概念题。这类题目不会直接要求你写代码但会以一种背景题的形式出现比如“给你一个数据仓库怎么设计数据质量监控方案”“怎么处理重复上报的埋点数据”等。如果你只是在刷 LeetCode 和 SQL 题看到这些题时很容易懵。我复习时把这部分当成“补工程常识”来处理重点理解几个关键词数据血缘、数据标准、数据质量监控、数据备份与恢复。尤其是“数据备份与恢复”在业务场景里非常重要笔试中常以“如果某一天的数据缺失如何通过备份恢复或者重新计算得到”的形式出现。虽然不要求你写出恢复脚本但你要能说出可行的方案比如离线备份表、增量备份、全量重跑等。数据治理题的高分答题思路是先定义问题再拆解分层最后落到可执行的动作。比如“如何保证埋点数据的准确性”我会这样回答先看埋点上报链路确认是否存在延迟和丢失再看数据仓库的清洗规则是否有去重和空值过滤最后加一个监控预警基于同环比波动来触发告警。这样的回答既有工程视角又不会空泛。3.2 数据集构建与数据标注算法向笔试的高频场景如果你的意向方向是算法数据岗那“数据集构建”“数据标注”“数据增强方法”这类关键词的命中概率会显著提升。这些题往往考察你对训练数据源头和特征工程的理解。比如给你一组小红书笔记文本要求你做文本分类任务你怎么构建训练集怎么处理类别不平衡问题怎么选择数据增强方法我自己复盘时发现数据增强并不是简单地说“加噪声”“做同义词替换”就能拿分笔试更看重的是你有没有考虑过“增强后的数据是否符合原始数据分布”。以文本分类为例如果直接对短文本做随机删除很可能会把核心语义删掉反而让模型学到错误信息。更好的做法是先定位关键词再做局部扰动。如果你能写出类似“按实体替换 回译 最小编辑”的组合策略分数会比干巴巴列一堆术语高很多。另外“yolov8训练自己的数据集”“mmrotate训练dota数据集”这类偏视觉的热词也说明算法方向的笔试或者加分题可能会涉及数据标注格式、类别不平衡、数据增强策略等问题并不要求你上手训练模型但至少要知道标注数据结构长什么样比如 COCO、VOC、YOLO 格式的区别以及如何从一份原始数据构造出符合训练要求的标注文件。这里不需要特别深入但概念不能是空的。3.3 业务分析与数据可视化把统计结果讲成决策建议数据岗笔试最后往往有一道业务分析题通常不会提供真实的数据而是给一个开放性业务场景比如“小红书笔记的平均曝光量下降了请你分析可能的原因并给出数据验证方案”。这类题没有标准答案但非常能看出一个人是不是只会跑数、不会思考。我的建议是答题时采用“先拆维度、再给假设、最后给验证方法”的结构。先拆维度把曝光量下降拆成渠道、内容类型、用户分群、时间周期等再给假设比如“某一天推荐策略变更导致低质内容曝光占比上升”“某类作者发布频率下降导致供给不足”最后落到验证方法比如看分桶实验、对比历史同期、分析用户行为漏斗。不要一上来就写“加强内容审核”“提升推荐准确性”这种正确的废话。数据可视化也是容易被忽略的点。笔试里不一定会让你画图表但可能会给你一组数据问你“用什么图表最合适”。比如“连续30天DAU趋势”应该用折线图“不同品类笔记占比”应该用饼图或堆叠柱状图“用户阅读时长和点赞量的关系”要用散点图。你要能说清楚为什么选这个图表而不是把所有图表类型都列一遍。数据可视化的本质是把信息编码成视觉元素选错图表等于编码错误即使数据没错读者也读不出结论。4. 实操过程中的时间分配与常见翻车点4.1 笔试环境与时间分配先做哪类题更划算笔试时的时间分配往往比多刷几道题更重要。我自己的经验是拿到卷子后不要立刻从第一题开始做而是先花两分钟把整张卷子的题型、题量和分值分布扫一遍。如果分数占比最高的是 SQL那就先保证 SQL 有时间做完如果你明显擅长 Python也可以先做 Python 热身再回来啃算法题。常见的考试配置可能是四部分选择题10-15道、编程题2-3道、SQL题2-3道、业务分析题1道。我的策略是先做选择题因为选择题往往是最花时间但单位分值偏低的而且答案是从几个选项里选纠结太久会崩心态。建议每道选择题控制在2分钟以内拿不准的做个标记后立刻跳过最后再回头补。编程题和 SQL 题建议分开做中间穿插一两个简单选择题换换脑子。业务分析题虽然主观性强但只要写下结构化思路得分往往比较稳定所以宁愿编程题AC率低一点也要给业务题留出15到20分钟。另一个容易被忽略的点是笔试系统断点续做的兼容性不一定好开考之前一定要测试网络环境关闭所有自动更新和弹窗避免写代码时被系统打断。4.2 代码细节导致AC低的三个典型原因我复盘过一批数据岗笔试发现很多同学明明思路正确但代码就是AC率很低。最常见的原因有三个变量名拼写错误、列表越界、忘记处理边界条件。这三类问题都非常隐蔽因为在本地编辑器里你可能已经通过了大部分测试用例但在笔试系统的隐藏用例里就会暴露。第一个是变量名拼写错误。笔试时间一紧张很多人会把user_id和userID混着写Python 对这种大小写敏感一旦写错就直接完蛋。我建议在写代码之前先统一命名风格想清楚用什么变量名再开始写。第二个是列表越界尤其是在处理指针和排序问题时。比如双指针的循环条件如果你只写了while left right但没考虑left和right在边界处的更新顺序很容易出现数组越界或死循环。更好的做法是先把边界条件写清楚再写循环体。第三个是忘记处理空值或者空数组。数据岗笔试题给的输入往往是模拟的“表数据”如果你在代码里假设列表一定非空、字典一定包含某个键那一旦出现None或空行代码就会崩。解决方案是在数据读入阶段先做一次必要的空值检查不要指望测试用例里全部都是干净数据。4.3 业务题答题陷阱答得越多得分越低业务分析题最容易犯的错误不是答得太少而是答得太多、太散。很多同学为了显得专业会把所有知道的指标和术语都堆上去比如转化率、留存率、ARPU、LTV、DAU、MAU。但面试官其实最反感这种“名词堆砌”式的答案因为它没有体现逻辑链条只是证明你知道这些词。正确的答法是选一个最核心的分析路径讲透。比如题目问“为什么推荐流人均时长下降了10%”你可以选“分位点分析 新老用户差异”这一个切入点先看时长下降是否集中在某个分位点再看新用户和老用户是否有显著差异然后给出假设和验证方案。一条清晰的逻辑线比你列十个指标但没有结论要强得多。另一个业务题陷阱是忽视成本约束。比如你说“我们可以上线A/B实验来验证”但题目背景里如果写了“当前资源有限无法做长期实验”那就要考虑用历史数据模拟或者同期群分析来替代。能意识到约束条件并用合适方法回应才是业务分析师区别于普通跑数员的加分点。5. 给后来者的一条条实干建议回顾这批笔试我最想强调的一句话是数据岗笔试考的不是某个单独的知识点而是你面对一个不熟悉的业务数据问题时能不能快速拆解、找到数据入口、给出可执行的分析方案。这个能力通过短期刷题不一定能突飞猛进但可以通过刻意练习慢慢建立起来。具体来说我建议在接下来两周内做三件事。第一把SQL窗口函数刷到闭眼能写尤其是ROW_NUMBER()和LAG()这是性价比最高的提分点。第二用一份真实的业务数据模拟笔试流程给自己定90分钟做完之后严格对照答案复盘重点看有没有因为代码细节扣分。第三把常见业务分析题整理成自己的答题框架每次答题先分维度再给假设最后落到验证方案形成肌肉记忆。我在实际准备过程中还有一个体会不要迷信“面经里的原题”。笔试题目每年都在变但考察底层能力是稳定的。如果你能把数据结构、SQL、数据清洗、业务分析这四个模块都过一遍即使题目换成新的业务场景你也知道该从哪下手。这时候再回头看小红书数据岗第二批笔试你会发现它没有那么神秘它就是一份“业务技术”的融合型试卷认真准备的人都能拿到一个体面的结果。
1. 2023秋招小红书数据岗第二批笔试先弄清楚它到底考什么2023年秋招的小红书数据岗第二批笔试是很多应届生和初级数据从业者绕不开的一道坎。相比第一批笔试第二批的题量更大、题型更杂而且部分题目会故意设置一些“看起来能做、上手就错”的坑。当时我在准备这批笔试时最强烈的感受是它不像传统互联网大厂那种“两道算法题定生死”的风格而是把数据处理全流程拆成选择题、SQL题、Python题、业务分析题放在同一套卷子里时间还压得比较紧。正因如此很多人不是败在知识储备上而是败在时间分配和答题节奏上。这篇复盘想解决的核心问题是第二批发数据岗笔试到底在考什么以及应该按什么优先级复习。不管你是刚投完简历准备笔试的应届生还是想跳槽到社区类产品做数据分析的初级打工人这篇文章都会尽量按照我当时“踩过坑之后整理出来的复习框架”来讲尽量少说废话多给能直接落地的思路。先说结论这类笔试复习真正的权重排序应该是——SQL 数据结构与算法 Python数据处理基础 业务分析思维 数据治理等概念题。不是说你每个岗位都要按这个顺序而是从“投入产出比”来看SQL是单位时间内提分最快的算法题决定了你能不能过系统筛选Python题则直接影响你在面试官印象里的专业度。接下来的章节就把这些模块逐一拆开结合具体的场景和题型来说。2. 核心考点拆解从数据结构到业务题的复习优先级2.1 数据结构与算法题该刷到什么程度数据岗的算法题没有纯后端岗那么硬核但也不能完全不准备。我观察到的普遍情况是小红书这类偏业务和内容生态的公司笔试里的算法题会刻意“场景化”。比如给你一段用户日志让你统计连续登录天数给你一批订单记录让你找出金额最大的Top N用户。这些题本质上还是在考察数组、哈希表、排序、双指针、动态规划等基础能力但包装了一层业务外衣。我当时给自己定的目标是 LeetCode 前 200 题里简单题稳定过关中等题能写出暴力解并尽可能优化。尤其是哈希表这种数据结构在数据岗笔试里出现频率极高因为很多题最后都会落到“去重”或“计数”上哈希表是最直接的工具。图的遍历虽然出现频率不高但一旦出现就会很致命。像“判断两个用户是否是好友关系链上的闭环”这类题如果没复习过 BFS/DFS现场很容易卡住。为什么不建议花大量时间刷 hard 题因为数据岗笔试时间有限算法题往往只占 30% 左右的分数你把 90 分钟全耗在一道 hard 题上后面的 SQL 题可能连题面都没看。我当时就犯过这个错误在第一道算法题上硬刚了 40 分钟结果后面有两个 SQL 表结构题没写完直接拉低了整体得分。复盘之后我才意识到算法题的目的是“筛掉完全不会写代码的人”而不是“筛出竞赛选手”。2.2 SQL数据提取窗口函数练到条件反射SQL 是数据岗笔试里的绝对大头。如果给各模块估分我倾向于认为 SQL 题能占 30% 到 40%比算法题更重。小红书这类以内容和社区为基本盘的平台业务场景天然适合出 SQL 题用户发布的笔记、浏览记录、点赞评论、订单转化、直播互动等每个场景都能衍生出一堆查询题。考察重点集中在几类分组聚合、条件筛选、多表关联、子查询以及最重要的窗口函数。窗口函数几乎成了互联网数据岗笔试的标配考点尤其是 ROW_NUMBER()、RANK()、DENSE_RANK()、LAG()、LEAD()、SUM() OVER(PARTITION BY ...) 这类写法必须练到能盲写的程度。举一个很典型的例子假设题目是“统计近30天内连续3天以上发布笔记的用户数量”你会怎么做很多人的第一反应是用自连接或者子查询但更高效的思路是用 LAG() 函数构造出每个用户的前两次发布日期再判断当前日期和这两个日期之间是否连续。代码大概是这样的WITH t AS ( SELECT user_id, publish_date, LAG(publish_date, 1) OVER(PARTITION BY user_id ORDER BY publish_date) AS prev_date_1, LAG(publish_date, 2) OVER(PARTITION BY user_id ORDER BY publish_date) AS prev_date_2 FROM user_publish_log WHERE publish_date DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY) ) SELECT user_id FROM t WHERE DATEDIFF(publish_date, prev_date_1) 1 AND DATEDIFF(publish_date, prev_date_2) 2;这类题看起来不难但考场上容易漏掉去重环节也就是同一个用户同一天发布多条笔记时应先聚合一次。这个细节我需要重点提醒因为我在练习时就踩过如果不加DISTINCT结果会多出一堆重复行最后的计数自然就偏了。SQL 题给分往往看最终结果一道题结果不对中间过程写得再漂亮也拿不到多少分。2.3 Python与pandas数据清洗与处理实操题重灾区pandas 数据清洗和处理是笔试里比较能拉开分差的模块。有的同学觉得 SQL 好写Python 难写有的同学正好相反。但小红书这批笔试的画像更偏向“数据分析和数据运营候选人”所以 pandas 题目的难度一般控制在拿到一个 DataFrame做缺失值填充、重复值去除、字段类型转换、时间处理、多表合并等操作。我当时遇到过一类很典型的题型给你一份用户表和一份订单表订单表里有一些下单时间为空、用户ID重复、金额字段是字符串类型的数据需要你把两份表合并成一份宽表再按用户维度统计每个用户的订单数、订单总额、最近一次下单时间。这个题有完整的操作链条每一个中间步骤都有明确的分数点。其中最重要的心法不是背 API而是理解每一步在做什么。缺失值填充用fillna不稀奇但什么时候用methodffill什么时候用中位数填充是根据业务含义决定的。用户ID重复时要用drop_duplicates但也要注意是保留第一个还是保留最后一个这会影响统计口径。字段类型转换用astype但不能硬转遇到异常值要先处理。时间处理用pd.to_datetime但很多笔试环境里的 pandas 版本可能不支持新参数建议优先用最基础的方法比如df[order_time] pd.to_datetime(df[order_time], errorscoerce) df df.dropna(subset[order_time]) df[order_date] df[order_time].dt.date这种写法简洁、兼容性好也能清楚表达你的处理逻辑。我个人的经验是不要在这种题里写“过于聪明”的代码比如用一堆高阶函数或者列表推导式阅卷人或者自动判分脚本更看重的是你能不能把逻辑写清楚而不是炫技。3. 从热词反推笔试考点数据治理、数据集与业务分析的隐藏分3.1 数据治理与数据质量概念题也能看出工程素养很多人在准备数据岗笔试时会忽略数据治理和数据质量这类偏“工程规范”的概念题。这类题目不会直接要求你写代码但会以一种背景题的形式出现比如“给你一个数据仓库怎么设计数据质量监控方案”“怎么处理重复上报的埋点数据”等。如果你只是在刷 LeetCode 和 SQL 题看到这些题时很容易懵。我复习时把这部分当成“补工程常识”来处理重点理解几个关键词数据血缘、数据标准、数据质量监控、数据备份与恢复。尤其是“数据备份与恢复”在业务场景里非常重要笔试中常以“如果某一天的数据缺失如何通过备份恢复或者重新计算得到”的形式出现。虽然不要求你写出恢复脚本但你要能说出可行的方案比如离线备份表、增量备份、全量重跑等。数据治理题的高分答题思路是先定义问题再拆解分层最后落到可执行的动作。比如“如何保证埋点数据的准确性”我会这样回答先看埋点上报链路确认是否存在延迟和丢失再看数据仓库的清洗规则是否有去重和空值过滤最后加一个监控预警基于同环比波动来触发告警。这样的回答既有工程视角又不会空泛。3.2 数据集构建与数据标注算法向笔试的高频场景如果你的意向方向是算法数据岗那“数据集构建”“数据标注”“数据增强方法”这类关键词的命中概率会显著提升。这些题往往考察你对训练数据源头和特征工程的理解。比如给你一组小红书笔记文本要求你做文本分类任务你怎么构建训练集怎么处理类别不平衡问题怎么选择数据增强方法我自己复盘时发现数据增强并不是简单地说“加噪声”“做同义词替换”就能拿分笔试更看重的是你有没有考虑过“增强后的数据是否符合原始数据分布”。以文本分类为例如果直接对短文本做随机删除很可能会把核心语义删掉反而让模型学到错误信息。更好的做法是先定位关键词再做局部扰动。如果你能写出类似“按实体替换 回译 最小编辑”的组合策略分数会比干巴巴列一堆术语高很多。另外“yolov8训练自己的数据集”“mmrotate训练dota数据集”这类偏视觉的热词也说明算法方向的笔试或者加分题可能会涉及数据标注格式、类别不平衡、数据增强策略等问题并不要求你上手训练模型但至少要知道标注数据结构长什么样比如 COCO、VOC、YOLO 格式的区别以及如何从一份原始数据构造出符合训练要求的标注文件。这里不需要特别深入但概念不能是空的。3.3 业务分析与数据可视化把统计结果讲成决策建议数据岗笔试最后往往有一道业务分析题通常不会提供真实的数据而是给一个开放性业务场景比如“小红书笔记的平均曝光量下降了请你分析可能的原因并给出数据验证方案”。这类题没有标准答案但非常能看出一个人是不是只会跑数、不会思考。我的建议是答题时采用“先拆维度、再给假设、最后给验证方法”的结构。先拆维度把曝光量下降拆成渠道、内容类型、用户分群、时间周期等再给假设比如“某一天推荐策略变更导致低质内容曝光占比上升”“某类作者发布频率下降导致供给不足”最后落到验证方法比如看分桶实验、对比历史同期、分析用户行为漏斗。不要一上来就写“加强内容审核”“提升推荐准确性”这种正确的废话。数据可视化也是容易被忽略的点。笔试里不一定会让你画图表但可能会给你一组数据问你“用什么图表最合适”。比如“连续30天DAU趋势”应该用折线图“不同品类笔记占比”应该用饼图或堆叠柱状图“用户阅读时长和点赞量的关系”要用散点图。你要能说清楚为什么选这个图表而不是把所有图表类型都列一遍。数据可视化的本质是把信息编码成视觉元素选错图表等于编码错误即使数据没错读者也读不出结论。4. 实操过程中的时间分配与常见翻车点4.1 笔试环境与时间分配先做哪类题更划算笔试时的时间分配往往比多刷几道题更重要。我自己的经验是拿到卷子后不要立刻从第一题开始做而是先花两分钟把整张卷子的题型、题量和分值分布扫一遍。如果分数占比最高的是 SQL那就先保证 SQL 有时间做完如果你明显擅长 Python也可以先做 Python 热身再回来啃算法题。常见的考试配置可能是四部分选择题10-15道、编程题2-3道、SQL题2-3道、业务分析题1道。我的策略是先做选择题因为选择题往往是最花时间但单位分值偏低的而且答案是从几个选项里选纠结太久会崩心态。建议每道选择题控制在2分钟以内拿不准的做个标记后立刻跳过最后再回头补。编程题和 SQL 题建议分开做中间穿插一两个简单选择题换换脑子。业务分析题虽然主观性强但只要写下结构化思路得分往往比较稳定所以宁愿编程题AC率低一点也要给业务题留出15到20分钟。另一个容易被忽略的点是笔试系统断点续做的兼容性不一定好开考之前一定要测试网络环境关闭所有自动更新和弹窗避免写代码时被系统打断。4.2 代码细节导致AC低的三个典型原因我复盘过一批数据岗笔试发现很多同学明明思路正确但代码就是AC率很低。最常见的原因有三个变量名拼写错误、列表越界、忘记处理边界条件。这三类问题都非常隐蔽因为在本地编辑器里你可能已经通过了大部分测试用例但在笔试系统的隐藏用例里就会暴露。第一个是变量名拼写错误。笔试时间一紧张很多人会把user_id和userID混着写Python 对这种大小写敏感一旦写错就直接完蛋。我建议在写代码之前先统一命名风格想清楚用什么变量名再开始写。第二个是列表越界尤其是在处理指针和排序问题时。比如双指针的循环条件如果你只写了while left right但没考虑left和right在边界处的更新顺序很容易出现数组越界或死循环。更好的做法是先把边界条件写清楚再写循环体。第三个是忘记处理空值或者空数组。数据岗笔试题给的输入往往是模拟的“表数据”如果你在代码里假设列表一定非空、字典一定包含某个键那一旦出现None或空行代码就会崩。解决方案是在数据读入阶段先做一次必要的空值检查不要指望测试用例里全部都是干净数据。4.3 业务题答题陷阱答得越多得分越低业务分析题最容易犯的错误不是答得太少而是答得太多、太散。很多同学为了显得专业会把所有知道的指标和术语都堆上去比如转化率、留存率、ARPU、LTV、DAU、MAU。但面试官其实最反感这种“名词堆砌”式的答案因为它没有体现逻辑链条只是证明你知道这些词。正确的答法是选一个最核心的分析路径讲透。比如题目问“为什么推荐流人均时长下降了10%”你可以选“分位点分析 新老用户差异”这一个切入点先看时长下降是否集中在某个分位点再看新用户和老用户是否有显著差异然后给出假设和验证方案。一条清晰的逻辑线比你列十个指标但没有结论要强得多。另一个业务题陷阱是忽视成本约束。比如你说“我们可以上线A/B实验来验证”但题目背景里如果写了“当前资源有限无法做长期实验”那就要考虑用历史数据模拟或者同期群分析来替代。能意识到约束条件并用合适方法回应才是业务分析师区别于普通跑数员的加分点。5. 给后来者的一条条实干建议回顾这批笔试我最想强调的一句话是数据岗笔试考的不是某个单独的知识点而是你面对一个不熟悉的业务数据问题时能不能快速拆解、找到数据入口、给出可执行的分析方案。这个能力通过短期刷题不一定能突飞猛进但可以通过刻意练习慢慢建立起来。具体来说我建议在接下来两周内做三件事。第一把SQL窗口函数刷到闭眼能写尤其是ROW_NUMBER()和LAG()这是性价比最高的提分点。第二用一份真实的业务数据模拟笔试流程给自己定90分钟做完之后严格对照答案复盘重点看有没有因为代码细节扣分。第三把常见业务分析题整理成自己的答题框架每次答题先分维度再给假设最后落到验证方案形成肌肉记忆。我在实际准备过程中还有一个体会不要迷信“面经里的原题”。笔试题目每年都在变但考察底层能力是稳定的。如果你能把数据结构、SQL、数据清洗、业务分析这四个模块都过一遍即使题目换成新的业务场景你也知道该从哪下手。这时候再回头看小红书数据岗第二批笔试你会发现它没有那么神秘它就是一份“业务技术”的融合型试卷认真准备的人都能拿到一个体面的结果。
