上季度走完了 ServiceNow 的 DS 面试流程，岗位是他们产品分析团队的 mid-senior data scientist。分享一下，因为我进去之前几乎在网上找不到任何关于这个 loop 的具体信息。
流程概览： Recruiter screen，technical phone screen（偏 DS），take-home case，onsite（4 轮）
Technical phone screen（45 分钟）： 感觉一半是 SQL 小测，一半是产品感觉的热身。SQL 题不刁钻，但确实在测真功夫： Window functions：running totals、分区内 rank、lag/lead 做留存 cohort 一个带 gap-fills 场景的 join 题（找 30 天窗口内没有任何活动的用户） 一个关于 query performance 的问题：同一个 filter 两种写法，哪种更快，为什么（index 使用、subquery vs. CTE 之类）
这一轮没有 Python。
Take-home case： 他们给了我一个假的 ServiceNow 平台事件和用户行为数据集。问题包括：描述 adoption curve、找出客户 churn 的 leading indicators、为某个功能改动提出 A/B test 设计。我有 5 天时间，最后交了一个带注释的 Jupyter notebook。
我大概花了 8 小时。分析不需要很复杂，他们想看你怎么把业务问题框起来、怎么做分析、以及怎么把「所以呢」讲清楚。别去堆一个巨大的模型，很多时候 descriptive stats 加一张好图就能讲清故事。
Onsite DS 轮次： SQL 深挖，45 分钟，比 screen 难。一个多表 join + aggregation 加一个很刁钻的条件，一个关于事件序列的 windowing 题。 统计 / 概率，30 分钟。Bayesian reasoning、A/B test power 计算、一个关于 Simpson's paradox 以及它什么时候会出现的问题。 ML / 建模讨论，45 分钟。不写代码。让我从头到尾讲一个我做过的模型。怎么处理 class imbalance？怎么给非技术 stakeholder 解释模型？你会怎么做得不一样？ 跨职能合作轮：模拟对话，我是 DS，他们扮演一个 product manager，让我做一个定义不清的东西。我怎么 scope，需要什么数据，怎么 push back？
Stats 坑点： Simpson's paradox 那题一开始把我绊住了。这个一定要烂熟。他们明显很在意统计严谨性，以及你能不能在东西进 dashboard 之前抓住误导性的 aggregation。
整体：loop 很扎实，感觉他们是真的想要一个靠谱的 data scientist，不是 SQL 苦力，也不是纯 ML engineer。跨职能那轮是分水岭。