On this page
Most guides about getting into a big company are written for software engineers. This one is for a data engineering role: the person who moves data from where it is created to where people can use it. It explains what Uber interviews usually look like, what to practise, and how to spend 8 weeks. You do not need to know any of this already.
Match your resume to the skills in the posting.
Background, interests and timing.
SQL or coding while you talk.
Coding, SQL, data modelling and pipeline design.
Feedback is gathered and a decision is made.
What the role looks like
Uber moves people and goods, so its data is about trips, drivers, riders, prices and maps. Data engineers build the pipelines and tables that answer questions such as how many trips finished in a city this hour, or how long riders waited.
Uber writes openly about its engineering. For example, it created Apache Hudi, a way to keep tables on a data lake up to date, and it has written about using Kafka and Spark. Reading a few of these posts shows you the kind of problems the teams face.
How the hiring process usually runs
Read this as a typical order, not a promise. Some stages are skipped for some roles, and for students the first stage is often an internship application.
- Application. Apply for the role that fits you and list the tools you have used. One project about events or trips is a strong fit.
- Recruiter call. A short conversation about your background and interests.
- Technical screen. Usually SQL or coding at an easy to medium level, solved while you explain your thinking.
- Interview set. Several interviews. For data roles, candidates commonly report SQL, coding, data modelling and a design question about a pipeline. Ask your recruiter what to expect for your role.
- Decision. Interviewers share feedback and decide. Timing varies.
What they test and how to practise it
Each row is one thing an interviewer wants to see, what to practise for it, and where to practise it here.
| What they check | What to practise | Practise it |
|---|---|---|
| SQL | Joins, windows, sessionising events, finding gaps | SQL practice |
| Coding | Hash maps, sorting, intervals, simple graphs | Python practice |
| Data modelling | Design tables for trips, drivers and payments | Star schema vs snowflake |
| Big data basics | Why Spark exists, what a shuffle is, what skew is | What is Apache Spark? |
| Streaming basics | What Kafka does, batch versus stream | What is Apache Kafka? |
Tools and ideas worth knowing by name
Uber's engineering writing mentions several open source tools. You do not need to know them deeply as a fresher, but you should be able to say what each is for.
- Apache Kafka carries streams of events, such as a driver location update or a trip status change.
- Apache Spark processes large amounts of data across many machines.
- Apache Hudi keeps tables on a data lake updated with inserts and updates.
- Presto or Trino run fast SQL queries over large data.
You do not need to be an expert in any of these. You need to say what each one is for, in one sentence, and show that you can learn it.
Questions to practise
These are the shapes of question to practise, written the way an interviewer might say them. They are not a leaked list. Solve each one yourself first, then check your answer.
- Given a trips table, return the number of completed trips per city per day.
- Find riders who took a trip on three days in a row.
- For each driver, find the longest gap between two trips.
- Group events into sessions where a new session starts after 30 minutes of no activity.
- Design tables for trips, drivers, riders and payments. What is one row in each?
- Trip counts for one city dropped to zero at 2 pm. What do you check first?
Practise with trip data
Make a small table of trips with a trip id, driver id, rider id, city, start time, end time and fare. Write ten questions about it: trips per city, average fare, busiest hour, drivers with no trips today. Then answer each in SQL and in Python. This one table covers most of the question types above.
An 8-week plan
Study about an hour a day. If you have less time, stretch each row and keep the order.
| Weeks | Focus | What you can do at the end |
|---|---|---|
| 1 to 2 | SQL basics: joins, GROUP BY, NULL | Answer easy SQL questions without looking anything up |
| 3 to 4 | Window functions, CTEs, deduplication | Solve "top N per group" and "latest row per key" questions |
| 5 | Python: dictionaries, loops, strings, files | Solve easy coding questions in about 20 minutes |
| 6 | Pipelines and warehouse ideas | Explain raw, clean and reporting layers and how a rerun stays safe |
| 7 | One project, written up | Walk through the project in 5 minutes and answer "what went wrong?" |
| 8 | Mock interviews for Uber | Talk through a problem out loud while you solve it |
Mistakes freshers make
- Memorising answers. Interviewers change the data and the wording. Learn why a solution works, not what it looks like.
- Going silent. Say what you are thinking. A wrong answer with clear thinking often scores better than a right answer nobody understood.
- Skipping the checks. After you write a query, say how you would check it: count the rows, look for NULLs, look for duplicates.
- Having no project. One finished project you can explain beats five half-finished ones.
- Not asking questions. If a question is unclear, ask about the data and what one row means. That is what a working data engineer does.
How to talk about your project
Pick one project and prepare a 5-minute story: the problem, the data, the design, one thing that went wrong, and what you would change. Interviewers at any company, including Uber, tend to spend the most time on "what went wrong", because it shows how you think. Build one from the projects page and write it up with a README.
Where to start today
Open the SQL practice problems, solve three, and write down what confused you. Then pick the Learn track that covers it. A small start today is worth more than a perfect plan next month.