Google Software Engineer (L4) Interview Experience
Google · Mid level · Software Engineer
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.
Interview process
I got into the loop through a backdoor-ish hiring manager route instead of a cold apply, and for L4+ I had to have a soft match with a team before the loop even started. My process was a recruiter alignment call, the GHA questionnaire, one phone screen, two onsite technicals, and a standard Googliness behavioral. What stood out was how collaborative and non-LeetCodey it felt, especially the phone screen, which was basically a live algorithms conversation that pushed on first principles instead of rehearsed patterns. I also learned that Google is doing more team matching before hiring committee now, because a hiring manager's statement of support can strengthen your packet if one round is only lean hire. I ended up accepting because the interview experience was consistently positive and honestly much better than how Google interviews are usually portrayed online.
Interview rounds · 6
- 1
Recruiter screen
BehavioralMy first call was basically a light alignment check with the recruiter, not a real evaluation, and it was mostly about role fit, motivations, and logistics.
Q1. What is your definition of success?
How they answeredI answered this at a pretty high level. The whole call felt more like they were trying to understand me as a person and what motivates me than score me on anything, so I kept it top level and fit-focused.
Q2. Tell me about yourself and walk me through your resume.
How they answeredI gave a very cursory overview rather than a chronological deep dive. They were not probing hard on impact, ownership, or technical depth yet. It was more just making sure my background matched the team and level.
Follow-up questions- Could you describe your experience in your own words?
Q3. Are you authorized to work here, are you open to relocation, and are we aligned on level and role details?
How they answeredI just confirmed the basics like work authorization, relocation openness, and the level I was interviewing for. It really was a checklist call more than anything else.
- 2
Online assessment
BehavioralAfter the recruiter call I got the GHA, which was an async work-style questionnaire where the main trick was staying internally consistent across a lot of similar prompts.
Q1. Complete the Google Hiring Assessment questionnaire.
How they answeredIt was a hundred-plus question async questionnaire. I treated it as a consistency test more than anything else. My prep was basically to keep my answers consistent across similar or inverted questions, and not sit in the middle on every scale.
- 3
Phone screen
Data Structures & AlgorithmsCodingConceptMy phone screen was the most interesting round because it felt like a collaborative whiteboarding conversation with a very senior interviewer, not a LeetCode screen.
Q1. What do you know about algorithms?
How they answeredI started with the fundamentals I knew, and when I mentioned I remembered sorting was n log n but could not fully recall why, he pushed there on purpose. We rebuilt it from first principles together and talked through big O and common algorithms. It felt like he was trying to get to the edge of what I actually understood in real time, so I stayed collaborative and reasoned out loud instead of trying to bluff.
Follow-up questions- Explain big O complexity.
- How do common algorithms fall into those complexity buckets?
- Why is merge sort n log n?
Q2. If the data set is too large to fit in memory on one machine and you have multiple workers, how would you sort it?
How they answeredI treated it as an algorithms problem distributed across workers. I talked through splitting the data, sorting partitions independently, and then merging across workers, and I also layered in a little real-world production thinking around scaling because I think that signals seniority. The prompt itself was very open-ended, so the important part was structuring the approach clearly.
Q3. Define the scope and requirements for a snake_case to camelCase converter function.
How they answeredI focused more on requirements than code. I clarified the exact input format, what invalid input should do, and which edge cases I would guard against before writing much syntax. He seemed much more interested in whether I scoped the function cleanly and set sensible checks than in the implementation itself.
Follow-up questions- What input format do you expect?
- What edge cases should be rejected or handled?
- 4
Technical round
Data Structures & AlgorithmsCodingMy first onsite technical was a string manipulation problem that looked simple at first but really hinged on clarifying the rules and reducing it to the right invariant.
Q1. Given two strings and two allowed operations, swapping positions of letters and converting all occurrences of one character to another, can the first string be transformed into the second?
How they answeredThe question needed a decent amount of clarification, so I whiteboarded edge cases with the interviewer first. Once we constrained it to lowercase letters, the core insight was that it came down to character frequencies, specifically whether the frequency multiset matched across the two strings regardless of which letters the counts were attached to. I also volunteered time and space complexity as I discussed approaches, so I was not really pushed on that at the end.
Follow-up questions- What assumptions can we make about uppercase versus lowercase input?
- Is the input limited to the 26 lowercase letters?
- What edge cases matter here?
- 5
Technical round
Data Structures & AlgorithmsCodingMy second onsite technical was a graph problem dressed up in a more realistic train-schedule format, so a lot of the challenge was parsing the prompt and locking down what exactly we were optimizing for.
Q1. Given a train schedule with departure city, arrival city, start time, end time, and duration, and given a source and destination, find the sequence of trains that gets you there at the earliest possible time.
How they answeredIt was basically the cheapest K stops style graph problem but translated into train-schedule language with more variables, so the first step was clarifying the requirements. We aligned that the real goal was getting from A to B arriving as early as possible, not just minimizing stops. I modeled it as a Dijkstra-style shortest path problem, gave time and space complexity up front, and then spent the rest of the round coding because the setup itself was already pretty dense.
Follow-up questions- Are we optimizing for fewest stops, lowest cost, or earliest arrival?
- Which schedule fields actually matter for the algorithm?
- 6
Final / onsite round
BehavioralThe Googliness round was very straightforward and honestly matched the standard Google behavioral prompts you can already find online, so the main thing was having clean STAR stories ready.
- Q1. Tell me about a time when you had to deal with ambiguity.
- Q2. Tell me about a time when you put the user first and led a product.
- Q3. Tell me about a time you had a disagreement with a co-worker.
- Q4. How do you retain a learning mindset? What do you do to ensure you're constantly learning and growing as an engineer?
Tips from the candidate
I would not prep for Google the same way I would cram tagged Meta questions. I would practice taking ambiguous prompts, clarifying constraints out loud, giving time and space complexity without being asked, and working from first principles when you hit something you do not fully remember. For Googliness, have clean STAR stories ready for ambiguity, user focus, conflict, and learning mindset because they really do ask the standard prompts. And for the GHA, I would be very consistent in my answers and not live in the middle on every scale.
Company culture
I saw a company that has not changed the core loop nearly as much as places like Meta. They are bringing interviews back onsite because cheating got bad, and at L4+ they want a soft team match before you even start, which means headcount can shift underneath you if the process drags for months. My interviewers all came from the same org I soft matched with, so it felt more targeted than a generic pool. I also saw this newer flow where recruiters may push team match before hiring committee so a manager can add a statement of support if your packet is borderline. The interviews themselves felt designed to get real signal, with more ambiguity and collaboration and less speed-running memorized LeetCode.