我在 2026 年 2 月走完了 Notion 的 DS 面试 loop。发个复盘，因为 SQL、case 和 stats 的组合，跟我在其他偏 PLG 的 SaaS 公司看到的不太一样。
背景： 我是 mid-level DS，5 年经验，主要做增长和产品分析。投的是他们增长团队的 product DS 岗。
结构： Recruiter screen、take-home，然后三轮连续的线上面试：SQL/technical、product case、behavioral。
Take-home： 大概 3 小时。给了一个虚构数据集，让你回答一组产品问题。既有 SQL query，也有一小段书面解读结果。他们明确说会评估沟通质量，不只是数字对不对。SQL 要写得干净、可读，结论也要写好。不要只甩一堆数字给他们。
SQL round： 现场 45 分钟。两到三个题。其中一个是留存计算：给一张用户事件表，写 query 计算每个 cohort 的 N-day retention。这是 DS SQL 的基本功。window function 要非常熟。第二题是跨多个 event type 聚合 funnel 数据。不难，但 SQL 写得不严谨就会丢分。
Product case round： 最有意思的一轮。他们给了个场景：某个 Notion 功能的使用 engagement 在六周内下降了 15%。"Walk me through how you'd diagnose this." 用标准的产品分析结构就行：先把下滑拆分开，排除埋点/数据问题，找外部原因，再按 feature/cohort/surface 建假设。他们会追问你会不会区分 detection 问题和真实行为变化。这点很关键。
Stats questions： 轻到中等。A/B testing 的设定与解读，基础 p-value / type I vs. type II error，还有一题是当实验结果统计显著但效应很小该怎么办。最后这题偏判断题。要知道什么时候 statistical significance 不是 business significance。
总体：更偏 SQL 和产品判断，而不是 machine learning。如果你是偏重 ML、想找应用建模岗的 DS，这可能不是你预期的 loop。
7 条回复
analyst_ana (Primly starter)
「statistical significance vs business significance」这个问题就是那种看起来很简单，进到面试间就不一样的。我以前的回答基本是「显著就重要」，完全错。说得太对了。
由 AI 翻译，查看原文
de_derek (Primly starter)
用 window functions 写 N-day retention 可能已经是整个行业里最常见的 DS SQL 题了。如果你不能直接默写出来，那在任何偏 analytics 的面试之前都得先补上。
由 AI 翻译，查看原文
pivot_pat (Primly starter)
同意。另外也要确保你既能用 LAG/LEAD window functions 做，也能用 self-join 做，因为有些面试官想看两种思路。Notion 没特别强调这一点，但我在别的地方遇到过。
由 AI 翻译，查看原文
qa_quinn (Primly starter)
loop 之后 debrief 多久？还有，他们是在 take-home 之前就聊了 comp expectations，还是要到完整个 loop 才聊？
由 AI 翻译，查看原文
ux_uma (Primly starter)
comp expectations 在 take-home 之前的 recruiter screen 就提了。debrief 是在最后一轮 virtual 面完大概 8 天。第 9 天就给了 offer，我没想到会这么快。
由 AI 翻译，查看原文
bootcamp_bri (Primly starter)
这个「write good prose around your findings（用好的文字把你的结论写清楚）」的提醒太关键了。我见过很多 DS take-home 纯按输出准确度来评。Notion 会看沟通能力，从工作文化角度来说其实挺让人振奋的。
由 AI 翻译，查看原文
Primly Team
在这种流程里，很多人容易低估的一环是：拿到正确答案之后的写作质量。在这个级别的大多数产品 DS 流程里，reviewer 想看的，是你能不能把 SQL 输出变成一个决策。一个简单结构就很有用：用一句话写清问题，精确定义指标（cohort 定义、分子、分母、时间窗口、排除项），展示 query 或计算思路，然后给出解读：一个核心结论加一个 caveat（数据缺口、季节性、埋点）。常见翻车点是中途混用定义，比如 cohort 里用「activated users」，但留存分母又变成「all users」，或者在步骤之间改了时区和事件去重规则。你有假设就标出来，并解释你会怎么验证。
你在 Notion take-home 或 live SQL 里踩过哪些假设或指标定义的坑？时间压力下你是怎么处理的？
由 AI 翻译，查看原文