Top Tech Transition Enroll now

Real Interview Experiences

Learn what to expect, straight from candidates who've been through it at top tech companies.

908 interviews243 companies286 offers
Loading experiences…

Browse by company

Browse by role

← Back to all experiences

Uber Staff Software Engineer (L5B), Ads Interview Experience

Uber · Staff · Software Engineer

If I were doing it again, I would spend less time trying to grind every Uber-tagged LeetCode problem and more time on two things: their engineering blog and getting my behavioral framing right for staff.
ResultIn progress
Timespan—
DifficultyDifficult
Rounds7

Interview process

I got in through a referral, had a lightweight recruiter call, then an initial coding screen, and then a five-round final. The final was two coding rounds, one system design, one past-project round that turned into a behavioral deep dive, and one straight behavioral. What stood out was how much Uber cared about technical depth over polished cross-functional storytelling, especially for a staff role. Even the coding rounds felt like they wanted system-design-style tradeoff thinking, and they gave me the Number of Islands variant in the final coding round.

Interview rounds · 7

  1. 1

    Recruiter screen

    I got a super lightweight recruiter screen, basically just enough to get me into process, and it felt very turn-and-burn because I came in through a referral.

  2. 2

    Technical round

    CodingData Structures & Algorithms

    I had an initial coding screen before the final loop, but nothing about it stuck out compared to the onsite, which is where all the real signal seemed to be.

  3. 3

    Final / onsite round

    CodingData Structures & AlgorithmsTechnical

    My first final-round coding interview was a pretty bare setup on HackerRank. The interviewer, an EM, just dropped the problem in and then pushed hard on optimization once I got to a working answer.

    1. Q1. Solve a variation of Number of Islands.
      How they answered

      I solved it the straightforward BFS way first, which I thought was fine, and then the real test started. He pushed me to think like a staff engineer and go deeper on sparse representations, memory tradeoffs, and how little state I actually needed if I only cared about the count. It felt less like normal LeetCode and more like putting a system design lens on one LeetCode problem. That was the moment Uber's technical-chops bias really hit me.

      Follow-up questions
      • Is there any way you can think of to make this more of a sparse data set?
      • How would you optimize the memory space for this?
      • Are there optimizations around just getting the number versus storing more state?
  4. 4

    Final / onsite round

    CodingData Structures & AlgorithmsTechnical

    The second coding round was also on HackerRank.

    1. Q1. Solve a Uber-tagged Leetcode question.
      How they answered

      This one was with a senior staff interviewer, and the only setup I got was basically, imagine a PM brought you this idea and you want to make it good. I lead with the optimized version rather than the naive one and discuss the trade-offs more aggressively. I got kind of a nod like, okay, you got it. The whole thing still felt very churn-and-burn.

      Follow-up questions
      • Imagine this is a product idea from some PM and you want to make it good, right?
  5. 5

    Final / onsite round

    Project DiscussionBehavioralTechnical

    The so-called past-project round was not really a presentation for me. I came in ready to whiteboard a project, but it turned into a behavioral plus technical deep dive with some real pushback.

    1. Q1. Tell me about a project.
      How they answered

      He kept drilling into scale, system choices, constraints, and tradeoffs rather than letting me do a polished walkthrough. The feel was, okay, did you really own this or are you hand-waving? It was much more technical than a normal project chat, and he kept double-clicking on the messy parts.

      Follow-up questions
      • What was the scale on that project?
      • What kind of systems did you use?
      • What were some of the technical challenges?
      • What technical trade-offs did you have to make?
      • What would happen if this happened?
    2. Q2. Tell me about a project that failed.
      How they answered

      I talked about a failed project from a past company and explained that it eventually got shelved. He pushed on whether I had just accepted that or whether I had actually advocated for alternatives. I made it clear I did push and I did explain my position, but the business just was not interested. It felt like he was testing whether I gave up easily or could hold a technical position and still lose for business reasons.

      Follow-up questions
      • What happened after?
      • Did you follow up on it?
      • You didn't push for any of the solutions that came naturally here?
  6. 6

    Final / onsite round

    System DesignProduct DesignMachine Learning

    The system design round was the most fun by far. The prompt looked deceptively simple, but the whole point was seeing how deep I could go once the obvious design was out of the way.

    1. Q1. Design the Uber Eats homepage.
      How they answered

      I got through the high-level design quickly and focused on scale, caching, and where I'd optimize the hot paths. Then he pivoted to top K by region, so I talked through how I'd compute and serve that efficiently. In the last few minutes he pushed into ML, and I explained a pretty standard ranking flow: generate a candidate list, build features, rank candidates, take the top K, and send that to the UI. I was explicit that I know what the models should do even if I'm not the person doing the math.

      Follow-up questions
      • Build me a top K per region of the top restaurants.
      • Let's talk about how ML fits into this.
  7. 7

    Final / onsite round

    BehavioralArtificial Intelligence

    The vanilla behavioral was with a director-level interviewer and felt pretty checkboxy, but the themes were clearly level calibration and org impact. The most interesting part was that he steered the velocity question toward AI almost immediately.

    1. Q1. For an org, give me an example of when you improved velocity.
      How they answered

      I gave him two options, one around AI and one around centralizing logs and metrics, and he immediately picked the AI one. I said I'm skeptical of the fully agentic, end-to-end coding hype, because if I can't reliably get that to work, a lot of people can't either. Where I do think AI is genuinely useful is querying the business: asking natural-language questions about metrics, generating SQL, and spinning up dashboards without waiting on a data scientist. That was the fully formed opinion he seemed to want.

      Follow-up questions
      • You mentioned two examples. Talk about the AI one.
    2. Q2. Give me a complex project.
    3. Q3. Tell me about a time you had a conflict with someone technical. How did you approach it?
    4. Q4. What is the scope of your job? What did you do?
      How they answered

      The subtext on this one was pretty obvious. They were trying to figure out whether I was actually operating at staff scope or if I was just a very strong senior, so I kept my answer anchored on org-level responsibility and what I personally drove.

Tips from the candidate

If I were doing it again, I would spend less time trying to grind every Uber-tagged LeetCode problem and more time on two things: their engineering blog and getting my behavioral framing right for staff. Read the blog because their technical posts and postmortems are insanely good, and if you can speak their language back to them, it lands. For coding, don't stop at getting it to work. Assume they're going to ask how to optimize space, handle sparsity, or justify why your approach is the right one. Also use AI to research the org and the blog hard before the loop.

Company culture

This process felt technically rigorous in a very practical way. They care a lot more about how deep your CS instincts go than about hearing a polished story about cross-functional partnership, and even their producty questions are still really engineering-heavy. The ads side felt kind of Amazonian managerially to me: standard behaviorals, bog-standard coding, then a system design where the real game is how deep you can go after the obvious answer. It also did not feel like one of those companies obsessing over some special culture-fit ritual right now. A lot of it felt more like, can you do the job at this level, yes or no.

Details

CompanyUber
RoleSoftware Engineer
LevelStaff
LocationUnited States
InterviewedApr 2026
Questions asked9