去年秋招季我印象最深的一场笔试就是小红书2019年校园招聘技术类在线笔试第二批。当时我投的是后端开发岗做这套题的时候明显感觉到它跟那些纯刷题库的公司不一样题目里透着一股“业务驱动”的味道。今天不聊虚的就结合我自己的复盘和周围上岸同学的经验把这场笔试的题型结构、考点逻辑、在线笔试系统的操作细节以及当时的踩坑记录一口气整理出来。准备投内容社区、UGC平台方向技术岗的同学这篇完全可以当备战的参考模板。1. 笔试整体情况与考核思路拆解1.1 2019年校招背景下的小红书技术笔试定位2019年的校招市场已经相当热闹小红书正处于高速扩张期社区内容量、用户规模都在快速增长技术团队也在大量补充新鲜血液。技术类笔试分批次进行第二批在线笔试的整体难度我个人体感是中等偏上但它的“偏”不在于题目有多难而在于它有两类考察点一类是常规算法题另一类是跟业务场景结合的工程题。这里要特别说明一个背景小红书作为内容社区核心业务链路是内容生产、内容分发、内容消费以及围绕内容产生的社交互动。所以它的技术笔试不像某些大厂那样纯考红黑树和线段树而是更看重候选人能不能用基础算法和数据结构去解决实际业务问题。这跟当时很多同学的预期不太一样我身边有人在笔试前狂刷难题偏题结果上考场发现题目没想象中那么硬核反而因为基础不牢、边界处理不到位挂掉了。1.2 题型结构与时间分配策略这场笔试的时间一般是90到120分钟题型分布大致是单选题、多选题、编程题部分批次可能还有简答题或系统设计题。选择题覆盖计算机网络、操作系统、数据库、Java或C基础、数据结构等校招常规科目编程题一般是2到4道难度递进分值占比也最大。先说我当时的教训我在选择题上花了太多时间特别是多选因为少选多选都不得分我在几道纠结的题上反复横跳结果压缩了后面编程题的时间。后来复盘才明白这种在线笔试拼的不是满分而是相对分数编程题才是拿分大头。合理的策略应该是选择题整体控制在20到25分钟遇到犹豫超过1分钟的题先标记跳过不要恋战。编程题先通读所有题目按难度排序先做自己最有把握的题。最后至少留10分钟检查代码格式、输出格式以及有没有漏题。时间分配建议我整理成一张表后面编程题策略那节会细讲。2. 核心考点与题目复盘2.1 数据结构与算法题高频出题方向把小红书历年笔试题和同期同学的反馈放在一起看编程题高频方向基本集中在字符串处理、链表操作、二叉树遍历、动态规划、以及排序查找的变种。跟纯OJ平台上的题不一样小红书喜欢把这些考点包装到“内容分享”场景里。举一个当时印象很深的题分享链接短ID解析。题目大意是小红书笔记分享链接里有一串看起来是乱码的短ID要求你写一个函数把这串短ID还原成原始笔记ID并且做合法性校验。这道题表面考的是字符串处理和进制转换实际还隐藏了一个边界点短ID的字符集可能不完全是大小写字母加数字遇到非法字符必须能正确报错而不是抛异常。这类题在LeetCode上的原型是“Excel表列序号转换”和“base62编码”的变形但加了业务外壳之后很多只刷题不思考的同学就懵了。我当时用的思路是先确认字符集和编码规则再做逐字符解析同时做越界判断和非法字符拦截。核心逻辑本质是62进制的解析但每一段都要考虑溢出。这里放一个Python版本的简化示例def parse_short_id(short_id: str) - int: chars 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ char_to_val {c: i for i, c in enumerate(chars)} result 0 for ch in short_id: if ch not in char_to_val: raise ValueError(finvalid char: {ch}) result result * 62 char_to_val[ch] if result 2**31 - 1: raise OverflowError(id out of range) return result这道题后来我在面试复盘时才发现它考的其实是对“分享链接可运营性”的理解短ID太短容易被遍历太长又影响URL美观所以必须做进制混淆和合法性校验。这种思路在内容平台的技术体系里是有真实落地的不是纯粹为了出题而出题。2.2 编码实现与边界条件处理在线笔试的编程题判题往往比本地IDE严格得多。同样一段逻辑你在本地怎么跑都对提交上去可能就是0分。原因大概率不是算法有问题而是边界条件没覆盖全。我每次复盘都会整理一份边界条件清单小红书这批题同样适用空字符串、空数组、null输入。单元素输入。数字溢出比如整数乘法后超过int范围。字符串包含特殊字符、空格、中文。循环输入多组测试用例时有没有正确处理到文件结束。递归深度过深导致的栈溢出。这里分享一个真实案例有位同学当时做一道链表反转的题本地自己写测试用例全过提交后通过率只有70%。后来排查发现他忽略了一个用例链表只有一个节点甚至链表本身是空的。他的代码里返回了新链表的头节点但新链表头在空输入时是未定义的导致判题时报错。这类错误在牛客、赛码这类在线笔试系统里太常见了。我的建议是写代码之前先把边界条件当注释写出来再写主逻辑。3. 在线笔试系统的实操经验3.1 在线笔试环境与代码提交要点接下来说说在线笔试环境本身。小红书当年用的在线笔试系统支持C、Java、Python等主流语言自带一个简易IDE和编译运行环境。听起来没什么特别的但实际操作中的坑不少。首先在线IDE的代码自动补全和语法检查非常弱基本就是个带高亮的文本编辑器。很多平时在本地IDE里靠插件活着的同学一上考场连括号匹配都费劲。所以备考阶段一定要习惯在网页编辑器里直接写代码不要依赖本地环境。其次是对输入输出的处理。在线笔试的判题逻辑是你的程序从标准输入读取测试数据然后把结果打印到标准输出系统拿你的输出和预期输出比对。很多人挂在输出格式上比如多打了一个空格或者少了一个换行。尤其是输出一个数组或矩阵的时候分隔符、行尾空格、最后一行要不要换行不同题目的要求都不一样。我踩过的坑是当时有一道题要求输出结果用逗号分隔但示例输出里最后一项后面没有逗号我没注意看直接用了循环加逗号的写法导致最后多了一个逗号被判格式错误。这种错误特别冤。解决方法是输出前先构造一个字符串列表再用join拼接而不是边循环边打印。3.2 时间分配与做题顺序策略做题顺序这件事我在前面提过这里详细展开一下。在线笔试的编程题通常不是均匀难度的第一题往往是热身题后面越来越难。但如果你一上来就被第一题卡住了千万别死磕。我个人的做题策略是拿到卷子先花3到5分钟通读全部题目包括选择题和编程题。快速判断每道编程题的题型和已知解法给它们排个难度序。先做自己最熟练的题目把保底分拿到手。再做中等难度的题最后剩下的时间去啃最难的题。每道题写完后如果时间允许马上用题目给的示例跑一遍确认输出无误再提交。这个方法说白了就是“先易后难拿满基础分”。因为在线笔试的判分往往不是只看你是AC还是没AC有些题是按通过用例比例给分的你写了个暴力解法至少能过部分用例也能拿到部分分数。所以哪怕不会最优解也别空着暴力先写上说不定就能拿个30%到50%的分数。4. 从题目看小红书业务背后的技术点4.1 内容分发与分享链路设计小红书是典型的内容社区产品笔记、视频、商品分享是核心功能。用户在App里点击“分享”系统会生成一条带有短ID的链接朋友点开链接后后台做一次重定向找到对应的笔记内容。这个过程听起来简单但背后涉及短链生成、存储、路由、缓存、过期处理等一系列技术问题。笔试里如果出现“分享链接解析”之类的题目其实就是在模拟真实业务的一环。这种题目的深层考点是你有没有理解短链服务的核心设计比如短ID的生成方式有两种常见思路一种是哈希后截断另一种是发号器生成。哈希方案简单但有碰撞概率发号器方案需要维护全局递增ID但更可控。真实场景下通常还会加入校验位防止用户恶意枚举短ID来抓取内容。反过来想如果让你从零设计一个分享链接系统你会怎么拆解我当时的思路是分配一个唯一ID号段ID转62进制得到短ID存Redis做热点缓存请求进来先查缓存再查DBDB没命中就回源并回填缓存。这个思路放到面试里也是一个合格的系统设计答案。所以不要只把笔试当刷题它其实在帮你模拟业务系统。4.2 图片视频处理与存储场景小红书的内容形态以图文和视频为主这就决定了技术体系里离不开图片处理和视频处理。你可能觉得笔试不会考这么偏但在系统设计题或者简答题中图片上传、缩略图生成、CDN加速是完全可能出现的。这里先给不熟悉这块的同学补个基础用户上传一张原图后端不能直接把原图返回给所有访客因为太占带宽了。通常的做法是上传后立即生成多档缩略图比如小图、中图、大图分别用于列表页、详情页和个人主页。缩略图生成一般会用Thumbnailator、ImageMagick或者云厂商的图像处理服务。图片存储到对象存储里再通过CDN分发到各地节点用户访问时就近返回。笔试如果出这类题大概率不会让你真的写图像处理代码而是考你概念和流程。比如给出一个上传流程让你指出性能瓶颈或者让你设计一个封面图生成方案。这种题的答题思路是不要只盯着单机处理要想到异步队列、任务拆分、缓存策略、失败重试这些工程化手段。我在笔试里遇到过一个类似场景的选择题问的是批量生成缩略图时怎么提升整体吞吐答案本质上是引入消息队列做异步削峰而不是同步一个个生成。4.3 数据采集与反爬对抗的平衡说完业务场景我想聊一个比较敏感但绕不开的话题内容平台和爬虫的对抗。市面上确实有不少人研究小红书笔记、图片、视频的采集工具但作为一个正规技术岗位的候选人你要明白什么能做什么不能做。笔试里如果涉及这块通常出题角度是防御方也就是让你设计限流策略、接口鉴权方式或者识别异常请求。比如有一类典型的笔试题设计一个接口限流方案要求单位时间内最多允许N次请求超过的请求拒绝或排队。这背后考的是限流算法的理解和应用。我用一个简化版滑动窗口计数器示例来说明class SlidingWindowRateLimiter: def __init__(self, max_requests: int, window_seconds: int): self.max_requests max_requests self.window_seconds window_seconds self.requests [] def allow(self, timestamp: int) - bool: while self.requests and timestamp - self.requests[0] self.window_seconds: self.requests.pop(0) if len(self.requests) self.max_requests: self.requests.append(timestamp) return True return False这类题看起来是算法题实际上是在考你有没有做风控的工程意识。比如要不要用Redis的ZSet做分布式限流还是单机用令牌桶就够。答题的时候如果你能把场景和具体方案联系起来分数会比单纯写个算法高很多。当然我在这里多说一句做技术的底线是合法合规。自己练手写个爬虫分析公开数据的代码没问题但大规模采集他人平台数据、绕过平台风控这是踩红线的行为校招笔试和面试里更要摆正位置不要主动展示这类“技能”。5. 备战建议与常见问题排查5.1 备考资料与刷题路线回头来看要打好校招技术笔试三个方面的准备缺一不可算法基础、专业基础知识、在线笔试环境的熟练度。算法基础最核心的资料就是LeetCode和剑指Offer。LeetCode建议按专题刷而不是按题号顺序刷。优先搞定高频题型的套路字符串处理、链表操作、二叉树遍历、动态规划、双指针、栈和队列应用、排序和查找。这些专题里字符串和动态规划是小红书笔试命中率最高的两类要额外花时间。专业基础知识方面计算机网络要重点看TCP三次握手、HTTP状态码、DNS解析过程操作系统要掌握进程线程区别、死锁条件、内存分页数据库要掌握索引原理、事务ACID、SQL常用操作。这些内容多是选择题和多选题看起来分值不高但错多了会很伤。刷题路线我给一个比较保守但有效的建议先刷LeetCode Hot 100里的高频题刷两遍第一遍看题解也能过第二遍必须完全自己写出来然后在牛客网上找几家目标公司的往年真题练手重点练在线笔试系统的操作手感。5.2 在线笔试常见问题速查在线笔试过程中每年都有人因为操作问题翻车。我把常见问题和解决办法整理成一张速查表建议收藏问题表现可能原因解决办法本地跑通但提交后0分主类类名或方法签名不匹配看清题目要求的类名和输入输出规范输出格式被判断错误多空格、少换行、行尾分隔符问题用join构造输出不边计算边打印超时算法复杂度过高先确认数据范围必要时换最优解或优化剪枝内存超限数组开得过大或递归过深检查数组边界改用迭代或压栈提交后一直编译失败漏了头文件/import粘贴代码后先检查依赖包有没有带上多组测试用例只跑了一组没有处理到EOF用while循环读取输入直到结束页面显示不全或代码框卡顿浏览器兼容问题优先用Chrome关闭无关插件这些坑每一个都是真实发生过的。我在一场模拟笔试里因为主类名写成了Main而题目要求是Solution导致整题0分那种感觉到现在还记得。所以交卷前花一分钟检查类名、方法名、输出样例非常值得。5.3 心态与实战技巧最后聊点务虚的但确实重要。在线笔试跟传统的纸笔考试不一样它是一场限时、高压、同时在线的编码对抗。周围可能有人说自己做得快有人已经在群里对答案这些噪音都很容易干扰心态。我的实战心得是把笔试当成一次日常的代码评审而不是“一考定终身”的战场。遇到做不出来的题先深呼吸写个暴力解能拿一分是一分。不要因为一道题没做出来就慌了神后面还有别的题在等着你。还有一个很多人忽略的细节笔试前把电脑充好电网络切换成稳定的有线或5G热点手机静音。如果条件允许提前打开在线笔试网站把系统自带的在线IDE测试一下确认能正常编译运行一个最简单的Hello World。这看起来不起眼但能避免很多临时状况。写在最后我自己在2019年秋招季前后折腾了很多场笔试回头看小红书这场“技术类在线笔试第二批”给我最大的收获不是某道题的解法而是让我意识到校招笔试本质上是让你在最短时间内展现工程思维和代码基本功。题目本身可能不会多难但它在模拟一种真实的工作状态——给你一个不算明确的问题限时内拆解、建模、编码、自查然后交付结果。希望大家准备笔试的时候别只盯着刷题量多花点时间做深度复盘。每道题做完问自己三个问题这道题核心考点是什么如果换一个业务场景我还能不能做出来我的代码在边界条件下会不会崩能把这三个问题想清楚笔试基本就稳了。祝各位都能顺利拿下心仪的offer。