Cruise Data Engineer Interview Guide

Most data engineering roles blur together once you've seen enough job descriptions. Cruise's doesn't. From what candidates report in mock interviews, the gap that trips people up isn't SQL or Python fluency. It's the domain: autonomous vehicle sensor data at sub-second granularity, lakehouse architectures processing ride telemetry and perception model outputs, and a data platform built more in-house than most candidates expect.

Cruise Data Engineer Role

Your job is to own the pipelines and data models that feed Cruise's ML, safety, and operations teams. Concretely, that means writing PySpark transformations in Databricks that turn raw disengagement logs and ride telemetry into curated Delta tables other teams query directly. Success after year one means you own an end-to-end data domain (ride events, vehicle telemetry, perception outputs) where your pipelines hit SLAs, your models are the trusted source of truth, and you've pushed meaningful improvements to the internal data platform.

A Typical Week

The thing that catches candidates off guard is how much time goes to infrastructure and operational work, not just writing transformations. A broken Delta table partition from schema drift in an upstream perception service isn't a theoretical scenario here; it's a Monday morning. On-call rotations are real because a stale pipeline can block vehicle testing, not just delay a dashboard refresh.

Projects & Impact Areas

Cruise's internal data platform is more custom-built than most candidates assume, which means you're extending platform capabilities rather than wiring together managed services. A single quarter might have you redesigning a fact table's grain to accommodate new ride types while also building a PySpark pipeline that joins raw sensor logs with route metadata for the safety data science team. The connective tissue across all of it is geospatial and time-series data at volumes, and correctness requirements, that come from operating physical vehicles on public roads.

Skills & What's Expected

The most overrated skill for this role is ML knowledge; you're building the platform ML engineers consume, not training models. Production engineering discipline is what's underrated. The job descriptions emphasize CI/CD for data workflows, performance tuning of Spark jobs and Databricks clusters, security and compliance controls, and cost optimization for compute and storage, all rated higher than statistical depth or visualization chops.

Levels & Career Growth

The single biggest promotion blocker, from what we see across candidates, is doing strong individual pipeline work without ever leading the cross-functional alignment that makes it stick. Aligning schema evolution strategy with the perception team before their new model version breaks your Delta tables is the kind of work that separates levels. Cruise's engineering culture has historically rewarded IC depth over management track, so Staff+ roles carry real technical authority rather than being repackaged manager positions.

Work Culture

The role is listed as remote-first with occasional in-person collaboration, though you should confirm current team location and cadence directly with your recruiter since organizational details may have shifted. Engineering teams are protective of deep-work blocks, and most engineers work roughly 9 AM to 6 PM with occasional on-call evening pages. The culture emphasizes blameless postmortems and engineering ownership, but be honest with yourself about the uncertainty that comes with a subsidiary navigating strategic changes.

Cruise Data Engineer Compensation

The most negotiable levers in a Cruise offer are level, base salary band placement, equity grant size, and sign-on bonus. Expect a 4-year vesting schedule with a 1-year cliff, then monthly or quarterly vesting after that. Bonus percentage tends to be less flexible, so spend your negotiation capital elsewhere.

Your strongest move is bringing a competing offer and pairing it with a concrete impact narrative (owning large-scale GCP pipelines, domain modeling across teams, reliability improvements). Push especially hard on base and sign-on, since those pay out regardless of how Cruise's equity story evolves. During your recruiter screen, ask explicitly about the current refresh grant policy and how performance ratings affect future equity, because these details aren't always volunteered upfront.

Cruise Data Engineer Interview Process

Plan for about four weeks from your first recruiter call to an offer decision. Weak SQL and data modeling fundamentals are among the most common rejection reasons, from what candidates report. We're not talking about forgetting a syntax keyword. It's failing to reason about grain, writing joins that silently duplicate rows, or proposing a schema with no clear serving pattern for Cruise's AV ride and sensor data.

