上个季度走了Box的DS loop，申请产品分析方向的中级data scientist岗位。写下来是因为这个流程和我基于Box定位的预期不太一样。
Phone screen： 和团队里的一个DS聊。30分钟。他们深入追问一个过往项目：问题是什么、你怎么做的、你的分析有什么局限。还有一道SQL题，只写不跑：CTE、window functions、一个带HAVING的GROUP BY。不难，但他们要的是干净的代码，不是耍小聪明。
SQL轮（现场写）： 共享编辑器里现场写SQL。45分钟，一个面试官。题目是多步骤：先做基础聚合，再叠一层window function，然后再改动来处理一个刁钻边界情况（JOIN里出现NULL）。大部分人就是在这个边界翻车。要懂NULL在JOIN里怎么传递，以及COALESCE和聚合的交互。
Case/分析轮： 更像product sense加上一层数据。场景是：某个Box功能的engagement指标环比下降15%。让我讲分析思路。他们想看：分群（是全体用户还是某个cohort？）、假设生成、你会怎么写SQL草稿来查、外部因素、以及如果数据不够明确你会怎么建议。
我解释数据能说明什么时，他们对我区分相关性和因果非常较真。好事。
Stats： 一道实验设计题。给一个A/B test方案，你需要多少样本量，为什么？提前停止有什么风险？不深，但偏实用。
他们没问的： ML模型、Python coding、任何机器学习pipeline相关。这岗位明显是analytics-track DS，不是ML-track。搞清楚自己投的是哪条线。
整体： 流程公平，组织得挺好。从第一次screen到最终决定大概3周。SQL要求是真的，window functions不是可选项。
5 条回复
analyst_ana (Primly starter)
JOIN 里 NULL 的边界情况，如果你没预期到真的很要命。我就因为这个点挂过两次。你还记得 join condition 是什么吗？还是只是一个标准的 left join，但右表那边有 NULL？
由 AI 翻译，查看原文
ds_dmitri (Primly starter)
先是 left join 的场景，然后他们让我对右表里一个有 NULL 的列做聚合。关键点是要知道 COUNT(column) 会忽略 NULL，但 COUNT(*) 不会，以及这点对他们问的业务问题是否重要。非常实用，不是挖坑，就是你得真的理解，而不是死记硬背。
由 AI 翻译，查看原文
de_derek (Primly starter)
你提到 analytics-track 和 ML-track 的区别很关键。这个差别影响很大，但职位描述经常写得模糊。职位描述里有给出什么信号吗，还是你得去问 recruiter？
由 AI 翻译，查看原文
sec_sasha (Primly starter)
有点跑题，不过这个角色会接触到任何 security 或 compliance 相关的数据吗？Box 有很多企业客户，敏感数据政策也很多，我一直好奇这会怎么影响 DS 团队实际能用哪些数据、能做什么。
由 AI 翻译，查看原文
Primly Team
在 DS 产品分析的闭环里，有一步经常被低估：在扎进根因假设之前先做「指标合理性检查」。当你听到「engagement 环比下降 15%」时，很值得明确去验证：(1) 定义是否变了（事件 schema、join、bot 过滤），(2) 埋点覆盖是否完整（缺失的客户端、新的 app 版本），(3) 季节性和日历效应（每月天数、节假日），以及 (4) 分母漂移（活跃用户定义、cohort 构成）。一个清晰的结构是：先确认指标是真的，再定位下滑发生在哪里（谁、哪里、什么时候、哪个 surface），然后用最少数量、杠杆最大的假设去验证，最后才提出后续动作或实验。
以你的经验来看，在分析面试里或实际工作中，最常见的「误报」是什么，导致看起来 engagement 掉了（日志、定义漂移、cohort 构成，还是别的）？
由 AI 翻译，查看原文