Notion数据科学家面试真题与SQL编程2026
一句话总结
答得最好的人，往往第一个被筛掉。Notion数据科学家面试不是考你SQL写得多快，而是看你能否从一团乱麻的产品日志里拎出真正的问题。大多数人准备的方向全错了——不是背题库，而是理解Notion的产品哲学：极简工具如何驱动复杂行为。
Notion的面试不筛选“会答题的人”，而是过滤掉“不懂协作产品的人”。你在简历上写的“提升DAU 15%”在Notion眼里可能是噪音，因为他们不追求粗放增长，而是看文档在组织内的渗透深度和复用率。所以，你面对的每一道SQL题，本质都不是技术题，而是产品洞察题。
举个真实例子：一位候选人完美写出留存计算SQL，却说不清“为什么嵌套页面的编辑频次比顶级页面高37%”意味着什么。他在debrie后被一致否决。面试官原话是：“他能跑通查询，但看不出这是权限设计的信号。”正确的判断不是“会写代码就行”，而是“写代码是为了验证假设”。你之前想的大概率是错的。
适合谁看
你不是应届生，也不是转行者。你是有2-5年经验的数据科学家，已经在中型SaaS公司做过AB测试、漏斗分析、用户分群，甚至主导过数据产品上线。你熟悉Postgres、Snowflake、Looker，能用Python做建模，也写过自动化报表。你之所以看这篇文章，是因为你意识到：Notion的面试和其他公司不一样。
你在LinkedIn上看到有人面完说“题目很简单”，结果自己一试发现根本不是那么回事。简单的是语法，难的是上下文。Notion的SQL题往往只给半句需求，比如“找出最近活跃但可能流失的用户”，你得反问：“活跃的标准是什么？文档类型是否区分？协作行为算不算？”——这正是他们要的。
你适合看这篇文章，如果你：正在准备Notion DS面试；已经挂过一轮，怀疑自己准备方向错了；或者想系统提升产品型数据科学能力。你不适合看，如果你只想背题。因为这里不提供“高频题100道”，而是告诉你：为什么你写的SQL在Notion眼里是错的，哪怕它语法正确。
我们不教你怎么写JOIN，而是告诉你：在Notion，JOIN不是技术操作，而是业务关系的映射。比如，文档表和权限表的JOIN，不是为了取字段，而是为了判断“一个用户是否真的‘拥有’这个文档”。这种思维转变，才是你缺的。
面试流程拆解：每一轮都在考什么？
Notion数据科学家面试共五轮，历时3-4周，每轮60分钟，全程远程。流程设计极其克制，没有冗余环节，每一轮都在过滤特定风险。第一轮是HR电话，15分钟，确认基本背景和动机。重点不是你能来多久，而是你为什么选Notion。答“我喜欢协作工具”会被直接pass，因为他们要的是“我研究过Notion内部文档结构，知道block model的独特性”。
第二轮是技术筛查（Technical Screening），由L4数据科学家主持。30分钟SQL，30分钟行为问题。SQL题通常是：给定users、pages、edits三张表，写一个查询，找出“过去7天编辑过至少3个不同文档，但从未创建过文档的用户”。
这不是考窗口函数，而是考你是否意识到“编辑”和“创建”是两个独立权限。很多候选人JOIN错了表，把created_at当成edit事件的时间戳，直接暴露对产品模型理解浅薄。
第三轮是产品分析（Product Analytics），由L5或Staff DS出题。给一个模糊问题，比如“最近团队空间的活跃度下降了10%，你怎么分析？”你要先定义“活跃度”——是打开次数？编辑时长？协作邀请？
然后拆解维度：是所有团队都降？还是特定规模？时间段是否匹配假期？我见过一位候选人直接跳到SQL，被面试官打断：“你还没告诉我，你怀疑的根本原因是什么。”
第四轮是数据建模与系统设计（Data Modeling & Systems），由工程经理和DS联合面试。题目是：“设计一个数据模型来追踪block-level协作行为。”这不是画ER图就行。
你要考虑：block是动态嵌套的，权限是继承的，版本是实时同步的。一个候选人提出用parent_id递归查询，被质疑“在Postgres上递归深度超过10层会超时，你怎么优化？”他答不上来，挂了。
第五轮是Hiring Committee（HC）终面，由两位Staff级以上DS和一位Director组成。不考技术，只考判断力。他们会回顾你前几轮的表现，问：“如果你发现高级用户的文档平均长度在下降，你会怎么建议产品团队？”这题没有标准答案，但如果你说“建议加富文本功能”，就错了——因为Notion的哲学是“少即是多”。
正确路径是先验证：是用户在删内容？还是新开文档更短？然后建议“检查模板使用率，可能是新用户依赖模板但不会扩展”。
每一轮都在淘汰一种人：第一轮淘汰动机不明的，第二轮淘汰技术不精的，第三轮淘汰思维混乱的，第四轮淘汰系统无知的，第五轮淘汰产品反智的。你不是被一道题干掉，而是被整体判断过滤。
SQL真题解析：为什么你写的对，但还是挂了？
我们来看一道2025年Q4真实考题：
“找出在过去30天内，至少被3个不同团队访问过的公共文档（is_public = true），且这些团队中至少有一个是企业版客户。”
表结构：
- documents: id, createdby, ispublic, created_at
- accesslogs: documentid, userid, teamid, accessed_at
- teams: id, plan (free, pro, enterprise)
候选人A的SQL：
`sql
SELECT d.id
FROM documents d
JOIN accesslogs a ON d.id = a.documentid
WHERE d.is_public = true
AND a.accessedat >= CURRENTDATE - INTERVAL '30 days'
GROUP BY d.id
HAVING COUNT(DISTINCT a.team_id) >= 3
AND SUM(CASE WHEN t.plan = 'enterprise' THEN 1 ELSE 0 END) >= 1;
`
错误在哪？他JOIN了access_logs，但没JOIN teams表，t.plan根本不存在。这是语法错误，当场挂掉。
候选人B的SQL：
`sql
SELECT d.id
FROM documents d
JOIN accesslogs a ON d.id = a.documentid
JOIN teams t ON a.team_id = t.id
WHERE d.is_public = true
AND a.accessedat >= CURRENTDATE - INTERVAL '30 days'
GROUP BY d.id
HAVING COUNT(DISTINCT a.team_id) >= 3
AND SUM(CASE WHEN t.plan = 'enterprise' THEN 1 ELSE 0 END) >= 1;
`
语法正确，逻辑也对。但他还是被debrie否决了。为什么？因为面试官问：“你如何保证accesslogs里每个teamid确实代表一个独立团队？有没有可能同一个团队有多个userid频繁访问，被你误判为‘多个团队’？” 他答：“数据是干净的。” 面试官说：“在Notion，我们从不假设数据干净。你应该先检查teamid的分布。”
真正通过的候选人C，先写了基础查询，然后补充：
“我会加一个预检查：SELECT teamid, COUNT(DISTINCT userid) FROM accesslogs GROUP BY teamid HAVING COUNT > 1000，看是否有异常team_id。
另外，is_public字段可能被滥用，有些用户设为public但只分享给特定team，我需要验证public文档的真实访问控制。”
这才是Notion要的：不是你写得多快，而是你是否质疑数据本身。SQL不是终点，而是推理的起点。你写的每一行，都应该暴露你的怀疑。
还有一个反直觉点：Notion不喜欢单一查询解决问题。他们期待你分步走。比如，先查出候选文档，再用Python或临时表验证企业客户占比。因为现实中，大表JOIN会超时，你得有降级方案。这不是考你技术，而是考你是否在真实环境中活下来过。
产品思维考察：数据只是表象，行为才是真相
Notion的数据面试，本质上是产品面试。他们不关心你算得准不准，而关心你推断得对不对。比如一道题：“发现新用户7日留存从40%降到32%，你怎么分析？”
大多数人的路径是：拆渠道、拆地域、拆设备、跑归因模型。但在Notion，这叫“表面分析”。正确的路径是先问：“留存怎么定义的？是打开App？还是编辑了至少一个block？”
因为在Notion，很多用户“打开但不编辑”——他们只是在看别人共享的文档。这种用户算“活跃”吗？不算。所以，如果你用“打开App”定义留存，数据本身就是错的。
一位L5面试官在debrief会上说：“候选人用漏斗分析拆解注册流程，发现第三步流失高，建议优化表单。但问题是，Notion的注册流程只有两步。他根本没用过产品。” 这种人直接pass——你分析的不是我们的产品，是你的想象。
真正的分析路径是：
- 先确认指标定义：留存是否包含只读用户？
- 检查产品变更：最近是否上线了新引导？是否修改了默认权限？
- 看行为模式：留存下降的用户，是否集中在某个模板使用群体？
- 验证假设：比如，如果怀疑是引导问题，就对比有/无引导用户的留存差异。
我在一次hiring manager会议上听到真实案例：一组用户留存下降，但DAU没变。深入发现，是另一组老用户开始创建大量新账号用于团队迁移。表面是新用户留存降，实则是老用户行为变。这种洞察，不是靠SQL，而是靠对产品节奏的敏感。
所以，不是“数据驱动决策”，而是“产品理解驱动数据提问”。你不是在跑查询，而是在验证你对人类行为的猜测。Notion的文档不是内容，而是工作流的载体。你要分析的不是点击，而是意图。
薪资结构与职业路径：你值多少钱，Notion怎么付
Notion数据科学家薪资分三级：L3（初级）、L4（中级）、L5（高级），对应硅谷标准。L3 base $140K，RSU $180K（分4年发放），bonus 10%（约$14K），总包约$334K。L4 base $165K，RSU $250K，bonus 12%（$19.8K），总包$434.8K。
L5 base $190K，RSU $350K，bonus 15%（$28.5K），总包$568.5K。Staff及以上为case by case，通常RSU超过$500K。
这不是靠加班换来的。Notion工作节奏克制，周均工时45小时左右，极少加班。但他们对产出质量要求极高。一个L4的年度目标不是“做10个分析”，而是“推动一个数据产品上线，并被三个核心团队采用”。
晋升机制透明：L3到L4需18-24个月，关键看是否能独立主导分析项目；L4到L5需3-4年，必须有跨团队影响力，比如设计通用指标或搭建监控系统。晋升材料要求：3个具体成果，每个含背景、行动、量化结果、组织影响。
我参加过一次晋升评审会。一位L4候选人提交了“优化搜索推荐模型，CTR提升8%”。材料很完整，但委员会否了。理由是：“CTR不是Notion的核心指标。我们更关心文档复用率和模板采用率。你提升了点击，但用户是否完成了工作？没有证据。”
这就是Notion的取舍：不是所有数据改进都算进步。你必须证明你的工作让用户更高效，而不是更忙碌。所以，不是“追求指标增长”，而是“追求工作流简化”。你的分析不能只停留在数字，而要连接到用户完成任务的路径。
职业路径上，DS可走专家线（Staff → Principal）或管理线（Tech Lead → Manager）。但管理岗极少，Notion偏好扁平结构。大多数高级DS选择深耕技术，比如主导A/B测试平台建设或定义公司级data dictionary。
准备清单
你不需要刷300道LeetCode。你需要的是精准打击。第一条：重新定义你的简历。不要写“提升转化率20%”，而是写“通过分析注册后7分钟内的block创建行为，识别关键激活点，推动引导流程重构，使7日留存提升8个百分点”。Notion只认具体行为和产品机制的关联。
第二条：精通Notion产品模型。你必须能画出block、page、workspace、relation的ER图，并解释权限如何继承。比如，一个嵌套页面的权限是继承父级还是可覆盖？答案是可覆盖，这意味着你的分析必须考虑权限粒度。
第三条：掌握Postgres高级特性。Notion用Postgres做OLAP，不是MySQL。你要会写CTE递归查询处理嵌套页面，会用JSONB字段解析block内容，会用窗口函数计算编辑时序。不是“会写SQL”，而是“用SQL表达产品逻辑”。
第四条：准备3个深度案例。每个案例必须包含：问题定义、数据挑战、分析路径、产品建议、实际影响。比如，“分析模板市场使用率下降”，你要展示如何拆解模板类型、用户分群、时间趋势，并建议“增加模板推荐位与工作流匹配度”。
第五条：模拟跨团队冲突场景。Notion的DS常要面对产品团队的质疑。准备一个案例：你建议停掉某个功能，因为数据表明使用率低。产品团队反对，说“这是战略方向”。你怎么用数据+用户访谈+竞品分析说服他们？答案不是“坚持数据”，而是“重构问题”——把“用不用”变成“能不能用”。
第六条：系统性拆解面试结构（PM面试手册里有完整的数据科学家实战复盘可以参考）。不是照搬，而是理解：为什么他们这样设计流程？每一轮在防什么风险？你就能预判他们的判断逻辑。
第七条：练习“反问面试官”。Notion重视候选人提问。不要问“团队氛围如何”，要问“当前最大的数据盲区是什么？”或“最近一次数据驱动的产品决策是什么？”——这展示你关心实质问题，而非表面文化。
常见错误
错误一：把SQL当编程题做
BAD：候选人面对“计算文档共享深度”题，直接写递归CTE，用parent_id一层层往上JOIN。代码能跑，但面试官问：“如果文档嵌套100层呢？”他答：“加LIMIT。”
GOOD：正确做法是承认递归性能风险，提出用materialized path模式，预先存储路径字符串（如/1/3/7/9），用LIKE查询子树。或建议用应用层缓存深度信息。Notion不要你硬刚数据库，而要你设计可持续的方案。
错误二：用通用指标回答产品问题
BAD：面试官问：“你怎么衡量Notion AI助手的价值？”候选人答：“看使用率、留存、NPS。”
GOOD：应答是：“先定义AI助手的目标。如果是降低文档创建时间，就测从空白页到完成模板的时长；如果是提升内容质量，就抽样评估AI生成block的采纳率。NPS是噪音，使用率可能只是好奇驱动。” Notion要的是指标与产品目标的对齐，不是KPI堆砌。
错误三：忽视数据权限的复杂性
BAD：分析“企业客户文档活跃度”，直接按team_id分组，算平均编辑次数。
GOOD：先确认：同一个文档可能被多个team访问，但权限不同。只读访问不应计入“活跃”。应先JOIN permissions表，过滤role IN ('editor', 'owner')。否则你的分析会高估真实参与度。我在一次debrie会上见面试官说：“他连权限都没考虑，显然没在真实协作系统里活过。”
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：没有SaaS经验，能面Notion数据科学家吗？
可以，但必须补足产品认知。有一位候选人背景是电商推荐系统，他准备时做了三件事：第一，用Notion三个月，记录每天行为路径；第二，反向工程Notion帮助中心的文档结构，画出信息架构图；第三，写一篇分析“为什么Notion模板比Coda更易传播”的博客。
面试时他用这个案例展示对“工作流可复制性”的理解，成功入职。Notion不看行业，看思维适配。你不需要有SaaS数据，但必须有SaaS级的产品洞察。如果你只懂转化漏斗，不懂权限模型和协作拓扑，你会在第三轮暴露。
Q：Python和机器学习考得多吗？
极少。Notion数据科学家90%工作是SQL+产品分析，10%是轻量建模。他们不建推荐系统，也不做用户分群模型。一次HC会上，一位候选人展示了复杂的LSTM流失预测模型，委员会一致认为“过度设计”。理由是：“Notion的流失信号很明确——连续7天没编辑任何block。
不需要复杂模型。” 他们要的是快速验证假设的能力，不是算法炫技。Python主要用于数据清洗和自动化，不是建模。如果你花三个月刷机器学习题，就错了方向。你应该花时间练SQL复杂查询和产品框架表达。
Q：内部转岗和外部招聘，哪个更容易进Notion？
内部转岗成功率是外部的3倍，但路径不同。一位工程师从前端转DS，他做了三件事：第一，主动接手团队的数据报表需求，用SQL重写低效查询，性能提升10倍；第二，在公司wiki发布“API调用频次与文档复杂度相关性”分析；第三，向DS团队提了一个数据质量改进提案，被采纳。
6个月后，他申请内部转岗，直接进入终面。外部候选人没有这种展示机会，必须靠面试一次性证明。所以，如果你在SaaS公司，先在内部做数据项目，比直接海投有效得多。Notion更信“已验证的协作能力”，而非“简历上的技能列表”。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。