Uber Software Engineer Interview: Coding, System Design and Behavioral

The calendar block just says “Technical interview.” No problem name. No “bring a laptop.” In the prep note your recruiter forwarded, CodeSignal shows up, so you spent twenty minutes last night clicking around the editor until the run button felt boring. That’s a better Sunday than a forum thread that swears Uber always asks the same six puzzles.

I keep seeing people treat the Uber software engineer interview as a secret question bank plus a folklore round count. Uber does publish a process. It just isn’t a promise that every team will use every box, in that order, with a fixed number of coding hours. Start with How we hire. Then ask your recruiter which of those boxes you actually get.

OfferBull is not affiliated with Uber. Your recruiter’s instructions beat this blog post.

The official skeleton of an Uber software engineer interview

Uber’s How we hire page is a company-wide sketch. They say every role is a little different and they point you to the relevant team page for specifics.

Apply. You submit for a role.

Talk with the talent team. Your experience, the role, and what working there is like: pace, expectations, impact. “I want to work on hard problems at scale” is a slogan. “I spent a year shrinking p99 on a matching API that fell over at dinner rush” is a conversation.

Chat with the hiring manager. Skills, decisions, how you approach problems, plus a clearer view of the team. I’d ask what they’re in the middle of, not for a rehearsed culture speech.

Technical interview, for tech roles. A shared problem or a real scenario, worked collaboratively, in real time.

Functional exercise or assessment, for some roles. An analytics task, written exercise, portfolio review, or work simulation, meant to be job-related rather than hypothetical. If you get one, read the instructions twice. If they don’t mention outside tools, don’t assume you can use them.

Team interview. Teammates and cross-functional partners, focused on collaboration and decision-making. If you completed an exercise, you may walk through it.

Decision. Recruiters partner with the hiring team and review you against the job criteria. Uber does not publish a pass rate, and I won’t invent one.

A skeleton from Uber’s How we hire page. Recruiters can skip or reorder steps; confirm yours.

That official list does not lock in “three coding rounds.” One official people story describes a fuller loop, and it is one person’s path, not a template. In Landing the job at Uber: Backend Engineer, Isidora, who joined an Uber Eats checkout team, said her process included a recruiter phone screen, then three coding interviews, two design and architecture interviews, and one focused on collaboration and leadership. The recruiter sent prep material. If you get a packet, use it.

An older Uber engineering post on the coding interview, published in July 2021, used to live at uber.com/blog/engineering-interview-process. That URL returned a not-found page when I checked it for this article. An archived copy is still readable, so treat these details as historically published by Uber engineering and confirm what’s current. After a short talent call, a recruiter or sourcer scheduled a technical phone screen with a software engineer or an engineering manager. Uber said it would not use logic puzzles or brain teasers (“how many golf balls could fit in a school bus?”). Problems were real-world coding, in the language of your choice, even if the interviewer didn’t know it, as long as you could explain. Each interviewer typically had about an hour, often 30 to 40 minutes of coding, 5 to 10 minutes on prior work or behavioral questions, and 5 to 10 minutes for your questions. A team interview day, in person or virtual, could include up to six interviews back-to-back, with short breaks and a lunch break. Phone screens used CodeSignal. Later interviews might use CodeSignal or a whiteboard. Don’t import round counts from Google, Meta, Microsoft, Amazon SDE, or Apple. And I’m not going to invent official Uber “leadership principles.” Read whatever your recruiter sent. If they didn’t send a culture packet, ask what the team actually cares about in the collaboration interview.

The Uber coding interview

For the Uber coding interview, official color also comes from an October 2022 Brazil Tech Center blog, Coding interview: joining the Uber Engineering team in Latin America. I could not load the live URL in this writing pass (also not found). The 2022 text is still in public archives, written by Uber as interviewer advice. Confirm the tool before you practice in the wrong editor.

