Google Software Engineer Intern Interview Experience
Google · Intern · Software Engineer
Google’s online assessment took me like 5 minutes and it was supposed to be 90, and that’s when I realized they really prioritize your interactions with the interviewer. You absolutely are not going to run any of your code, so if you don’t understand that landscape, you’re going to fail.
Interview process
I got an OA first, and it was so easy that I finished it in about five minutes even though it was supposed to be ninety, which told me pretty quickly Google was not using that as the real filter. After that I had two technical interviews that were both blank-doc coding rounds where you cannot run code, so the whole thing is about reasoning, asking good questions, and keeping the interviewer engaged while you work. My actual coding questions were both pretty standard LeetCode-medium level, but the follow-up optimizations were where the signal really was, especially when I had to optimize a heap update problem with no hints. Then I went into team matching, which lasted way longer than the technicals and stretched from September into December with multiple team-specific conversations. Those calls were mostly resume-driven, but some were unexpectedly technical, so it felt like the real bottleneck was not passing interviews but getting matched.
Interview rounds · 4
- 1
Online assessment
CodingI got an OA first, and honestly it was very easy. It was supposed to be 90 minutes, but I finished it in like 5 minutes, and right after that they moved me straight to interviews. It felt more like a gate than a real evaluation.
- 2
Technical round
CodingData Structures & AlgorithmsMy first technical was a pretty standard Google-style coding round on a blank doc, no running code, very little hand-holding. The interviewer gave me a short prompt, held back information unless I asked, and really wanted me to talk through intent, test cases, and edge cases before and after coding.
Q1. Implement a function that processes a stream of interval data.
How they answeredI started with the straightforward interval-processing approach, basically iterating through the stream one piece at a time. Then I realized the real push was around streaming input, so I talked through turning it into a class instead of just a function. I said I’d cache information I’d already processed and batch work together instead of redoing everything in a for loop. I kept the interviewer involved by asking for examples and then walked through edge cases and complexity out loud since you can’t run anything.
Follow-up questions- How would you make this more optimal for streaming input instead of just doing a simple loop?
- What should you cache or store as data keeps coming in?
- 3
Technical round
CodingData Structures & AlgorithmsTechnicalMy second technical was harder because the interviewer gave me basically no hinting at all. It was still a LeetCode-medium type problem, but the real challenge was an optimization follow-up where I had to hit a target complexity and figure out the right supporting data structure on my own.
Q1. Design a priority-queue based structure that maps IDs to people and supports incoming updates.
How they answeredI framed it as a heap or priority queue that stores people keyed by some identification tag, then talked through how new stream updates would break the naive approach because updating inside a heap is awkward. The interviewer pushed me to optimize to a specific complexity and gave me no hint, so I backed into the answer from the complexity bound. I said I’d keep an auxiliary array pointing to positions in the heap so I could update elements in place. That was the hardest part of my whole process because I’d never seen that exact trick before.
Follow-up questions- How would you update values already inside the heap efficiently?
- Can you optimize this to the required complexity?
- 4
Final / onsite round
BehavioralProject DiscussionTechnicalCross-FunctionalTeam matching was a whole separate phase and honestly felt like its own process. I had multiple calls from September through December, and they usually would not even tell me the team beforehand. Most of it was resume and behavioral, but some teams got surprisingly technical depending on what they thought my background was.
Q1. Tell me about your background and why your experience fits this team and role.
How they answeredThese calls were very team specific, and it felt like the managers did not know much about me beyond an AI-style match from my resume. Since I was not told the team in advance, I had to adapt in real time once they introduced the team and role. I focused on tying my past work, both technical and social, to what they said they needed. The biggest prep here was just knowing my resume inside and out and being completely honest on the form, because if you exaggerate, it will catch you fast.
Follow-up questions- What kind of work are you looking to do?
- How do your technical and social experiences match this team’s vibe?
Q2. How would you rebuild one of your projects in a lower-level language to make it faster?
How they answeredOne team took one of my AI projects and basically asked me to rebuild parts of it in C++ because I had said I had lower-level language experience. That caught me off guard because I expected a normal team match chat, not a technical redesign. I said I’d focus on the lower-level parts like tokenization and other fundamental LLM processing pieces that don’t need Python overhead. We worked through it together, and it felt difficult but collaborative rather than adversarial.
Follow-up questions- What parts would you move out of Python?
- Why would C++ or C help here?
Tips from the candidate
For Google, do not prep like this is a normal coding interview where you just grind until the code works. Practice solving on a blank doc, ask for test cases early, talk through your intent the whole time, and always debug your own code out loud with edge cases before they do it for you. If they give you a streaming problem, think about classes, caching, and helper data structures instead of just a raw for loop. And for team matching, know your resume inside and out and have an actual niche, because being vaguely into ML is not enough.
Company culture
My read was that Google cares way more about how you think and communicate than whether you brute-force the exact right answer immediately. The interviewers seemed to value curiosity, methodical reasoning, and whether I could keep them involved, and I really got the sense that if you get quiet or make it boring, you lose them. There was no recruiter screen in my case, and the OA felt almost trivial, so the real evaluation started once I was talking to humans. Team matching also felt very different from other companies because it seemed heavily resume-driven and maybe AI-matched on the backend, and a lot of strong people probably get stuck there rather than in the technical rounds. It also felt like they were hiring for very specific skill sets, not just generic smart interns.