Uber data interview pack

The Uber loop

1. Design

   Trip fact grain. How a streaming count and a nightly batch must reconcile.

2. SQL

   Sessionize or gap events. Event time vs processing time after an outage.

3. ML features

   Point-in-time joins. A backtest that leaked the future.

SQL (2)

1. medium · SQL

   Running total of daily revenue. Why is SUM(SUM(amount)) OVER (...) valid?

   The inner SUM is the GROUP BY aggregation (daily revenue). The window SUM then walks those grouped rows. You need both: group to the day first, then window. A bare SUM(amount) OVER (ORDER BY day) without grouping double-counts every order row.

2. medium · SQL

   A date spine is missing Sundays. What breaks in a 7-day rolling metric?

   The window walks existing days, not calendar days, so Sunday is skipped and Monday’s “7-day” is six days plus a hole. Generate a complete date dimension and LEFT JOIN facts onto it before the window.

Coding (3)

1. easy · Spark

   Narrow vs wide transformation. Why does that decide runtime?

   Narrow (map, filter) stays on the same partition. Wide (groupBy, join) shuffles over the network. Shuffle is the expensive part. If you can filter and project before a join, you cut shuffle bytes. That is the interview.

2. medium · Spark

   Kryo vs Java serialization. When do you care?

   When the UI shows time in serialization and shuffle bytes are huge. Register classes. It does not fix a bad join.

3. medium · Spark

   You cached a 400 GB dataframe. The next action still recomputes. Why?

   Cache is lazy until an action; memory was evicted; or you transformed after cache without using the cached handle. persist(StorageLevel) and check the Storage tab. Caching is not a free lunch on a 20-node cluster.

Data modeling (5)

1. medium · Recent signal, 2026-09-08

   Your backtest looks perfect. The production model is worse. What join did you write?

   A calendar merge that used future labels. Point-in-time is merge_asof (or a warehouse ASOF), not merge on date. Leakage is a join bug.

2. medium · dbt

   You need yesterday’s incremental plus a 3-day lookback for late CDC. How do you not rebuild the month?

   Filter on a watermark minus lookback, merge on the unique key, and unique/not_null tests. max(updated_at) alone misses late deletes. Say the lookback in hours.

3. easy · Python & modeling

   pandas vs Spark vs SQL for a 40 GB join. How do you choose?

   If it already lives in a warehouse, write SQL (or dbt). Spark when the data is files on a lake and the job is distributed. pandas when it fits in memory on one box — and 40 GB does not. “I would load it into pandas and merge” ends the interview.

4. medium · Python & modeling

   apply vs a vectorized expression. Why is apply slow?

   It is a Python loop. Use vectorized pandas/numpy or push the work to SQL/Spark.

5. hard · Python & modeling

   You need a point-in-time join in pandas. What bug looks like a great backtest?

   Merging on date without as-of (merge_asof with direction=backward) so future labels leak. Leakage is a join bug. Say the as-of key and that the label was known at t.

   Hint: merge_asof, not merge on calendar_date.

Orchestration (3)

1. easy · Airflow

   TaskFlow vs operators. When do you still write a classic Operator?

   TaskFlow is fine for Python that stays in the worker. Use a dedicated Operator (SnowflakeOperator, DatabricksSubmit) when the work should run in the warehouse, not on the Airflow box. The tell: if the function downloads a table into pandas, you already lost.

2. medium · Airflow

   You need a backfill of 400 days. How do you not strand the 08:00 DAG?

   A separate backfill DAG with a low pool/priority, partitions in batches, and a freeze on overlapping writes to gold. Same DAG with a huge start_date is how Monday pages.

3. medium · Dagster

   A late partition arrived. What must not happen?

   A full rebuild of every downstream asset. Partitioned assets + targeted backfill. If your graph cannot backfill one day, it is a batch script wearing assets.

Streaming (8)

1. easy · Kafka

   Why can two consumers in the same group not share one partition?

   A partition has a single offset per group. Throughput scales with partitions, not with extra consumers parked on the same partition. To add parallelism, add partitions (and accept the rebalance) or split topics by domain.

2. easy · Kafka

   max.poll.interval vs a slow sink.

   If processing exceeds the interval, the member is kicked and the group rebalances. Shrink the work per poll, speed the sink, or raise the interval with eyes open.

3. hard · Kafka

   linger.ms and batch.size — what are you trading?

   Latency for throughput. A firehose with linger 0 wastes RPCs. Correctness is acks/ISR, not linger.

