Morgan Stanley data engineer interview, pipelines and SQL

Morgan Stanley data engineer interview, pipelines and SQL: what they actually test

de_derek (Primly starter) · 5 replies

Just wrapped my Morgan Stanley data engineer loop for a VP-level DE role in their enterprise data platform group. Sharing notes while they're fresh because I could not find good specifics when I was prepping.

The loop had four rounds: Recruiter screen (30 min, standard) Technical SQL and data modeling (60 min, one interviewer) Data pipeline design / architecture (60 min, senior engineer interviewer) Behavioral (30 min, hiring manager)

No live coding in a traditional DSA sense. This is not a LeetCode-heavy loop. It's very focused on data engineering specifically.

SQL round:

Actual SQL, not pseudocode. We were in a shared editor. Questions included: Complex window functions (running totals, rank within partition, lag/lead for time-series analysis) A multi-table join question with a schema that looked like trade history + account data. The schema was given. One question about query performance: given a slow query, how would you diagnose and fix it. They wanted to hear: check the query plan, look at indexes, consider partitioning for large time-series tables.

The SQL questions were harder than most SQL interview questions I've gotten elsewhere. They assume you actually use SQL, not just know what SELECT is.

Pipeline design round:

Prompt: design a pipeline that ingests real-time market data, processes it for downstream risk calculations, and stores it in a way that supports both historical queries and live dashboards.

They wanted specifics on: Kafka vs. alternatives for ingestion, batch vs. streaming processing (Spark, Flink, or similar), storage layer choices (why columnar for analytics), and latency SLAs. They probed data quality: what happens when a message arrives out of order or is duplicated.

The financial domain matters here. They pushed on "what happens if you miss a tick" and the answer is not "retry later," the answer is "here's how we detect gaps, here's how we backfill, here's how we alert."

Tools they seemed familiar with: Kafka, Spark, dbt, Snowflake, internal proprietary systems they mentioned by name but I didn't recognize.

5 replies

ds_dmitri (Primly starter)

The window function depth sounds about right for financial data roles. Time-series SQL on financial data requires LAG/LEAD constantly. Good to know they actually test it at the DE level.

analyst_ana (Primly starter)

Did they ask about data governance or lineage tooling at all? Wondering if they're using something like DataHub or Collibra.

de_derek (Primly starter)

Briefly. The hiring manager mentioned data lineage as a concern in the behavioral round but nobody tested me on specific tooling. I brought up dbt's lineage graph as an example from past work and it landed fine.

alex_design (Primly starter)

"What happens if you miss a tick" is such a great signal question. If you don't have an instant answer to that you've never run a pipeline on real financial data.

Primly Team

One stage people often underestimate in VP-level DE loops is the “requirements clarification” part of pipeline design. Even when the question sounds like “design an ingestion and transformation pipeline,” interviewers usually watch whether you can turn a vague request into concrete contracts: data producers and consumers, freshness and backfill expectations, SLOs for latency and correctness, schema evolution rules, and how you will reconcile late or corrected events.

A useful structure is: clarify inputs and outputs, choose the grain and keys, define idempotency and dedupe strategy, then cover observability (data quality checks, lineage, alerting), and finally failure modes (retries, poison messages, replay, partial outages). A common failure is jumping straight to tool choices before stating the invariants, which makes it hard to evaluate tradeoffs.

For folks who have done this loop, what “clarifying question” seemed to change the direction of the design discussion the most?