Notion的工程师团队规模不大，但产品复杂度极高——一个笔记工具要同时做好离线优先、多人实时协作、复杂富文本渲染、插件生态和跨平台性能。这个技术栈的深度，决定了Notion对工程师的考察逻辑和FAANG有本质区别。不是考察你能不能写出O(n)的算法，而是考察你能不能在约束条件下写出工程上可持续的代码。
这篇文章不教你怎么刷LeetCode——那是基本功，自己搞定。我要告诉你的是：Notion的面试官真正在找什么人，以及你在每一轮里怎么让对方觉得“你就是我们要的人”。
一句话总结
Notion的软件工程师面试不是考察你会多少奇技淫巧，而是考察你在真实工程约束下写代码、聊系统设计和做产品决策的能力——你不需要比Google更会刷题，但你需要比Google的候选人更懂协作工具的产品逻辑和技术取舍。
适合谁看
这篇文章适合以下几类候选人：
第一类，正在准备Notion软件工程师岗位面试的人——你可能已经通过了简历筛选，正在等待第一轮技术面试，或者已经经历过一轮但不确定表现如何。第二类，对Notion这家公司的工程文化感兴趣的人——你想知道在这家以产品体验著称的公司做工程师，日常工作到底在做什么。第三类，正在比较多家公司Offer的人——Notion、Google、Stripe、Airbnb都在你的候选列表里，你想了解每家公司的面试风格差异，以便做出更明智的选择。
如果你是刚入门编程、连数据结构还没学完的学生，这篇文章对你来说太早了——先去刷完NeetCode 150再说。如果你是资深Staff Engineer以上级别，准备的是E7/E8级别岗位，这篇文章的细节粒度可能不够——你需要的是另一套关于Leadership Principles和系统影响力的叙事。
Notion的面试流程到底在考什么
Notion的软件工程师面试流程通常由5到6轮组成，不同团队（前端、后端、移动端、基础设施）略有差异，但核心结构基本一致。
第一轮是HR筛选和Hiring Manager聊，这一轮不考技术。HR会核实你的基本背景、签证状态和薪资期望。Hiring Manager会花30分钟介绍团队正在解决的问题，评估你对这个领域是否有真实的兴趣和基本的理解。这个环节的淘汰率不高，但如果你对Notion的产品一无所知，甚至连他们最近收购了哪家公司都答不上来，Hiring Manager会直接在你的反馈里写下“文化匹配度存疑”。
第二轮是电话技术面试，通常是45到60分钟的Code Interview。Notion在这一轮使用的题目难度中等——不是Hard级别的动态规划，而更接近Medium的树/图遍历或者系统设计前置题。关键点在于：Notion的面试官非常关注你的沟通过程。他们不是找一个人闷头写代码然后给答案，而是找一个人从理解问题开始就不断确认假设、讨论边界条件、评估不同方案的trade-off。如果你写完代码才开始说话，这一轮的反馈很可能是“candidate缺乏协作意识”。
第三到第四轮是现场面试（Onsite），通常包含两到三轮深度编码、一轮系统设计、一轮产品直觉和一轮行为面试。 深度编码的题目往往围绕Notion的真实技术挑战展开——比如如何设计一个支持200人同时编辑同一文档的冲突解决算法，或者如何在移动端实现无限滚动的同时保证性能。系统设计面试不是让你设计Twitter或者Uber，而是更接近Notion的实际场景：设计一个块级编辑器的数据模型，或者设计一个插件系统的沙箱隔离机制。产品直觉这一轮是Notion区别于大多数硅谷公司的特色环节——面试官会给你一个Notion产品的真实问题，比如“用户反馈在团队空间里找不到自己创建的内容”，让你分析根因，提出解决方案，并讨论工程实现的优先级。
最后一轮是Hiring Committee（HC）评审，由面试你的所有工程师和Hiring Manager共同决定你是否通过。HC关注的不是某一道题你答对了没有，而是你整体展现出来的工程师画像是否匹配这个岗位的需求。
这里有一个insider场景需要你知道：在Notion的HC评审中，最常被讨论的话题不是“这个候选人算法多厉害”，而是“这个候选人能不能在我们的代码库里活下来”。Notion的代码库复杂度极高——一个页面的渲染涉及React组件树、CRDT同步层、本地IndexedDB缓存和远程服务的多层抽象。很多技术优秀的候选人因为在这一轮被评价为“可能难以适应高复杂度代码库”而挂掉。
> 📖 延伸阅读：Notion数据科学家薪资与职级体系
不是刷更多题，而是理解Notion的技术语境
大多数候选人的准备策略是：加大刷题量，从200题刷到400题。这条路径在Google有效，但在Notion的投入产出比很低。
不是刷更多题，而是理解Notion的技术语境。 Notion的技术栈核心是四个方向：React和前端架构、CRDT（无冲突复制数据类型）为核心的协作引擎、离线优先的数据同步、以及块级编辑器模型。你不需要成为CRDT的学术专家，但你需要理解为什么Notion选择CRDT而不是OT（Operational Transformation），这个选择带来的工程代价是什么，用户端感知到的表现是什么。
具体准备方式是这样的：花两到三个小时通读Notion的工程博客。Notion的Engineering Blog是公开的，里面有大量关于他们如何实现实时协作、如何处理移动端性能、如何设计块级编辑器的深度文章。这些文章不是给你学知识的，而是给你提供面试中的“共同语言”。当面试官问“你怎么设计一个支持撤销重做的编辑器”时，如果你能说“我看到你们博客里用了Command Pattern来实现这个功能，你们选择的方案相比Memento模式的优势是……”，这比任何算法答案都更有说服力。
不是展示你知道多少，而是展示你知道什么是对的。 Notion的面试官见过太多“正确答案型”候选人了——题目刷过，答案背过，代码写得完美，但一旦被追问“为什么这个方案在这里不work”就开始卡壳。Notion真正看重的是你在不确定中做判断的能力。在产品直觉轮和系统设计轮，面试官会故意给你一个没有标准答案的问题，然后观察你如何拆解问题、如何在多个可行方案中做取舍、如何承认自己不知道的东西并提出验证方法。
一个具体的insider场景是这样的：在系统设计面试中，一位面试官曾问候选人“如何设计Notion的搜索功能，让用户在输入一个关键词时，毫秒级返回结果”。很多候选人立刻开始讨论倒排索引、分片策略、缓存层。但面试官真正想听到的不是这些——他想听到的是候选人先问一个问题：“搜索的实时性要求是什么？是全局搜索还是当前工作空间内的搜索？用户对搜索结果的预期是相关性优先还是时效性优先？”这种先问问题再给方案的思维方式，是Notion工程师画像的核心特征。
薪资结构：Notion给多少钱
Notion的软件工程师薪资在硅谷属于competitive但不是顶尖档位。以下是2024年的典型总包范围，基于L4到L6级别的常见Offer：
L4（入门级工程师）：Base Salary约$130,000到$160,000，RSU（限制性股票）第一年约$40,000到$60,000（四年分期），Bonus约10%到15%。总包大概在$170,000到$210,000之间。
L5（中级工程师）：Base Salary约$160,000到$200,000，RSU第一年约$60,000到$120,000，Bonus约15%到20%。总包大概在$220,000到$320,000之间。
L6（高级工程师）：Base Salary约$200,000到$250,000，RSU第一年约$120,000到$200,000，Bonus约20%到25%。总包大概在$350,000到$500,000之间。
需要注意的是，Notion的RSU vesting schedule是四年期，第一年悬崖期后拿到25%，之后每月拿到1/48。股票价值取决于公司估值和上市后的表现，这一点和所有未上市公司一样存在不确定性。相比之下，Google和Meta的L4到L6总包通常比Notion高出20%到30%，但Notion的成长空间和产品影响力是很多候选人选择它的核心原因。
> 📖 延伸阅读：Notion 产品经理薪酬拆解：offer 到手到底写了什么
系统设计面试：Notion在找什么样的架构思维
Notion的系统设计面试不是让你设计一个分布式系统，而是让你设计一个有用户体验约束的分布式系统。这两个的区别非常大。
传统的系统设计面试——设计Twitter、设计Uber、设计Netflix——考察的是你对大规模系统的理解：负载均衡、数据库分片、缓存策略、异步处理。这些是必要的底层能力，但Notion的面试官更关心的是：你能不能在用户体验和工程复杂度之间找到最优解。
举一个真实的面试题例子：“Notion的页面可以包含数千个块（Block），每个块可以是文本、图片、表格或者嵌入内容。当用户在一个有500个块的页面中滚动时，如何保证帧率稳定在60fps？”这不是一道算法题，这是一道前端架构题。候选人的回答会立刻分化成两个方向：
错误的方向是立刻开始讨论虚拟列表、React.memo、debounce——这些都是技术手段，但没有回答“为什么”以及“以什么顺序”。正确的方向是先分析问题：500个块导致性能下降的根本原因是什麼？是DOM节点过多导致layout计算耗时，还是每个块都有自己的状态更新导致re-render，还是图片懒加载没有做好导致网络阻塞？不同的根因对应完全不同的解决方案。面试官想看到的是你从现象到根因的分析链条，而不是直接给答案。
不是给技术方案，而是给技术判断。 在Notion的系统设计轮，面试官会频繁challenge你的方案。当你提出使用Web Worker来做主线程卸载时，面试官可能会问：“Web Worker的通信开销在这个场景下会不会反而增加延迟？如果用户用的是低配Android机，Web Worker的内存占用会不会触发浏览器的内存限制？”你需要能够当场评估自己方案的边界条件，而不是坚持“我觉得这个方案最好”。
这里有一个关键的组织行为学原理：Notion的团队规模小，每个工程师对产品的影响直接且可见。因此他们在Hiring Committee上偏好“全能型”工程师——不是说你必须什么都会，而是说你能够从产品问题出发，自主判断做什么、不做什么、先做什么。这种思维在系统设计面试中的表现就是：你能否在讨论中不断把话题拉回到“用户实际会遇到什么问题”这个原点。
产品直觉轮：Notion独有的考察维度
大多数硅谷公司在软件工程师面试中不考产品直觉，但Notion考。这一轮通常由Product Manager或者Senior Engineer担任面试官，时长45分钟。
这一轮的考察逻辑是这样的：Notion的工程师不只是写代码的——他们需要参与产品决策。每一个功能改动都涉及工程代价和产品价值的权衡，工程师如果只能执行而不能判断，就会在Notion的文化里感到非常痛苦。
具体来说，这一轮的题目类型包括几种：
第一种是产品分析题。面试官会给你一个真实的用户反馈或者数据现象，让你分析问题。比如：“我们发现企业版用户在创建新页面时，从点击'New Page'到页面加载完成的平均时间是2.3秒，而个人版用户是0.8秒。请分析可能的原因，并提出排查方向。”这不是让你立刻给解决方案，而是让你展示如何从数据出发构建假设、如何设计实验验证假设、如何在多个可能的原因中排序优先级。
第二种是功能设计题。面试官会让你为一个新功能设计技术方案，但重点不是技术实现细节，而是“你认为这个功能应该有什么样的用户体验”。比如：“如果你要为Notion设计一个AI助手，帮助用户自动总结页面内容，请从用户体验的角度描述这个功能应该怎么做，然后从技术角度评估最复杂的挑战是什么。”
第三种是优先级判断题。面试官会给你三个功能需求和有限的工程资源，让你决定先做哪个。每一个功能都有用户请求数量、工程实现难度和战略价值的标签，你需要展示你的决策框架，而不仅仅是决策结论。
不是回答产品经理的问题，而是展示你和产品经理协作的方式。 这一轮很多候选人犯的错误是表现得像是要抢PM的饭碗——过度关注产品细节，而忽视了展示自己和PM协作的成熟度。正确的姿态是：在产品讨论中展现出“我理解产品逻辑，但我更擅长评估工程代价和可行性”的角色意识。
一个具体的对话场景可以帮助你理解这一轮的氛围。面试官说：“我们考虑在Notion里加一个'一键整理'功能，用户点击一下，页面自动变得井井有条。你觉得这个功能应该怎么做？”错误的回答是立刻开始讨论算法逻辑——如何识别标题、如何排序块、如何自动加标签。正确的回答是先问：“'整理'对不同用户的定义可能完全不同——有人希望按时间线整理，有人希望按主题分类。你说的'整理'是指什么场景下的整理？企业用户和个人用户的需求一样吗？”这种先定义问题再解决问题的思维方式，是Notion工程师文化的核心。
行为面试：你的简历不是你自己
Notion的行为面试通常由Hiring Manager或者资深工程师担任，考察的是你的过往经历和Notion文化的匹配度。
Notion的文化有几个核心关键词：Ownership（主人翁意识）、Efficiency（效率优先）、Craftsmanship（对工程质量的追求）、Collaboration（跨职能协作）。 行为面试的题目会围绕这些维度展开。
常见的题目包括：“讲一次你推动了一个你本来不需要负责的项目”、“讲一次你和产品经理意见不一致的经历，你是怎么处理的”、“讲一次你写的代码出了问题，你是怎么发现和修复的”、“讲一次你在一个高复杂度代码库中工作的经历”。
不是讲你做了什么，而是讲你为什么这么做。 行为面试中最大的坑是“流水账式叙述”——从入职讲到离职，中间做了ABCDE五件事，每件事用三句话概括。面试官想听到的不是事件清单，而是你在每一个关键决策点的思考过程：你为什么选择做A而不是B？你在那个冲突中是如何权衡各方利益的？如果再来一次，你会做什么不同的选择？
具体准备方式：准备四个到五个核心故事，每个故事能够映射到Notion文化中的一个或多个维度。每个故事按照STAR法则（Situation, Task, Action, Result）组织，但重点放在Action和Result上。每个故事准备一个“后续篇”——如果让你重新做一次，你会有什么不同的做法。这个“后续篇”是行为面试中最加分的部分，因为它展示了你对自身经历的反思能力。
一个真实的HC评审场景是：一位候选人在行为面试中讲了一个“我独立完成了一个重构项目”的故事，technical层面非常出色。但HC讨论时，一位面试官提出了一个问题：“这个故事里全是'I'，没有'we'。Notion的团队很小，每个人都需要跨职能协作，他能融入我们的文化吗？”最终这位技术优秀的候选人没有拿到Offer。所以，不是展示你有多厉害，而是展示你多适合。
准备清单
以下是针对Notion软件工程师面试的系统性准备清单，按优先级排列：
第一项，完成Notion产品的深度体验。不是注册一个账号随便点两下，而是真正使用Notion一到两周，创建不同类型的页面（个人笔记、团队wiki、项目管理看板），使用高级功能（公式、关系数据库、模板），观察产品细节。你需要能够回答“如果让你改进Notion的一个功能，你会改什么”这个问题。
第二项，阅读Notion的Engineering Blog至少五篇文章，重点理解他们选择特定技术方案的原因和trade-off。每一篇文章读完后，写一段200字的总结，核心是“这篇文章解决的问题是什么，Notion的方案相比其他方案的优劣是什么”。
第三项，针对Notion的技术栈准备两个深度话题：CRDT的基本原理和工程实现挑战、React在复杂状态管理下的性能优化。这两个话题在面试中被问到的概率最高。
第四项，在LeetCode上完成30到50道Medium级别的题目，重点练习树、图、动态规划和系统设计前置题（如设计哈希表、设计LRU缓存）。不需要刷Hard题，但需要确保Medium题能够在30分钟内完成且bug-free。
第五项，准备行为面试的四个核心故事，每个故事包含Situation、Task、Action、Result和“重新做一次我会怎么做”五个部分。每个故事控制在三分钟以内能够完整叙述。
第六项，进行两次模拟面试——一次技术面，一次产品直觉面。模拟面试的价值不在于题目本身，而在于训练你在被追问时的思考节奏和沟通方式。
第七项，系统性拆解Notion的面试结构。PM面试手册里有完整的Notion技术面试实战复盘可以参考，其中关于系统设计轮和产品直觉轮的常见题目分类对你的准备会很有帮助。
常见错误
以下是三类Notion面试中最常见的失败模式，每一个都有具体的BAD vs GOOD对比：
错误一：在技术面试中只顾写代码，不说话。
BAD版本：面试官出一道编码题，候选人点头ok，然后闷头写了45分钟代码，写完说“完成了”。面试官问“你这个方案的时间复杂度是多少”，候选人回答“O(n)”。面试官追问“如果输入数据量增大到100万，你的方案会有什么瓶颈”，候选人开始现场分析，但已经浪费了面试官的大量时间——他本来想考察的是你在写代码之前的思考过程。
GOOD版本：面试官出题后，候选人先花三到五分钟确认问题边界：“我确认一下，输入数据的规模大概是什么范围？有没有特殊的约束条件比如内存限制？我可以假设输入都是合法的吗？”在写代码之前，先口述自己的思路和备选方案，评估每个方案的时间空间复杂度，然后选择一个最合适的。写代码的过程中保持轻度的口头同步：“我现在在写主循环，这里用双指针是因为……”面试官challenge方案时，不防御、不坚持，而是当场评估并调整。
错误二：在系统设计面试中直接给架构图，不聊需求。
BAD版本：面试官说“设计一个支持百万用户的实时协作编辑器”，候选人立刻开始画架构图——前端WebSocket、后端Redis发布订阅、数据库分片、负载均衡。画了满满一白板，面试官问了一个问题：“你说的这个方案，延迟大概是多少？用户敲下一个字到看到字符出现在屏幕上，这个链路有多长？”候选人答不上来。
GOOD版本：候选人先问问题：“'实时'的定义是什么——100毫秒内还是1秒内？协作的用户数量级是多少——10人还是1000人？容错要求是什么——偶尔丢一次消息可以接受吗？”在明确了需求约束之后，再开始设计架构，并且在整个设计过程中不断回到需求层面评估：“这个方案能满足100毫秒的延迟要求，因为WebSocket的点到点延迟通常在50毫秒以内……”
错误三：在产品直觉轮表现得像产品经理，而不是工程师。
BAD版本：面试官问“如果让你改进Notion的一个功能，你会改什么”，候选人开始大谈特谈产品定位、用户细分、市场策略，讲了十分钟产品战略，但完全没有提到任何工程层面的实现难度或者技术约束。面试官内心OS：我是来找工程师的，不是来找CEO的。
GOOD版本：候选人选择一个具体功能，从用户痛点出发（“我注意到在团队空间里，用户经常找不到自己创建的页面，因为页面层级太深”），然后分析可能的解决方案，最后落到工程层面（“如果要实现页面搜索优化，挑战在于索引的实时性——用户在页面创建的同时就需要能搜到，这对后端的写入链路会有性能影响，我们可以考虑……”）。整个叙述保持在产品和工程的交界面上，展现的是“我懂产品，但我更擅长评估工程代价”的角色感。
FAQ
Q1：Notion的面试难度和Google相比怎么样？
从算法题的绝对难度来看，Notion比Google简单。Google的L4面试通常包含多道Hard级别的算法题，时间压力大，容错空间小。Notion的算法题大多在Medium级别，但考察维度更分散——你除了算法，还需要准备系统设计和产品直觉。这意味着你的准备范围更广，但每个维度的深度要求比Google低。另一个关键差异是面试节奏：Google的面试风格更标准化，每个轮次有明确的评分标准，面试官像是在完成一份检查表；Notion的面试风格更取决于Hiring Manager的个人偏好，有的Manager更看重技术深度，有的更看重文化匹配。这意味着在Notion，运气因素的占比比Google更高——不是你的绝对实力变了，而是不同面试官眼中的“好候选人”标准不同。准备Notion面试的正确心态是：把自己能控制的部分做到极致（算法、系统设计、产品直觉、行为面试），接受面试中不可控的部分（面试官的个人偏好、当天的状态、HC的构成）。
Q2：如果我之前没有做过协作工具相关的项目，面试中会不会吃亏？
不会直接吃亏，但需要你展示相关的迁移能力。Notion的面试官知道不是每个人都有协作工具的经验，所以他们不会期望你之前做过CRDT或者实时同步系统。但他们会期望你有能力快速理解这个领域的技术挑战，并在面试中展现出学习能力和技术迁移能力。一个有效的准备方式是：选择一个你做过的项目，找出其中和Notion技术挑战相似的维度。比如，如果你做过聊天应用，你可以聊消息同步的挑战；如果你做过文档处理，你可以聊富文本编辑器的状态管理；如果你做过离线优先的移动端应用，你可以聊本地缓存和远程服务器的一致性问题。关键不是“你做过”，而是“你能理解并迁移”。
Q3：Notion的HC评审通常会因为什么原因挂掉候选人？
从多个面试反馈的案例来看，Notion的HC评审中最常见的挂人原因有三个。第一个是“工程判断力不足”——技术能力OK，但在系统设计轮和产品直觉轮展现出的是“执行型”思维，不是“决策型”思维。第二个是“文化匹配度存疑”——在行为面试中展现出过于强烈的个人英雄主义，或者对协作的意愿不足。第三个是“代码质量不稳定”——电话面试或者现场编码轮中写出的代码有明显的bug，或者代码风格粗糙（变量命名混乱、缺乏模块化、边界条件处理不完整）。第三个原因是最可惜的，因为它是可以通过认真准备完全避免的。很多候选人在练习时只关注算法是否正确，而不关注代码的可读性和健壮性。但在Notion的面试中，面试官会花时间读你的代码——他们不是在找“能work”的代码，而是在找“能维护”的代码。一个小细节：写完代码后主动检查边界条件并主动修正的候选人，在这一轮的通过率显著高于写完就等面试官提问的候选人。
如果你正在准备Notion的面试，记住最重要的一件事：Notion不是在找最会刷题的人，而是在找最合适的人。每一轮面试都在验证一个核心问题——“这个人能不能在我们的高复杂度环境中做出好的工程判断”。围绕这个核心去准备，比围绕“如何答对所有题目”去准备，更接近Notion真正想要的工程师画像。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。