Uber Software Engineer (SWE) Interview Guide

Role focus: Uber Software Engineer, Software Engineer II, Senior Software Engineer, Staff Software Engineer, Senior Staff Software Engineer, Principal Engineer, Backend Engineer, Full-Stack Engineer, Infrastructure Engineer, Marketplace Engineer, Uber Eats Engineer, Payments Engineer, Ads Engineer, Maps / Mobility Engineer

Uber’s Software Engineer interview is more structured than many candidates realize, but it is not one identical loop for every engineer.

Uber currently publishes dedicated engineering interview guidance and separate domain-specific preparation material for Backend, Frontend, Android, iOS, Data Engineering, Production Engineering, ML & AI Engineering, Security Engineering, and Engineering Management. For backend engineers, the public interview framework explicitly separates Algorithms & Data Structures, Depth in Specialization, Design & Architecture, and Collaboration & Leadership.

That distinction matters.

A candidate who prepares only LeetCode may be ready for one part of the interview but underprepared for machine coding, low-level design, production follow-ups, distributed-system reasoning, or level calibration.

Uber also creates a particularly interesting engineering environment because software state frequently corresponds to something happening in the physical world:

• a rider is waiting;
• a driver is moving;
• a courier has accepted an order;
• a restaurant has closed;
• a payment may already have been sent;
• a vehicle location may be stale;
• an event may arrive twice;
• a marketplace can change faster than cached state.

That changes what strong engineering judgment looks like.

The best mental model is:

Uber SWE = strong algorithmic coder + practical software builder + distributed-systems thinker + production owner + level-appropriate technical leader.

The interview is ultimately asking:

“Can this person take an ambiguous real-world engineering problem, clarify the semantics, build a correct solution, evolve it under production constraints, and own the consequences at Uber scale?”

TL;DR

Note

The core Uber interview pattern is:

clarify → solve → make it work → add a constraint → expose a bottleneck → evolve the system

In many Uber interviews, the most revealing part begins after the initial problem is already solved.

Interview Process

Uber publishes a general company-wide hiring process, but engineering roles use more specialized interview frameworks.

For Backend Engineering, the current public framework includes level-specific tracks for L3, L4, L5A, L5B, and L6+. The exact sequence can change with role, level, specialization, location, and business need.

A commonly visible backend sequence includes a recruiter or sourcer conversation, a possible HackerRank assessment, a Business Technical Phone Screen, Algorithms & Data Structures, Depth in Specialization, Collaboration & Leadership, and the final decision.

Recent experienced-hire reports also include dedicated system design, machine coding, low-level design, and technical project deep dives. These should be treated as team- and level-dependent rather than universal stages.

A useful way to think about the backend loop is:

Coding 1 asks whether you understand computer science.

Coding 2 asks whether you can build software.

System Design asks whether you can build software that survives scale and failure.

Behavioral asks whether you can own that work with other people.

Questions to Ask Your Recruiter

Note

Recruiter guidance for your exact loop should override a Reddit post, Exponent guide, or a friend’s interview from a different Uber organization.

Recruiter Screen

The recruiter is not primarily trying to determine whether you know Java, Go, or Python.

They are trying to understand:

What kind of engineer are you, where could you fit inside Uber, and does your demonstrated scope support the level being considered?

This becomes particularly important because Uber Software Engineers work across very different areas:

• Rides
• Uber Eats
• Grocery
• Payments
• Ads
• Identity
• Core Services
• Search
• Maps
• Infrastructure
• Autonomous Vehicles
• Developer Platforms

A payments engineer and an AV infrastructure engineer may share a level but have very different domain depth.

What the Recruiter Is Really Calibrating

Common Recruiter Questions

Weak vs Strong Positioning

Note

The biggest recruiter-screen mistake is positioning yourself as a generic Big Tech SWE.

Strong positioning answers:

What class of systems are you unusually good at, what scale have you owned, and why does that matter for this Uber team?

Technical / Coding Screen

Uber coding should be treated as a serious interview signal even for experienced engineers.

Recent candidate reports continue to include recognizable algorithm problems involving graphs, monotonic data structures, heaps, intervals, matrices, caches, trees, and dynamic connectivity.

