Uber | SDE-2 (L4) | Interview | 2026 | Pending Results

Education: 2023 Graduate from a Tier-2 NIT

Current Company: Microsoft

Date of Interviews: Feb-March 2026

I recently finished my virtual loop for the SDE II (L4) position at Uber. The process was intense but the interviewers were highly collaborative. A huge heads-up for anyone interviewing: Uber requires you to write runnable code in both the DSA and Machine Coding rounds.

Here is a breakdown of my 4 rounds.

Round 1: BPS (Business Phone Screening)

• Duration: 60 minutes
• Problem: Alien Dictionary (LeetCode 269).
• Experience: Standard topological sort. I coded it, walked through the time complexity, and successfully ran the test cases.
• Verdict: Strong Hire

Note on Interview Order: Typically, the C1 (DSA) round happens before C2 (Machine Coding). However, my C1 panel was on leave, so that round was postponed and actually took place after my Machine Coding round.

Round 2: C2 / Machine Coding

• Duration: 60 minutes (Interviewer extended by 18 mins)
• Description: Design a simplified, in-memory version of Twitter.
• Required APIs: createUser, postTweet, getNewsFeed (last 10 tweets of self + followees), follow, unfollow.
• My Approach:
  • Architecture: Anticipating a focus on scale, I avoided the standard Pull Model for getNewsFeed (which requires an O(N log N) fetch-and-sort operation on the fly). Instead, I implemented a Fan-out on Write (Push Model).
  • Data Structures: I maintained a bounded size-10 Min-Heap (ordered by timestamp) for each user's newsfeed. When a tweet is posted, it is actively pushed to the Min-Heaps of all the user's followers, ensuring getNewsFeed remains a strict O(1) read operation.
  • Design Patterns: I utilized a Thread-Safe Singleton for the in-memory database to accurately simulate connection pooling and ensure thread safety.
• Outcome: I successfully implemented and ran the user creation, follow, and post services. Although I completely wrote the logic for getNewsFeed, I ran out of time to execute its final test loop in the runner. However, because the underlying Min-Heap architecture was rock solid, the interviewer was highly satisfied and actually stayed 18 minutes over the scheduled time to discuss the system design trade-offs.
• Verdict: Hire / Lean Hire

Round 3: C1 / DSA

• Duration: 60 minutes
• Description: Given a list of currency exchange rates [Source, Target, Rate], return the conversion rate for a given query. Return -1.0 if impossible. (Very similar to LC 399: Evaluate Division).
• Base Solution: I modeled it as a directed weighted graph. I solved the base problem using BFS in about 25 minutes.
• Follow-up 1 (High Throughput): Suppose the graph updates infrequently (once a day) but gets millions of reads per second. How do you avoid traversing the graph every time?
  • My Answer: I discussed caching the pairs in a DP array / Hash Map matrix asynchronously.
• Follow-up 2 (Maximum Arbitrage): Real-world exchanges have multiple paths. Find the maximum possible conversion rate from currency A to B.
  • My Answer: I modified Dijkstra's Algorithm. I swapped to a Max-Heap and changed the relaxation condition from addition to multiplication (if maxRate[next] < maxRate[curr] * rate).
• Outcome: The Max-Heap Dijkstra implementation didn't return the exact correct output in the runner before time ran out, but the interviewer was extremely happy with the architectural discussion and the math reasoning.
• Verdict: Strong Hire

Round 4: High-Level Design (HLD)

• Duration: 60 minutes
• Description: Design a Notification System for a Stock Price Exchange.
• Experience: Taken by a Staff Engineer. It was a heavy, rapid-fire session. We deep-dived into the tech choices (Kafka vs. RabbitMQ, Push vs. Pull, deduplication). He asked a ton of follow-ups regarding edge cases during market open thundering herds, and I answered almost all of them.
• Outcome: The round was scheduled for an hour, but he was satisfied with the architecture by the 50-minute mark and disconnected early.
• Verdict: Strong Hire / Hire