Google

I applied for the Google Software Engineering Intern role through the off-campus process and was initially contacted by a recruiter. The first conversation was fairly short and mostly introductory. I was asked about my background, coding experience, competitive programming profile and some of the projects I had worked on. There was no complicated technical discussion at this stage, but I got the impression that the recruiter was trying to understand whether my profile matched the internship before moving me to the interview stage. A recent off-campus candidate reported a similar recruiter conversation before the technical rounds. The first technical interview was entirely centered around data structures and algorithms. After a brief introduction, the interviewer presented the problem and gave me some time to think before asking me to explain my approach. I started by considering a straightforward solution and then worked towards a more efficient one. I was expected to explain the complexity and discuss edge cases while coding. The interviewer also asked follow-up questions to make sure I understood the reasoning behind the solution rather than simply memorizing a pattern. I managed to work through this round successfully and was invited to the second technical interview. The second round was where I struggled. The problem was based around trees, and although I could identify the general direction, I couldn't develop the complete solution quickly enough. I received hints during the discussion, but even after narrowing down the approach, I wasn't able to finish a correct implementation within the interview. The problem required more than just knowing standard DFS or BFS; I had to recognize the underlying structure and formulate the right state or traversal strategy. The candidate report I used for this experience similarly describes the second round as a considerably tougher tree problem where the candidate could not complete the solution despite follow-up hints. What I noticed throughout the interviews was that the interviewer cared a lot about my thought process. I had to keep communicating while solving, explain why I was choosing a particular data structure, and adjust my approach when the interviewer introduced additional conditions. This was different from practicing problems alone, where I could spend several minutes experimenting before settling on an approach. I ultimately received a rejection after the technical rounds. The experience made it clear to me that my preparation needed to go beyond standard easy and medium DSA questions. In particular, I needed more practice with difficult tree and graph problems where the solution isn't immediately recognizable. Recent Google internship discussions also point to trees and graphs as recurring areas in the technical interviews. Overall, although I wasn't able to convert the interview into an offer, I found the process useful because it showed me exactly where I was losing time: recognizing harder patterns, developing the optimized approach quickly, and turning that idea into working code while continuously explaining my reasoning.