Google Software Engineer interviews typically run 4-6 rounds over about 4-10 weeks. The process usually moves from resume review and an online assessment into recruiter and technical screens, then a multi-round onsite loop with coding and Googliness/behavioral evaluation before final review and team matching.
$119K
Avg. Base Comp
$320K
Avg. Total Comp
4-6
Typical Rounds
4-10 weeks
Process Length
Across the two dozen experiences we've collected, one pattern stands out immediately: Google's interview bar is less about algorithmic obscurity and more about how you reason under ambiguity. Multiple candidates noted that questions were intentionally vague, requiring them to spend meaningful time clarifying the prompt before writing a single line of code. This isn't accidental. The interviewers are watching how you drive the conversation, not just whether you arrive at the right answer. Candidates who jumped straight into coding without establishing the problem constraints consistently struggled more than those who slowed down to ask good questions.
The technical content itself skews heavily toward graphs, trees, dynamic programming, and string manipulation — and the questions we've seen confirmed this, with problems like cyclic detection, longest increasing subsequence, and substring variants appearing repeatedly. What's less obvious is that the follow-up pressure is often harder than the initial question. A recurring theme is interviewers asking candidates to optimize after a first working solution, and several candidates described this escalation as the real filter. One candidate described a stack problem where the two-pointer approach alone wasn't sufficient — you had to combine it with a stack to reach the optimal solution. That kind of layered thinking is what Google is actually screening for.
The Googleyness round deserves more attention than most candidates give it. We've seen multiple people treat it as a formality after the coding rounds, but the experiences here suggest it carries real weight — particularly for new grad candidates. Communication, motivation, and how you talk about team dynamics came up consistently as factors that influenced outcomes. The process is long, sometimes nine rounds across months, and the difficulty escalates deliberately toward the end. Candidates who paced their preparation evenly across the full loop, rather than front-loading coding practice, seemed better positioned for the later stages.
Synthetized from 20 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Google process.
I had four rounds in total—three technical coding rounds and one Googliness/behavioral discussion. Going in, I expected the coding questions to be insanely difficult, but what surprised me was that the interviewers cared just as much about how I thought as whether I got the final answer.
The first round was probably the smoothest. It started with a few minutes of introductions and then jumped straight into a data structures problem. I talked through my thought process, proposed a brute-force solution first, and then optimized it after discussing trade-offs. The interviewer dropped a few hints along the way, which made it feel more collaborative than adversarial.
The second round was where I started sweating a bit. I got stuck on an edge case that broke my solution, and for a couple of minutes I just couldn't see what was wrong. Instead of silently staring at the screen, I kept explaining what I was checking. The interviewer nudged me in the right direction, and once I found the bug, I managed to finish the optimized solution. That round taught me that staying communicative is much better than freezing.
The third technical round focused more on problem-solving than memorized algorithms. There were follow-up questions about complexity, handling larger inputs, and how I would design the solution if the constraints changed. It felt closer to discussing software engineering than just solving a LeetCode problem.
The final conversation was much more relaxed. We talked about projects I had worked on, times I had handled setbacks, why I wanted to work at Google, and how I approach learning new technologies. It felt like they were trying to understand how I collaborate and think, rather than trying to catch me out.
The biggest surprise was how interactive the interviews were. I had imagined long periods of silent coding, but instead it felt like solving problems with another engineer. The moments where I felt most confident were when I clearly explained my reasoning. The moments I felt least confident were when I hit an unexpected edge case or couldn't immediately see the optimization. Overall, the experience was challenging, but much less intimidating than I'd built it up to be.
Questions asked: Some of the technical questions I remember included:
Given the root of a binary tree, find the lowest common ancestor of two nodes. I first explained the recursive approach and then discussed the iterative version and time/space complexity. Design an LRU Cache supporting get() and put() in O(1) time. The interviewer expected a combination of a hash map and a doubly linked list and asked me to explain why both were needed. Given a list of intervals, merge all overlapping intervals. After solving it, I was asked how the solution would change if the intervals arrived as a stream instead of all at once. A graph problem involving finding the shortest path in an unweighted graph using BFS, followed by a discussion on how the approach would change if the graph were weighted. A system design style follow-up where I was asked how I would design a URL shortener for millions of users. It wasn't a full design interview, but they wanted to understand my thought process around scalability and trade-offs.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Google
Select the 2nd highest salary in the engineering department
| Question | |
|---|---|
| Empty Neighborhoods | |
| Top Three Salaries | |
| Merge Sorted Lists | |
| String Shift | |
| First Touch Attribution | |
| Raining in Seattle | |
| Top 3 Users | |
| Job Recommendation | |
| Minimum Change | |
| Delivery Estimate Model | |
| Find the First Non-Repeating Character in a String | |
| Find Bigrams | |
| Last Transaction | |
| Detecting ECG Tachycardia Runs | |
| The Brackets Problem | |
| Friendship Timeline | |
| Size of Joins | |
| Daily Retention Summary | |
| P-value to a Layman | |
| Level Of Rain Water In 2D Terrain | |
| Google Maps Improvement | |
| N-gram Dictionary | |
| Nearest Common Ancestor | |
| Four Person Elevator | |
| Cyclic Detection | |
| Basic Regex | |
| Type-ahead Search | |
| Longest Increasing Subsequence | |
| Sort Strings |
Synthesized from candidate reports. Individual experiences may vary.
Applications are screened by a recruiter or hiring team, and some candidates report a silent rejection through the portal rather than email. Qualified applicants may then complete a 20-60 minute coding assessment with two LeetCode-style problems, usually easy to medium difficulty.
A recruiter or HR representative confirms your background, role fit, and logistics while outlining the rest of the process. This conversation may also include a light technical check or a discussion of salary expectations, depending on the recruiter and level.
You complete a one-on-one coding interview with a Google engineer focused on data structures and algorithms. Candidates are expected to clarify vague prompts, explain their reasoning aloud, and work toward an optimized solution, often in a shared Google Doc rather than an IDE.
The main loop usually includes several coding rounds spanning graphs, trees, dynamic programming, strings, and backtracking. Interviewers often push for follow-up optimizations after a first solution, and the loop may also include a Googleyness or behavioral round; some teams add system design depending on level.
Interview feedback is compiled for hiring committee review before a final decision is made, and candidates may have little direct communication during this stage. If approved, the process can continue into team matching conversations with a hiring manager or potential team lead that are more project- and fit-focused.