But algorithm recognition is only part of the bar.

Strong candidates also:

• clarify ambiguous semantics;
• communicate the baseline;
• identify why it is inefficient;
• produce correct code;
• analyze complexity;
• test deliberately;
• adapt to follow-up constraints.

Coding Topic Map

Representative Practice Prompts

What Good Looks Like

Strong Answer Structure

1. Restate the problem.
2. Clarify input, output, constraints, ordering, and boundary semantics.
3. Explain the simplest correct approach.
4. Identify its bottleneck.
5. Propose an optimized approach.
6. State time and space complexity.
7. Write clean code.
8. Dry-run one representative input.
9. Test edge cases.
10. Handle follow-ups while preserving existing invariants.

Strong Answer Example

Prompt:

Maintain the number of requests received during the previous 300 seconds. Writes are extremely high volume.

Weak opening:

“I’ll use a queue.”

Stronger opening:

“I want to clarify whether timestamps arrive in non-decreasing order and whether an event exactly 300 seconds old is still included.

A queue gives a straightforward solution: append each timestamp and remove expired timestamps as time advances. That is amortized O(1), but at very high write QPS, storing one object per request may become the larger problem.

Since the window is fixed, if second-level granularity is acceptable I can aggregate requests into timestamp buckets. Each write becomes one increment instead of one queue entry.

If reads are infrequent, I can aggregate active buckets when reading. If reads also become high volume, I’d maintain a rolling count and update it as buckets expire.”

Notice what makes this answer stronger:

It optimizes for the workload—not merely for asymptotic complexity.

Common Coding Mistakes

Practical / Production Coding

The second coding dimension at Uber deserves separate preparation.

Uber’s backend framework calls it Depth in Specialization, which is a useful way to think about the round.

For backend candidates, this may test whether you can take a small real-world domain and create software around it:

entities + state + operations + complexity + tests + changing requirements

This is different from solving another independent algorithm puzzle.

Standard Algorithm Coding vs Practical Coding

Typical Task Styles

What They Are Testing

Strong Practical Coding Behavior

1. Clarify required operations.
2. Define important invariants.
3. Choose the simplest state representation.
4. Implement one complete version.
5. Test it.
6. Accept the next requirement.
7. Refactor only the boundary that must change.
8. Preserve previous behavior.
9. Add a test for the follow-up.
10. Discuss production hardening after the interview-scale solution works.

Strong Response Example

Initial requirements:

openRestaurant(id) closeRestaurant(id) countOpenRestaurants()

Follow-up:

Restaurants now serve one or more delivery zones. Return the number of open restaurants serving a given zone.

A strong response:

“For the initial requirements, a set of open restaurant IDs is sufficient.

The new requirement introduces a second lookup dimension. I would keep restaurant state separate from geographic membership rather than coupling everything inside one object.

I’d maintain restaurant → zones and either zone → open restaurant IDs or zone → open count, depending on whether future APIs require identities or only counts.

Opening or closing a restaurant then updates its relevant zone indexes.

Before implementing, I’d clarify whether a restaurant can change zones while it is open, because that introduces another state transition.”

That response shows:

state modeling → requirements analysis → operation complexity → extensibility

Note

The best practical-coding candidates keep the interviewer aligned on:

assumptions → state → invariants → tests → follow-up → production hardening

Low-Level Design / Machine Coding

Some Uber backend loops separate this more explicitly.

Treat LLD as:

Can you convert a domain into executable, maintainable software?

Do not prepare it as a vocabulary test for design patterns.

LLD Topic Map

High-Yield Practice Problems

LLD vs HLD

Note

Use Strategy, Observer, Factory, or other patterns because a requirement creates a useful abstraction—not because you want to demonstrate that you memorized them.

System Design

System design matters heavily for experienced Uber engineers because Uber’s systems often combine three difficult properties:

1. high scale;
2. rapidly changing state;
3. real-world consequences when the system is wrong.

A generic web architecture answer is usually insufficient.

A strong Uber design answer should understand:

What state is authoritative?

What may be stale?

What can safely retry?

What can happen twice?

What happens when components disagree?