In that writeup, the algorithm stage was a session with an Uber engineer using CodeSignal. You chose a language and solved a problem with algorithms and data structures. They flagged a spoiler: be ready for binary search, and be ready to talk about Big-O. Their interviewers’ tips: get familiar with CodeSignal and the language you plan to use; ask clarifying questions and think about edge cases, not only the sample; think out loud and share the approach before you implement; run and debug early; use readable names; account for time and space complexity; practice under time limits.

This prompt is fictional. I am not claiming Uber uses it.

Interviewer: you’re given a sorted list of driver arrival times in minutes, and a target t. Return the earliest arrival that is at least t. If none, say so.

I’d say: “Sorted is doing the work here. I can binary search for the first value greater than or equal to t. I assume the list can be empty, and that duplicates are allowed, so I want the first qualifying time, not any matching time. I’ll talk through the lower-bound loop, type it, then run the sample before I decorate anything.” Then I’d write a tight loop with lo and hi, test [], [3,3,9] with t=3, and t larger than the last value. Then Big-O: log n time, constant extra space. I would not start with a custom tree to look senior.

System design practice, not an official question list

People search for an Uber system design interview the way they search for a leak. I’d skip that. Use design as practice for marketplace and real-time systems, and let your recruiter tell you whether your loop even includes it. Isidora’s loop had two design and architecture interviews. The official How we hire page does not promise that for every software seat.

The 2022 LATAM design blog, Design and Architecture Interview: Joining the Uber Engineering team in Latin America, described two types. A new problem: high-level architecture for a large-scale application. A previously solved problem: your contributions, the challenges, the architecture you actually shipped. Their interviewers suggested learning CodeSignal and Miro, eliciting functional and non-functional requirements plus edge cases, thinking out loud, presenting a solution then scaling it, and covering an end-to-end path before disappearing into one component. Discuss trade-offs. Lead the time. Don’t force a concept just because Uber uses it. If you don’t know something, offer alternatives. The diagram is the artifact, and a hiring panel may see it later. Same caveat: historically published, live URL currently unreliable, confirm the tool.

Practice themes I’d actually rehearse, at a high level, without pretending they are official questions: dispatch and matching, marketplace pricing at a conceptual level, location and streaming updates, high fan-out, and consistency versus latency. Interview prep only. No product secrets, no invented surge formula.

A dispatch-style sketch, also fictional:

“I’d start with one city and one vehicle type. A request comes in with a pickup point. A location service has approximate positions for available drivers. I need a geospatial index for nearby candidates, then a matcher that offers one driver a trip and waits for accept, decline, or timeout. If two requests grab the same driver, the matcher has to lose one cleanly. Location pings arrive often and many clients care about the same area, so I’d call out a high fan-out path: a pub/sub or a partitioned stream, not a fresh database read on every map refresh. I’d accept slightly stale positions for a faster offer, and be honest about the failure: a driver who looked close may have moved. Pricing can live in a separate service that reads demand and supply signals. I would not invent Uber’s actual pricing logic in this room. For consistency versus latency, I’d ask which hurts more: a delayed offer, or an offer that expires because the data was twenty seconds old. Then I’d scale: more cities, more vehicle types, retries that don’t stampede.”

For a fuller scaffold, use the system design interview template and translate a prompt from common large-scale design questions into a marketplace shape. When the talk turns to partitions, replication, or a region blipping, the distributed systems interview questions post is a better drill than reciting a vendor diagram.

Behavioral questions and spoken answers

The collaboration hour is not filler. Isidora had a dedicated one. The 2021 engineering post also put behavioral questions in the last part of a coding hour, and gave two prompts you can practice without treating them as a complete bank: a technical disagreement with a teammate, and a time you needed information from someone who was not very responsive.

Sample answers below are illustrative. The names, products, and numbers are made up. Please don’t recite them. The STAR method is enough structure if you want a scaffold. You don’t have to label the letters out loud.

“Tell me about a time you resolved a technical disagreement with a team member.”

Situation. We were about to cache estimated arrival times for a courier app because the source service was expensive at dinner.

Task. I wanted to ship a cache. A teammate thought stale ETAs would be worse than a slower page.

