Adobe · Primly 社区

Adobe data scientist 面试:SQL、case、统计,以及真正重要的点

ds_dmitri (Primly starter) · 5 条回复

我走完了 Adobe 的 DS interview loop,团队是他们的 Digital Media analytics。做 DS 五年了,这是我第四个公司 loop,所以有比较的参照。下面是我的观察。

整体结构 先是 recruiter phone screen,然后是 technical screen,再是一个完全线上 virtual onsite,共四轮。

technical phone screen 30-45 分钟。两道 SQL 和一道轻量 stats。SQL 是中等难度:一道多表 join 加聚合,一道 window function(rank、lag 之类)。stats 问题是 A/B testing:如何决定样本量,什么是 statistical power,commit 一个 Type II error 是什么意思。

提示:A/B testing 的 stats 问题每次都会出现。在 Adobe 尤其重要,因为他们在 Creative Cloud 上做非常大的实验。要会在不打太多太极的情况下解释 p-values。

onsite 轮次 SQL deep dive(45 分钟):更难的查询。我遇到一道题是计算 cohort 的 7-day rolling retention。还有一道是从 raw clickstream 表里对 events 去重。这些都是现实业务问题,不是脑筋急转弯。 stats and probability(45 分钟):Bayesian vs frequentist 的框架(他们问我更偏好哪个以及原因),confidence intervals,一个不算太难的 probability 脑筋题,但会考你能不能把思路说出来。还有一道关于如何处理模型里 imbalanced classes。 product case(45 分钟):给了一份关于 Acrobat DC 用户行为的数据集,你会问什么问题,怎么组织分析?我需要选一个要提升的指标并解释理由。感觉像 DS/PM 的混合轮。 behavioral(45 分钟):和 PM、SWE 那边一样。Adobe 范围内关于协作、模糊性、影响力的问题。

他们最看重的点 说实话:SQL 熟练度和沟通。很多 DS 候选人 stats 知识没问题,但跟非技术方解释时就崩了。product case 那轮就是专门考这个的。「how would you explain this finding to the marketing team(你会怎么把这个发现解释给市场团队)」出现了两次。

难度对比其他 DS loops stats 深度比 Netflix 或 Airbnb 更简单。SQL 细节上比大多数中型公司更难。整体比较贴近实际。

由 AI 翻译,查看原文

5 条回复

analyst_ana (Primly starter)

7-day rolling retention 的 SQL 题很值得准备。我已经在四家公司见过变体了。难点通常是把 cohort date 处理对,以及别把第 3 天和第 7 天都回来的用户重复算。对方更在意精确语法,还是更在意思路?

由 AI 翻译,查看原文

de_derek (Primly starter)

clickstream 去重是我最不喜欢的面试题,因为答案太依赖你的 event schema 长什么样。他们一开始就给了 schema,还是题目的一部分就是让你自己想需要哪些列?

由 AI 翻译,查看原文

ds_dmitri (Primly starter)

他们给了一个简化 schema:eventid, userid, eventtype, timestamp, sessionid。去重规则是同一个 session 内按 (userid, eventtype, timestamp) 去重,允许 1 秒的容差窗口。我用了 ROW_NUMBER 分区的做法。他们说有多种有效做法。

由 AI 翻译,查看原文

ml_mike (Primly starter)

DS loop 里问 imbalanced classes 挺有意思。他们是想听 SMOTE、class weights、threshold tuning,还是只是想看你知道这个问题存在?有时候感觉像是个暗号题。

由 AI 翻译,查看原文

Primly Team

在这种 DS loops 里,有个环节经常被低估:SQL 和实验题里的业务框定。就算 prompt 看起来很纯技术(rolling retention、clickstream 去重),面试官往往希望你先停一下,把定义锁死:什么算「active」用户,event-time vs ingest-time 是什么,session 边界怎么定,延迟事件怎么处理,bot、跨设备身份怎么处理,以及留存是按 first-touch cohort 还是 last-touch。

一个读出来也很顺的简单结构: 1) 复述指标和分析单位,2) 列假设和边界情况,3) 写一个正确的 baseline query,4) 再优化或验证(sanity checks、期望区间)。

在产品分析面试里,你见过哪个指标定义或数据质量边界情况最容易把候选人绊倒?

由 AI 翻译,查看原文