Roblox · Primly Community

Roblox data engineer interview, pipelines and SQL: here's what they test

analyst_ana (Primly starter) · 5 replies

Went through the Roblox DE loop in January 2026. There's almost nothing online specific to their data engineering interview so I'm writing this up.

The process (DE-specific): Recruiter screen (30 min, standard) Technical phone screen (60 min, mixed SQL + pipeline design) Onsite loop: SQL deep-dive, system design for data, behavioral, hiring manager

SQL round: The SQL was harder than I expected. Not just aggregations and joins. They gave me a scenario involving event-stream data from user sessions in a game. I had to write a query to calculate session durations, handle null end events (players crash or close the app), and find users with unusual patterns. Window functions were essential. They also asked me to optimize a slow query with a query plan walkthrough, which I hadn't seen at other companies at this stage.

Know: CTEs, window functions (LEAD, LAG, ROW_NUMBER), partition by, handling nulls in event data, writing queries that don't do full table scans on huge tables.

Pipeline design round: This was the most Roblox-specific part. They described a scenario: you need to build a pipeline that ingests real-time player activity events from millions of concurrent sessions, transforms them, and makes them available for both real-time dashboards and batch ML feature generation. Classic lambda vs. kappa architecture tradeoff.

They cared about: exactly-once semantics (or why you'd accept at-least-once), latency requirements for the real-time path, idempotency in the batch path, and how you'd handle schema evolution as the game events change.

Tools I mentioned: Kafka for ingest, Spark Structured Streaming for the real-time path, dbt for the batch layer. They mentioned they use Spark internally so that felt relevant.

Behavioral: Mostly focused on cross-team work and handling ambiguous requirements from analytics stakeholders. Same ownership themes as the SWE behavioral rounds.

Comp: I ended up with $195k base for a senior DE role, RSUs made it higher but I don't want to be specific. Felt slightly below what I've seen for senior SWE at the same level but DE band is what it is.

5 replies

analyst_ana (Primly starter)

Did they ask about specific tools like Airflow or Prefect for orchestration or was it more tool-agnostic?

de_derek (Primly starter)

Mostly tool-agnostic in framing but I mentioned Airflow and they were familiar with it. I got the sense they use a mix internally. Don't just list tools though, explain why you'd choose one over another for the tradeoffs in the scenario.

alex_design (Primly starter)

The event-data SQL with nulls is a classic. That exact pattern (handling missing end events) is on a lot of gaming company interviews. Makes sense given the domain.

de_derek (Primly starter)

Yeah, honestly the SQL prep I should have done was more gaming-data-specific. Session data, funnel analysis, retention cohorts. All of that came up in some form.

Primly Team

One stage people underestimate in DE loops like this is requirements clarification before you write anything. With event stream sessionization, interviewers often want to see you define the contract: what is a “session start”, what counts as a valid “end”, how you handle missing ends (timeout window, last-seen heartbeat), late and out-of-order events, and whether you dedupe by event_id. If you state those assumptions up front, your SQL and pipeline design get much cleaner.

A useful structure is: (1) restate the business metric, (2) list edge cases, (3) propose a baseline query, (4) add correctness fixes (ordering, null handling, dedupe), (5) then performance levers (partition pruning, pre-aggregation, incremental models).

Common failure mode is jumping to window functions without proving ordering keys and uniqueness, which can silently double-count.

What assumptions did you find you had to negotiate explicitly in your session data question, and which ones surprised you?