The behavioral round is where candidates who prep only for technical screens get caught. Cruise's engineering culture emphasizes ownership and safety-first thinking (they've written publicly about blameless postmortems and psychological safety), so interviewers in that final round are specifically probing whether you've owned pipeline incidents end-to-end and navigated data modeling disagreements with ML or mapping teams. Coasting on a strong system design performance won't save you if your behavioral stories are vague or interchangeable with any SaaS company's problems.

Cruise Data Engineer Interview Questions

1WITH base AS (
2  SELECT
3    vehicle_id,
4    session_id,
5    CAST(event_ts AS DATE) AS event_date,
6    event_ts,
7    odometer_m,
8    ROW_NUMBER() OVER (
9      PARTITION BY vehicle_id, session_id, event_ts, odometer_m
10      ORDER BY event_ts
11    ) AS rn
12  FROM raw_events
13), dedup AS (
14  SELECT vehicle_id, session_id, event_date, odometer_m
15  FROM base
16  WHERE rn = 1
17)
18SELECT
19  vehicle_id,
20  session_id,
21  event_date,
22  MAX(odometer_m) - MIN(odometer_m) AS distance_m
23FROM dedup
24GROUP BY vehicle_id, session_id, event_date;

1from pyspark.sql import functions as F
2
3# Inputs
4telemetry = spark.read.format("delta").table("raw.telemetry_frames")  # very large
5trips = spark.read.format("delta").table("dim.trip_metadata")          # large but smaller
6
7# Prefer shuffle join with AQE for stability
8spark.conf.set("spark.sql.adaptive.enabled", "true")
9spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
10
11# Right-size shuffle partitions, set via env or job config in practice
12spark.conf.set("spark.sql.shuffle.partitions", "4000")
13
14# Pre-filter early if possible to reduce shuffle
15telemetry_f = telemetry.where(F.col("event_date") >= F.date_sub(F.current_date(), 7))
16trips_f = trips.select("trip_id", "vehicle_id", "route_id", "start_ts", "end_ts")
17
18joined = (
19    telemetry_f
20    .join(trips_f.hint("shuffle_hash"), on="trip_id", how="inner")
21)
22
23# Write out with sane partitioning and file sizing
24(
25    joined
26    .repartition("event_date")
27    .write
28    .format("delta")
29    .mode("overwrite")
30    .option("overwriteSchema", "true")
31    .saveAsTable("canon.fact_telemetry_enriched")
32)

1/*
2Build a daily canonical fact table from raw telemetry.
3Assumptions (rename to match your schema):
4  - Table: `cruise_raw.telemetry_events`
5  - Columns:
6      vehicle_id STRING
7      event_id STRING
8      event_ts TIMESTAMP
9      ingest_ts TIMESTAMP
10      trip_id STRING
11      miles FLOAT64
12
13Outputs one row per (vehicle_id, event_date).
14*/
15
16WITH params AS (
17  -- In production, drive this from an orchestrator and process a bounded window.
18  SELECT
19    DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AS start_date,
20    CURRENT_DATE() AS end_date
21),
22
23scoped AS (
24  SELECT
25    vehicle_id,
26    event_id,
27    trip_id,
28    miles,
29    event_ts,
30    ingest_ts,
31    DATE(event_ts) AS event_date
32  FROM `cruise_raw.telemetry_events`
33  WHERE DATE(event_ts) BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
34),
35
36deduped AS (
37  SELECT
38    vehicle_id,
39    event_id,
40    trip_id,
41    miles,
42    event_date
43  FROM scoped
44  QUALIFY
45    ROW_NUMBER() OVER (
46      PARTITION BY event_id
47      ORDER BY ingest_ts DESC
48    ) = 1
49)
50
51SELECT
52  vehicle_id,
53  event_date,
54  COUNT(DISTINCT trip_id) AS unique_trips,
55  SUM(COALESCE(miles, 0.0)) AS total_miles
56FROM deduped
57GROUP BY vehicle_id, event_date;
58

