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 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.
Questions asked
Overview
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.
Get full access with a membership, or share your experience to try it free.
