Google · Phone screen → Onsite
In processGoogle U.S. 2027 Intern Interview Experiences & Question Tracker (Part 5 :)
I'll add candidate reports here from mid-October through October 30, 2026. Let's get started :)
October 13, 2026: Two rounds, both prefix sums
This candidate interviewed for Google's U.S. 2027 Summer SWE internship. Both coding rounds were 45 minutes. They found a linear-time approach in each round, but left worried about the hints they needed and how much time they spent checking their code. They were still unsure whether they'd pass or be asked to interview again.
Round 1: Equal endpoints, maximum subarray sum
The interviewer was quiet and pasted the question into a coding document with very little small talk. The candidate read it, explained their understanding, and checked that they had it right.
The task was to find the maximum-sum subarray with equal endpoint values. Given an array, choose i and j with nums[i] == nums[j], maximize the sum from i through j, and return the two indices.
They asked about negative numbers, arrays where every value is different, and whether i == j was allowed. The interviewer explicitly confirmed that a single element was valid. Even if a longer valid interval existed, a single large value such as 100 could still win.
They first described an O(n³) brute-force approach, then moved to prefix sums and a hash map. For each endpoint value, the map kept the smallest prefix sum before a matching start. That gave O(n) time and O(n) space.
Coding started around minute 10 and finished around minute 20. They then walked through [1,2,3,2,5], showing how the prefix sum and map changed. The answer was [1,3], with a sum of 7. By the time that walkthrough and the complexity discussion were done, it was roughly minute 30.
The follow-up removed the equal-endpoint rule. They explained that one global minimum prefix sum could replace the map. The interviewer wanted a separate function and asked them to keep the original code. They misunderstood, started editing the original, and had to undo the changes.
With little time left, they explained the follow-up without finishing the code. They also initially said O(n) space, then corrected it to O(1) after a prompt from the interviewer.
Afterward, they worried that their original implementation might have missed the single-element case, despite discussing it at the start. They couldn't remember the final code well enough to be sure. The interviewer became much more talkative during their questions at the end, discussing mentors, teamwork, and what makes an intern successful.
Round 2: Endpoints minus the middle
The second interviewer started with introductions and explained the format. The candidate was surprised to get another prefix-sum question.
This time, they had to maximize the endpoint sum minus the interior sum: choose a subarray of at least two elements, add its first and last values, and subtract everything between them. Return the maximum score. The interviewer confirmed that negative values were allowed and a one-element subarray was not.
After describing brute force, they split the score into a part that depended on the left endpoint and a part that depended on the right. They wrote out the formula in the document to make the explanation clearer. The interviewer asked how they would choose the left endpoint during a single pass, so they explained how to keep the best contribution from an earlier start.
Two bugs came up. First, they initialized the answer to 2 * nums[0], which accidentally allowed a one-element interval. The interviewer reminded them of the minimum length. Second, their prefix-sum initialization happened in the wrong order. When asked what a variable would actually contain at that line, they spotted the mismatch and fixed it.
The dry run was slow. They wrote down each running value, made a few arithmetic mistakes, and corrected them. Their final score for the supplied example was 9; the report doesn't include that example's input. They explained O(n) time and O(1) space, and the interviewer said it sounded good.
It was around minute 40 by then. The interviewer asked whether they could simplify the code, such as removing an unnecessary temporary prefix-sum variable. They explained the cleanup aloud rather than rewriting it. There wasn't time for another coding follow-up. The interviewer said feedback would come through the recruiter.
October 9, 2026: A custom set and rental cars
Another candidate shared two rounds in the comments.
Round 1: Add and remove on a custom set
The interviewer gave them a special set data structure and asked for add and remove. They didn't describe the set's internal structure.
They spent about 30–40 minutes understanding the structure and writing both functions, with almost no hints. While checking test cases, they found and fixed a small issue. There wasn't much conversation. The interviewer asked about complexity, then moved to the candidate's questions. There was no follow-up.
Round 2: Assign rental cars
The next question was the rental-car assignment problem: work out the minimum number of cars needed and return the corresponding ID assignments.
They went straight to a min-heap approach without first discussing brute force and finished the code early. The interviewer then asked them to write several test cases and walk through them. There was no follow-up or complexity question.
There was still time left, but the interviewer had no more questions. The candidate found that awkward and felt the October 13 poster had done a better job talking through their work. They didn't share an interview result.
Comments
0No comments yet — be the first to share what you know.