Google New Grad Software Engineer (L3) Interview Experience
Google · Entry level · Software Engineer
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.
Interview rounds · 3
- 1
Technical round
CodingData Structures & AlgorithmsTechnicalMy 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.
Q1. Given an array of strings, return groups of "buddy strings," where the strings have the same length and the distance between corresponding characters is the same.
How they answeredI 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.
Follow-up questions- 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?
- 2
Other round
BehavioralCross-FunctionalProject DiscussionThe 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.
Q1. Walk me through your previous internship and what you worked on there.
How they answeredThey 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.
Follow-up questions- How did it go?
- What did you like and dislike about it?
- What was your summer project?
- Q2. If another team rewrote your code and now it's broken, how would you communicate with them?
- Q3. If you and a coworker disagree in a meeting about how to solve a problem, how would you handle it?
Q4. If you felt like you weren't getting credit for your work, how would you bring that up with your manager?
How they answeredI 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.
Follow-up questions- What specifically would you bring to that conversation?
- 3
Final / onsite round
CodingData Structures & AlgorithmsTechnicalThe 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.
Q1. 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.
How they answeredI 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.
Follow-up questions- Can you change this part so the solution is actually linear?
- Can you dry run it on an example?
Q2. Given a string and an integer width, return how many lines you can write the string in.
How they answeredThis 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.
Follow-up questions- What exactly are the assumptions here?
- Have you thought about using modulo?
Tips from the candidate
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.