2024年春招投小红书研发岗的同学，很多人都在第二批笔试这里卡了一下。说是第二批，实际从投递到收到笔试通知，节奏比想象中快，题目风格也明显不是随便刷两三百道LeetCode就能应付的。作为参加过这一轮的人，我把整场笔试的考察方向、题型特征、做题顺序和踩坑细节整理出来，尤其适合后面准备社交内容平台研发岗、或者正在规划2025届春招的读者。这篇不是官方答案，就是一个过来人对笔试现场的还原和拆解，希望能让你在进考场前，心里更有底。
1. 笔试考核的底层逻辑：研发岗到底想筛什么样的人
1.1 为什么报名后面还有“第二批”笔试
很多同学一看到“第二批笔试”就紧张，觉得是不是第一批没招满，或者自己简历不够硬才被排到后面。从我了解到的招聘流程来看，批次更多是投递时间和简历池滚动筛选的结果。春招不像秋招有固定的大规模统一场次，HR会根据简历量、岗位HC和各团队需求，把候选人分批安排笔试。第二批不代表你是“备胎”，反而说明简历已经通过了初筛，进入正式考核通道。
能走到笔试这一步，说明基础学历、项目经历、实习背景至少过了关卡。接下来要看的，就是真刀真枪的编码能力和逻辑思维。小红书研发岗覆盖的方向挺多，后端、客户端、算法、数据、测试开发都可能出现在同一批笔试里，但不同岗位的试卷侧重点会有差异。比如后端和客户端可能更看重工程实现能力，算法岗会额外侧重模型和论文相关考察。不过共同点是，第一轮笔试基本都以算法题为主，再穿插一些基础客观题或场景设计题。
1.2 考核范围：算法、数据结构、工程思维三位一体
从我参加的这轮笔试看，整体考核范围可以浓缩成三块：算法与数据结构、基础技术知识、工程化场景题。算法题一般是两到三道，难度在中等到偏难之间，不会纯考背模板，而是把常见考点包装成业务味道很浓的题目。数据结构部分其实不会单独出简答题，更多是要求你在解题过程中用到合适的结构，比如LRU缓存、单调队列、并查集、线段树这些，不一定考到，但至少要具备灵活选型的能力。
工程思维是容易被忽略的一块。有的题目看起来是算法题，但题目背景会和内容社区相关，比如笔记推荐、关注流、搜索排序、消息推送。这时候除了把代码写对，还要注意边界条件、数据量级、时间复杂度。你写的解法能不能支撑几百万用户量级的调用，往往比“玄学AC”更重要。阅卷人看的不只是最终答案，还有代码风格、变量命名、异常处理，这些隐含的工程要求，很多人容易在笔试里丢掉。
1.3 笔试在整体招聘流程中的权重
笔试不是走过场，它直接影响你能不能进入面试环节，甚至在某种程度上面试官会拿着你的笔试代码来提问。如果笔试代码写得乱，思路也不清晰，面试官大概率会针对某一题深挖，问你“当时为什么这么设计”“有没有考虑过更优解”，答不上来反而会暴露真实水平。
从我个人的体感看，笔试分数高低会有一定“定级参考”作用。通过的候选人和高分的候选人，后续面试体验可能不一样。高分的候选人更容易被好团队捞走，面试中聊项目时也有更多主动权。所以不要抱着“能过就行”的心态，笔试题能优化就优化，能写注释就写注释。尤其是第二批笔试，和前面批次之间的题目可能存在部分重叠，多做几套回忆版真题，针对高频考点提前准备，收益会非常明显。
2. 核心题型与知识点拆解
2.1 算法题：出题风格和常见考点
小红书的算法题，给我的感觉是“中等题为主，难题随缘”。常考的知识点分布很有规律，数组、字符串、链表、二叉树、哈希表、双指针、滑动窗口、动态规划，这些是绝对主力。贪心、二分、堆、栈也偶有出现，但不会特别偏门。和纯竞赛题目不同的是，笔试题目常常会给你一段比较长的业务背景描述，需要你先从描述里提取出核心的数学模型，再动手写代码。这点对阅读理解能力有要求，读题不要着急。
举个例子，它可能把“滑动窗口最大值”包装成“统计一段时间内笔记热度最高的窗口”，或者把“最长无重复子串”包装成“用户连续浏览去重”。识别出题目本质是哪个经典问题，比直接莽写重要得多。我参加的那场，就有一道题表面上在讲“粉丝增量统计”，剥掉背景后，实际就是区间合并和排序问题。如果你平时只是按题号刷，没有训练过“脱掉马甲看本质”的能力，遇到这种题会浪费大量时间。
2.2 数据结构题：从HashMap到设计类题目
笔试里不太会直接问你“HashMap底层原理”，但会在代码题里用隐性的方式考你。比如实现一个带过期时间的缓存，就涉及HashMap加双向链表、时间戳清理、线程安全等问题；再比如实现一个支持频次统计的结构，就需要考虑用Map嵌套或者堆来优化。
这类题目的难点不在数据结构本身，而在于你能不能根据操作复杂度要求选择合理实现。以LRU缓存为例，如果你只用一个数组去存key-value，get和put都是O(n)，在数据一多就会超时；正确思路是哈希表加双向链表，get和put都做到O(1)。很多人在准备笔试时，觉得LRU是面试题不会考，但恰恰相反，它就是典型的笔试高频题。它能把链表操作、哈希表、边界清理串在一起，很好地区分出候选人基本功是否扎实。
另外要提醒一点，笔试环境里写链表相关代码特别容易出错。你没有本地IDE的自动补全，节点定义、指针移动全得靠自己手写。平时一定要练到闭着眼能写出双向链表删除节点和插入节点的基本操作，并且注意空指针判断。我见过太多人思路对，但写着写着指针绕晕，最后只能return null，这种丢分最可惜。
2.3 场景与系统设计题：用业务语境包装的工程题
除了纯算法题，笔试里还可能出现一到两道场景设计题，可能是简答，也可能是让你写代码实现一个接口。这类题和业务结合非常紧，比如“设计一个笔记详情页的分页加载接口”“用户关注列表和粉丝列表如何存储”“消息推送去重怎么做”。看起来开放，但背后考察的其实是数据库设计、缓存设计、接口幂等、高并发下的可靠性这些工程问题。
回答这类题，不需要把系统做成能支撑亿级流量的完整架构，但至少要有清晰的思路。第一步先确认需求边界，比如数据量多大、读写比例多少、是否需要实时；第二步给出数据表设计和核心接口字段；第三步说明缓存和异步策略；第四步分析可能的瓶颈。哪怕只是用文字分点写出来，也会给阅卷人留下不错的印象。笔试时不要留白，能写多少写多少，尤其是系统设计题，部分得分的机会很大。
3. 实操复盘：一场典型第二批次笔试的完整经历
3.1 开考前的准备与环境检查
笔试当天，我提前半小时打开邮件里给的笔试链接，确认使用的平台是牛客网。这个平台的特点是有一个在线编辑器，但不像本地IDE那么智能，代码补全很弱，也没有自动格式化。所以建议提前准备好常用的输入输出模板，尤其是Java和Python的模板。比如Java读一行整数数组、Python用sys.stdin读取多行输入，这些固定代码直接复制保存，开考后能省下几分钟。
另外提醒几件容易被忽略的事：一是网络要稳定，最好用有线网络或手机热点做备用；二是关闭所有会弹窗的软件，笔试过程中切屏次数太多会被系统警告；三是把手机静音放到远处，避免来消息时下意识低头看。笔试开始后不要急着读题，先用两分钟把题目列表全部扫一遍，看看共几题、每题分值、各题难度，心里有一个全局的作战计划。
3.2 从读题到AC：一道典型题目的解题全流程
我这轮遇到的一道题，背景大概是这样：一个内容平台要统计连续N天里，每天新增笔记数量，求满足“区间内最大值和最小值之差不超过K”的最长连续天数。说白了，就是给一个数组，找出最长的连续子数组，使子数组内最大值和最小值之差不超过K。这是一道非常经典的滑动窗口题，但难在如何高效维护窗口内的最大值和最小值。
如果只用一个普通数组来遍历，每次扩展右边界后都要重新扫一遍窗口，复杂度是O(n²)，数据量一大必超时。正确做法是用两个单调队列分别维护窗口最大值和最小值。右边界扩展时，把新元素从队尾加入队列，同时把队尾小于新元素（对最大值队列来说）的元素弹出；左边界收缩时，判断队头元素是否已经移出窗口，是则弹出。这样每个元素最多入队出队一次，整体复杂度O(n)。
当时我写的是Java版本，核心思路如下：
public int longestSubarray(int[] nums, int k) { Deque<Integer> maxDeque = new ArrayDeque<>(); Deque<Integer> minDeque = new ArrayDeque<>(); int left = 0, res = 0; for (int right = 0; right < nums.length; right++) { while (!maxDeque.isEmpty() && nums[maxDeque.peekLast()] <= nums[right]) { maxDeque.pollLast(); } maxDeque.offerLast(right); while (!minDeque.isEmpty() && nums[minDeque.peekLast()] >= nums[right]) { minDeque.pollLast(); } minDeque.offerLast(right); while (nums[maxDeque.peekFirst()] - nums[minDeque.peekFirst()] > k) { left++; if (maxDeque.peekFirst() < left) maxDeque.pollFirst(); if (minDeque.peekFirst() < left) minDeque.pollFirst(); } res = Math.max(res, right - left + 1); } return res; }这道题有个容易踩的坑：在收缩左边界时，不能只left++，还要同步处理两个单调队列的队头过期数据。如果漏了这一步，队头可能已经不在窗口内，但依然参与最大值最小值计算，结果就会错。另外，这里的数组元素可能有负数，所以初始化res要用0而不是负无穷。笔试时我因为第一版代码忘了更新队列头，导致提交后WA了一次，后来打印队列内容才定位到问题。
3.3 遇到没思路的题时，我是怎么稳住策略的
笔试里不一定每道题都有思路，我心里很明白这一点。如果遇到一道题超过十分钟都没有一个可行的方向，我不会继续死磕，而是先跳到下一题，把能拿的分拿稳。等所有题都过了一遍，再回头来看卡住的那道题。这个策略帮我避免了很多次“一题卡2小时，后面白送分也没捡到”的惨案。
没有思路不代表只能交白卷。我会先写一个最暴力的解法，不管复杂度，先把正确性保证住。如果暴力都无从下手，就尝试分情况特判，比如数组长度为1、所有数相等、k特别大等边界场景，把这些简单case先写好，至少能拿到部分测试点的分。笔试系统多数是按通过率给分的，不是非黑即白的“AC或零分”。所以，哪怕只通过30%的用例，也比什么都不写好得多。
4. 常见问题与避坑技巧实录
4.1 线上笔试最容易丢分的三个细节
第一个细节是输入输出格式。笔试平台不像LeetCode那样已经帮你封装好函数，你需要自己处理标准输入。有些人做题习惯在LeetCode函数里写，一到牛客网就懵了，连怎么读一行以空格分隔的整数都要想半天。建议提前背熟三种最常见的输入模板：读取第一行的n和m、读取一行整数数组、读取多行字符串。这些模板非常基础，但能直接在考场上稳住心态。
第二个细节是自测用例。写完代码后不要急着提交，先构造几个典型用例测试：一个正常用例、一个边界用例、一个空数据用例。很多人写滑动窗口忘了处理空数组，直接nums[0]就数组越界。自己多花两分钟自测，能换来一次AC，性价比很高。
第三个细节是提交前检查代码里的调试输出。很多人喜欢在本地打印中间变量，提交时忘了删，结果输出一大堆调试信息，系统直接判WA。这个错误在紧张状态下反复出现，极其冤。我每次提交前会花10秒扫一遍代码，把所有System.out.println或print语句删干净，再确认方法返回类型和题目要求一致。
4.2 语言选择与代码规范的隐性要求
笔试支持的语言一般有Java、C++、Python、Go，选择哪一种会直接影响你的写题速度。我个人建议优先选自己最熟悉、能闭眼写基础语法的语言，不要在笔试里尝试新语言。如果熟悉程度差不多，可以按岗位方向选：后端岗选Java或Go，客户端岗选Java或Kotlin，算法岗选Python会方便很多。小红书后端不少场景都用Java，笔试里用Java写出来的代码，后续面试讨论时更贴合。
代码规范方面，注意变量名不要用a、b、c这种无意义的缩写，尽量用能表达含义的单词，比如left、right、maxCount、windowSize。缩进保持统一，逻辑块之间空一行。不建议在笔试里写特别多的设计模式，但至少要把一个核心函数拆成两个小函数，减少单个函数的代码行数。面试官看到清晰的代码，更愿意在面试中给你正向反馈。
4.3 做不出题也能拿部分分的技巧
如果题目确实没解出来，有几个“捞分”技巧可以试试。先写一个能保证正确但复杂度高的暴力解，这样平台上的小数据用例大概率能通过，一般能拿到百分之三十到五十的分数。然后在暴力解基础上加一个最简单的缓存或剪枝，比如用哈希表记录已经算过的状态，或者排序后提前退出循环，也能把部分用例的分数拉高。
如果连暴力解都写不出来，就把你想到的数据结构、可能的思路、甚至伪代码写在答题区。有些平台支持代码注释，你可以把思考过程写在注释里，阅卷人可能会看你思路给点主观分。但要注意，不要写和题目完全无关的代码，也不要试图在答案里写“我这题不会”，那样只会让阅卷人直接划零分。最重要的是，不要在一道题上耗尽所有时间，留出十分钟检查前面AC的题是否真的稳了。
5. 从笔试到面试：复盘价值与后续准备建议
5.1 考后复盘的正确姿势
笔试结束后的24小时，是记忆最清晰的阶段，务必要把每道题的题目背景、你的解法、卡住的点、正确解法记录下来。不要只记一个“AC”或“WA”，而是写清题号、数据范围、时间复杂度和空间复杂度。如果你是“蒙对”AC的，事后一定把相关解法重新推导一遍，不然面试官一问就穿帮。
复盘时还可以把题目归类到知识点，比如“滑动窗口”“二分答案”“树上DP”“链表操作”。之后每周抽时间把这些题目重新做一遍，看自己能不能在30分钟内写出无Bug版本。这个方法比刷新题更有效。因为笔试中出现过的题目，很有可能会在后续批次或同岗位面试中再次出现，尤其是一些通用题型，比如缓存设计、滑窗、TopK问题，几乎每个平台都会考。
5.2 针对小红书业务场景的专项准备
如果时间允许，建议针对内容社区型产品做一些专项准备。小红书的业务场景绕不开笔记、搜索、推荐、评论、私信、增长。你可以多想想“如果一个用户关注了1000个人，首页Feed流怎么做？”“笔记的点赞数如何异步更新？”“搜索关键词纠错和补全怎么做？”这些问题不一定会出现在笔试里，但面试环节问的概率很高。
准备的时候，尝试从数据规模和实时性两个维度去思考。比如Feed流，是拉取模式还是推送模式？如果需要实时推荐，用推拉结合；如果只是离线热度排序，那就可以用定时任务加缓存。面试官更看重你分析问题的框架，而不是记住某个标准答案。笔试中如果遇到场景设计题，也可以复用这套分析框架：确认需求、明确量级、设计存储、优化性能、考虑容灾。
5.3 给2025届和补录同学的时间线建议
如果你不是这届春招，而是打算准备2025届秋招或补录，建议提前三个月左右开始刷题。前一个月把基础数据结构过一遍，包括数组、链表、栈、队列、哈希表、二叉树、堆、图的基础遍历；第二个月集中刷中等难度的算法题，每天3到5道，重点放在滑动窗口、双指针、动态规划、二分查找；第三个月开始做模拟笔试，每周至少完整掐表一次，培养手写代码和调试的能力。
对于临近笔试的同学，最后一周的重点不是刷难题，而是复习自己做过的错题，并熟悉笔试平台的操作。每天可以找一道中等题在规定时间内完成，刻意训练“读题-建模-编码-自测”四个环节。不要迷信题海战术，要相信方法总结和心态稳定更重要。笔试只是第一关，通过后的面试才是真正拉开差距的地方，所以把握每一次笔试机会，多一次就多一分经验。
我个人这几轮笔试下来最大的感受是：代码能力是底线，但比代码更值钱的是你把一个模糊的业务问题转化成清晰技术方案的能力，以及遇到没见过的题时稳住不乱的心态。准备小红书这类平台的笔试，与其刷一千道零散题目，不如吃透三十道高频题型，把每道题背后的复杂度和边界条件想明白。希望这篇复盘能帮你少走一些弯路，也祝下一次轮到你时，能稳稳拿下入场券。
