Notion软件工程师面试怎么准备
一句话总结
Notion的软件工程师面试不是考察你刷了多少LeetCode，而是判断你是否能在没有明确需求的情况下推动产品演进。大多数人把准备重点放在算法题上，结果在系统设计和行为面试中被淘汰。正确的判断是：Notion要的不是编码机器，而是能用工程思维定义问题的产品型工程师。
你之前可能以为，只要把二叉树和动态规划练熟，就能通过技术轮。但现实是，一个在LC上刷了800题的候选人，因无法解释“为什么选择IndexedDB而不是LocalStorage”被拒。
另一个只刷300题的人，因在设计文档中清晰对比了CRDT与OT同步机制的权衡，被 Hiring Committee 主动加录一轮。这说明，Notion的筛选逻辑根本不在“题量”，而在“工程决策的清晰度”。
更关键的是，Notion的面试流程中，行为面试和技术面试同样重要——不是简单问“你遇到过什么冲突”，而是通过你如何描述技术取舍，来判断你是否具备跨职能协作的底层思维。你不需要背诵标准答案，但必须能还原真实的技术决策现场。你之前想的“准备面经模板”大概率是错的，真正有效的是重构你过去项目中的决策链条。
适合谁看
这篇文章适合三类人：一是有2-5年经验、正在从执行层向独立 contributor 过渡的工程师；二是目标进入产品驱动型公司的中级开发者；三是已经面过Notion但失败，且困惑于“明明题都做出来了，为什么没过”的候选人。
如果你属于第一类，你可能正卡在“能完成任务，但说不清为什么选这个技术方案”的阶段。比如你在前公司做过一个文档协作功能，但面试时被问“为什么用WebSocket而不是轮询”，你只能回答“因为实时性好”，却无法量化延迟差异或带宽成本，这就暴露了工程思维的断层。
如果你是第二类人，你可能误以为Notion这类公司只看重产品感，于是花大量时间研究Figma或Linear的交互细节，却忽略了工程实现背后的技术权衡。但现实是，Notion的产品感不是UI层面的，而是体现在数据模型和同步机制的设计上。你研究再多动效，不如搞懂一次CRDT的merge冲突如何解决。
至于第三类失败者，你们的问题往往出在“答案正确但逻辑不透明”。比如在系统设计轮中，你设计了一个笔记系统，用了S3+DynamoDB+Lambda，架构图也画得漂亮。
但当面试官问“为什么不用PostgreSQL的JSONB字段”，你回答“因为NoSQL扩展性好”，却说不出具体QPS阈值或垂直扩展瓶颈，这就让面试官怀疑你只是套模板。这篇文章将帮你识别这些隐性雷区。
Notion的工程师到底要解决什么问题？
Notion的软件工程师不是在实现产品经理给的需求文档，而是在参与定义“这个功能到底应该长什么样”。这不是简单的“开发+沟通”，而是“用代码探索产品边界”。大多数候选人误以为Notion是工具类产品，因此技术挑战主要是前端复杂度。
但真实情况是，Notion的核心难题是数据一致性与协作编辑的工程实现。你看到的“一个页面可以同时被10个人编辑”，背后是CRDT（Conflict-Free Replicated Data Type）的落地，而不是简单的WebSocket广播。
在一次内部 debrief 会议中，一位候选人在设计“多设备同步”时，直接跳到了技术选型：“我用Firebase Realtime Database，因为它支持离线同步。” 面试官追问：“如果两个用户同时修改同一个文本块，Firebase怎么解决冲突？” 候选人答：“它自动 merge。” 面试官再问：“怎么 merge？
是最后写入优先，还是时间戳优先？” 候选人卡住。最终 debrief 时，Hiring Manager 说：“他把同步当成黑盒，这不是Notion要的人。我们招的是能拆解‘自动’背后机制的人。”
另一个案例发生在 hiring committee 讨论中。候选人设计了一个block级权限系统，提出用RBAC（基于角色的访问控制）。但当被问“如果一个block被移动到另一个page，权限如何继承”时，他回答“跟随父page”。面试官追问：“如果原page和目标page的权限模型不一致呢？
比如一个是公开，一个是私有？” 候选人说“弹窗提示用户调整”。委员会成员立刻指出：“这不是工程解决方案，是产品逃避。Notion要求工程师提前预判这种边界，并在设计阶段就定义数据模型的继承规则。”
这揭示了一个本质：Notion的工程师必须同时是数据建模者和产品逻辑的构建者。你不是在实现“权限”这个功能，而是在定义“权限在嵌套结构中的语义”。因此，准备Notion面试，不是准备“如何设计一个社交网络”，而是训练自己在模糊需求下，用工程手段明确产品规则。不是“我能写代码”，而是“我能让系统在无人干预下做出正确决策”。
技术面试轮次到底在考什么？
Notion的技术面试共四轮，每轮60分钟，全部为真人面试。第一轮是算法与数据结构，但重点不是题号或难度，而是你如何解释代码背后的权衡。比如你用HashMap解决Two Sum，面试官会问：“如果数据量超过内存怎么办？
” 如果你只回答“用disk-based hash”，而没提Bloom Filter或外部排序的trade-off，分数会立刻下降。真实案例是，一位候选人用Trie解决“自动补全”，面试官追问：“Trie的空间复杂度是O(ALPHABET * N)，如果支持多语言，ALPHABET会暴涨，怎么办？” 候选人提出压缩Trie和分片存储，还对比了与倒排索引的查询延迟，最终这轮拿到Strong Hire。
第二轮是系统设计，考察点不是架构图的美观度，而是你如何定义“成功指标”。比如设计“文件上传系统”，大多数人从S3、CDN、分片上传讲起。但Notion面试官会先问：“你定义的‘上传成功’是什么？是文件写入磁盘，还是用户能在页面中引用它？
” 一位候选人回答：“上传成功是文件可被block引用，且元数据已写入数据库。” 他接着说明，这要求事务性写入——先写元数据，再传文件，失败时用Saga模式回滚。这种从“成功语义”反推架构的设计思路，是Strong Hire的关键。
第三轮是工程设计（Engineering Design），这是Notion独有的轮次，常被候选人误认为是“写代码的系统设计”。实际上，这一轮的核心是技术选型的推理过程。比如题目是“实现Notion页面的版本历史”。
你不仅要画架构，还要对比Git-style snapshot与delta-based log的存储成本、恢复速度和冲突处理。一位候选人提出用WAL（Write-Ahead Logging）+ periodic snapshot，还计算了每天10万次编辑下，纯delta存储一年需1.2TB，而snapshot+delta可压缩到300GB。这种量化推理直接说服了面试官。
第四轮是行为面试（Behavioral），但不是听你讲故事。面试官会用STAR法则追问细节，重点是“你在技术决策中扮演的角色”。比如你说“我们优化了加载速度”，面试官会问：“你如何确定瓶颈在数据库查询而不是前端渲染？
” 如果你回答“用Chrome DevTools分析”，这是基础。但如果加上“我们对比了SSR与CSR的首屏时间，发现数据库序列化占70% CPU”，这才体现深度。Notion要的是能用数据驱动技术决策的人，而不是执行命令的工程师。
如何准备系统设计中的“产品感”？
在Notion的系统设计中，“产品感”不是指你会画原型或懂用户体验，而是你能否从用户行为反推数据模型。大多数候选人准备系统设计时，只关注“如何支撑百万并发”，却忽略了“用户真正需要什么”。比如设计“搜索功能”，90%的人从倒排索引、ElasticSearch、分词器讲起。
但Notion面试官更关心：“用户搜索时，是在找内容，还是找上下文？” 一位候选人在 debrief 中被称赞，因为他提出搜索应支持“在某个workspace内搜”，并设计了一个multi-tenant aware的索引路由层，将查询按workspace_id分片。这不仅解决了性能问题，还预判了企业客户的数据隔离需求。
另一个关键点是默认行为的设计。比如“分享页面”功能，大多数人设计一个share link生成器，设置public/private权限。但Notion的真实挑战是“默认权限该是什么？
” 在一次内部讨论中，Hiring Manager 提出：“如果用户误点分享，内容泄露，责任在产品还是工程？” 因此，优秀候选人会主动提出“默认私有，且首次分享时弹出风险提示”，甚至设计一个“分享审计日志”，记录谁在何时分享了什么。这显示你理解工程决策对产品责任的影响。
再比如“模板市场”设计。候选人常聚焦在“如何上传模板、如何分类”。但Notion更关注“模板如何不破坏数据一致性”。一位候选人提出，模板实例化时，必须深拷贝所有block，避免引用原模板的动态内容。他还设计了一个“模板版本冻结”机制——一旦被使用，模板结构锁定，防止上游修改导致下游页面错乱。这种对“副作用”的预判，是普通候选人不会触及的。
因此，准备系统设计时，不要只练Grokking the System Design Interview里的题目。而是要问自己：这个功能上线后，用户最可能误操作什么？数据模型在哪种边界会崩？你不是在设计一个“能用”的系统，而是在设计一个“难用错”的系统。不是“功能完整”，而是“容错优先”。
工程文化如何影响面试判断？
Notion的工程文化不是“快速迭代”，而是“长期可维护性优先”。这直接影响面试中的评分标准。在一次 hiring committee 会议中，候选人设计了一个实时通知系统，用Redis Pub/Sub实现。技术上可行，但委员会质疑：“Pub/Sub是at-most-once delivery，如果用户离线，消息就丢了。
你们怎么保证通知不丢失？” 候选人回答：“客户端轮询补漏。” 委员会认为这不可接受——Notion要求工程方案从第一天就保证语义正确，而不是靠补丁堆砌。
这反映了一个核心原则：不是“能跑就行”，而是“设计即契约”。比如数据库事务，Notion工程师必须明确每个操作的ACID属性。在面试中，如果你说“我们用MongoDB，因为它灵活”，却说不清“文档更新时如何保证原子性”，就会被质疑。
一位候选人处理“事务性block移动”时，提出用两阶段提交：先标记block为“移动中”，再更新parent_id，最后清除标记。他还设计了一个recovery job，扫描标记超时的block进行回滚。这种对一致性的执着，正是Notion文化的体现。
另一个文化特征是文档驱动决策。Notion内部所有重大技术变更都必须有RFC（Request for Comments）文档。因此，面试中你如何解释设计，比设计本身更重要。
比如你选择用gRPC而不是REST，不能只说“性能好”，而要写出对比表格：gRPC的protobuf序列化比JSON快40%，连接复用降低TCP开销，但调试成本高，需配套工具链。这种结构化表达，是Notion工程师的日常。
薪资方面，Notion软件工程师的总包具有竞争力：Base $180K，RSU $200K（分4年归属），Bonus 15%。高级工程师Base可达$220K，RSU $300K以上。但高薪对应高要求——你必须证明自己能在模糊中建立秩序，而不是等待明确指令。
准备清单
- 深入理解CRDT与OT（Operational Transformation）的差异，特别是它们在文本同步中的冲突解决机制。你能画出两个用户同时插入字符时，CRDT如何通过vector clock或dot model resolve冲突吗？
- 练习从用户场景反推数据模型。例如，“拖拽排序”功能，背后是pos字段的浮点数设计还是linked list结构？你能比较两者的插入、移动、一致性的trade-off吗？
- 掌握至少一个复杂前端状态管理案例，如富文本编辑器的selection同步、undo/redo的merge逻辑。Notion不用Redux，但你需要理解如何用immer或proxy实现不可变更新。
- 准备3个真实项目，每个项目都能回答：“你如何定义这个功能的成功指标？”“你如何量化技术决策的影响？”“如果重来一次，你会改变什么？” 数据越具体越好，比如“QPS从1.2k提升到4.8k，P99延迟从800ms降到180ms”。
- 系统性拆解面试结构（PM面试手册里有完整的系统设计实战复盘可以参考），特别是如何将产品需求转化为工程约束。
- 模拟debrie会议：找同行扮演面试官，追问你的设计决策，直到你无法回答。记录哪些问题暴露了你的知识盲区。
- 精读Notion API文档和公开技术博客，理解他们如何暴露block、page、workspace的抽象。你能推测出他们的GraphQL schema设计吗？
常见错误
错误一：只讲技术，不讲权衡
BAD：在设计“图片上传”时说：“我用S3存储，CloudFront CDN加速，Lambda处理缩略图。” 这只是工具堆砌，没有决策。
GOOD：应先定义需求：“用户期望上传后3秒内可预览。” 然后分析：“S3最终一致性可能导致延迟，因此用Lambda触发后，先生成base64 placeholder，再异步处理。缩略图用WebP格式，节省40%带宽，但兼容性差，故降级用JPEG。” 这种从目标到方案再到fallback的推理，才是Notion要的。
错误二：忽视数据一致性语义
BAD：设计“评论功能”时说：“用DynamoDB，分区键是post_id，排序键是timestamp。” 但没提“如何防止重复提交”或“删除评论后，关联的notification如何处理”。
GOOD：应说明：“提交评论时用DynamoDB的Condition Expression防止重复；删除时，用SNS广播事件，由notification service异步清除。若清除失败，有daily job修复。” 这显示你考虑了全链路一致性。
错误三：行为面试变成自我表扬
BAD：回答“最大挑战”时说：“我带领团队3个月上线了新功能，用户增长50%。” 这是结果描述，不是过程。
GOOD：应说：“挑战是数据库锁竞争导致超时。我用Perfetto分析发现是高频counter更新。改为redis incr + batch flush到DB，QPS从200提升到5000。” 用工具、数据、具体技术动作展示能力。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：没有分布式系统经验，能过Notion的系统设计吗？
能，但你必须展示可扩展的思维方式。Notion不期望初级工程师设计全球分布式数据库，但他们希望你理解本地问题的扩展性。比如你做过一个博客系统，面试官问“如果单篇博客有10万条评论怎么办”。如果你回答“分表”，这是基础。但如果你说“先分析访问模式：90%用户只看前100条，因此用cursor-based pagination，只查前N条；
热评用redis缓存；历史评论归档到cold storage”，这就展示了分层思维。一位候选人只有后端经验，但在设计“最近访问页面”时，提出用LRU cache + DynamoDB TTL，还估算出缓存命中率85%，成功进入HC。关键不是经验多深，而是你能否用现有知识推演复杂场景。
Q：LeetCode要刷多少题？
不需要刷500+。Notion的算法题难度在Medium，且常与实际场景结合。比如“设计一个支持undo的文本编辑器”，本质是栈的应用；“计算block的嵌套深度”是DFS。一位候选人只刷了200题，但每道题都写了复杂度分析和边界测试用例，面试时能快速识别题目变体。
另一位刷了600题的人，遇到“合并区间”时直接写代码，没问“区间是否包含端点”“是否已排序”，被质疑工程严谨性。Notion要的是问题拆解能力，不是题海记忆。你应精做100道经典题，重点训练：1）如何与面试官确认输入输出；2）如何先写test case再编码；3）如何解释每一行代码的代价。
Q：行为面试该怎么准备？
不要背故事，要重构决策链。Notion的行为面试本质是“技术决策复盘”。比如你说“优化了API性能”，面试官会层层追问：“怎么发现的瓶颈？工具？数据？对比方案？
最终指标？” 一位候选人准备时只记了“用缓存提升了性能”，面试时被问“为什么选Redis而不是Memcached”，答不出，失败。另一位候选人说：“用pprof发现GC压力大，尝试了对象池和sync.Pool，最终用flatbuffers减少allocation，GC时间从200ms降到20ms。” 他甚至带了pprof火焰图截图（脱敏后），直接拿到Strong Hire。准备时，为每个项目写一份“技术决策备忘录”：问题、假设、实验、数据、结论。这才是Notion要的“行为”。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。