Uber SDE-2 Interview Experience : LLD, HLD, DSA & Hiring Manager Round

A few months ago, I interviewed with Uber for an SDE II position. At the time, I had around 3 years of experience at another product-based company, so I was excited to see how Uber's interview process compared with other top tech companies.

The entire process stretched over nearly two months, followed by another two months of waiting because of a hiring freeze. Although the final outcome wasn't what I had hoped for, I walked away with valuable lessons that have genuinely improved the way I approach system design and technical interviews.

Here's how each round went.

Round 1 : Screening (Parking Lot  Design)

The first round started with a fairly common Low-Level Design problem: design a parking lot system.

Initially, I assumed the interviewer only wanted a high-level class structure with a few important methods implemented. Based on that assumption, I kept several components as black boxes and focused on designing clean interfaces.

However, midway through the interview, the expectations changed. Instead of discussing only the design, I was asked to turn it into fully executable code.

Thankfully, the transition was manageable because the initial design was flexible enough to extend. The discussion revolved around choosing appropriate  data structures, writing clean object-oriented code and making the implementation scalable.

Overall, it felt like a collaborative discussion rather than an interrogation.

Round 2 :  Data Structures & Algorithms

The second round was a pure coding interview.

The problem was very similar to LeetCode 871 (Minimum Number of Refueling Stops) and required finding the most optimal solution.

It wasn't one of those questions where an accepted solution is enough. The interviewer expected the best possible time complexity, along with clear reasoning behind every data structure choice. I eventually arrived at the optimal solution, but it took me longer than I would have liked. Although the code was correct, I could sense that speed also played a role in the evaluation.

Looking back, I think I spent too much time validating different approaches before committing to one. The solution was optimal, but interviews are as much about pacing as they are about correctness.

Round 3 : Low-Level Design (Ride Hailing System)

This was easily the most frustrating interview of the entire process. The problem was to design an Uber Ride Hailing system.

As always, I started by gathering requirements and explicitly confirming the scope with the interviewer. We agreed on the features that needed to be implemented and I began designing accordingly.

Unfortunately, once I started coding, the expectations kept changing. Every few minutes, a new requirement would appear something that hadn't been discussed during requirement gathering. Instead of allowing me to complete one part before moving on, the interviewer continuously interrupted with additional scenarios and implementation questions.

At one point, the discussion even drifted into High-Level Design topics, such as:

"What happens if publishing to Kafka fails?"

That felt slightly out of place because the interview was clearly positioned as an LLD round. Nevertheless, I explained how a Dead Letter Queue (DLQ) could be used to handle failed events. The interviewer didn't provide any feedback, so it was difficult to gauge whether that was the expected direction.

Because of the constant shifts in expectations, I couldn't finish the implementation within the allotted time.

To be honest, this round was mentally exhausting not because the problem itself was difficult, but because the target kept moving.

Round 4 : High-Level Design

After LLD, I wasn't entirely sure whether I'd move forward, but Uber continuing the interview loop.

The HLD round focused on designing a stock market alert system. The system received stock price updates from an exchange every second. Users could subscribe to alerts whenever a stock price changed by a configurable percentage over a rolling time window.

The tricky part was understanding what "rolling window" actually meant. For example, a one-week window didn't mean Monday through Sunday. Instead, it represented the previous seven days from the current timestamp, constantly moving forward in time.

Another requirement was that:

• a subscription should be removed once it triggers, or
• expire automatically after one month if it never triggers.

Initially, the problem felt overwhelming because many requirements were intentionally left open-ended.

As the discussion progressed, things gradually started making sense. I proposed an architecture, discussed storage choices, event processing, scalability and latency trade-offs. It certainly wasn't a perfect design and the interviewer had to give me a few hints along the way, but the discussion remained constructive.

I honestly expected this round to be the end of my interview process, but I was surprised to receive an invitation for the next round.

Round 5 : Hiring Manager

This round was with the Hiring Manager and it was entirely behavioral. Instead of asking technical questions, the discussion focused on my previous work experience and leadership responsibilities.

Some of the topics included:

• Owning a project end-to-end
• Handling disagreements within a team
• Working across multiple stakeholders
• Going beyond assigned responsibilities
• Mentoring teammates
• Making technical decisions under pressure
• Delivering impact as an engineer

Compared to the previous rounds, this conversation felt much more relaxed. It was less about finding the "right" answer and more about understanding how I work with people and solve real engineering problems.

The Long Wait

After completing all five rounds, I honestly had no idea what to expect. Then came the waiting.

A hiring freeze delayed the process by almost a month. I even reached out to the recruiter and mentioned that I'd appreciate a straightforward rejection rather than being left uncertain. Interestingly, the recruiter clarified that I hadn't been rejected and that my profile was genuinely on hold.

Eventually, after another month or so, I received the rejection email.

From what I understood, Uber was likely comparing several candidates with similar feedback and they ultimately decided to move forward with someone else. My experience level was also close to the minimum requirement they were looking for engineers with 3+ years of experience, while I was only just reaching that mark.

My Biggest Takeaway

Looking back, the only interview I didn't enjoy was the LLD round, mainly because the expectations kept changing throughout the session. Every other interviewer was transparent about what they were evaluating and gave me enough room to think aloud, discuss trade-offs and refine my ideas.

Although getting rejected after investing nearly four months was disappointing, I don't consider the experience wasted.

Preparing for Uber forced me to strengthen areas that I had previously ignored, especially system design, scalability and reasoning about architectural trade-offs.

In fact, after going through this interview process, many other interviews felt noticeably easier. Sometimes the biggest value of an interview isn't the offer. it’s the growth that comes from preparing for it and reflecting on what you learned afterward.

Final Verdict

Result: ❌ Rejected (after the complete interview loop)

Despite the final outcome, I'm glad I went through the process. It challenged me in ways that few interviews had before and gave me a much clearer understanding of what companies like Uber expect from an SDE II engineer.

If you're preparing for Uber interviews, don't focus only on solving coding problems. Spend equal time on Low-Level Design, High-Level Design and communicating your thought process clearly. More often than not, the interviewers are evaluating how you think just as much as what solution you arrive at.

I hope this experience helps anyone preparing for Uber. Good luck with your interviews ~ you've got this!