INTERVIEW GUIDE

Uber Data Analyst Interview: Questions & Process

Uber's Data Analyst interview is SQL-heavy and product-focused. Expect to write real queries (joins, window functions, aggregations) and to reason about metrics, experiments, and A/B tests for a two-sided marketplace. The loop typically runs a recruiter call, a SQL/analytics screen, and a 3-4 round onsite mixing SQL, product cases, and experimentation.

The interview process

1. Recruiter screen — ~30 min call

Tests: background, the team and product area, and timeline

2. Technical SQL / analytics screen — 45-60 min, live or HackerRank

Tests: writing SQL against realistic tables — joins, aggregation, window functions

3. Onsite: advanced SQL — 45-60 min

Tests: harder queries, debugging logic, and translating a vague business question into SQL

4. Onsite: product & metrics case — 45-60 min

Tests: defining metrics, diagnosing changes, and reasoning about a marketplace product

5. Onsite: experimentation & behavioral — 45-60 min

Tests: A/B testing design and interpretation, plus teamwork and communication

Questions you're likely to get

Technical

Write SQL to find the top 3 cities by completed trips last month.
Using a window function, find each driver's most recent trip and the gap since the prior one.
Calculate week-over-week growth in active riders from a trips table.
Find users who took a first trip but never took a second — write the query.
What's the difference between a LEFT JOIN and an INNER JOIN, and when does it change your result?

Role-specific

Completed trips in a city dropped 8% week-over-week. How do you investigate?
How would you define a single metric to measure the health of the rider experience?
We're testing a new pricing feature. How would you design and evaluate the A/B test?
Driver supply is short during peak hours. What data would you pull to understand why?
How do you account for network effects when measuring a change in a two-sided marketplace?

Behavioral

Tell me about a time your analysis changed a product or business decision.
Describe a time you had to explain a complex result to a non-technical stakeholder.
Tell me about a time you were wrong about a hypothesis and what you did next.

How to answer (worked examples)

Completed trips dropped 8% week-over-week. How do you investigate?

Don't guess a cause — segment systematically. First confirm the data isn't a logging or pipeline issue. Then slice by city, platform, rider vs driver side, new vs returning users, and time of day. Compare against seasonality and holidays. Form a hypothesis (supply shortage? a release? a competitor promo?), quantify how much each segment explains, and name the query or metric that would confirm it. Uber wants structured marketplace diagnosis, not a lucky single answer.

Design and evaluate an A/B test for a pricing feature.

State the hypothesis and the primary metric up front, then the guardrail metrics you won't let regress. Define randomization unit (and flag the spillover risk — in a marketplace, treating riders can affect drivers). Cover sample size and test duration for significance, then how you'd read the result, including segment effects and novelty. Calling out network effects and guardrails is the senior signal here.

Define a single metric for rider experience health.

Resist naming a vanity metric. Tie it to the user's core value (reliable, fast rides), propose a concrete candidate like completion rate or time-to-pickup, and explain why it captures experience better than raw trip counts. Acknowledge its blind spots and one guardrail you'd watch alongside it. They're testing metric judgment, not trivia.

What Uber looks for

Strong, fast SQL — joins, aggregation, and window functions against messy real-world tables
Structured diagnosis — you decompose a metric change instead of guessing
Product and metric judgment grounded in a two-sided marketplace
Sound experimentation thinking — hypotheses, guardrails, significance, and network effects
Clear communication of findings to non-technical partners
Red flag: SQL that ignores edge cases, or product answers with no metric definition or guardrails

FAQ

How SQL-heavy is the Uber Data Analyst loop?

Very. SQL is the backbone of the screen and at least one onsite round, and it goes beyond basics into window functions and translating ambiguous questions into queries. Drill SQL until it's automatic.

Do they test statistics and A/B testing?

Yes — expect an experimentation round covering hypothesis design, significance, guardrail metrics, and the marketplace-specific wrinkle of network effects. Know the fundamentals cold.

What kind of product cases come up?

Metric definition ('how would you measure X?'), diagnosis ('this number moved, why?'), and marketplace tradeoffs between rider and driver sides. Practice structuring these out loud.

Is there a coding/algorithms round?

For Data Analyst, it's SQL and analytics rather than LeetCode-style algorithms. The harder edge is advanced SQL and product reasoning, not data structures.

How long is the process?

Usually a few weeks from recruiter screen to decision, depending on scheduling and team.

Make the SQL and the case feel routine

Writing queries is one thing; narrating a metric diagnosis and an A/B test design out loud is another. Practice this exact interview with OfferLoop's realtime voice coach so the SQL, the product case, and the experimentation round all come out clean.

Practice this interview out loud →

All Uber interviews →Uber Software Engineer interview →Uber Data Scientist interview →Uber Data Engineer interview →Uber Machine Learning Engineer interview →

OfferLoop is an independent interview-practice tool and is not affiliated with, endorsed by, or sponsored by Uber. All company names and trademarks are the property of their respective owners.

Interview formats vary by team, level and year, and this guide is compiled from general knowledge of publicly discussed hiring processes — treat it as preparation material, not an official description of Uber's current process.