4. hard · Kafka

   acks=all and a producer still duplicates. How?

   Retries after a timeout when the broker actually committed. Idempotent producer (enable.idempotence) plus a key. acks=all is durability, not exactly-once at the consumer.

5. easy · Apache Flink

   Event time vs processing time. When does the dashboard lie?

   Processing time windows close on wall clock. Late Kafka events fall in the wrong window. Event time plus watermarks is the honest window. If you cannot explain watermarks, you are not ready to ship the job.

6. medium · Apache Flink

   Watermark of 10s vs 10 minutes. What did you trade?

   Late events vs completeness. A 10s watermark closes windows fast and drops late data (or side-outputs it). 10 minutes waits and uses more state. The product owner picks the lateness, not the framework default.

7. hard · Apache Flink

   Exactly-once into Kafka is on; the warehouse sink is at-least-once MERGE. What do you tell the stakeholder?

   End-to-end is the weakest sink. The MERGE must be idempotent on a primary key. “Flink is exactly-once” without a sink contract is marketing.

8. hard · Apache Flink

   A keyed state store is 80 GB and checkpoints take 12 minutes. First two levers?

   TTL on state, tighter windows, incremental checkpoints, and whether you stored the whole event instead of an aggregate. Scaling TaskManagers helps after you stop keeping forever.

Warehouse (5)

1. medium · Snowflake

   COPY INTO failed halfway. Is the target table half-loaded?

   A single COPY INTO is transactional per file set: failed files can be skipped with ON_ERROR, but committed files stay. Know VALIDATION_MODE, PURGE, and force vs load history. Interviewers want “I check COPY_HISTORY, I do not assume all-or-nothing across a folder of 400 files.”

2. easy · Databricks

   A shuffle-heavy join OOMs the worker. Name three levers before you “just scale the cluster.”

   Broadcast the small side if it fits. Repartition both on the join key. AQE / skew join hints. Filter before the join. If it is still huge, rethink the grain — you may be exploding a many-to-many. Scaling the cluster last is the expensive answer.

3. medium · ClickHouse

   What is the primary index in ClickHouse?

   ORDER BY (the sorting key). There is no B-tree on every column. A wrong ORDER BY is a full scan. Say that before you talk about clusters.

4. easy · ClickHouse

   Can I UPDATE a fact like Postgres?

   Mutations are expensive background rewrites. Design append-only or use ReplacingMergeTree with a version. Frequent point updates belong in OLTP.

5. medium · ClickHouse

   ORDER BY (tenant_id, ts) vs ORDER BY ts. What did the primary key actually do?

   ClickHouse sparse index is the ORDER BY. Filters on prefix columns skip granules. A leading ts with a tenant filter scans everyone. Put equality columns first when they are selective.

System design (6)

1. hard · System design

   Exactly-once from Kafka into a warehouse. What do you actually promise?

   At-least-once plus an idempotent sink (MERGE on event_id / offset+partition). True EOS is a specific Kafka + sink setup. Saying “Kafka is exactly-once” without a key is a fail.

2. hard · System design

   When is a warehouse the wrong serving plane?

   Sub-100ms point lookups, per-user online features, or a product API that is not SQL. Then you need a keyed store or a feature/online path — and a contract with the batch grain.

3. easy · System design

   Streaming dashboard vs a 1-hour mart. How do you choose?

   If the decision can wait an hour, batch is cheaper and simpler. Streaming is for operational actions (fraud, inventory, live ops). Do not stream a CFO dashboard to look modern.

4. hard · System design

   Backfill 3 years after a grain change. How do you cut over without two revenues?

   Dual-run old and new marts, reconciling on a date range, then swap the BI pointer on a freeze window. Keep the old table read-only for a month. A silent rename on Friday is how finance pages you.

5. medium · System design

   Online store for features must answer in 20 ms. Warehouse p95 is 800 ms. What is the serving path?

   Not the warehouse. Materialize features to Redis/Dynamo/Feast online, with a batch/stream publisher and a mismatch monitor. Warehouse is the offline train path.

6. medium · System design

   A “real-time” ops dashboard can be 2 minutes late. Kafka + Flink + ClickHouse vs Kafka + 5-min microbatch Spark. Pick and defend.

   Microbatch if 2 minutes is fine and the team already runs Spark. Flink+CH if you need event-time windows and sub-minute. Complexity is a cost. Do not pick Flink to look senior.

Data quality (3)

