Google

Google was the kind of interview where I walked out thinking, “I solved it… so why do I still feel like I messed up?” After the resume screening and initial recruiter conversation, I reached the technical interviews for the SWE Intern role. The process was heavily focused on DSA. One thing I noticed immediately was that the interviewer wasn't interested in hearing a memorized solution. I had to actually build the solution in front of them, explain my choices, and keep answering “what if?” questions. Similar off-campus Google experiences report medium-to-hard DSA problems with a strong emphasis on explaining the thought process. The first problem was based around a tree. At first glance, it looked like a normal DFS question, so I started explaining a recursive approach. The interviewer let me continue, but then asked me to calculate the complexity and consider what would happen with a much larger tree. That was where the problem became interesting. My first solution worked, but it wasn't optimal enough for the constraints. I had to rethink what information I actually needed to maintain during the traversal. Once I changed the state I was carrying through the DFS, the solution became much cleaner. A reported Google India interview had a very similar experience: the candidate solved a DFS problem but was pushed toward a substantially more optimal approach. The next problem involved arrays and had a follow-up. I initially went with a straightforward approach and then tried to improve it using the structure of the input. The interviewer kept changing small conditions—duplicates, larger constraints, and what should happen in an edge case. I realized that I was comfortable when the problem matched a pattern I had practiced, but less comfortable when the same problem was slightly modified. Another off-campus candidate described almost exactly this experience: they could solve the original question but struggled when additional constraints were introduced. There was also a lot of attention on communication. I had to clarify the problem before coding, give test cases myself, and explain time and space complexity. One candidate specifically mentioned that asking clarifying questions and thinking aloud were important parts of their Google interview, and that failing to communicate the reasoning clearly hurt their performance. Eventually, I received the rejection. Honestly, the rejection didn't feel like I had completely failed. I had solved parts of the interview and understood most of the concepts. But Google exposed a gap in my preparation: I knew many DSA patterns, yet I wasn't always comfortable deriving an approach when the interviewer changed the rules. That interview changed how I prepared afterward. Instead of only increasing the number of problems I solved, I started spending more time asking myself, “What happens if this constraint changes?” That turned out to be much more valuable than simply memorizing another solution.