OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
一般都是60min，分成三个part：聊简历 + 两个sql题 + 一个python题。面试官可能在San Jose 或者国内。PT 6pm之后一般都是国内的面试官，PT 6pm之前一般都是美国面试官。国内的面试官100%讲中文，美国的面试官小概率讲中文。
面试一开始是简历deep dive。这一部分总体以candidate的输出为主，没有特定的考点，只要你的项目和data engineering相关，并且足够熟悉就没啥问题。在一个真实案例中，面试官让 candidate 从项目中挑一个最能体现数据工程能力的例子，candidate 选择讲一个基于 Kinesis + Flink 的实时用户行为分析系统。candidate 主要介绍了从数据采集、实时计算到下游入库的整体链路。面试官问到如何应对 Flink 的 checkpoint 延迟或状态膨胀问题，candidate 解释说可以通过调整 RocksDB state backend、控制 checkpoint 频率，以及给状态数据设置 TTL 来避免积压。面试官还问当流处理任务出现 back pressure 时该如何排查。
第二部分是两道 SQL 题，在 HackerRank 平台上完成。第一题考的是用户活跃度增长分析，要求根据用户注册与事件表计算每日活跃用户数，并统计相较前一天的增长率。面试官进一步追问如何在大规模数据下优化查询，candidate 提到可以按日期字段进行表分区，配合日期范围过滤避免full table scan。第二题是关于content creator内容互动的分析，需要从多张表中进行 JOIN，计算过去一段时间内 engagement 得分最高的creator。面试官继续问如果事件表规模达到亿级，如何优化大表 JOIN。candidate 回答可以通过 broadcast join 或预聚合 summary 表降低计算量；在分布式环境下，也可以使用窗口函数与 CTE 优化查询逻辑。这部分总体难度中等，更注重分析清晰度与优化思路。
最后一部分是 Python 编程题，同样在 HackerRank 平台完成，难度低于 SDE 面试。题目要求在一组用户日志中找出满足特定行为模式的用户，例如连续执行相同行为达到一定次数。candidate 的解法是先按用户分组并根据时间排序，再用单次遍历统计连续出现的行为次数，时间复杂度为 O(n log n)。面试官随后追问了followup（感觉是临时想出来的）：如果日志是乱序输入的分布式数据流，如何保证处理顺序；以及当数据量过大无法一次性加载内存时，如何处理。candidate 分别解释了可以通过时间分桶与 watermark 控制乱序日志的延迟窗口，也可以使用流式处理或外部排序的方式分批计算。