Google Software Engineer Interview Experience — Four Technical Rounds, From a Mumbled Zigzag Traversal to a Log-Eviction Design

Round 1: Technical Interview

The interviewer was a guy with a really heavy accent, spoke fast, and I had a hard time understanding him. For the whole round I was basically guessing what he was asking. This round was a binary tree traversal question (a LeetCode original or a close variant). The core ask: given the root of a binary tree, implement a zigzag (sawtooth) level-order traversal. This is literally LeetCode 103, Binary Tree Zigzag Level Order Traversal. When the interviewer asked for my approach, my first reaction was inorder traversal. The moment I realized inorder was wrong, I switched to saying postorder instead. The interviewer gave a wry smile and said that the inorder idea could barely count as a starting point if I processed it level by level, but the more direct standard solution is BFS with a queue. Only after he hinted at the keywords BFS/queue did I finally get back on track. I stumbled through writing the code (adding in the direction-switching logic), but I wasted too much time, and it definitely wasn't my best performance.

Round 2: Phone Screen

The interviewer gave me a course-dependency validation problem: design a function to check whether an e-learning platform's course catalog is valid. My approach was to use a two-dimensional detection algorithm to catch missing courses. Then I did cycle detection (topological sort) by building a graph and an in-degree dictionary. I built the graph edges in the direction of dependent-course → depending-course. Then I just wired it all together for the final validation.

Round 3: Coding

The question was an array/string processing problem, a sliding window variant. Given a string s and an integer k, find the length of the longest substring containing at most k distinct characters. This is a great fit for sliding window plus a hashmap. The goal is to maintain a window [left, right], make sure the number of distinct characters in the window never exceeds k, and find the maximum window length under that constraint. The interviewer listened carefully the whole time, agreed when I mentioned "sliding window" and "hashmap," and nodded along at the key steps (the shrink condition, when to update maxLen). He said, "Good, you are on the right track."

Round 4: Phone Screen

The question was about deleting logs. The interviewer wanted me to design a log management class with these core requirements:

1. The total number of logs across all files can't exceed total_max
2. Adding a new log has to automatically clean up old data
3. Decide which log is the "least important" to delete

The first thing I did was control capacity: per-file logs ≤ X, global logs ≤ max_length (a dual-threshold trigger for cleanup). Making the deletion decision efficient mattered too — how do you locate the log to delete in O(1) time? First I nailed down the key boundaries, differentiated log priority, and introduced a weight factor. Then I designed a two-dimensional data structure: a time-ordered deque for file-level storage. The deletion policy followed the same idea — when a single file goes over its limit, evict straight from the front of its queue; when the global count goes over, do a heap-top deletion with cascading updates.