Google Software Engineer L4 Interview Complete Review: Algorithms, System Design, and Behavioral Rounds

Background

Let me start with my background: 5 years of software development experience, currently working as a backend engineer at a major Chinese tech company. My primary tech stack is Go and Python, and I also write infrastructure-related code on a regular basis. In March 2026, a former colleague who works at Google's Mountain View office referred me — he said his team was hiring L4 SWEs and asked if I wanted to give it a shot.

Honestly, I hesitated for a full week. On one hand, while I wasn't exactly thrilled at my current company, the pay was stable and the team was decent. On the other hand, Google had always been my dream company, and an opportunity like this might not come again. I finally submitted my resume in late March for the Software Engineer L4 position, with Mountain View as my preferred location.

The entire process from application to offer took about 8 weeks. I got the recruiter's initial screening call in mid-April, completed the phone screen in late April, had my virtual onsite scheduled for mid-May, and received the result in late May. The process was faster than I expected, but that one week of waiting for the result felt like an eternity.

My preparation period was about 6 weeks. I did 2-3 LeetCode problems every day after work and practiced system design on weekends. I solved roughly 120 problems total, focusing on Medium and Hard, with emphasis on graph theory, dynamic programming, and binary search. For system design, I read both of Alex Xu's books and watched some YouTube videos. I spent one week on behavioral prep, organizing about 8 STAR stories.

Round 1: Coding Interview (~45 minutes)

My interviewer was a Senior SWE who had been at Google for 6 years. He was very friendly, spent about 2 minutes on introductions, and then jumped straight into the problems.

Problem 1: Course Schedule Validity Check (Variant)

Problem description: Given n courses, a set of prerequisite pairs [a, b] meaning course a depends on course b, and a set of conflict pairs [c, d] meaning courses c and d cannot be taken in the same semester. Determine whether a valid course schedule exists.

This is essentially a topological sort variant. I initially only considered the prerequisite relationships for the topological sort. After I finished writing it, the interviewer asked about handling the conflict relationships. I thought for about 3 minutes and proposed modeling the conflict relationships as a graph coloring problem — courses in the same semester cannot conflict, which is equivalent to assigning semester numbers to topologically sorted courses such that conflicting courses end up in different semesters.

I used a BFS topological sort + greedy semester assignment approach, with time complexity O(V+E+C) where C is the number of conflict pairs. The interviewer acknowledged this approach but then asked about minimizing the number of semesters. I got stuck briefly here, but eventually proposed binary searching on the number of semesters and using topological sort to check feasibility for each candidate. The interviewer nodded.

Problem 2: Interval Merge Count

Problem description: Given a set of intervals, find the number of merged intervals and output the start and end positions of each merged interval. Follow-up: If the number of intervals is extremely large (on the order of billions), how would you optimize?

The first part is a classic interval merge problem, which I quickly completed. For the follow-up, I proposed an external sort + streaming merge approach. The interviewer asked for implementation details, including how to handle large-scale data with limited memory. I drew a diagram showing how to use multi-way merge + a min-heap approach, and the interviewer seemed satisfied.

My impression: The pace was quite tight. The first problem's variant definitely required some thinking, but fortunately topological sort is a fundamental skill. The follow-up on the second problem made me a bit nervous, but I managed to come up with the external sort approach. The interviewer didn't show much expression throughout, but said "good job" at the end, which gave me some relief.

Round 2: Coding Interview (~45 minutes)

This interviewer was an L5 SWE with a completely different style from the first round — very quiet, barely spoke, and just watched me code the entire time.

Problem 1: Decode String

Problem description: Given an encoded string where k[encoded_string] means the bracketed string is repeated k times (with possible nesting), return the decoded string. For example, "3[a2[c]]" decodes to "accaccacc".

This is LeetCode 394. I quickly wrote the stack-based solution in about 10 minutes. The interviewer glanced at it, asked me to analyze the time and space complexity (both O(n)), and then said "next question."

Problem 2: Minimum Flight Transfers with Budget Constraint

Problem description: Given a list of flights (from, to, price), find the path from origin to destination with the minimum number of transfers where the total price does not exceed a given budget. If multiple paths have the same number of transfers, return the one with the lowest total price. n cities, m flights, n ≤ 100, m ≤ 10,000.

