Updated by Google candidates
New Grad Software Engineer (L3) Interview Experience
One of my onsite interviewers pasted a prompt that was basically one sentence long and then just sat back. That round made it click for me that Google was testing how I clarified and structured the problem, not whether I could speedrun a DSA coding problem.
Interview process
I got in through a referral, so I didn't have a recruiter screen and went straight into interviews. I applied around the end of September, didn't hear back until mid-November, then did two 45-minute virtual rounds in December: one technical and one googliness/behavioral. I heard back within the week that I passed, then had about another month to prep before the onsite in mid-January, which was just two more 45-minute technical interviews. The coding questions felt more custom than straight LeetCode, and the main thing Google seemed to care about was how I clarified the problem, communicated my thinking, and reasoned my way to a solution. I made it through the full loop but got rejected, and the timing was all over the place because the first feedback came quickly while the final decision took about three weeks.
- Technical interview
- Other
- Final round
Interview rounds
7 questions across 3 roundsTechnical interview
1 questionOverview
My first 45-minute technical was in a shared Google doc with no compiler, and the interviewer mostly let me drive unless I got stuck, then circled back hard on dry-running, complexity, and whether I really understood my own code.
Question types asked
Specific questions asked
Can you dry run your code line by line on an example?
What's the time complexity and space complexity?
If you had more time, what improvements would you make?
Are you sure this Python ASCII built-in works the way you expect?
I treated it like a hashmap/string problem and talked through how I'd group strings based on that character-distance pattern. Since the doc doesn't run, I had to make my own example and manually dry run everything line by line. After that I explained the time and space complexity. They also pushed on whether I understood a Python ASCII-related built-in the way I was using it, and then asked how I'd clean the solution up if I had more time, like making it more modular instead of just coding fast.
Other
4 questionsOverview
The googliness round was a separate 45-minute interview right after, and it was pretty straightforward: a quick resume skim plus hypothetical conflict questions about teammates, managers, and how I'd handle messy workplace situations.
Question types asked
Specific questions asked
Walk me through your previous internship and what you worked on there.
How did it go?
What did you like and dislike about it?
What was your summer project?
They pulled up my resume and had me talk through a previous software engineering internship. I explained how it went overall, what I liked, what I didn't like, and gave some context on the project I worked on. It wasn't super deep, but they definitely wanted to get a real sense of my past experience instead of just reading the bullets.
What specifically would you bring to that conversation?
I said I'd use my regular one-on-ones with my manager and come in prepared with actual notes from the week. I mentioned writing down the specific work I did, including things like pull requests and concrete tasks, and then bringing that up directly instead of just saying I felt overlooked. Their follow-up was basically asking what details from those notes I'd actually share.
Final round
2 questionsOverview
The onsite was just two 45-minute technicals on a Chromebook in the same shared-doc setup, and the big difference was that one interviewer gave me the target complexity up front while the other gave me an extremely vague one-line prompt and made me clarify everything.
Question types asked
Specific questions asked
I got a custom two-pointer/sliding-window string question over an array of strings, and the interviewer said he wanted a linear-time solution.
Can you change this part so the solution is actually linear?
Can you dry run it on an example?
I started with a pretty normal sliding-window approach and talked through initializing the window and scanning through the array. My first pass wasn't actually linear even though that was the target. The interviewer pointed at one part of my solution that was slowing it down, and once he nudged me there I saw how to adjust it and get to the linear version. I don't remember a bunch of extra follow-ups on that one besides the dry run and that complexity push.
Given a string and an integer width, return how many lines you can write the string in.
What exactly are the assumptions here?
Have you thought about using modulo?
This one threw me off because the prompt was literally one sentence and he didn't add anything unless I asked. I spent a lot of time asking clarifying questions, but I think I was still going down the wrong path because I started trying to implement too fast instead of really pinning down the problem. He kept responding with stuff like, "that might work," which didn't help much, and eventually gave me a pretty big hint around using modulo. In hindsight, I should have slowed down way earlier.
Interview tips
I wouldn't just grind LeetCode and call it good. If I were doing it again, I'd give myself more like two to three months, do a lot more mock interviews, and really practice the act of talking through a problem with someone instead of solving it alone. The biggest thing I learned is not to rush straight into code. What helped me most was solving examples by hand first and building the intuition for the problem before I ever started typing, because that's a lot closer to what Google actually rewards.
Company culture
Google's interview process felt less like, "can you solve the hardest coding problem," and more like, "can you reason clearly in front of me." All the technical rounds used a shared doc where nothing compiles, so dry-running and explaining your thought process matters a lot. The questions also felt more custom than normal LeetCode, especially when they gave me something vague and expected me to ask the right clarifying questions. Process-wise, they seem pretty inconsistent on timing. I heard back from my first round fast, then waited weeks after the onsite, so I wouldn't overread how long it's taking. From the people I know there, the culture itself seems pretty relaxed with solid work-life balance, and compared with other big tech places it feels a little more driven to build new things.
Get full access with a membership, or share your experience to try it free.
More Google interview experiences
“My strongest Google round was with a senior interviewer who never opened a LeetCode prompt. He just asked what I knew about algorithms, pushed me into distributed merge sort from first principles, and apparently got more signal from that than a standard coding screen.”
“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.”