This distribution is shaped by Terra and Cruise's lakehouse-on-GCP stack: pipeline design and Spark tuning dominate because the daily job is moving autonomous vehicle telemetry through Delta Lake layers on Databricks, not writing ad hoc queries. Where candidates get burned is prepping SQL window functions in isolation while ignoring the skills that actually compound in Cruise's interviews, like defending backfill strategies for late-arriving sensor data while simultaneously explaining how you'd handle partition skew in the underlying Spark job. The single biggest mistake is treating each topic area as independent when Cruise's questions routinely force you to cross boundaries, say, designing a canonical dataset grain and then justifying the GCS IAM pattern that secures it.

Drill Cruise-style questions across pipeline design, Spark tuning, and AV data modeling at datainterview.com/questions.

How to Prepare for Cruise Data Engineer Interviews

Here's the tension you need to understand before interviewing. Cruise's Terra platform was built to process massive volumes of autonomous vehicle sensor and telemetry data, a custom lakehouse architecture that feeds ML training, safety validation, and fleet operations. But GM paused robotaxi operations, Cruise subleased their SoMa office in 2024, and the company's trajectory is genuinely uncertain. As a candidate, you need to walk in with eyes open about both the technical depth and the organizational reality.

Most candidates blow their "why Cruise" answer by gushing about self-driving cars in the abstract. Interviewers have heard that pitch hundreds of times. What works: name Terra, explain why ingesting lidar point clouds and sub-second telemetry at fleet scale creates pipeline problems you can't solve with standard dbt runs, and be direct about the GM situation rather than pretending it doesn't exist. Cruise's engineering culture post highlights ownership and psychological safety. Acknowledging uncertainty while articulating why the technical challenge still pulls you in signals exactly the kind of maturity that post describes.

Try a Real Interview Question

1WITH bounds AS (
2  SELECT
3    vehicle_id,
4    TIMESTAMP_TRUNC(MIN(event_ts), MINUTE) AS min_minute,
5    TIMESTAMP_TRUNC(MAX(event_ts), MINUTE) AS max_minute
6  FROM vehicle_events
7  GROUP BY vehicle_id
8),
9vehicle_minutes AS (
10  SELECT
11    b.vehicle_id,
12    m.minute_ts
13  FROM bounds b
14  JOIN minute_dim m
15    ON m.minute_ts BETWEEN b.min_minute AND b.max_minute
16),
17events_by_minute AS (
18  SELECT
19    vehicle_id,
20    TIMESTAMP_TRUNC(event_ts, MINUTE) AS minute_ts,
21    ANY_VALUE(status) AS status
22  FROM vehicle_events
23  GROUP BY vehicle_id, minute_ts
24),
25joined AS (
26  SELECT
27    vm.vehicle_id,
28    vm.minute_ts,
29    ebm.status AS event_status
30  FROM vehicle_minutes vm
31  LEFT JOIN events_by_minute ebm
32    ON ebm.vehicle_id = vm.vehicle_id
33   AND ebm.minute_ts = vm.minute_ts
34),
35with_groups AS (
36  SELECT
37    vehicle_id,
38    minute_ts,
39    event_status,
40    SUM(CASE WHEN event_status IS NOT NULL THEN 1 ELSE 0 END)
41      OVER (PARTITION BY vehicle_id ORDER BY minute_ts) AS grp
42  FROM joined
43)
44SELECT
45  vehicle_id,
46  minute_ts,
47  MAX(event_status) OVER (PARTITION BY vehicle_id, grp) AS status,
48  CASE WHEN event_status IS NULL THEN 1 ELSE 0 END AS is_imputed
49FROM with_groups
50ORDER BY vehicle_id, minute_ts;

Cruise's SQL and data modeling round combines schema design with query writing under time pressure, often involving time-series AV ride data where late arrivals and null sensor readings are expected edge cases, not surprises. You'll want your window functions and CTEs sharp enough that you can focus your mental energy on modeling decisions rather than syntax. Practice these patterns at datainterview.com/coding.

Test Your Readiness

Find your weak spots, then close them with targeted practice at datainterview.com/questions.