一句话总结
Lattice的系统设计面试不是考你画架构图的能力，而是考你在资源受限、时间紧迫、信息不全的真实产品环境中，如何做出一个“可执行”的决策。不是看你懂多少分布式系统术语，而是看你能不能在一小时内，把一个模糊的“我们需要改进员工体验”变成“我们要优先做目标对齐模块，因为它在三个月内影响60%的日活”。正确的判断不是“设计一个完美的系统”，而是“设计一个下周就能开始开发的系统”。
适合谁看
- 准备跳槽到Lattice的PM，尤其是从B2C或消费级产品转B2B SaaS的PM——你的用户增长思维在这里不适用
- 在Latticeonsite轮中被系统设计题卡住的候选人——你大概率在“架构”和“需求”之间选了前者
- 想理解SaaS产品经理面试底层逻辑的产品人——不是教你解题，是告诉你面试官真正在判什么
核心内容
为什么Lattice的系统设计面试不同于FAANG？
FAANG的系统设计面试，核心是技术架构：设计一个Instagram feed，设计一个Uber地图。面试官判断的是你的技术深度、可扩展性思维和工程协作能力。Lattice的系统设计面试，核心是产品架构：设计一个员工OKR模块，设计一个绩效对焦流程。面试官判断的是你能否在SaaS产品的约束下——现有代码库、客户定制化需求、销售团队的承诺——做出一个“明天就能写spec”的决策。
一次真实的debrief会议：一位来自Google的候选人，画了完美的微服务架构图，用了事件驱动、CQRS、数据分片，面试官反馈是“他不知道Lattice的客户平均只有200人，不需要分布式系统”。不是A：展示技术广度，而是B：展示产品决策的优先级和权衡。
如何在一小时内完成从模糊需求到可执行Spec的转化？
Lattice的系统设计面试通常是60分钟，分成三块：前15分钟澄清需求，中间30分钟设计系统，最后15分钟讨论取舍。大多数候选人死在第一块：拿到题目就画框架图。
正确做法：前15分钟必须问出至少5个具体问题。不是“用户需求是什么”，而是“这个功能的日活是多少？现有代码库有没有类似的模块？客户的定制化请求占多少比例？销售承诺过什么交付时间？工程团队当前的可信度是多少？”
一个具体场景：面试题是“设计一个员工反馈收集系统”。候选人直接开始画数据库表结构。面试官打断：“为什么不做成现有绩效模块的一个子页面？”候选人愣住了。正确答案：先问“现有绩效模块的月活是多少？员工反馈收集的历史数据是怎么存储的？”——面试官在看你能否识别出“复用”是最优解，而不是“新造一个”。
如何应对面试官故意给出的“糟糕需求”？
Lattice的面试官会故意给出不完整的、矛盾的需求。比如：“客户要求能匿名收集反馈，但经理要求能看到反馈人名字。”这不是bug，是feature。他们要看你能不能识别出这是利益冲突，并给出一个权衡方案。
不是A：直接说“这不可能实现”，而是B：给出一个分阶段方案——第一阶段先做匿名收集，第二阶段通过A/B测试验证经理看到名字是否影响反馈质量。或者：对特定角色（HRBP）开放查看权限，对经理不开放。
另一个真实案例：面试官说“我们需要一个目标对齐功能，但工程资源只有2个后端工程师”。候选人直接说“那做不了”。面试官反问：“那你会怎么跟销售说？”候选人没答上来。正确判断：这不是一个技术问题，是一个资源分配问题。你应该说“我会跟销售对齐，这个功能Q2只能做MVP版本，只支持公司级目标对齐，团队级对齐放到Q3”。面试官要听的是你能不能做trade-off，不是你能不能拒绝。
如何用数据驱动设计决策，而不是靠直觉？
Lattice的面试官特别看重你能否用指标来指导设计。不是“我觉得用户需要这个”，而是“根据现有数据，这个功能的使用率是X，我们的目标是Y，所以我们要做Z”。
一个具体例子：设计“员工成长路径模块”。候选人说“员工需要职业发展功能”。面试官问：“你怎么知道员工需要？数据在哪？”候选人答不上来。正确做法：先问“现有Lattice产品中，员工在绩效模块中查看‘发展计划’页面的平均停留时长是多少？点击率是多少？如果点击率低于10%，说明需求不真实。”面试官会点头，因为你在用产品经理的思维做判断，而不是产品运营。
不是A：从用户故事出发，而是B：从数据指标出发。Lattice的面试官会给你一个假设的数据集，你要用它来验证需求优先级。
如何在系统设计中体现对SaaS商业模型的理解？
Lattice的客户类型多样：从50人的初创公司到5000人的企业。系统设计必须考虑多租户、定制化、定价层级。不是“设计一个统一的系统”，而是“设计一个可以按客户规模定价的系统”。
一个面试题：“设计一个员工绩效对焦系统。”大多数候选人画一个通用架构。但面试官会追问：“企业客户要求能自定义对焦流程，小客户只需要模板。你怎么做？”正确答案：设计一个多租户架构，企业客户用自定义配置表，小客户用预置模板。同时，这个功能必须能通过定价来区分——企业版才支持自定义。面试官在看你能否把产品设计和商业策略结合起来。
不是A：只考虑技术实现，而是B：考虑定价、销售、客户成功。Lattice的系统设计面试本质上是“产品+商业+技术”的三维决策。
如何应对面试结尾的“还有什么问题吗”？
大多数候选人会问“团队文化怎么样”这种无效问题。Lattice的面试官希望你能问出能体现你判断力的问题。正确问题：“如果我入职，前30天我需要优先解决哪个产品的遗留技术债？”“你们当前系统设计中，哪个模块的扩展性最差，为什么？”“客户成功团队最近反馈最多的产品问题是什么？”
这些问题的共同点：不是问面试官感受，而是问具体、可执行、能验证你判断的信息。面试官会从你的问题中判断你是否能快速融入。
准备清单
- 准备一个30分钟的系统设计练习模板，包含：需求澄清（5个问题）、数据指标（3个核心指标）、技术架构（只画关键模块）、商业权衡（定价/销售影响）
- 熟悉Lattice现有产品模块：OKR、绩效、成长、反馈、入职。面试题大概率是基于这些模块的扩展或改进
- 准备至少3个“如果资源砍半，你会怎么调整”的应对方案。面试官一定会在某个环节问资源约束
- 练习用“复用现有模块”代替“新建系统”——Lattice的代码库已经很大，面试官不希望你再加一个服务
- 系统性拆解系统设计面试结构：PM面试手册里有完整的Lattice实战复盘可以参考，包括面试官常问的5个追问方向
- 准备一个“如果客户要求违反产品原则”的案例。比如客户要一个不安全的匿名功能，你怎么拒绝并给出替代方案
- 模拟一次30分钟的debrief，让朋友扮演面试官，专门给出矛盾需求。重点练“先问数据再给方案”的习惯
常见错误
错误1：把系统设计当技术面试，而不是产品面试
BAD：候选人拿到“设计员工反馈系统”后，直接画了一个数据库ER图，用了MySQL、Redis、消息队列。面试官问“为什么用消息队列”，答“为了异步处理”。面试官追问“异步处理解决什么问题”，答“提高响应速度”。面试官再追问“响应速度多少算快”，答不上来。
GOOD：候选人先问“当前反馈收集的提交率是多少？目标是多少？现有系统延迟是多少？”然后说“如果当前提交率低于20%，延迟不是问题，先解决参与度。我们可以用现有邮件通知系统做嵌入表单，不需要新服务。”面试官点头。
错误2：不敢做权衡，试图讨好所有人
BAD：面试官问“客户要求能匿名反馈，但经理要求能看到反馈人。你怎么做？”候选人说“我设计一个权限系统，让HRBP能看到，经理看不到”。面试官问“那经理不乐意怎么办”，候选人说“那让经理也看”。面试官问“那匿名性怎么保证”，候选人说“那经理看的时候隐藏姓名”。面试官问“那你设计的是什么权限系统”，候选人已经混乱。
GOOD：候选人说“这是一个利益冲突。我的方案是：第一阶段只做匿名收集，数据只给HRBP看。第二阶段通过A/B测试验证，如果经理能看到反馈人名字，反馈质量是否下降。如果下降，保持匿名。如果不下降，可以开放权限。”面试官说“那客户坚持要一起上呢”，候选人说“我会跟客户说明，这是一个实验性功能，需要先验证再上线。如果客户拒绝，我宁愿不做，因为它会损害产品核心价值。”
错误3：忽略商业现实，只谈技术
BAD：候选人设计了一个“完美”的员工成长系统，包含AI推荐课程、职业路径图、导师匹配。面试官问“这个系统需要多少工程资源”，答“6个后端，3个前端，1个数据科学家”。面试官问“我们只有2个后端，2个前端”，候选人说“那做不了”。
GOOD：候选人说“基于现有资源，我优先做职业路径图模块，因为它可以用现有OKR数据做基础，只需要一个后端和前端。AI推荐放到Q3，导师匹配放到Q4。同时，这个模块可以做成企业版功能，按客户规模定价。”面试官问“那AI推荐为什么不能现在做”，候选人说“因为需要训练数据，而当前Lattice的课程数据不足以训练一个有效模型。先做路径图可以收集用户行为数据，为AI推荐打基础。”面试官点头。
FAQ
Q1: Lattice系统设计面试有标准题库吗？是固定的还是随机出题？
结论：没有标准题库，但出题逻辑有规律。面试官从三个方向出题：现有产品模块的扩展（如改进绩效模块）、新功能设计（如员工成长系统）、流程优化（如减少经理的行政负担）。所有题目都围绕“员工体验”这个核心。你不需要背题库，但需要理解Lattice的产品逻辑。一个真实案例：面试官出的题是“设计一个员工入职的OKR对齐系统”，这直接关联Lattice的产品路线图。如果你提前研究过Lattice的博客和产品更新，就能猜到题目方向。
Q2: 系统设计面试中，画架构图重要还是讲产品逻辑重要？
结论：产品逻辑占70%，架构图占30%。面试官更关心你能否解释“为什么这样设计”，而不是“画得多漂亮”。一位面试官在debrief上说过：“我见过候选人画了完美的AWS架构，但他解释不了为什么用SQS而不是Kafka。那没用。”正确做法：先讲产品逻辑——需求、用户、指标、权衡——再画一个简单的架构图，只画关键模块。不要画超过5个服务，否则会被追问细节。
Q3: 如果面试官反驳我的设计，我该怎么办？
结论：不是反驳，是测试。面试官故意提出反对意见，看你能不能在压力下调整方案。正确做法：先承认“这个观点有道理”，然后给出一个基于数据的回应。比如面试官说“你的设计太简单了”，你可以说“基于我假设的数据，简单方案就能满足80%的需求。但如果你有数据证明20%的客户需要复杂功能，我可以在下个版本加入动态配置模块。”不要争辩，不要立刻改方案，而是展示你的思考过程。一个真实案例：候选人被反驳后直接说“你说得对，我改”，面试官反而认为他没有自信。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。