PrepFinity
All posts

How to Crack the Uber India SDE Interview

Most candidates preparing for an Uber India SDE interview spend three weeks grinding LeetCode and walk into the system design round completely blindsided. The interviewer asks them to design a ride-matching engine, and suddenly "I know Dijkstra's" isn't enough. Uber's interview process is specific. The system design rounds are anchored in geospatial problems, and the DSA rounds test the exact graph and heap concepts that power those systems. If you don't know that going in, you're prepping for the wrong interview.

This post breaks down every round, the exact topics Uber India focuses on, and how to build answers that land.

Uber India's interview format has four distinct stages

The process typically runs across four rounds: one online assessment, two technical rounds (DSA and system design), and one hiring manager or behavioural round. For SDE-2 and above, there's sometimes a fifth round focused on cross-functional thinking.

The online assessment is on HackerEarth or an internal Uber platform. Two to three problems, 90 minutes. Difficulty ranges from medium to hard, with at least one graph problem. You get filtered here before any human sees your resume.

The two technical rounds are back-to-back on the same day, usually with a 20-minute break. That pacing matters. Your energy in the second round is a real variable.

The DSA round is not random — it follows a pattern

Uber's DSA questions cluster around four areas: graphs, heaps, sliding window, and interval problems. This isn't a guess. It matches what their products actually need. Surge pricing, ETA calculation, driver allocation — all of these reduce to graph traversal and priority queue problems at the algorithmic level.

Specific topics to drill:

  • BFS and DFS on grids (not just adjacency lists)
  • Dijkstra's and modified shortest-path variants
  • K-nearest points using a max-heap
  • Merge intervals and sweep line problems
  • Sliding window for real-time stream data

If you can solve "Find K closest drivers to a pickup point" in under 20 minutes with a clean heap implementation, you're in the right shape. If that question makes you pause, start there.

The system design round almost always involves location or matching

This is where the Uber India SDE interview is most different from a generic FAANG prep track. Interviewers here pull directly from Uber's real architecture. Common prompts include:

  • Design the Uber ride-matching system
  • Design a real-time driver location tracking service
  • Design surge pricing for a city grid
  • Design ETA prediction at scale

Each of these has a geospatial component. You need to know how to partition a map (geohashing is the standard answer), how to handle high-frequency location updates (write-heavy systems with eventual consistency), and how to think about latency when a user is waiting on a result in under two seconds.

The interviewer is not looking for you to have worked at Uber. They want to see that you can reason about trade-offs in a system that has real-world constraints. Saying "I'd use a database" without specifying read/write patterns, indexing strategy, and replication will not pass.

Geohashing is the concept that separates prepared candidates from the rest

Geohashing converts a latitude-longitude pair into a short alphanumeric string. Nearby locations share a common prefix. This makes proximity queries fast without doing expensive radius calculations across millions of rows.

You should be able to explain:

  • How geohash precision levels work (level 6 is roughly a 1.2 km × 0.6 km cell)
  • How to find all drivers in a given geohash cell and its eight neighbours
  • Why you'd store geohashes in a Redis sorted set for fast range queries
  • What breaks at high driver density (hash collisions, uneven cell sizes in cities like Mumbai vs a rural area)

Interviewers at Uber India have asked candidates to whiteboard the geohash lookup flow during a system design round. If you've never drawn that out before, the first time you do it should not be in the interview.

Treat the behavioral round as a technical conversation, not HR small talk

Uber's behavioral round uses a structured competency framework. The questions sound soft but they're evaluated hard. Common ones:

  • "Tell me about a time you disagreed with a technical decision and what you did."
  • "Describe the most complex system you've built. What would you change?"
  • "How have you handled a production incident under pressure?"

The mistake most candidates make is giving a vague story. "I once fixed a bug that was causing slowdowns" is not an answer. The interviewer wants to hear the specific system, the specific trade-off you made, and the measurable outcome. If you're targeting SDE-2, they expect you to have owned something end-to-end.

Prepare three to four stories from your actual work. Map each one to a different competency: ownership, technical depth, collaboration, and speed under pressure. Rotate them across questions.

Your resume will be interrogated in the first five minutes

Before any coding starts, most Uber India interviewers spend five to ten minutes on your resume. They're looking for inconsistencies and for topics they can pressure-test. If you wrote "built a real-time notification system," expect "what was your p99 latency and how did you measure it?"

Go through every bullet on your resume and prepare a two-minute deep-dive for each one. Know the numbers: throughput, latency, scale, team size, your specific contribution. If you can't answer those questions about your own work, the interviewer notices, and it affects how they score the rest of the round.

The second technical round is where most candidates drop

Back-to-back technical rounds on the same day is a real test of stamina. We see candidates perform well in round one and noticeably worse in round two, not because they don't know the material, but because they're mentally fatigued and start second-guessing themselves.

Two things help. First, do your mock sessions in pairs. One mock interview, 10-minute break, second mock interview. The second one will reveal gaps the first one hides. Second, have a reset ritual between rounds. Walk to the bathroom. Drink water. Say the problem statement out loud before you start writing anything. It sounds small. It works.

You can run paired mock sessions on PrepFinity — the platform tracks how your answer quality shifts across consecutive sessions, which gives you a concrete signal on where your stamina breaks.

Salary expectations and offer structure at Uber India

Uber India SDE-1 offers typically land between ₹25–40 LPA total compensation, depending on your college, prior experience, and negotiation. SDE-2 roles range from ₹45–70 LPA. These numbers include base, RSUs (Uber stock), and joining bonus. The RSU component is meaningful and vests over four years, so understand what you're comparing when you're looking at competing offers from Swiggy, Razorpay, or a Series B startup.

Don't accept the first number. Uber India recruiters have room to move on the joining bonus and sometimes on the RSU grant. Come in with a specific competing offer if you have one.

Build your prep around Uber's actual problem space

Generic interview prep will get you through the DSA round if you're strong. It will not get you through the system design round. Uber India interviewers are testing whether you can think about systems that handle millions of real-time events, geospatial queries, and sub-second latency requirements. That's a specific skill set.

Spend two weeks on geohashing, ride-matching architectures, and write-heavy distributed systems before you start scheduling rounds. Read about how S2 geometry works as an alternative to geohashing. Understand why Uber moved parts of their stack to their own in-house mapping infrastructure. The more you understand the domain, the more naturally your answers will land.

The candidates who clear all four rounds aren't necessarily the ones who solved the most LeetCode problems. They're the ones who understood why Uber's problems are hard and came in with a point of view on how to solve them.

Ready to pressure-test your system design answers before the real thing? Start with 3 free interviews on PrepFinity — no credit card needed.