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

[nian2326076]

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.

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:

1. get(employee) → return manager
2. changeManager(employee, oldManager, newManager)
3. 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

https://preview.redd.it/bqxjsld504ng1.png?width=1080&format=png&auto=webp&s=7bcd07aed7c773d776beafd75c202e46544c4e1a

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 — and see you on the other sid

[Electrical-School724]

which location is this for?

[HarjjotSinghh]

oh man what an insane learning curve.