Morgan Stanley · Primly 社区

Morgan Stanley data engineer 面试,pipelines 和 SQL:他们真正考什么

de_derek (Primly starter) · 5 条回复

刚结束 Morgan Stanley data engineer 的完整流程,面的是他们 enterprise data platform 组的 VP 级别 DE。趁记忆还新鲜分享一下,因为我准备时完全找不到靠谱的细节。

总共四轮: Recruiter screen(30 分钟,常规) 技术 SQL 和数据建模(60 分钟,一位面试官) 数据 pipeline 设计 / 架构(60 分钟,senior engineer 面试官) Behavioral(30 分钟,hiring manager)

没有传统意义上的 DSA live coding。这不是 LeetCode 重的 loop。非常聚焦 data engineering 这件事本身。

SQL 轮:

是真 SQL,不是伪代码。在共享编辑器里做。题目包括: 复杂 window functions(running totals、分区内 rank、做时间序列分析的 lag/lead) 多表 join 题,schema 像 trade history + account data。schema 会给。 一题问 query 性能:给你一个慢 query,你怎么诊断和修。想听到:看 query plan,看 indexes,考虑对大型时间序列表做 partitioning。

SQL 题比我在其他地方遇到的大多数 SQL 面试题都难。他们默认你是真的在用 SQL,不是只知道 SELECT 是什么。

Pipeline design 轮:

题目:设计一个 pipeline,摄入实时 market data,加工后用于下游 risk 计算,并以一种既支持历史查询又支持实时 dashboard 的方式存储。

他们想听到很具体的点:摄入用 Kafka vs 其他方案,batch vs streaming 处理(Spark、Flink 或类似),存储层选择(为什么 analytics 用 columnar),以及延迟 SLA。他们也会追问数据质量:消息乱序或重复怎么办。

金融领域在这里很关键。他们会追问「what happens if you miss a tick(如果你漏掉了一个 tick,会发生什么?)」,答案不是「晚点重试」,而是「我们怎么检测缺口,怎么 backfill,怎么告警」。

他们看起来熟悉的工具: Kafka、Spark、dbt、Snowflake,还有一些内部自研系统,他们提了名字但我没听过。

由 AI 翻译,查看原文

5 条回复

ds_dmitri (Primly starter)

window function 的深度对金融数据岗位来说挺合理的。金融数据的 time-series SQL 基本离不开 LAG/LEAD,一直在用。知道他们真的会在 DE 级别考这个很有用。

由 AI 翻译,查看原文

analyst_ana (Primly starter)

他们有问 data governance 或 lineage tooling 吗?想知道他们是不是在用像 DataHub 或 Collibra 这样的东西。

由 AI 翻译,查看原文

de_derek (Primly starter)

简单提到过。hiring manager 在 behavioral 轮提了数据血缘是个顾虑,但没人考我具体工具。我提了下 dbt 的 lineage graph 作为过往工作里的例子,效果还不错。

由 AI 翻译,查看原文

alex_design (Primly starter)

「What happens if you miss a tick(如果你错过一个 tick 会发生什么)」是个信号很强的问题。如果你对这个没有立刻的答案,那你就没在真实的金融数据上跑过 pipeline。

由 AI 翻译,查看原文

Primly Team

在 VP 级别的 DE 流程里,很多人常常低估的一环是 pipeline 设计里的「需求澄清」。即使问题听起来像「design an ingestion and transformation pipeline,(设计一个数据摄取与转换 pipeline)」,面试官通常也在看你能不能把模糊的需求变成具体的 contracts:数据生产者和消费者、freshness 和 backfill 预期、延迟和正确性的 SLO、schema 演进规则,以及你如何处理晚到或被更正的事件。

一个好用的结构是:澄清输入输出,选定 grain 和 keys,定义幂等性与去重策略,然后讲可观测性(数据质量检查、lineage、告警),最后覆盖失败模式(重试、poison messages、重放、局部故障)。常见失败是先跳到工具选型而不讲 invariant,导致很难评估 tradeoffs。

做过这轮的同学:哪个「澄清问题」最能改变设计讨论的走向?

由 AI 翻译,查看原文