I thought about this for about 5 minutes. I initially considered Dijkstra, but realized it wouldn't work well since we need to optimize two dimensions simultaneously (transfer count and price). I then proposed using BFS by level (each level represents one transfer), while maintaining the minimum price to reach each city, and pruning any path where the total price exceeds the budget.

I made a bug while coding — I wrote the BFS visited check incorrectly. I should have used city + currentPrice as the state key, not just the city alone. The interviewer pointed this out, and I immediately fixed it. The time complexity is O(m * budget), and the interviewer didn't raise any objections.

My impression: The second problem definitely made me nervous. The BFS dual-dimension optimization approach wasn't the first thing that came to mind, and the visited state bug made me feel like I didn't perform well. The interviewer was expressionless the entire time, making it impossible to read their thoughts. After this round, I honestly thought I might have failed it.

Round 3: System Design (~45 minutes)

This was the round I was most nervous about, since system design has always been my weak point. The interviewer was a Staff Engineer — very senior, and his questions were quite guiding.

Problem: Design Google Drive

The interviewer said: "Design a cloud file storage system like Google Drive that supports file upload/download, sharing, and real-time collaboration."

I started breaking it down using my usual framework:

1. Requirements clarification: I proactively asked several questions — user scale (the interviewer said 1 billion+), single file size limit (5TB), whether version control is needed (yes), whether real-time collaborative editing is needed (yes, similar to Google Docs). The interviewer acknowledged my questions positively.

2. Capacity estimation: 1 billion users, assuming an average of 50GB per user, total storage is approximately 50PB. Assuming 100 million DAU, with an average of 10 file uploads/downloads per day, QPS is approximately 100K, with peak QPS around 500K.

3. High-level architecture: I drew a Client → API Gateway → Metadata Service + File Storage Service + Notification Service architecture. Metadata Service uses a relational database (Spanner), File Storage uses object storage, and Notification uses long polling or WebSocket.

4. File upload: I proposed a chunked upload approach with 4MB chunks. The client uploads multiple chunks in parallel, and the server merges them. The interviewer asked about implementing resumable uploads, and I described tracking the list of uploaded chunks.

5. File sharing: I designed an ACL-based permission model where each file/folder has an owner and an ACL list. The interviewer asked about implementing sharing links — I proposed using short URLs + tokens with expiration times and optional password protection.

6. Real-time collaboration: This was the hardest part. I proposed an OT (Operational Transformation) based approach, but the interviewer asked me to explain OT's principles in detail. Honestly, my understanding of OT was only at the conceptual level, and I couldn't explain the implementation details clearly. The interviewer then asked about the difference between CRDT and OT. I roughly explained that CRDT provides eventual consistency while OT provides strong consistency, but I clearly wasn't deep enough on the details. The interviewer didn't push further, but their expression suggested they weren't fully satisfied.

7. Data consistency: The interviewer asked about cross-region replication. I proposed async replication + read-your-writes consistency, using version numbers to resolve conflicts.

My impression: I performed well in the first half — requirements clarification and capacity estimation were solid, and chunked upload and ACL-based sharing were explained clearly. But the real-time collaboration part definitely exposed my weakness. I hadn't prepared the OT/CRDT implementation details thoroughly enough. If I could do it over, I would definitely study Google Docs' collaboration principles in depth.

Round 4: Coding Interview (~45 minutes)

This interviewer was an L4 SWE who had joined Google even more recently than me, but was clearly very strong technically. The style was very relaxed, almost like discussing a problem with a colleague.

Problem 1: Binary Tree Maximum Path Sum

Problem description: Given a binary tree, find the maximum path sum between any two nodes (the path with the maximum sum of node values). This is LeetCode 124, a classic Hard problem.

I had practiced this problem before, so I quickly provided the recursive + global variable solution. The key insight is: for each node, compute the maximum path sum using that node as the "turning point," while returning the single-sided maximum contribution from that node to its parent. Time complexity O(n), space complexity O(h). The interviewer had me run through two test cases, confirmed correctness, and moved on.

Problem 2: Design a Data Structure for Dynamic Median Queries

Problem description: Implement a data structure supporting three operations: addNum(num) to add a number, findMedian() to return the current median, and removeMedian() to delete the median. All operations should be O(log n).

