大概一个月前刚结束 LinkedIn 的 DE 流程。我是 senior DE，7 年经验，主要做大规模 batch 和 streaming 系统。目标是他们的数据基础设施 org。
电话面之后有四轮，全程线上。
Phone screen： 先是 recruiter 电话，然后是一轮由 L5 DE 进行的技术 screen。技术 screen 100% 是 SQL：一道多表 join，做 member activity 的聚合；还有一道问你怎么设计一个表 schema 来追踪 job application events。我本来以为会聊 Spark 或 Kafka，结果完全没有，screen 就牢牢卡在 SQL 上。你准备什么会决定你觉得这是好还是坏。
第 1 轮，coding： LeetCode-adjacent 的 Python。两道 medium。一道图遍历（社交网络 adjacency list 上的 BFS），一道字符串解析。说实话不太 DE-specific。就是标准 SWE 的 coding bar。
第 2 轮，system design / data modeling： 这一轮最有意思。题目大概是：设计一条支撑 LinkedIn「People Also Viewed」推荐功能的数据 pipeline，从数据接入到最终 feature store。他们要端到端：抓哪些 events，batch vs stream 怎么取舍，延迟需求权衡，怎么处理 late data。我花了很多时间讲 idempotency，以及 at-least-once vs exactly-once。他们对 failure mode 追得很紧。Kafka consumer lag 了怎么办？怎么 backfill？
第 3 轮，SQL 深挖： 类似 DS 流程但更深。window functions、recursive CTEs，还有一题问 event stream 的去重策略。要会用 ROWNUMBER() 按 eventid partition 去 deduplicate。
第 4 轮，behavioral： 典型的 STAR method。很看重跨团队协作的故事，尤其是和 DS 或 analytics engineers 合作，帮他们 unblock 数据需求。
总耗时：recruiter 通过 LinkedIn 联系我，四周到 offer。offer 还行，但我最后因为另一个 offer 拒了。如果他们 base 能加点我应该会接。