VMware · Primly Community

VMware data engineer interview: pipelines, SQL, and what actually tripped me up

de_derek · 4 replies

Finished my VMware data engineer interview loop last month, senior level, remote role on their cloud infrastructure data team. Posting because I found almost nothing useful online about their DE process specifically.

The loop was four rounds after a recruiter screen:

Round 1: SQL + data modeling, 45 min. This was the real filter. They opened with a schema they'd designed themselves (something like a simplified vCenter telemetry schema: hosts, VMs, resource pools) and asked me to write window functions to compute running averages, identify outliers, and do a multi-table join with some tricky NULL handling. Not Leetcode-style, more like 'here is a real schema, show us you can use it.' They explicitly said they test SQL this way because it's closer to what the job is.

Then they asked me to design a data model for a new ingestion use case. I drew a medallion architecture (bronze/silver/gold) and talked through partitioning strategy. They pushed back a bit on my partitioning choice, which felt like a technical conversation more than a gotcha.

Round 2: Python + pipelines. Coding in a shared IDE. One task was to write a pipeline that reads from a Kafka topic (mocked), transforms records, and writes to a target with deduplication. They cared about error handling and idempotency. I leaned hard on 'what happens if this step fails halfway' and that seemed to land well.

Round 3: System design for data. 'Design a pipeline to ingest VM performance metrics at scale.' Classic. Talked through Kafka, Flink/Spark Streaming, Delta Lake, monitoring. They asked a lot about late-arriving data and exactly-once semantics. The interviewer had opinions; it felt like a back-and-forth, not a quiz.

Round 4: Behavioral. Straightforward STAR. Cross-team conflict, a time I pushed back on a technical decision, a project I'd do differently.

Offer came in about ten days later. Process was organized, feedback was real. The SQL round is the one to prepare hardest for. Window functions, CTEs, and be ready to talk about your indexing choices.

4 replies

analyst_ana

Thanks for this. Did they ask anything about dbt or orchestration tools like Airflow? Trying to figure out if I need to brush up on those or focus entirely on raw SQL and Python.

sec_sasha

They mentioned Airflow during the system design conversation but didn't test it directly. I brought it up myself when talking about scheduling and they seemed comfortable with it. I'd say know it enough to talk about it intelligently but don't expect a deep dive.

ae_andre

The NULL handling in SQL interviews is always the tell. Most people say they know SQL until the NULLs show up. Sounds like they run a real interview. Did they give you any take-home or was it entirely live coding?

sdr_sky

The late-arriving data question is genuinely hard to prep for if you haven't dealt with it in production. For anyone reading: look up watermarks in Flink/Spark Streaming and know the tradeoffs between event time and processing time. That question shows up at VMware, Snowflake, and a bunch of infrastructure-adjacent companies.