Copy<\/button><\/div>\n\nfrom collections import deque\ndef level_order(root):\n\n if not root:\n\n return []\n\n result, queue = [], deque([root])\n\n while queue:\n\n level = []\n\n for _ in range(len(queue)):\n\n node = queue.popleft()\n\n level.append(node.val)\n\n if node.left:\n\n queue.append(node.left)\n\n if node.right:\n\n queue.append(node.right)\n\n result.append(level)\n\n return result\n<\/code><\/pre><\/div>Describe a time you had to handle a conflict with a teammate<\/span>Googleyness<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Conflict resolution stories should include the specific nature of the disagreement (not “we had different opinions” but “they wanted to rewrite the entire service; I thought we should isolate the broken module”), how you surfaced it constructively, and whether the resolution actually stuck. “We talked it out and agreed” is not a complete answer. What changed after the conversation, and how do you know the change held?<\/p>\n
Reported from a 2025 Googleyness round where the candidate said the interviewer asked specifically about the aftermath, not just the resolution moment. Google cares about durable outcomes, not one-off conversations.<\/p>\n
<\/div><\/div><\/div>\n
Tell me about a time you improved a process or system without anyone asking you to<\/span>Googleyness<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
This maps to the “putting users first” and “doing the right thing” Googleyness traits. The strongest answers involve spotting a pain point (slow CI pipeline, flaky test suite, manual deployment step) that others had accepted as normal, quantifying its cost (2 hours per engineer per week), and shipping a fix that persisted after you moved on. The “without being asked” element matters: Google wants engineers who identify problems, not just execute on assigned tickets.<\/p>\n
One specific pattern that scores well here: the candidate noticed the problem through user or teammate feedback, not because it affected them directly. That signals user-first orientation.<\/p>\n
<\/div><\/div><\/div>\n
Why Google? What draws you to this role specifically?<\/span>Googleyness<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Generic answers about scale, impact, or “working on products used by billions” do not land well at Google. They hear that in every interview. What works: specificity about the team’s actual work, a product or infrastructure challenge that connects to your background, or a technical direction at Google that you’ve thought about and have an informed opinion on.<\/p>\n
Do homework on what the specific team ships. If it is a Search infrastructure role, that’s the 2024 Search quality updates and the indexing pipeline changes. If it is a YouTube team, that’s the live streaming latency work. If you cannot get specifics from the recruiter, ask directly: “What is the team’s top priority in 2026?” That question itself is a signal.<\/p>\n
<\/div><\/div><\/div>\n
Tell me about a time you went out of your way for a user, even though it wasn't technically your job<\/span>Googleyness<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Maps to “put the user first.” The strongest stories describe noticing a user-facing problem that wasn’t on your team’s roadmap and either fixing it directly or escalating it loudly enough that someone did, with a concrete before-and-after: fewer support tickets, lower error rate, a specific latency number.<\/p>\n
Candidates who reach for an actual customer or end user in the example score better than ones who substitute a teammate for “user.” The trait is specifically about people outside your immediate team, and interviewers reportedly notice when a candidate quietly swaps in an easier internal example.<\/p>\n
<\/div><\/div><\/div>\n
Does Google ask system design questions at L4?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Not as a standard round. System design is formally part of the L5 and above evaluation at Google. Multiple candidate reports from 2024 and 2025 confirm that L4 onsites typically include two to three coding rounds plus one Googleyness round. That said, a few teams include a lighter design conversation within the hiring manager call, and some candidates are simultaneously evaluated against the L5 bar, in which case a design round may appear. Ask your recruiter directly for your specific loop format.<\/p>\n
<\/div><\/div><\/div>\n
How long does the Google L4 interview process take?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Most candidates report six to ten weeks from initial application to verbal offer. The phone screen typically happens one to two weeks after the GHA. Onsites are scheduled one to three weeks after the phone screen clears. Hiring committee review after the onsite adds another one to two weeks. Referrals and recruiter-sourced candidates often move faster, sometimes four to five weeks total. The hiring committee review is the step with the most variance in timing.<\/p>\n
<\/div><\/div><\/div>\n
What coding language should I use for Google interviews?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Python is the most commonly used language in reported Google interviews and is generally preferred for its readability in a shared Google Doc. Java and C++ are also accepted. The shared Doc format means there is no syntax highlighting or autocomplete, so using a language with clean, readable syntax matters more than usual. Whatever you choose, know the standard library cold: Python’s collections module, heapq, and itertools come up constantly, and fumbling with syntax in a Doc with no autocomplete wastes time.<\/p>\n
<\/div><\/div><\/div>\n
How difficult are Google's coding problems compared to LeetCode?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Phone screen: medium difficulty, sometimes on the easier end of medium. Onsite coding rounds: medium to hard, with follow-up constraints that often push a medium problem into hard territory. The “Count Range Sum” problem (hard) has been specifically reported at L4 onsites. A practical benchmark from candidate reports: if you can solve 70% of LeetCode mediums and 30% of hards in 30 minutes with a clean explanation, you are roughly at the bar. Speed matters less than correctness and communication.<\/p>\n
<\/div><\/div><\/div>\n
What is the Google Hiring Assessment and can I fail it?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
The GHA is a 30 to 45 minute personality-and-culture screen with about 50 Likert-scale questions. It is not a coding test. Google does use it as a filter before the recruiter call in some pipelines, so candidates who rush through it or answer inconsistently can get screened out before their resume reaches a human reviewer. Answer honestly and consistently. There are no objectively correct answers, but large inconsistencies between related questions flag the screener.<\/p>\n
<\/div><\/div><\/div>\n
Is Google interviewing in-person or virtually in 2026?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Both, and increasingly a hybrid. As of 2025, Google has been requiring at least one in-person round for candidates within commuting distance of a Google office, partly in response to AI-assisted cheating concerns during virtual coding sessions. For candidates geographically remote from a Google office, fully virtual loops are still available. The format for your specific loop will be communicated by your recruiter. The coding environment is identical either way: a shared Google Doc with no editor tooling.<\/p>\n
<\/div><\/div><\/div>\n
What happens after the Google onsite? How does the hiring committee decide?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Each interviewer submits a written packet, not just a numeric score, describing what they observed in detail. A hiring committee made up of engineers and managers who never interviewed you then reviews the full set of packets and makes the call without meeting you in person. If approved, most L4 candidates move into a separate Team Match process to be paired with a specific team, and Google’s final leveling can occasionally shift up or down slightly during that stage based on team fit.<\/p>\n
Reported: this two-stage structure surprises a lot of candidates who assume the interview loop itself makes the final decision. Multiple 2025 write-ups describe waiting two to three weeks between hiring committee approval and being matched to an actual team, which is separate time from the interview process itself.<\/p>\n
<\/div><\/div><\/div>\n
Can I reapply if I get rejected in the Google L4 loop?<\/span>FAQ<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Yes, but Google enforces a cooldown before you can interview again. The most commonly reported window is 12 months after a full-loop rejection, sometimes shorter for candidates rejected earlier in the process, such as at the recruiter screen or phone screen stage. The exact window isn’t published anywhere official, and recruiters give different numbers depending on the specific req and how the rejection was recorded internally.<\/p>\n
Reported: candidates who reapply after addressing one specifically named weakness from their prior loop describe better outcomes than those who just say they “practiced more” in general. Vague, undirected re-preparation reportedly gets flagged in a similar way to the first attempt.<\/p>\n
<\/div><\/div><\/div>\n
What is the difference between a stack and a queue, and when would you use each?<\/span>Data structures<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
A stack is last-in-first-out. The last element you push is the first one you pop. A queue is first-in-first-out. The first element you enqueue is the first one you dequeue. Both support O(1) insert and remove when implemented correctly, the difference is purely about which end you’re allowed to touch.<\/p>\n
Stacks show up in call frames (the actual function call stack), undo\/redo history, parsing balanced parentheses, and depth-first traversal, since you naturally want to explore the most recently discovered node first. Queues show up in breadth-first traversal, task scheduling, and any producer-consumer setup where fairness matters, like a print queue or a request buffer, because you want to process things in the order they arrived rather than the order you most recently saw them.<\/p>\n
One gotcha interviewers like to probe: implementing a queue with two stacks. You push everything onto an “in” stack, and when you need to dequeue, you pop everything from “in” into an “out” stack (reversing the order) and pop from “out”. Each element moves at most twice across its lifetime, so the amortized cost per operation is still O(1) even though a single dequeue can occasionally be O(n).<\/p>\n
<\/div><\/div><\/div>\n
What is Big O notation and why do interviewers care about it?<\/span>Complexity analysis<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Big O describes how the running time or memory use of an algorithm grows as the input size n grows, ignoring constant factors and lower-order terms. O(n) means the work scales linearly with input size, O(n log n) is what you get from good sorting algorithms and divide-and-conquer approaches, O(n squared) usually means nested loops over the same collection, and O(log n) means you’re cutting the problem in half at each step, like binary search.<\/p>\n
Interviewers care about it because it’s the fastest way to tell whether a candidate’s solution will actually work at scale, not just on the small example in front of them. A brute force O(n squared) solution that checks every pair might pass on an input of 10 elements and time out on an input of 10 million, which is exactly the kind of thing that breaks in production. Asking for the complexity forces you to reason about your own solution instead of pattern-matching to a memorized answer.<\/p>\n
It’s also worth knowing the difference between average case and worst case, and being able to state both. A hash map lookup is O(1) on average but O(n) in the worst case if every key collides into the same bucket. Google interviewers will sometimes push on this specifically, asking what happens if your hash function is bad or your input is adversarial, so having an answer ready for the worst case, not just the happy path, shows you actually understand the data structure rather than just having used it.<\/p>\n
<\/div><\/div><\/div>\n
<\/span>Medium questions<\/h2>23<\/span><\/div><\/div><\/div>\n
Find the length of the longest substring without repeating characters<\/span>Sliding Window<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Sliding window with two pointers and a hash set. The left pointer advances whenever a duplicate is found, removing the leftmost character from the set. Track the maximum window size seen. Time complexity O(n), space O(min(n, alphabet size)).<\/p>\n
Reported from a 2025 phone screen. The follow-up almost always extends to: “What if the string contains Unicode characters instead of ASCII?” The answer changes the space complexity bound, since the character set is no longer bounded by 128. The interviewer is checking whether you understand why you chose the data structure, not just that you did.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\ndef length_of_longest_substring(s: str) -> int:\n\n char_set = set()\n\n left = 0\n\n max_len = 0\n\n for right in range(len(s)):\n\n while s[right] in char_set:\n\n char_set.remove(s[left])\n\n left += 1\n\n char_set.add(s[right])\n\n max_len = max(max_len, right \u2013 left + 1)\n\n return max_len\n<\/code><\/pre><\/div>Merge overlapping intervals<\/span>Arrays<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Sort by start time. Iterate through the list; if the current interval’s start is less than or equal to the previous merged interval’s end, extend the end. Otherwise append a new interval. Common edge cases to discuss: single interval, all intervals overlapping, intervals that touch exactly (e.g., [1,3] and [3,5], most Google interviewers want these merged).<\/p>\n
Reported from multiple L4 onsites and at least two phone screens. Shows up with different framings: meeting rooms, calendar events, time blocks. The underlying structure is always the same. One candidate’s 2024 write-up described four follow-up questions after the base solution, ending with “what if intervals can be added dynamically and you need to query the merged state after each insertion?”<\/p>\n
python<\/span>Copy<\/button><\/div>\n\ndef merge(intervals: list[list[int]]) -> list[list[int]]:\n\n intervals.sort(key=lambda x: x[0])\n\n merged = [intervals[0]]\n\n for start, end in intervals[1:]:\n\n if start <= merged[-1][1]:\n\n merged[-1][1] = max(merged[-1][1], end)\n\n else:\n\n merged.append([start, end])\n\n return merged\n<\/code><\/pre><\/div>Word break: determine if a string can be segmented into dictionary words<\/span>Dynamic Programming<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Bottom-up DP. Boolean array dp where dp[i] is true if s[0:i] can be segmented. For each index i, check all j from 0 to i: if dp[j] is true and s[j:i] is in the word set, set dp[i] to true. Time O(n^2 * m) where m is average word length for the substring check; use a hash set for O(1) word lookups.<\/p>\n
Reported from a phone screen and an onsite in 2024. Follow-up: “Return all valid segmentations, not just whether one exists.” That shifts the problem from DP to backtracking with memoization, and the state space is much larger. Interviewers want to hear you articulate the shift in approach before implementing.<\/p>\n
<\/div><\/div><\/div>\n
Group a list of strings into anagrams of each other<\/span>Hash Map<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Build a hash map where the key is a canonical form of each word (either the sorted character string, or a fixed-length count vector of the 26 lowercase letters) and the value is the list of original words that share that key. One pass through the input, one hash map. Time is O(n * k log k) with sorting as the key, or O(n * k) with a count vector, where k is average word length.<\/p>\n
Reported from several 2024-2025 phone screens as a warm-up before a harder string problem. The follow-up worth having ready: “the sorted-string key is O(k log k) per word, can you do better?” The count-vector key answers that directly, and most candidates don’t reach for it until prompted, which is exactly why interviewers ask.<\/p>\n
<\/div><\/div><\/div>\n
Compute the product of every element except itself, without using division<\/span>Arrays<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Two passes. First pass builds a prefix-product array where each index holds the product of every element to its left. Second pass walks right to left, multiplying a running suffix product into the prefix array as it goes. No division anywhere, so a zero anywhere in the input never causes a divide-by-zero edge case to handle separately.<\/p>\n
Reported from multiple 2024 phone screens. The instinctive first answer (divide the total product by each element) gets rejected immediately once you say it out loud, since division isn’t allowed and zeros in the input break it anyway. Interviewers want to see you reach for prefix and suffix products without being told division is banned.<\/p>\n
python<\/span>Copy<\/button><\/div>\n\ndef product_except_self(nums: list[int]) -> list[int]:\n\n n = len(nums)\n\n result = [1] * n\n\n prefix = 1\n\n for i in range(n):\n\n result[i] = prefix\n\n prefix *= nums[i]\n\n suffix = 1\n\n for i in range(n \u2013 1, -1, -1):\n\n result[i] *= suffix\n\n suffix *= nums[i]\n\n return result\n<\/code><\/pre><\/div>Find the minimum number of coins needed to make a target amount<\/span>Dynamic Programming<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Bottom-up 1D DP. dp[amount] holds the fewest coins needed to make that amount, initialized to infinity except dp[0] = 0. For each amount from 1 up to the target, try every coin denomination and take dp[amount – coin] + 1 if that’s smaller than the current value. If dp[target] is still infinity at the end, the amount can’t be made with the given coins.<\/p>\n
Reported from a phone screen in late 2024. The follow-up that shows up almost every time: “now return one valid combination of coins, not just the count.” That requires tracking which coin was used at each dp index and walking backward from the target once the table is filled, which is a different kind of bookkeeping than the count-only version.<\/p>\n
<\/div><\/div><\/div>\n
Number of islands in a 2D grid<\/span>DFS \/ Graphs<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
DFS or BFS from each unvisited land cell. Mark visited cells in-place (change ‘1’ to ‘0’ or a separate visited array). Each DFS call from a new ‘1’ increments the island count. Time O(m*n), space O(m*n) for the recursion stack in the worst case (grid entirely land).<\/p>\n
Reported from multiple 2025 onsite rounds. Follow-ups go fast here: “What if the grid is too large to fit in memory?” (stream rows, track boundary cells). “What if cells connect diagonally?” (add 4 more neighbor directions). “What is the area of the largest island?” (track size during DFS). Having these extensions ready to discuss matters.<\/p>\n
<\/div><\/div><\/div>\n
Autocomplete system using a trie<\/span>Trie<\/span>Medium<\/span><\/span><\/span><\/button>