小红书秋招 PE（产品工程师）一面

《面试题目》

1. 请做一下自我介绍。
2. 为什么要做这个项目？要解决的问题在业务中大约占多少比例？
3. 这个比例在你看来算高还是低？为什么？
4. 上线后指标从多少变成了多少？是如何观测的？
5. 技术方案是怎么演进的？过程中为什么做了关键的加法/减法（例如引入或移除某个模块）？
6. 为什么选用当前的核心算法/技术？它的边界与局限在哪里？
7. 能否用多种方法做级联/分层检测？不同层各自解决什么问题？
8. 这个项目里，产品、mentor、你分别扮演什么角色？关键决策由谁拍板？
9. 把问题比例压到极致，对业务意味着什么？你的北极星指标是什么？
10. Redis 为什么快？
11. SDS（简单动态字符串）相比 C 字符串做了哪些优化？
12. 跳表的查找/插入/删除为什么是 O(log n)？Redis 是用什么语言实现的？
13. 如何用 Redis 实现分布式锁？解锁要怎么做？
14. 了解 RocketMQ 或内部 MQ 的架构吗？
15. Kafka 的架构是怎样的？broker、topic、partition、consumer group 之间是什么关系？
16. 你日常开发中如何使用 AI？AI Coding 大致占多少？
17. 什么样的技术方案对 AI 更友好？
18. 项目规约和个人 code style 冲突时怎么处理？团队有没有形成 AI Native 的研发规范？
19. LRU 一般用在哪些场景？你还知道哪些页面置换算法？
20. 能讲一下虚拟内存吗？
21. 手写一个 LRU Cache。为什么必须用双向链表，而不是单链表？
22. 为什么选择本科毕业直接工作，而不是读研？
23. 你怎么看全栈工程师，或者说”产品工程师”这个角色？

《参考解析》

项目类问题按产品口径准备：这类岗位不会只问「你用了什么技术」，而是问「这件事值不值得做」。回答结构建议是：业务问题是什么（谁在痛、痛在哪一步）→ 问题覆盖面怎么量化（日均发生量 / 影响用户数与工单量的占比，口径要说得出来）→ 方案怎么演进（第一版做了什么、为什么后面加或减了某个模块，加减的判断依据是什么）→ 结果怎么观测（指标定义、埋点位置、灰度对照、观测周期，最好有前后对照数字）。北极星指标要选与业务价值直接挂钩的那个，而不是技术侧的过程量。若指标确实是估算的，就直说是估算并给出推算方式，别硬报一个精确数——面试官一追问口径就会露馅。

Redis 为什么快、SDS 与跳表：Redis 快是几条合起来的：纯内存操作、单线程处理命令避免了锁与上下文切换、IO 多路复用（epoll）让一个线程管理大量连接、协议与数据结构都为常见场景做了优化，另外还有精细的编码优化（小对象用 listpack/intset 等紧凑编码省内存与指针跳转）。SDS 相对 C 字符串的改进：头部记录 len 与 alloc，取长度 O(1)；二进制安全，内容里可以有 \0；预分配与惰性释放减少内存重分配次数；拼接前检查容量避免缓冲区溢出。跳表是「多层索引 + 有序链表」，每层以概率 1/4 提升，查找从最高层开始逐层下降，期望层数为 O(log n)，插入删除只需改局部指针且不触发树那样的旋转或再平衡，实现简单、范围查询友好，适合 ZSet 这种需要按 score 排序又频繁增删的场景。

Redis 实现分布式锁：加锁用 SET key value NX PX <ttl> 一条命令完成「不存在才设置 + 过期时间」，value 放一个全局唯一标识（如 UUID + 线程标识），防止误删别人的锁；不要用 SETNX 加 EXPIRE 两步写法，中间崩溃就成了死锁。解锁必须校验持有者并保证原子性，标准做法是 Lua 脚本：先比对 value 是否等于自己，是才 DEL。TTL 是安全兜底，但业务执行时间可能超过 TTL，这时要引入看门狗续期（后台线程按 TTL/3 周期续），续期也要校验锁还是自己的。更严格的场景用 Redlock 或直接上 ZooKeeper / etcd 的临时顺序节点。最后要能说出这套方案的固有局限：主从切换时锁可能丢失，所以对安全性要求极高的场景不能只靠单点 Redis 锁，得配合数据库唯一约束或状态机做最终兜底。

消息队列架构，RocketMQ 与 Kafka 对照讲：Kafka 里 broker 是服务节点，topic 是逻辑消息流，partition 是物理分片也是并行与顺序的单位（同一 partition 内有序，跨 partition 无序），consumer group 是消费分组，组内每个 partition 只被一个消费者消费，以此实现「组内负载均衡、组间广播」；副本机制靠 ISR 与 leader/follower 保证可靠。RocketMQ 的模型类似但组件名不同：NameServer 做路由注册与发现，Broker 分 Master/Slave，topic 下分 MessageQueue，消费组内的消费者按队列做负载均衡；它额外提供事务消息、定时/延迟消息、消息轨迹、顺序消息等更偏业务的能力。选型时把差异落到需求上：吞吐量与堆积能力看 Kafka，事务消息与延迟消息、业务侧可控性看 RocketMQ；延时、顺序、重复消费、消息回溯这几项是常被追问的接口契约细节。

手写 LRU Cache 与双向链表：LRU 的标准实现是哈希表 + 双向链表：哈希表存 key 到链表节点，链表头部是最近使用、尾部是最久未用；get 命中后把节点摘下来插到头部，put 时若 key 存在则更新并提前，不存在则插到头部，容量超了删尾节点并同步删哈希表里的 key，两个操作都要求 O(1)。必须用双向链表是因为删除节点需要 O(1) 拿到它的前驱与后继：单链表只有 next，删除一个已知节点要么从头遍历找前驱（退化成 O(n)），要么用「偷梁换柱」式的删除技巧——但那要求节点本身不被外部持有，和哈希表直接引用节点的用法冲突。手写时注意几个易错点：哨兵头尾节点可以消掉大量边界判断；put 已有 key 时要返回值是否替换；哈希表和链表的删除顺序都要覆盖；扩展追问常见有「实现带过期时间的 LRU」「LFU 怎么设计」「这些页面置换算法的区别」——顺带把 FIFO、Clock、LFU、OPT 的差别准备一句。

AI Native 的研发协作与反问：这类问题没有标准答案，考察的是你有没有形成可复述的方法。可以按「什么样的方案对 AI 友好」来组织：接口边界清晰、单文件职责单一、类型与契约显式、有可运行的测试与文档，AI 才好改也不容易改错；规约与个人风格冲突时，先按团队规约走，确有改进意见就提 PR 讨论，而不是让 AI 生成的风格各自为政。团队层面的 AI Native 规范通常包含：提示词与 Skill 的沉淀位置、AI 生成代码的 Review 与门禁、敏感信息与数据边界、工具与模型选型、以及文档产物在哪个阶段产出。反问环节建议问团队当前的产品指标与角色分工、新人上手路径，别只问「用什么技术栈」。