Real, anonymized candidate journeys from recent (2025) Uber SDE-1 and SDE-2 loops in India — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Round 1 — DSA + System Design Screening
A recruiter messaged me on LinkedIn in late October and the first round was set up for the following week, a one-hour video call. The plan was half coding, half a short system design discussion. The interviewer shared a problem: a set of keys with access weights, build a search tree that minimises total weighted search cost, and then he added one extra constraint on top of the standard version. I first explained the classic interval DP — pick each key in a range as the root, add the range's weight sum, recurse on both sides. He agreed and I started coding with memoisation. The extra constraint took me a while to fit into the recurrence and I went back and forth on it twice. By the time the code passed his example there were about five minutes left, so we never got to the system design part. He said it was fine and asked me to just talk through the complexity. I left the call worried, but the recruiter confirmed the next day that I was moving ahead.
Round 2 — Pure DSA
Round two was three days later, another hour, only coding this time. The interviewer gave me a row of numbers where two players pick from either end in turns, and each wants the biggest total. Then she changed how the corner values could be chosen, so it was not exactly the textbook version. I started by writing the recurrence on the shared doc: the value the player to move can guarantee on a range equals the pick minus the best the opponent gets on what is left. She asked me to first solve the standard version, so I did the bottom-up table over all ranges, then adjusted the two end-picks for her variant. I dry-ran it on [5, 3, 7, 10] and got 15 for the first player, which matched her expectation. She asked about space and I said the table could be trimmed to two diagonals. We spent the last ten minutes on a couple of questions about my current team and the round ended on time.
Round 3 — Machine Coding + LLD
The machine coding round was in the same week, 90 minutes. The problem was a small Unix-like file system: mkdir, cd, ls and pwd, working end to end from a command loop. I asked whether relative and absolute paths both mattered and the interviewer said yes, but to get something running first. So I spent five minutes on the class list — a Node, a Directory with a map of children, a FileSystem holding root and the current directory — and then coded the happy path: create a directory, move into it, print the path by walking parent pointers. That was running in about forty minutes. Then I wrote a path resolver that split on slashes and handled dot and double-dot, and hooked mkdir and cd to it. With fifteen minutes left he asked me to try a path that did not exist and a cd through a missing directory; the first one crashed, so I added the error message and kept cwd unchanged on failure. He said the order I worked in was exactly what he wanted to see.
Round 4 — HLD with a Staff Engineer
The design round was with a Staff Engineer the following Monday, one hour. The prompt was a Splitwise-style bill-splitting and settlement system. I started with the schema: users, groups, group members, expenses, and a splits table with one row per participant, plus a pairwise balances table so reads stay cheap. He asked how many entries per group I expected and told me to assume a very large number of concurrent expense entries. Then he pushed on debt simplification. I drew the group as a graph, users as nodes and debts as edges, collapsed it to one net position per person, and described the greedy match between the biggest creditor and the biggest debtor. He asked whether that was minimal, and I said finding the true minimum is hard because of zero-sum subgroups, so this is a heuristic. Then he came back to the schema and asked what happens when two people add expenses touching the same pair at once. I explained the single-shard transaction and the relative update on the balance row, and an idempotency key on the request. It was the toughest round of the loop.
Round 5 — Managerial / Behavioral
The last round was with a manager, about 45 minutes, two days after the design round. Before it I wrote a one-page summary of the things I had actually shipped in the last two years, with the numbers next to each, and I read through it right before the call. The questions were STAR-style: a project I owned end to end, a time I disagreed with a decision, a mistake that affected others and what I changed afterwards. Because I had the summary in front of me I could pick an example quickly and give the situation, what I did and the result without rambling. He followed up on the mistake story and asked what process change came out of it, and I described the checklist we added to deploys. At the end he explained his team's work and I asked about how they prioritise and what the on-call load looked like. The recruiter called about a week later with the offer.
Key takeaway: Prepare a written summary of past achievements ahead of the managerial round, and prioritize getting machine-coding solutions to a runnable state quickly so remaining time can go toward debugging and edge cases.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Online Assessment
I applied through the careers page in August and got the online assessment link about ten days later, with a week to take it. I sat down on a Saturday morning. There were three problems and they got harder as they went. The first was a straightforward array question that I finished in about ten minutes. The second was a string problem with a hash map, a bit more careful work with edge cases, and I tested it on a couple of my own inputs before submitting. The third was a graph problem where I had to think for a while about the right traversal and how to track visited states without blowing up memory. I wrote a plain BFS first, saw it would be too slow on the constraints, and reworked it with a priority queue. All three passed the visible test cases. I had done a lot of competitive programming in college, so the format itself felt familiar. The recruiter emailed me four days later to schedule the phone screen.
🔒 4 more rounds — continue this journey in the full kit