整体风格

Reddit 的面试整体体验还是挺不错的，面试官普遍比较友好，不会一直给你压力，也不是那种疯狂考算法或者八股的风格。Coding 和 System Design 都特别偏真实业务，很多题目看起来像是工作里真的会遇到的问题。不用急着回答，可以先确认需求、聊聊 trade-off，再一步一步把方案搭起来。

Coding

基本都是业务题，不太像 LeetCode。最近看到的几道 Coding 基本都不是传统 LeetCode，而是一个业务背景，然后不断加需求，看你的代码能不能继续扩展。

Billing Status 就是最典型的一道。第一部分很简单，就是根据 transaction 把每个用户当前的 BillingStatus 算出来。第二部分突然加入 overwrite transaction，原来是累加，现在有些 transaction 要直接覆盖当前金额。第三部分又加入 undo 和 redo，如果前面代码设计得不好，这时候基本就要重写了；如果一开始把 transaction 的处理都放进 BillingStatus 里面，再维护一个 history stack 和 redo stack，其实扩展起来就比较顺。所以这题真正考的不是算法，而是代码结构和可扩展性。

另一道高频题是 Report Chain，也就是公司组织架构。输入 manager 和 employee 的关系，第一步先把整棵树建出来并打印，后面又会让你找 Skip-Level Meeting、查询某个人上下级、找 Lowest Common Manager。其实所有 follow-up 都围绕同一套数据结构展开，所以一开始把 parent map 和 children map 建好，后面很多东西基本就是 DFS。

还有Merge Chat Messages 看起来像聊天系统，其实本质就是 Merge K Sorted Lists。给你一个 API，每次返回某条消息附近几条聊天记录，现在需要把多个查询结果合并、去重、排序，而且不能直接用 set。Follow-up 会问如果消息还能编辑怎么办，这时候可以开始聊 Message Version、Event Log 这些设计，而不是继续写算法。

Moderator System 和 Tennis Game 都更偏 OOD。Moderator 那题主要考怎么维护一个有顺序的数据结构，怎么根据日志恢复状态；Tennis Game 更像状态机，实现几个 API，然后处理 Deuce、Advantage 这些特殊情况。整体都不算特别难，更重要的是类怎么设计、Edge Case 有没有考虑到。

整体来说，Reddit Coding 不会故意出特别难的算法，而是一直往原来的题目上加需求。所以千万不要一开始为了图快，把所有逻辑都写在一个函数里面。代码留好扩展空间，比算法本身更重要。

System Design: 设计游戏排行榜（出现频率最高）

这是目前出现最多的一道题。背景一般都是一家刚成立的游戏公司，需要提供一个后端服务给游戏厂商，支持玩家提交成绩，并查询排行榜和个人历史最高分。面试官通常会直接告诉你，现在用户量很小，是创业公司，希望先做一个能跑起来的 MVP。

这里最重要的一点就是不要 over engineer。一开始直接用一台机器，把 API、业务逻辑和数据库放在一起就够了。先确认需求，例如是否只需要设计后端、排行榜是不是每个游戏一个、除了排行榜是否还要查询个人历史最高分，以及排行榜是不是游戏结束以后立刻返回。确认清楚之后，再设计 API、数据库和整个数据流，把用户提交成绩、更新排行榜、返回结果这一整套流程讲完整。

讲完 MVP 后，面试官几乎一定会开始聊扩容。这个时候不要一下子把 Redis、Kafka、Sharding 全部搬出来，而是一个瓶颈一个瓶颈去解决。数据库读压力大了，就加 Redis 缓存排行榜；查询越来越多，就增加 Read Replica；数据库越来越大，再讨论 Sharding；API 压力增加，再加 Load Balancer 和更多 API Server。每次都解释为什么现在需要做这个优化，而不是一开始就全部设计进去。

这道题还有一个经典 Follow-up，就是某个游戏突然特别火，所有请求都集中到同一个 gameId，出现 Hot Partition。很多人第一反应是把 gameId 分片，但马上就会发现排行榜没法直接查询，因为 Top 10 分散到了多个分片里面。这时候比较好的回答是维护 Redis Sorted Set 保存实时排行榜，数据库负责保存历史成绩；或者每个分片维护自己的 Top 100，再由一个服务把多个分片的 Top 100 合并成最终的 Top 10，这样不用扫描整个数据库，也能够解决热点问题。

另外还有一个比较容易加分的点，就是 Availability over Consistency。排行榜晚更新几百毫秒用户基本感觉不到，但是如果整个排行榜因为数据库挂了打不开，体验就很差，所以这个场景更适合 Eventually Consistent。

System Design: Reddit Home Feed

另一道面经提到的是设计 Reddit 首页 Feed，也就是用户打开 Reddit 后看到的首页内容。

这题重点不是排行榜，而是 Feed 的生成方式。首先需要确认 Feed 是按时间排序还是个性化推荐，是否支持无限下拉、是否需要实时更新、是否包含广告等。小规模阶段完全可以同步查询用户关注的 Subreddit，然后按时间排序返回。

随着用户越来越多，就可以开始讨论 Fan-out on Write 和 Fan-out on Read 的选择。如果关注人数比较少，可以在发帖的时候提前推送到每个用户的 Feed；如果像明星账号一样拥有几千万粉丝，就更适合在用户打开首页的时候动态生成 Feed。这里主要就是分析不同方案在写放大、读延迟以及存储成本上的 Trade-off，而不是一定要给出唯一答案。

System Design: Web Crawler

还有一道出现过的题是设计一个 Web Crawler。用户提交一个网址，系统需要爬完整个网站，把网页保存下来，同时不断发现新的链接，最后通知用户爬取完成。

整体架构比较直接。API 接收用户请求之后，把 Crawl Job 放进消息队列，由多个 Crawler Worker 消费任务。Worker 下载网页、解析 HTML、提取新的 URL，然后继续放回队列，实现 BFS 或 DFS 爬取。最终把网页存到对象存储或者数据库里，并更新任务状态。

这题最容易追问的是失败场景。例如消息队列里的任务丢了怎么办、Worker 爬到一半挂了怎么办、同一个网站如何避免重复爬取、多个 Worker 如何避免重复访问同一个 URL，以及如何保证同一个网站不会被过多 Worker 同时抓取。这些 Follow-up 都比画架构更重要。

面试技巧

Reddit 的 System Design 更像是真实工作的设计讨论，而不是让你画一个特别大的分布式架构。几乎所有题目都会从一个很简单的 MVP 开始，然后不断增加流量、增加用户、增加需求，看你是不是能够自然地把系统一步一步扩展下去。