addNum + findMedian is the classic two-heap problem, which I quickly implemented. But removeMedian stumped me — after deleting the top element, you need to rebalance the two heaps. I initially thought of lazy deletion, but the interviewer said "if deletions are frequent, lazy deletion will cause the heaps to grow unbounded." I thought for a moment and proposed using two heaps + an auxiliary rebalancing operation: after deleting the median, move one element from the larger heap to the smaller one. For the implementation, I used a HashMap to track deleted elements, only truly popping from the heap when the top element is marked as deleted.

The interviewer asked about edge cases, like what happens with consecutive median deletions. I admitted this approach could degrade in extreme cases, but the interviewer said "it's good enough for an interview."

My impression: Overall, I performed well. The first problem was one I had practiced, and while the removeMedian part of the second problem had some bumps, I eventually provided a workable solution. The interviewer's feedback was also positive, and we even chatted briefly about his project at the end.

Round 5: Googleyness & Leadership (~45 minutes)

Google's behavioral interview is different from other companies. They call it "Googleyness & Leadership," focusing on whether you align with Google's cultural values. My interviewer was a People Partner (HRBP) with a technical background.

Question 1: Tell me about a time you had a disagreement with a colleague. How did you resolve it?

I described a disagreement with a frontend colleague about API design format. I advocated for RESTful, while he preferred GraphQL. Instead of dismissing his approach, I organized a technical discussion where each of us prepared a 5-minute presentation comparing both approaches with real data for our specific use case. We ultimately chose RESTful but incorporated his suggestion for flexible querying by adding field filter parameters to some endpoints.

The interviewer followed up: "What if the other person refuses to compromise?" I said I would escalate to the tech lead for a senior decision, but only after ensuring both perspectives were fully understood.

Question 2: Tell me about a mistake you made at work. How did you handle it?

I described a production incident — a service I owned started experiencing memory leaks after a release, leading to OOM restarts. I immediately rolled back the version, then spent two days investigating the root cause. It turned out a cache I had introduced had no expiration set. After the fix, I did three things: added memory usage checks to our code review process, pushed the team to integrate memory profiling into CI, and wrote a post-mortem document shared with other teams.

The interviewer followed up: "Why do you think code review didn't catch this?" I honestly explained that the cache was initialized in a utility class, which was outside the scope of the business code review — a process gap.

Question 3: Tell me about a time you took on work beyond your job responsibilities

I described building an on-call scheduling system that nobody on the team wanted to own. The old system was a manual Excel spreadsheet that frequently had errors. I volunteered to build an automated scheduling tool in two weeks, considering each person's timezone, preferences, and rotation fairness. After launch, scheduling errors dropped to zero and team satisfaction improved significantly.

The interviewer asked: "Did anyone else maintain this tool afterward?" I said I wrote detailed documentation and unit tests, and later handed it off to a new hire who added several new features after taking over.

Question 4: How do you help underperforming team members?

I described a mentoring experience with a new graduate. He had solid coding skills but weaker design abilities. I did weekly 1-on-1 code reviews with him — instead of simply pointing out problems, I guided him to discover issues himself. For example, I'd ask "Do you think this code would be easy to modify if requirements changed?" rather than saying "You should use the Strategy pattern." After six months, he independently designed a module and did an excellent job.

Question 5: Why Google?

I tied this to my career aspirations and passion for Google's products. I highlighted three points: Google's technical depth and scale — many problems only exist at Google's magnitude; Google's commitment to engineering culture — 20% time, internal tech talks, etc.; and Google's investment in AI — I want to work on products that impact billions of people.

My impression: The behavioral round was easier than I expected, probably because I had prepared 8 STAR stories covering common themes like conflict resolution, mistakes, initiative, and helping others. The interviewer's follow-up questions felt natural, not adversarial. The key is to tell real stories — don't fabricate, because follow-up questions will expose you.

Interview Questions Summary

Round 1: Coding

1. Course Schedule Validity Check (Topological Sort Variant + Bipartite Graph Coloring) | Topics: Graph Theory, Topological Sort, Bipartite Graph | Difficulty: Hard

2. Interval Merge Count + Large-Scale Data Optimization | Topics: Sorting, Greedy, External Sort | Difficulty: Medium → Hard (follow-up)

Round 2: Coding

3. Decode String (Stack) | Topics: Stack, String Processing | Difficulty: Medium

