Thirty-five minutes into her Uber onsite, a data engineer I'll call Divya had written a beautiful query for "average wait time per city." The interviewer nodded, then asked the question that ended the round: "It's 6pm Friday in Bangalore. Surge is live. Half your driver-location events are arriving eleven seconds late and some arrive twice. Is your average still true?" Divya's query was correct. Her system was fiction. She had prepared for a database. Uber interviews you about a moving marketplace.
That's the defining feature of Uber data engineer interview questions: nothing sits still. Trips, drivers, prices and ETAs all change while your pipeline is running, so every question eventually becomes a question about late data, duplicates and freshness. I built Greenroom after freezing in a round where I knew the material and still couldn't say it, so this guide covers both what Uber asks and how to answer it out loud.
The Uber data engineer interview process in 2026
Uber hires data engineers into several orgs — Rides, Eats, Freight, and the central data platform — and the loop is broadly consistent across them. What candidates report as the Uber data engineer interview process:
- Recruiter screen — background, location, and which org. Ask: platform teams go deeper on distributed systems, product teams go deeper on analytics and modeling.
- Technical screen — about an hour of SQL on trip and driver data, plus practical Python, usually in a shared editor with the interviewer watching you type.
- Virtual onsite — typically one day, four to five rounds: a SQL/coding round, a data modeling round, a pipeline/system design round, and behavioral.
- Bar raiser — an interviewer from outside the hiring team whose job is to protect the hiring bar. Amazon made the name famous; Uber runs its own version, and it carries disproportionate weight.
Two practical consequences. First, the onsite is compressed into one day, so pacing matters — candidates lose rounds by spending twenty minutes on a query they could have written in eight. Second, the bar raiser has no stake in filling this role, which means they will happily keep pushing until you say "I don't know." Saying it cleanly is a pass, not a fail.
Uber data engineer SQL interview questions
The Uber SQL interview questions are all framed on marketplace data: trips, drivers, riders, requests that never became trips. The recurring shapes are funnels, sessionization and time-windowed aggregation.
Compute the request-to-trip funnel by city and hour.
Uber's core health metric is the gap between demand and fulfilment. Conditional aggregation over a request table is the workhorse:
SELECT city_id,
DATE_TRUNC('hour', requested_at) AS hr,
COUNT(*) AS requests,
COUNT(*) FILTER (WHERE matched_at IS NOT NULL) AS matched,
COUNT(*) FILTER (WHERE completed_at IS NOT NULL) AS completed,
ROUND(100.0 * COUNT(*) FILTER (WHERE completed_at IS NOT NULL)
/ NULLIF(COUNT(*), 0), 2) AS completion_pct
FROM ride_requests
WHERE requested_at >= NOW() - INTERVAL '7 days'
GROUP BY city_id, DATE_TRUNC('hour', requested_at);The NULLIF is not decoration — an interviewer will ask what happens in a city with zero requests in an hour, and "it divides by zero" is a real answer given by real candidates. Then come the follow-ups: which timezone is requested_at in, and does an hour bucket in a city on a DST boundary still contain sixty minutes? Our SQL interview questions guide drills the aggregation and window-function family.
Find each driver's longest streak of consecutive active days.
The gaps-and-islands pattern shows up constantly in driver-supply analysis:
WITH d AS (
SELECT DISTINCT driver_id, active_date,
active_date - (ROW_NUMBER() OVER (
PARTITION BY driver_id ORDER BY active_date
) * INTERVAL '1 day') AS grp
FROM driver_activity
)
SELECT driver_id, COUNT(*) AS streak_days,
MIN(active_date) AS streak_start
FROM d
GROUP BY driver_id, grp
ORDER BY streak_days DESC;Be ready to explain why subtracting the row number collapses a consecutive run into a constant group. Reciting the trick without the reasoning is the most common way to half-pass this question.
Python and data wrangling in the Uber DE loop
Uber's coding round leans practical rather than algorithmic — you'll be asked to process events, not to invert a binary tree. A very common shape is deduplicating or reconciling a stream of location pings:
def latest_pings(pings, window_secs=300):
"""Keep the newest ping per driver, dropping anything older than the window."""
newest = {}
horizon = max(p["ts"] for p in pings) - window_secs
for p in pings:
if p["ts"] < horizon:
continue
cur = newest.get(p["driver_id"])
if cur is None or p["ts"] > cur["ts"]:
newest[p["driver_id"]] = p
return list(newest.values())Then say the part that scores: this holds every active driver in memory, which is fine for one city and not for a global stream — at that point it becomes a keyed state store in Flink with a TTL. Volunteering the scaling limit before you're asked is the single highest-leverage habit in this loop. The Python interview questions guide covers the language layer.
Streaming pipeline design: the round Uber actually cares about
Uber built and open-sourced Apache Hudi to solve one specific problem — upserting late-arriving records into a data lake without rewriting entire partitions — and its engineering blog documents a stack of Kafka, Flink, Spark, Hudi and Presto. You don't need to have run that stack, but you must reason at its altitude:
- Design the trip-events pipeline — millions of events a minute. State the freshness requirement out loud first: a fraud rule needs seconds, a weekly finance report does not.
- Late and out-of-order events — event time vs processing time, watermarks, allowed lateness, and what you do with the event that shows up an hour after its window closed.
- Exactly-once and upserts — idempotent writes, dedup keys, and why an append-only lake gets painful the moment a trip's fare is corrected after the fact.
- The surge/dynamic-pricing feed — a genuinely real-time path with a hard latency budget, sitting beside a batch path serving the warehouse.
- Backfills — a bug corrupted three days of trip data across every city; recover without taking the executive dashboards down.
There is no single correct architecture, and interviewers know it. What's scored: do you ask about requirements before drawing boxes, do you name tradeoffs unprompted, and do you change your design gracefully when pushed. The data engineer interview questions guide covers the ETL and warehousing fundamentals, our Kafka interview questions guide covers the streaming layer, and the Uber data engineer prep page has a compact round-by-round checklist.
The bar raiser and behavioral round
Uber's behavioral round is not filler. The bar raiser is explicitly looking for evidence of ownership and judgment under ambiguity — the daily reality of working on a marketplace where the data is always slightly wrong and someone always needs an answer by 4pm.
Expect: a time you shipped something wrong and how you found out; a time you had to pick between fast and correct; a disagreement with an analyst or PM about a number. Two minutes each, first person, with real figures. "The pipeline was slow" is nothing; "the nightly job took 6 hours and blocked the 7am ops dashboard, I repartitioned on city_id and got it to 40 minutes, and I broke one downstream job doing it" is a hire signal. Our tell me about a time you failed guide has the structure, and the Amazon leadership principles guide is worth reading purely because the bar-raiser mechanic is the same idea.
LeetCode, StrataScratch, the Uber blog — where each fits
An honest map of the prep stack for this specific loop:
- LeetCode — moderately useful. Keep a light daily habit for Python fluency, but Uber's DE coding round is data wrangling, not competitive programming. Hard DP is misallocated time.
- StrataScratch and DataLemur — the closest written practice to Uber's actual SQL, and StrataScratch in particular carries real Uber-style marketplace questions. Their limit: they grade the query, and Uber grades the follow-up conversation.
- The Uber Engineering blog — the best free company-specific prep available. Read the posts on Hudi, on the real-time platform, and on their data lake architecture; you'll speak the interviewers' vocabulary honestly instead of guessing.
- GeeksforGeeks and Blind interview experiences — decent for calibrating format and difficulty. Anecdotes, not a syllabus.
- ChatGPT — good for generating design prompts and critiquing a written answer. It won't interrupt you mid-sentence with "what if the event is an hour late?" the way the design round will.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud, pushes back when a pipeline answer hand-waves past late data, and scores structure and clarity. Fair tradeoff: Ari won't teach you Hudi internals; pair it with the engineering blog.
How to prepare for the Uber data engineer interview
- Week 1: SQL on marketplace shapes — funnels, conditional aggregation, sessionization, gaps-and-islands. Write each, then re-explain it aloud in ninety seconds without reading.
- Week 2: practical Python daily — event dedup, reconciliation, joins without pandas — always ending with "and here's where this breaks at scale."
- Week 3: streaming design. Read three Uber Engineering posts, then design aloud: the trip-events pipeline, the surge feed, and a three-day backfill. Twice each, defending every tradeoff.
- Final week: five behavioral stories in first person at two minutes, two full spoken mocks with pushback, and the role-specific prep page the night before — not new material.
If other big-tech data loops are on your calendar, they rhyme but weight differently: the Amazon data engineer guide covers Leadership-Principles-in-every-round, the Microsoft data engineer guide covers the Azure and as-appropriate version, the Netflix data engineer guide covers the culture-memo version, and the general Uber preparation guide covers the SWE track.
Frequently asked questions
What is the Uber data engineer interview process?
Candidates consistently report a recruiter screen, a technical screen of about an hour mixing SQL on trip data with practical Python, then a virtual onsite of four to five rounds in a single day: SQL and coding, data modeling, streaming pipeline design, and behavioral. A bar raiser from outside the hiring team joins the loop and carries disproportionate weight in the final decision.
What SQL questions does Uber ask data engineers?
Reported questions are framed on marketplace data: request-to-trip funnel conversion by city and hour, driver activity streaks using gaps-and-islands, sessionizing rider app events, surge-window aggregation, and joins across large trip and driver tables. Follow-ups push on timezones, late-arriving events, duplicate records and what the query costs at Uber's volume.
Does Uber ask LeetCode-style questions for data engineers?
Lightly. The data engineering coding round is usually practical Python — deduplicating event streams, reconciling records, transforming nested JSON — rather than algorithm puzzles. Keep a daily easy-to-medium habit so your syntax stays fluent, but grinding hard dynamic programming is not the best use of preparation time for this specific role.
What is the bar raiser round at Uber?
The bar raiser is an interviewer from outside the hiring team whose job is to protect the company-wide hiring bar rather than fill the open role. They focus on judgment, ownership and how you reason under ambiguity, and they will keep pushing follow-ups until you reach the edge of what you know. Saying "I don't know, here's how I'd find out" clearly is a passing answer.
Do I need Kafka, Flink or Hudi experience for an Uber data engineer interview?
Direct experience helps but is rarely a hard requirement. What is required is fluency in the concepts those tools implement: event time versus processing time, watermarks and late data, exactly-once semantics, upserts into a data lake, and when streaming genuinely beats batch. Uber's engineering blog explains its own stack in enough depth to prepare from.
How long does the Uber data engineer interview process take?
Most reported timelines run three to six weeks from recruiter contact to decision, with the onsite compressed into a single day. The longest waits are usually scheduling the onsite and waiting on the bar raiser's availability. Use that window for spoken pipeline-design practice rather than more written SQL drills.