Went through the Lyft data engineering interview in January. I'm a senior DE (7 years) and was interviewing for a senior IC role. Here's the actual structure and what they cared about.
Loop structure: SQL/data modeling round (1 hour) Pipeline design / system design round (1 hour) Coding round (Python, 45 min) Behavioral (45 min) HM chat
SQL and data modeling: This was the most intensive round. Two parts: first a SQL problem, then a data modeling question.
SQL: window functions, aggregations, and a subquery involving Lyft's core domain (rides, drivers, timestamps). The problem was: compute, for each city, the percentage of rides where the driver accepted within 10 seconds over the past 30 days, then rank cities by this metric. Sounds straightforward but the schema had some gotchas around how cancellations were recorded.
Data modeling: design a schema to power a dashboard showing driver earnings per week, broken down by ride type and market. They want to see that you know the difference between a normalized OLTP schema and what you'd actually put in a Snowflake or Redshift table for analytical queries. I sketched a fact-dimension model and they pushed on how I'd handle slowly changing dimensions for driver attributes.
Pipeline design: Given a real Lyft-adjacent scenario: a stream of GPS pings from active drivers, build a pipeline that computes ETA accuracy in near-real-time. This is classic streaming: Kafka ingestion, a stateful processing layer (they asked about Flink specifically but Spark Streaming would also work), windowing strategy, latency vs. throughput tradeoffs, and how you'd backfill if a downstream service goes down.
They were not just asking what tech you'd use. They asked what the SLA would be and how you'd know if you were missing it. Have an answer for observability: what metrics do you instrument, where does the alert fire, who gets paged.
Python coding: More of a data manipulation problem than a pure algorithms problem. Given a list of trip records as dicts, compute some aggregated metric and handle some messy data (nulls, duplicates). They wanted clean, readable code. They asked me to write a couple of unit tests as well.
Overall: Lyft's DE interview is solid. They're testing actual DE skills (streaming, modeling, SQL depth) not generic SWE algorithms. If you know your pipelines and can model data for analytical queries, the loop is manageable. The SQL round was the hardest part for me, mostly because of the schema gotchas.