尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

小红书校招技术笔试全解析:从算法到业务场景的备考指南

小红书校招技术笔试全解析:从算法到业务场景的备考指南 每年秋招季技术岗在线笔试都是第一道大坎。小红书2019年校园招聘技术类在线笔试第二批我陪过好几届学弟学妹复盘也帮身边人整理过真题思路。今天把这场笔试从流程到考点、从环境准备到答题技巧掰开揉碎讲一遍。如果你正在准备类似的内容社区型公司笔试这篇可以直接当参考手册用。先说结论小红书这批笔试在同类互联网公司里不算难但非常“偏业务”。算法题不会上来就甩一道hard压你更多是考察你能否用常见的算法模型解决社区产品里的真实问题比如图片去重、文本审核、推荐排序、视频抽帧甚至反爬虫策略。所以光刷LeetCode还不够得学会把数据结构、分布式、网络协议这些底层能力翻译成“小红书场景下的解决方案”。1. 笔试全流程与环境准备1.1 在线笔试的整体安排小红书技术类在线笔试第二批通常是在牛客网或赛码网这类第三方平台完成全程开启摄像头和屏幕录制。整场笔试差不多120分钟题型分为三块单选/多选题、编程题、业务场景问答。前两块是机判第三块由人工review所以别指望只把代码跑通就万事大吉方案设计能力同样是筛人利器。笔试前会收到一封邮件或短信里面包含考试链接、账号密码、试考链接和注意事项。这里有个特别容易忽略的细节一定要提前24小时做“试考”。试考不只是测试摄像头和麦克风更重要的是看清考试禁用项——有的平台会检测切屏次数一旦超过三次直接判作弊。我认识不止一个同学代码能力没问题结果因为电脑弹了个微信通知被记了一次切屏最后心态崩了。考试当天建议提前30分钟进到安静的房间把手机放到另一个房间或交给家人桌上只留身份证、草稿纸、笔、水、纸巾。身份证不是必须但建议备着部分监考会让你展示一下。电脑最好用电源供电别指望电池扛两个钟头。浏览器方面Chrome和Firefox兼容性最好IE就别用了很容易白屏。1.2 平台操作与代码调试技巧在线笔试平台和本地IDE差别很大。比如牛客网做题时代码是从头到尾手写不支持自动补全也不支持跳转到函数定义。如果你平时用惯了PyCharm或VS Code建议在笔试前一周就开始适应平台上的裸写环境。我的做法是先在本地IDE把思路和关键代码写一遍再复制到纯文本编辑器里看能不能一眼读通。还有一点写代码时尽量用标准库。笔试平台通常会标明支持的语言版本比如C14、Python3、Java8。但要注意有些平台的Python没有numpyC也没有Boost。也就是说你没法import numpy的时候自己实现矩阵运算或者用bits/stdc.h时可能编译不过。提前在试考链接里跑一个“hello world”把输入输出样例测试一遍能排除80%的意外。代码调试环节最容易踩坑的是输入输出格式。很多同学在本地测试没问题提交后却是0分十有八九是没处理多行输入或输出多了空格。笔试平台的判题是严格字符匹配哪怕多一个换行都可能判错。写代码时养成一个习惯int n; cin n; 先读数量再读数组输出时用cout ans endl;。如果题目要求输出浮点数一定要看清保留几位小数有的题是“四舍五入”有的是“直接截断”审题时圈出来。2. 核心考点拆解从算法到业务场景2.1 算法与数据结构的高频考察点根据多批笔试的反馈小红书技术类笔试的算法题主要集中在数组与哈希表、字符串处理、二叉树遍历、DFS/BFS、动态规划、贪心、二分查找。链表单独出现的次数不多但偶有涉及。难度大概是LeetCode Medium偶尔有一道Hard压轴。有个很有意思的现象小红书特别喜欢出“字符串相关”的题目。这和内容社区的业务是强相关的——笔记、评论、标签、搜索词全都是字符串。常见题目包括判断回文子串、字符串去重、敏感词过滤的简化版、正则表达式匹配。比如有一道很经典的题“给定一个字符串找出包含所有元音字母的最短子串”本质上就是滑动窗口位掩码但套上了文本处理的壳。二分的考法也不是直接说“在有序数组中查找”而是包装成“标记为内容质量分找出满足发布审核条件的最少时间”这类场景。所以我建议刷题时多积累“业务化包装”的敏感度看到“最短”“最大”“最少”优先想二分和动态规划看到“所有区间”想扫描线看到“前K个”想堆。做到这一步笔试时看到题就不会慌。2.2 计算机基础知多少除了算法选择题里还有一部分是计算机基础覆盖网络、操作系统、数据库、Linux命令。小红书毕竟是内容平台网络问题考得很务实HTTP和HTTPS的区别、TCP三次握手、DNS解析过程、CDN加速原理、HTTP状态码含义。印象最深的是有一道题问“用户上传视频后后台进行转码和抽帧应该用HTTP的什么方法”答案是POST但很多人选了PUT。操作系统主要考进程与线程、死锁条件、内存管理。数据库方面索引失效场景、事务隔离级别、SQL语句优化几乎必考。Linux题目就是给一个场景问用什么命令比如“查看当前端口被哪个进程占用”答案netstat -tunlp或lsof -i。如果你之前没系统准备过建议找一份“互联网公司校招计算机基础题汇总”把高频题背一遍性价比很高。这里有一个容易被忽略的点选择题是倒扣分吗在线笔试通常是不定项选多选、漏选、错选都不得分甚至扣分但小红书这批好像没倒扣只算正确得分。不过保险起见拿不准的选项宁可不选因为少选还能拿0.5分或部分分多选就只能拿0分。当然这是基于多数平台规则的补充具体以当年的考前说明为准。2.3 业务场景题小红书味的技术考卷业务场景题是这批笔试的特色题目本身不限定标准答案考察的是你的系统设计思维。简单说就是我们常说的“设计一个XX系统”。但背景都换成小红书业务比如如何设计一个笔记/视频去重系统如何实现图片的快速压缩和格式转换如何设计热搜榜要求实时更新且并发量大如何对用户发布的文本做敏感词过滤如何检测异常爬虫流量这类题的答题思路要套“需求分析 - 架构选型 - 核心流程 - 细节优化 - 扩展性”的框架。比如图片去重很多人第一反应“转成base64比较”这就是典型的缺乏工程视角。正确思路应该分两步先用感知哈希pHash或颜色分布直方图做粗筛再用尺度不变特征转换SIFT或深度学习特征做精排。同时要说明存储方案比如用Redis作为哈希索引缓存MySQL存图片元信息OSS存原图。最后再补一句“如果单台机器性能不够可以引入分布式计算框架比如MapReduce或Spark”。我在帮同学复盘时发现大部分人只会答“用xx算法”但说不清“数据存哪”“处理链路是什么”“挂了怎么办”。所以准备业务场景题时关键是反复练习“从0到1画出一个系统的技术架构”。3. 典型题目精讲与代码实现3.1 编程题基于用户行为的签到打卡先看一道典型的数组哈希表题。题目大致是给定一个整数数组代表用户连续N天的活跃次数要求找出最长的连续天数且每天的活跃次数单调不减并输出这个长度。这道题其实是个变形的“最长连续递增子序列”解法很简单遍历一次维护当前连续不减长度cur和最大值maxLen。遇到不满足时重置cur1。核心代码如下def max_continuous_days(arr): if not arr: return 0 max_len 1 cur_len 1 for i in range(1, len(arr)): if arr[i] arr[i-1]: cur_len 1 max_len max(max_len, cur_len) else: cur_len 1 return max_len这道题考察的点不是算法本身而是边界条件。笔试结束后很多人对答案说“我用了动态规划怎么超时了”其实题目数据量不大O(n)遍历就够了动态规划反而白费空间。踩过的坑如果数组只有一个元素要返回1而不是0如果全部相等也要返回n而不是1如果数组是空照理说返回0但题目可能会保证非空最好写上防御性判断。3.2 编程题字符串转驼峰还有一道字符串处理题给定一个下划线命名的字符串转成驼峰命名法要求首字母小写后续单词首字母大写。比如“user_name_info”变成“userNameInfo”。def to_camel(s): parts s.split(_) res parts[0] for part in parts[1:]: if part: res part[0].upper() part[1:] return res这道题本身没难度但坑点在于字符串可能包含连续下划线比如“user__name”split后会多出空字符串需要跳过还可能出现首字母本来就是大写的情况要不要保持题目如果没说默认按规则转。所以代码里用if part判断一下最稳妥。这题考察的是代码的健壮性。真实业务中后端接口字段经常要转驼峰给前端转换函数如果没处理好连续分隔符、空字符串线上就会出bug。笔试出这种题就是想看候选人有没有防御式编程意识。3.3 编程题视频播放量Top K压轴题往往是稍微复杂一点的数据处理。比如给定一个日志文件每行是“视频ID 用户ID 播放时长秒”要求输出播放量最高的K个视频ID播放次数相同按视频ID升序排列。这道题有两个关键点先去重统计播放量再求Top K。如果数据量不大直接统计后用sorted排序如果数据量大就要用堆。import heapq from collections import Counter def top_k_videos(logs, k): counter Counter() for video_id, user_id, _ in logs: counter[video_id] 1 # 使用最小堆堆内保存播放量前k个 heap [] for vid, cnt in counter.items(): if len(heap) k: heapq.heappush(heap, (cnt, vid)) else: if cnt heap[0][0] or (cnt heap[0][0] and vid heap[0][1]): heapq.heappushpop(heap, (cnt, vid)) res sorted(heap, keylambda x: (-x[0], x[1])) return [vid for cnt, vid in res]注意排序规则播放次数降序ID升序。用堆时堆顶是最小的播放次数当计数相同且ID小于堆顶ID时也替换。这里有个细节counter[video_id] 1这一行如果用字典手动统计需要考虑key不存在用Counter确实简洁但如果平台不支持collections模块就得自己写了。所以平时练习不要只会调包底层逻辑也要能默写。这道题如果能顺利跑通说明哈希表、排序、堆这三大件已经掌握扎实了。实际业务中热门视频榜、热门笔记榜都是类似的TopK问题只是数据量更大需要结合分桶、滑动窗口和Redis ZSET来做笔试考的是基础版。3.4 业务设计题如何设计图片去重系统除编程题外业务题也需要给出清晰答案。我建议按以下模板写亲测有效第一步限定范围。说明去重的粒度是“完全相同”还是“视觉相似”。小红书场景下盗图、抄袭通常需要“视觉相似”所以不能只做MD5。第二步整体流程。用户上传图片 - 图片预处理 - 特征提取 - 哈希索引 - 精确匹配 - 返回结果。第三步特征提取方案。可以用pHash计算得到64位哈希值汉明距离小于阈值认为是相似图。但pHash对旋转、缩放、滤镜的鲁棒性有限所以生产环境要配合深度学习模型比如用ResNet提取特征向量再存入向量数据库。第四步存储架构。特征片段可以用Redis的BitMap或布隆过滤器加速粗筛候选集再去向量库比对精确距离。原图存OSS元数据存MySQL或MongoDB。第五步分布式扩展。如果每天上传几千万张图单机无法完成哈希比对需要引入消息队列削峰用Spark/Flink做分布式特征提取再用Faiss或Milvus做向量检索。最后补一句容灾设计特征索引至少三副本Redis宕机时降级到全表比对不影响新用户上传。这样一套答下来即使没有真正做过图片系统面试官也能看出你有完整的技术视野。4. 在线笔试避坑指南与实战经验4.1 环境与网络问题的应急预案最心疼的一种挂法是做到一半断网。在线笔试一旦断网超过一定时长考试可能直接被提交你根本来不及重连。考试前建议把路由器重启一遍关掉所有后台下载、视频播放甚至让室友暂时不要用网。有条件的话手机开热点作为备用但别直接用热点考试因为网速不稳。另外Windows系统容易在后台触发更新考试前最好把Windows Update暂停几天Mac系统则关掉自动更新时间。如果你真的中途断网立刻尝试重连然后看考试页面是否还能进入。多数平台支持断线重连但计时不会暂停。所以时间允许的话先不停刷新等网络恢复后再继续。千万不要疯狂截图否则会被记录异常操作反而更糟。4.2 时间分配与答题策略整场120分钟我的建议分配是选择题25分钟编程题60分钟业务设计题35分钟。选择题别恋战一眼看不出答案就在草稿纸上标记赶紧跳下一题。编程题第一道通常送分10分钟内搞定第二道中等难度25分钟第三道如果没思路先跳过做完后面的再回头啃。业务设计题至少留30分钟因为要写字打字慢的同学更要注意。很多同学有个误区编程题没过case就反复调试最后没时间做业务设计题。实际上编程题过了部分case可能拿一半分而业务设计题只要写了架构框架也能拿不少分。笔试不是竞赛分分必争。所以遇到编程题卡壳超过20分钟建议先转去做业务题回头再补代码。4.3 心态崩了怎么办在线笔试和线下不一样旁边没有同伴只有摄像头对着你。遇到不会的题人会格外焦虑。我的建议是提前准备一个“冷静清单”贴在屏幕边先深呼吸打开本地IDE写一个小测试函数调试一下或者把题目的输入输出样例在草稿纸上抄一遍。这样能快速把注意力拉回题目本身而不是陷入“我完了”的情绪里。还有一个很实用的小技巧笔试过程中一旦做完一题立刻按CtrlS保存不要等最后统交。虽然大多数平台会定时自动保存但手动保存能让你安心尤其是输入输出比较长的题。4.4 关于摄像头和监考摄像头会在考试开始时拍照考试过程中随机抓拍。如果系统检测到你长时间低头可能会触发警告。所以做题时尽量看屏幕草稿纸放屏幕下方抬头低头幅度不要太大。不需要紧张监考一般不是真人实时盯着主要是AI辅助识别。但千万别抱有侥幸心理百度查答案、切后台、拿手机拍题一旦被系统捕获直接标记作弊连申诉机会都没有。5. 笔试复盘与后续准备建议5.1 笔试后多久出结果怎么跟进小红书技术类笔试批次出结果的时间不固定快的三五天慢的两三周。期间看到状态变成“面试中”或“已通过”就可以准备下一轮了。如果状态一直是“笔试中”也不用太焦虑因为分批组织的话可能要等同一批全考完才统一出结果。这几天建议做三件事第一把自己笔试时没做出来的题重新写一遍整理到自己的题库里第二梳理一份“项目经历技术栈”的故事线为面试做准备第三把高频面试题过一遍尤其是计算机网络、数据库索引、Redis数据结构、消息队列、分布式缓存。因为这些正是业务面最常问的点。5.2 延伸笔试背后的技术能力图谱从这批笔试能看出来小红书这类内容社区对技术的核心需求集中在三个方向一是海量内容处理包括文本、图片、视频的解析与去重二是实时推荐系统涉及用户行为日志、特征工程、排序模型三是安全与风控包括内容安全、反垃圾、反爬虫。所以如果你时间充裕可以针对这三个方向分别准备一个小项目。比如做一个简单的图片感知哈希去重demo或者用公开数据集训练一个文本审核模型又或者写个分布式爬虫框架注意遵守robots协议和法律法规。这类项目写在简历上会比单纯的算法题更有竞争力。5.3 一个容易被忽视的加分项笔试中的业务设计题写了“容灾”“限流”“降级”这些词会明显加分。即使题目没明确问也要在架构描述最后加一句“如果服务出现雪崩我会用Redis做限流用降级开关保护核心链路”。这体现了工程思维面试官看到会很认同。还有一个加分点是“权衡”。比如设计图片去重系统时主动说“pHash速度快但准确率低深度学习准确率高但成本高所以在实际中会采用级联策略”。这种trade-off思考是资深工程师和校招生最大的区别。写在最后说句实在话小红书这批笔试的题目本身不难但非常考验“把书上学的东西落到业务场景”的能力。我见过不少同学LeetCode刷了三百道却在业务设计题上写得稀碎最后遗憾止步。反过来那些代码能力中上、但能用通俗语言把架构讲清楚的同学反而顺利通过。如果你正在准备类似的内容社区校招笔试不妨把重心从“刷题量”转移到“场景化思考”上多问自己一句这个算法在真实产品里用在哪系统会面临什么问题这样做你通过笔试的概率会大很多。最后再分享一个小技巧平时刷题时每道题写完顺手在注释里写一句“本题可以应用于XX场景”。这个习惯会逼迫你把算法和业务建立连接考场上看到包装过后的题目也能一秒拆穿本质。祝各位笔试顺利早些拿下心仪的offer。
返回列表