适合人群：目标偏推荐、搜索、后端、基础 infra 和内容平台方向，想弄清小红书为什么总容易被准备偏的同学
很多人准备小红书，最容易先犯一个判断错误：
把它想成“又一家互联网大厂”。
然后再进一步，把它想成“也能按纯 C++ 或纯后端主线去准备”。
这两个理解都不太准。
因为小红书真正有辨识度的地方，不是某一门语言本身。
而是它很多技术问题天然会带着：
推荐
搜索
内容生态
缓存
性能优化
这些场景。
你当然也会遇到：
链表
滑动窗口
LRU基础数据结构
但如果你把小红书完全准备成“又一家刷这些题的公司”，后面大概率还是会偏。
因为小红书真正筛的，不只是基础题本身。
而是你能不能把基础题放进推荐、搜索和性能语境里去讲。
这篇就把这条线拆开。
校招大礼包获取：入口
可能是至今最全，最好，最实用的校招大礼包，减少信息差，预期漫步无敌的刷提，不如有的放矢，针对性的准备，这样才能有效备考，有了这份资料，不说100%拿到offer，至少帮你提升50%概率拿到offer
小红书到底在筛什么
1. 它不是纯 C++ 主场
这句话必须先说清。
因为如果不讲边界，后面很容易写偏。
从现有资料看，小红书更像下面这种结构：
后端主场更偏 Go
推荐 / 搜索 / 基础 infra 会更看算法、性能和系统优化
C++ 更多是算法和工程能力的一部分
也就是说，小红书当然有很多适合按 C++ 口径准备的题型。
但它并不适合被理解成“纯 C++ 公司”。
2. 它很看内容平台语境
小红书和很多公司很不一样的一点是：
它的问题很容易带着内容平台特征。
比如：
推荐缓存
已读过滤
内容分发
搜索召回
新内容和老内容怎么平衡
这意味着很多看起来普通的题，一到小红书，就会被追进业务语境。
3. 它很看性能和工程表达
小红书这条线很容易从：
滑动窗口
链表
LRU
这些题切进去。
但真正有区分度的地方，经常在后面：
为什么性能在这里很重要
缓存为什么这么设计
这题和推荐 / 搜索到底怎么接上
小红书最常见的 4 条追问链
1. 滑动窗口和字符串追问链
这是小红书很有辨识度的一条线。
常见入口是：
无重复字符的最长子串
滑动窗口最大值
最小覆盖子串
后面常见会继续追：
左右指针什么时候动
状态怎么维护
为什么复杂度能降下来
这条链背后看的，是你对状态维护和性能是不是清楚。
2. 链表和基础题追问链
小红书当然也看基础题：
反转链表
合并链表
环形链表
第 K 大元素
这条链背后看的，是你代码是不是足够稳。
但和字节那种高压写题不同，小红书更像在用这些题确认你有没有稳定基本功。
3. 缓存和推荐场景追问链
这条线很小红书。
常见会追到：
LRU推荐缓存
布隆过滤器
已读过滤
这条链背后看的，是你能不能把数据结构放进真实推荐场景。
4. Go 和性能优化追问链
如果你投后端或基础 infra，这条线很难绕开。
后面很容易继续追：
切片
map并发安全
runtime
性能问题怎么查
这条链说明，小红书不是一条只靠 C++ 或只靠算法就能打穿的线。
准备小红书，最容易错的 3 件事
误区 1：把小红书准备成纯 C++ 公司
这会直接把很多时间放错地方。
尤其如果你投的是后端或基础设施，Go 的存在感不能假装不存在。
误区 2：只刷基础题，不补推荐和搜索语境
你当然要会链表和滑动窗口。
但如果完全不会把这些题往推荐、搜索、缓存和性能上讲，小红书这条线会显得很平。
误区 3：把线索题写成完整题库思维
小红书现有资料更适合做：
题型判断
岗位判断
场景化准备
而不是假装有一套完全独立成熟的 C++ 题库体系。
如果只剩两周，小红书该怎么补
第 1 段：先把滑动窗口和链表打稳
优先过：
无重复字符的最长子串
滑动窗口最大值
反转链表
合并链表
第 K 大元素
第 2 段：补缓存和推荐场景
至少把下面这些讲顺：
LRU推荐缓存
已读过滤
布隆过滤器
第 3 段：按岗位补 Go 或推荐方向
如果你投后端：
Go runtime
map/ 切片并发安全
如果你投推荐 / 搜索：
检索和排序基础
多样性和内容生态
缓存和性能问题
小红书真正筛的，不是单一语言能力
而是你能不能把基础题、推荐 / 搜索语境和性能优化感一起站住。
所以准备小红书，最稳的打法不是把它当纯 C++ 公司。
而是把基础题稳定性、推荐搜索场景、缓存和性能表达、岗位主语言这四条线一起补起来。
)