Real, anonymized candidate journeys from recent (2025) Google 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
Phone Screen
The recruiter email said 45 minutes, one problem, shared Google Doc. I logged in two minutes early, tested my mic, and then the interviewer joined — friendly, straight to business. He pasted the problem: a tree, and I needed to answer range queries fast using prefix sums layered on top of a graph traversal. First I just read it twice, out loud, so he could hear me actually understanding it before touching the keyboard. I said, "okay so this is basically DFS to flatten the tree, then binary search on a prefix-sum array for each query" — and he nodded and said "go on." I coded the flattening first, ran it on his sample by hand, then added the binary search part. Ran into one bug where my prefix array was off by one index. I caught it myself while re-reading the loop, fixed it, and re-traced the example. He said "nice catch" and that was it — 45 minutes felt like 20.
Onsite 1
This one came right after a 10-minute break, so I was still a bit warm from the phone screen days earlier — no wait, this was a different day, the actual onsite loop. First round of the day: intervals, a scheduling problem. I'd drilled this exact pattern the week before, so I recognized it almost instantly, but I didn't just blurt the answer — I still asked two clarifying questions first: are the intervals already given, or do I read them from a stream? Are they sorted? He said unsorted, read all upfront. So I said sort by start time, then sweep with a merged-end pointer. Wrote it clean, dry-ran it against his example, and then he threw a twist: "what if two intervals share an endpoint — should they merge?" I talked through both interpretations and picked one, explained why, and he seemed happy with the reasoning more than the final answer.
Onsite 2
Right after lunch, which is never the best slot for DP problems — my brain wanted a nap, not recurrences. The interviewer gave me a 2D DP problem where the tricky part wasn't the recurrence itself, it was initializing the base row and column correctly. I sketched a tiny 3x3 example on the doc first, filled it in by hand, and only then wrote the code — that habit saved me, because my first instinct for the base case was wrong and the manual trace caught it before I'd typed a single line. Once the base cases were right the rest of the DP was routine. He asked me to state the time and space complexity without hesitating, and I did, and that was round two done.
Onsite 3 — Googlyness
No coding this round, just conversation, and honestly it was the one I'd prepped least for and worried about most. She asked for a time I'd disagreed with a teammate but still had to ship together. I told a real story from my last job — not a rehearsed one — about a code review fight over a caching approach. She kept asking "and then what did you do" after almost every sentence, which pushed the story further than I'd planned to go. By the end she asked what I'd do differently now, and I actually had an answer because I'd thought about it since. It didn't feel like a test, more like she wanted to know how I actually think.
Onsite 4
Last technical round of the day, and I was running low on energy by then. He asked for the MEX of an array — smallest non-negative integer missing from it. I gave the obvious hash-set answer first, said it out loud as "the baseline," and he immediately asked, "can you do it without the extra space?" So I walked through cyclic sort — placing each value at its own index where possible, then scanning for the first mismatch. I talked through why this works before coding it, which he seemed to want. Coded it, traced two examples by hand including a tricky one with negative numbers, and he said it was solid but wanted me to state the invariant clearly one more time before we wrapped.
Additional round (post team-matching)
This one happened almost three weeks after the main loop, once I'd passed and was in team matching — a specific team wanted one more technical conversation before making an offer. It was lower-pressure than the onsite loop, more of a discussion: an optimization/resource-allocation problem where I talked through trade-offs more than I wrote code. A week later the recruiter called with the offer.
Key takeaway: Drill core data structures and algorithms until fluent, always ask clarifying questions before coding, dry-run your solution against sample inputs, and write test cases before declaring it done.
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.
Elimination Round
First round of the whole process was called the "elimination round" — the name alone made me nervous before it even started. The problem was MEX-tracking, but as a stream: numbers kept arriving one at a time, and I had to report the missing smallest number after each one. I started with the straightforward hash-set approach, updating it as each number came in. It worked on the sample, but the interviewer asked what happens as the stream gets really long, and I didn't have a sharp answer ready for the follow-up on amortized cost. We moved on, but I could tell that question stayed a little unresolved.
🔒 4 more rounds — continue this journey in the full kit
Phone Screening (45 min)
This was my third attempt at Google, so I walked in calmer than the first two times, if that makes sense. The problem was simple on the surface — pairs in a sorted array that sum to a target — and I said so out loud, which I think interviewers actually like hearing rather than pretending everything is hard. I set up two pointers from both ends and moved them based on the sum, being careful to skip duplicates so pairs didn't repeat. Traced it against the sample, got the right output first try, and we still had ten minutes left, so he asked a small follow-up about an unsorted input, and I said I'd sort first and gave the updated complexity. Ended early, which I took as a good sign.
🔒 4 more rounds — continue this journey in the full kit
Onsite Round 1
I'd rescheduled this round twice already because of work, so by the time it actually happened I just wanted to get it done. The problem was a dependency graph — classic topological sort setup. I went with Kahn's algorithm, building an in-degree count and processing nodes with a queue as their in-degree hit zero. It went smoothly until the follow-up: "can node A reach node E through the graph?" I added a quick BFS from A and checked if E showed up, explained the extra time cost, and he seemed satisfied enough. Round felt fine walking out, nothing alarming.
🔒 3 more rounds — continue this journey in the full kit