4. Minimum Flight Transfers with Budget Constraint (BFS + Pruning) | Topics: BFS, State Design, Multi-dimensional Optimization | Difficulty: Hard

Round 3: System Design

5. Design Google Drive | Topics: Distributed Storage, Chunked Upload, ACL Permissions, Real-time Collaboration | Difficulty: Hard

Round 4: Coding

6. Binary Tree Maximum Path Sum (Recursion + Global Variable) | Topics: Tree DP, Recursion | Difficulty: Hard

7. Dynamic Median Data Structure (Two Heaps + Deletion) | Topics: Heap, Data Structure Design | Difficulty: Hard

Round 5: Googleyness & Leadership

8. Conflict Resolution | 9. Handling Mistakes | 10. Beyond-Job-Responsibility Initiative | 11. Helping Underperformers | 12. Why Google

Key Takeaways and Advice

1. Practice algorithms until they become muscle memory. Google's coding interviews are fast-paced — 2 problems in 45 minutes leaves almost no time for extended thinking. Topological sort, BFS, two heaps — these must be second nature. My BFS variant in Round 2 wasted time because I wasn't fluent enough with state design. Don't just chase problem counts; do 3-5 problems per pattern type to ensure genuine understanding.

2. Go deep on system design — don't stop at the framework level. My lesson from Round 3 was only discussing real-time collaboration conceptually without diving into OT/CRDT implementation details. Google interviewers will push you until you can't go further, so every design decision needs a clear "why" and "how." I recommend deep-diving into each commonly asked Google system design problem (Google Drive, YouTube, Search, etc.).

3. Prepare real stories for behavioral interviews — don't memorize templates. Googleyness interviewers excel at follow-up questions. If your stories are fabricated or over-packaged, two or three layers of follow-up will expose you. My advice: prepare 6-8 genuine STAR stories covering different themes, and think through potential follow-up directions for each.

4. Communication and composure matter more than perfect solutions. My BFS variant in Round 2 wasn't optimal, but I maintained good communication with the interviewer — thinking out loud and showing my thought process. In Round 3, even though my real-time collaboration answer was weak, I honestly said "I'm not deep enough on OT implementation details" and then gave the best answer I could. I still got the offer, which shows Google values your thinking approach and communication skills more than perfect answers to every question.

Finally, on May 28th, I received a call from the recruiter saying HC (Hiring Committee) had approved, and the compensation package was pending approval. I got the official offer in early June — L4 level, with total compensation about 40% higher than my current package. The hardest part of the whole process was the week waiting for HC results, but in the end, it was all worth it. Best of luck to everyone aiming for their dream offer!

FAQ

Q1: How many rounds are in a Google L4 interview?
Typically, the onsite consists of 4-5 rounds: 3-4 coding/algorithm rounds, 1 system design round, and 1 Googleyness behavioral round. The exact arrangement may vary by position and team. In my case, it was 4 technical rounds + 1 behavioral round, totaling 5 rounds.

Q2: Can I use Python in Google interviews?
Yes. Google supports multiple programming languages including Python, Java, C++, Go, and JavaScript. I chose Python for coding problems because it's faster to write and saves time. However, be aware of Python-specific pitfalls like recursion depth limits and the GIL — interviewers may ask about these.

Q3: What's the difficulty level of Google's algorithm questions?
Using LeetCode as a reference, most questions fall between Medium and Hard. Google rarely gives pure Hard problems, but they often add variants or follow-ups to Medium problems that push the difficulty to Hard. I recommend focusing on LeetCode Medium, with emphasis on graph theory, DP, binary search, and heaps — the most frequently tested categories.

Q4: Do I need to draw diagrams in system design interviews?
Yes. Google's virtual onsite typically uses Google Docs or Codelab, where you can draw simple architecture diagrams. I recommend familiarizing yourself with these tools beforehand. Diagrams help the interviewer understand your design faster and demonstrate your communication skills.

Q5: What does the Googleyness interview actually test?
Googleyness primarily evaluates four dimensions: Respect (respecting others), Judgment (sound decision-making), Inclusion (embracing diverse perspectives), and Leadership (driving outcomes proactively). Specifically, it assesses whether you can collaborate effectively in a team, make good decisions under ambiguity, respect different viewpoints, and take initiative to move things forward. Organize your STAR stories around these four dimensions when preparing.