Uber · Primly Community

Uber data engineer interview, pipelines and SQL, what they tested and what I wish I'd prepped more

de_derek · 6 replies

Finally went through an Uber data engineer loop in Q1 2026, targeting senior DE (roughly their L5 equivalent for data roles). Here's the breakdown, specifically for the DE track, because most posts are SWE-focused.

The loop structure: Four rounds for the senior DE role I interviewed for. Coding (Python/SQL), system design for data, data modeling, and behavioral.

Coding round: They gave me a Python problem, not SQL, which surprised me. It was around processing and transforming log data efficiently. Think: given a stream of records, aggregate in a time-bucketed way with some edge cases around late-arriving data. Late-arriving data handling came up, which makes sense given their scale.

SQL came up in a different way: in the data modeling round, they asked me to write a query against the schema I'd just designed. So it's not a pure SQL-focused round, it's embedded in the modeling exercise.

System design for data: This was the heaviest round. Prompt was something about building a pipeline that ingests ride events, transforms them, and makes them available for analytics and near-real-time dashboards. I had to design the ingestion layer, the storage tier, and the serving layer.

Kafka came up (they use it heavily internally). They pushed on exactly-once semantics, which is always a fun conversation. Schema evolution and how you handle breaking changes. I talked about Protobuf with a schema registry. Interviewer engaged pretty deeply there.

Spark vs Flink tradeoff also came up. I argued for Flink for the streaming path, Spark for batch historical backfill. They seemed to agree but pushed me on operational complexity of running two systems.

Data modeling round: Dimension tables, fact tables, slowly changing dimensions. Pretty classic stuff, but at senior level they want nuance: when do you use SCD Type 2 vs just append-only logs? How do you handle schema migration at scale?

What I wish I'd prepped more: exactly-once guarantees in distributed systems and the data contract/schema evolution space. Those came up and I was less sharp than I wanted to be.

6 replies

content_cole

The exactly-once semantics question is a trap for people who memorize the answer. Kafka 0.11+ has idempotent producers and transactional APIs, but whether your downstream system can actually guarantee exactly-once end-to-end is a completely different question.

pivot_pat

Exactly. They were specifically probing whether I understood that you can't just say 'Kafka handles it.' The consumer side, the sink, the re-processing on failure, all of it has to be designed. That's the nuance they wanted.

mobile_mara

The data modeling round sounds similar to what I got in the DS loop, though less deep. Did they ask about performance tuning at all, like partitioning strategies for large tables?

sre_sol

Yes, partitioning by event date was basically a given, they wanted to know how I'd handle hot partitions during peak hours. Event-time vs ingestion-time bucketing came up too.

sec_sasha

Did data security or access controls come up at all? For pipelines that touch PII like ride data I'd expect some discussion of encryption at rest, column masking, audit logging.

qa_quinn

Briefly, in the system design round. Interviewer mentioned they care about it but it wasn't a deep drill. More of a 'how would you handle PII in this pipeline' follow-up question.