My Uber SDE-2 Interview Experience (Not Selected, but Worth Sharing)

I recently interviewed with Uber for a Backend SDE-2 role. I didn’t make it through the entire process, but the experience itself was incredibly insightful — and honestly, a great reality check.

Since Uber is a dream company for many engineers, I wanted to write this post to help anyone preparing for similar roles. Hopefully, my experience saves you some surprises and helps you prepare better than I did.

Prep Resource: LeetCode 75 & PracHub Uber SWE Questions

Round 1: Screening (DSA)
The screening round focused purely on data structures and algorithms.

I was asked a graph problem, which turned out to be a variation of Number of Islands II. The trick was to dynamically add nodes and track connected components efficiently.

I optimized the solution using DSU (Disjoint Set Union / Union-Find).

If you’re curious, this is the exact problem:

Key takeaway:
Uber expects not just a working solution, but an optimized one. Knowing DSU, path compression, and union by rank really helped here.

Round 2: Backend Problem Solving
This was hands down the hardest round for me.

Problem Summary
You’re given:

A list of distinct words

A corresponding list of positive costs

You must construct a Binary Search Tree (BST) such that:

Inorder traversal gives words in lexicographical order

The total cost of the tree is minimized

Cost Formula
If a word is placed at level L:

Contribution = (L + 1) × cost(word)
The goal is to minimize the total weighted cost.

Example (Simplified)
Input

One Optimal Tree:

Words: ["apple", "banana", "cherry"]
Costs: [3, 2, 4]

banana (0)
/
apple (1) cherry (1)
TotalCost:

banana → (1 × 2) = 2

apple → (2 × 3) = 6

cherry → (2 × 4) = 8 Total = 16

What This Problem Really Was
This wasn’t a simple BST question.

It was a classic Optimal Binary Search Tree (OBST) / Dynamic Programming problem in disguise.

You needed to:

Realize that not all BSTs are equal

Use DP to decide which word should be the root to minimize weighted depth

Think in terms of subproblems over sorted ranges

Key takeaway:
Uber tests your ability to:

Identify known problem patterns

Translate problem statements into DP formulations

Reason about cost trade-offs, not just code

Round 3: API + Data Structure Design (Where I Slipped)
This round hurt the most — because I knew I could do better.

Problem
Given employees and managers, design APIs:

get(employee) → return manager

changeManager(employee, oldManager, newManager)

addEmployee(manager, employee)

Constraint:
👉 At least 2 operations must run in O(1) time

What Went Wrong
Instead of focusing on data structure choice, I:

Spent too much time writing LLD-style code

Over-engineered classes and interfaces

Lost sight of the time complexity requirement

The problem was really about:

HashMaps

Reverse mappings

Constant-time lookups

But under pressure, I optimized for clean code instead of correct constraints.

Key takeaway:
In interviews, clarity > beauty.
Solve the problem first. Refactor later (if time permits).

Round 4: High-Level Design (In-Memory Cache)
The final round was an HLD problem:

Topics discussed:

Key-value storage

Eviction strategies (LRU, TTL)

Concurrency

Read/write optimization

Write Ahead Log

However, this round is also where I made a conceptual mistake that I want to call out explicitly.

Despite the interviewer clearly mentioning that the cache was a single-node, non-distributed system, I kept bringing the discussion back to the CAP theorem — talking about consistency, availability, and partition tolerance.

In hindsight, this was unnecessary and slightly off-track.

CAP theorem becomes relevant when:

The system is distributed

Network partitions are possible

Trade-offs between consistency and availability must be made

In a single-machine, in-memory cache, partition tolerance is simply not a concern. The focus should have stayed on:

Data structures

Locking strategies

Read-write contention

Eviction mechanics

Memory efficiency

r/LeetcodeChallenge - My Uber SDE-2 Interview Experience (Not Selected, but Worth Sharing)
Resource: PracHub

Final Thoughts
I didn’t get selected — but I don’t consider this a failure.

This interview:

Exposed gaps in my DP depth

Taught me to prioritize constraints over code aesthetics

Reinforced how strong Uber’s backend bar really is

If you’re preparing for Uber:

Practice DSU, DP, and classic CS problems

Be ruthless about time complexity

Don’t over-engineer in coding rounds

Think out loud and justify every decision

If this post helps even one person feel more prepared, it’s worth sharing.

Good luck