Action. I didn’t win it in Slack. I pulled one hour of traces, showed that 30 percent of identical pickups were asked again within fifteen seconds, and proposed a ten-second cache with a visible “updated Xs ago” label and a bypass when a courier was already assigned. We agreed to ship that behind a flag in one city.

Result. The expensive service’s peak dropped enough that we stopped talking about a rewrite. Two weeks later we shortened the TTL because a dispatcher caught a stale value after a road closure. The disagreement was about which failure the user would notice first.

“Describe a time you needed information from someone who was not very responsive. How did you handle it?”

Spoken, no labels:

“I needed a field definition from a data team to finish a payout report. I’d messaged twice and got nothing, and the launch date wasn’t moving. I wrote a half-page note with the three questions, the query I had already tried, and the decision I’d make on Friday if I heard silence. Then I asked their manager for ten minutes on the next standup, not a new meeting. The engineer said they’d been firefighting a pipeline, and we walked the fields in that slot. I left with enough to ship a conservative version and a follow-up for one column. I didn’t escalate for theater. I made it easy to answer, and I gave a deadline I actually meant.”

“Tell me about a production incident you were involved in.”

“We changed a timeout from two seconds to 400 milliseconds on a downstream call and didn’t retune retries. The dependency blinked, every client retried at once, and we amplified a blip into a half-hour mess. I helped roll the timeout back, then added a retry budget and a dashboard for retry rate, not only error rate. The unglamorous part was writing the postmortem sentence that said the change was mine. I still like aggressive timeouts. I just don’t ship them without a cap anymore.”

Other prompts worth saying out loud once:

• Walk me through a system you owned, including the tradeoff you still don’t love.
• Tell me about a time you had to cut scope before a launch.
• Why this team, and why now?

When they leave time for your questions, use it. A focused list lives in questions to ask at the end of an interview. Broader practice: software engineer behavioral interview questions and behavioral interview questions and answers.

How I’d practice for a couple of weeks

One timed coding session a day, out loud, in the editor they told you to expect. If they said CodeSignal, open it before the first real hour. Two projects you can defend for fifteen minutes each, including a diagram. One design prompt in a marketplace shape, started small, then scaled. Two behavioral stories spoken to about two minutes, then interrupt yourself with “what did you measure?” A general plan: how to practice for an interview.

About AI tools. Uber’s How we hire page does not spell out a ChatGPT ban the way NVIDIA’s software engineer interview guidance does on NVIDIA’s own careers page. I will not invent an Uber policy. Confirm with your recruiter. The safe default is no outside tools in the live session, and none on a take-home or exercise unless they explicitly allow them. Do not assume they do. No second-monitor chat. No answers in your ear. In that official backend-engineer story, Isidora described using AI as a practice partner before the loop. That’s practice, not a hall pass for the real hour.

OfferBull is an AI mock interview app for iOS and Android. A voice interviewer asks questions aloud. You answer by speaking. Paste the job description or upload a resume for tailored questions. Follow-ups based on what you said and what’s on the resume. While you practice, you get answer suggestions and STAR structures. English and Chinese. Close it before the real call starts.

Start an AI mock interview

FAQ

How many coding rounds does Uber use? Uber’s How we hire page does not fix a number. One official backend-engineer story described three coding interviews plus two design interviews and a collaboration interview. Ask your recruiter what you will actually sit.

Can I use ChatGPT or another assistant during the interview? Ask your recruiter. Uber’s public How we hire page does not publish a ChatGPT rule the way some other companies do. The safe default is no outside tools in the session unless they have said otherwise in writing.

What language should I use? Historically, a language you can actually write and explain, even if the interviewer doesn’t know it. Don’t pick a stack you barely know because the team uses it. Ask if a later round will switch into the team’s language.

Practice This Out Loud

Tonight: one timed coding prompt in the editor you were told to expect, a ten-minute dispatch-style design sketch that starts in one city, and a two-minute disagreement story with a number in it. Interrupt yourself once. Then a voice mock with follow-ups. → Practice Now

Take Control of Your Career Path:

• Official Site: www.offerbull.net/mock-interview
• iOS App: Download for iPhone/iPad
• Android App: Download for Android