1. medium · Data quality

   Four checks you put on every gold table first.

   Freshness, volume (not zero, not 10×), schema, uniqueness of the grain. Everything else is extra. 400 noisy tests train people to ignore red.

2. easy · Data quality

   Where should the contract live — producer or warehouse?

   Producer owns the schema and SLA. Warehouse tests are defense in depth. A contract only in dbt is how source teams ship breaking changes on Friday.

3. medium · Data quality

   Where should the contract live — producer app or warehouse?

   Producer first (schema registry, API contract, protobuf). Warehouse tests are defense in depth. If only the warehouse tests, you find out after the app shipped. Both, with an owner on the producer.

AI / ML (5)

1. hard · AI / RAG / MLOps

   Where does a data engineer stop in MLOps?

   Reliable feature tables, training-data DAGs, point-in-time joins, and serving logs. Model architecture and eval design belong with ML. Interviewers want the boundary, not a PyTorch lecture. If you cannot explain training/serving skew, you are not done.

2. hard · AI / RAG / MLOps

   Feature store vs “a gold table named features.” What is the extra work?

   Point-in-time correct joins (no leakage), online/offline parity, and a serving path with low latency. A gold table is a start. If training used yesterday’s snapshot and serving uses a live join that can see the label, you shipped leakage.

3. medium · AI / RAG / MLOps

   Online vs offline features for the same model.

   Same definition, two stores, a point-in-time story. If online computes a different join, you shipped skew.

4. hard · AI / RAG / MLOps

   Offline feature table has 40 columns; online store has 12. The model’s AUC collapsed after deploy. First check?

   Training-serving skew: missing features defaulted, or a different join grain online. Diff a production request against the training row for that entity_id and time. Then freeze a schema contract.

5. easy · AI / RAG / MLOps

   When is a feature store overkill?

   One model, one batch job, one gold table with a documented as-of join. A store pays off with many models, online serving, and reuse. “We bought Feast” is not a design.

Behavioral (3)

1. easy · Behavioral

   You and an analyst disagreed on the grain of revenue. How did it end?

   Write both grains on the board: order vs line vs payment. Pick one for the gold table and give the other a named mart. Do not average the disagreement into a DISTINCT. Close with who owns the metric definition now — dbt docs, a semantic layer, or finance. The interview is about conflict plus a contract, not who won.

2. medium · Behavioral

   A source team broke a contract on Friday. How did you handle the people side?

   Page on the contract test, not the person. Share the failing rows, the SLA, and a dated fix. Then move the contract upstream so warehouse tests are defense in depth. Blame in Slack is the junior tell; a written producer contract is the senior one.

3. medium · Behavioral

   A PM wanted the metric by Friday without a source contract. How did you negotiate?

   Offer a dated prototype on bronze with a watermark in the title, not gold. Gold needs a key and an owner. Give them a number they can use with a caveat, or a date you can certify. “No” without an alternative is brittle; “certified Friday” without a contract is how you get fired later.

SQL coding labs

Problem statements only. Run them against tests on DataLane; solutions live in the pad.

1. medium · about 12 min · tables: orders

   Cancel rate by country

   Ops wants a cancel rate per country on one row: total orders, cancelled orders, and the ratio. The trap is integer division — cancelled / orders returns 0 in most engines unless you force a float.

   https://www.datalane-data.blog/coding/problems/cancel-rate-by-country/

2. hard · about 14 min · tables: orders

   Seven-day moving average

   Daily revenue is noisy, so the dashboard smooths it over a trailing week. The frame has to include the current day and the six before it — off-by-one here is the most common review comment on this query.

   https://www.datalane-data.blog/coding/problems/moving-average-7d/

3. hard · about 14 min · tables: orders

   Day-over-day revenue growth

   Put yesterday’s revenue and the percent change beside each day. The first day has no prior row, and the answer must leave it NULL rather than inventing a zero.

   https://www.datalane-data.blog/coding/problems/day-over-day-growth/

4. hard · about 18 min · tables: orders

   Second order within seven days

   Retention wants customers whose second completed order landed within 7 days of their first completed order. Return customer_id and the days between those two orders, smallest customer_id first.

   https://www.datalane-data.blog/coding/problems/repeat-within-7-days/

5. hard · about 16 min · tables: orders

   Customers above average order volume

   CRM wants customers whose completed order count is strictly above the average completed-order count across customers who have at least one completed order. Return customer_id and completed_orders, highest volume first.

   https://www.datalane-data.blog/coding/problems/above-average-order-count/