Interviews During Covid (3)

Image generated by Copilot

TLDR

• Google’s interview process includes four rounds of technical interviews and one behavioral interview.
• Prepared for a month by solving ten LeetCode problems every day.
• Following the interview, I entered the team selection stage and ultimately chose YouTube integration testing.

During Google’s onsite interview process, there are five interviews. For candidates at my level, there are four technical interviews and one behavioral interview. The behavioral interview presents scenarios commonly experienced at work and asks how you would handle them. For instance, if a colleague asks for your help with a project but you also have your own work, how would you politely decline? For senior engineers, there is an additional system design interview where you might be asked to design a website similar to YouTube.

In my preparation, I dedicated thirty days to practicing approximately ten problems each day. If I get stuck on a problem, I’d pretend I was in a real interview and try to find a solution within a short timeframe. If I couldn’t, I’d spend five to ten minutes quietly thinking about solutions. You don't want to waste more than 10 minutes; I’d look at the answer, then reflect on why I didn’t think of that approach initially.

There are several possibilities for getting stuck. First, perhaps I hadn’t practiced enough problems of that type, so I’d seek out similar type of questions. Second, maybe I was overthinking it, and a straightforward approach would suffice. In such cases, I’d remind myself to start with simpler ideas and iterate from there. Third, sometimes I misread the problem; for example, not noticing input constraints or failing to ask clarifying questions. Lastly, there are moments when inspiration doesn’t strike immediately. In those cases, I’d consider how to trigger that “aha!” moment through observation.

The most common one I call “complementary observations.” If the problem asks for set A, but set B is easier to compute and complements set A, I’d calculate set B first and then derive the answer for set A. For instance, when finding the ocean area in a map, it might be easier to compute the land area and subtract it from the total area. Another technique is what I call “invisible constraints.” These are limitations not explicitly stated in the problem. For example, if we’re dealing with three letters of the alphabet, there are only 26^3 permutations, which is less than 20,000. Many people see three loops and assume O(N^3) complexity and avoid it.

Around 10 questions every day in November

During the interview, based on online resources and my own experience, there are some key points to maximize your chances of scoring well:

1. Start by asking questions

Clarify what the problem is asking, request examples from the interviewer (including input variable ranges and any unusual cases), and verify your understanding. Avoid diving straight into solving the problem. Good interviewers will let you know if you’ve misunderstood the question, while less helpful ones might watch you struggle before gently pointing out the error.

2. Thinking Aloud

It’s essential to verbalize your thought process when solving problems. If you keep everything in your head, the interviewer cannot determine whether you’re actively thinking or not. Without verbalizing, there’s no basis for evaluation, and you end up receiving a lower score. Sharing your ideas out loud also allows the interviewer to provide appropriate hints. Initially, I often share the most obvious solution, even if it’s inefficient. It doesn’t take more than 30 seconds to talk about the easy solution and get some basic points. However, be cautious: after sharing the straightforward solution and before the interviewer has time to critisize it, quickly add, “I believe there’s a better, more efficient approach”, revealing that your initial solution was just a setup—the real solution is yet to come.

3. Think about Complexity

If you’re unsure of the optimal solution, avoid making random statements. Instead, provide logical reasoning. My approach is to start with the algorithm’s complexity. If the worst-case solution is O(N^2), try exploring O(NlogN). Typically, this involves nested loops with binary search or using a heap. For instance, you might say, “I see an unknown variable here. Let’s try binary search to find it.” If this approach is correct, the interviewer will likely guide you excitedly. Less helpful interviewers might remain silent, but when you decide to abandon the correct algorithm, they’ll usually ask, “Are you sure? Maybe try again.”

Of course, most problems won’t have an O(NlogN) solution. In that case, think in terms of O(N). There are many O(N) algorithms that utilize basic data structures like hash maps, linked lists, trees, and queues. More advanced approaches involve tries, stacks, two pointers, and sliding windows. You can find examples of these problem types on LeetCode. If the problem is graph-related, such as shortest paths or costs between two points, common algorithms include depth-first search (DFS) and breadth-first search (BFS). Occasionally, you might encounter topological sorting. It’s also a graph problem, where sorting is based on relationships and depths. Union-find data structures are used in problems related to classification, like grouping people or categorizing colored balls. These less common types can be challenging if you haven’t practiced them before the interview.

4. Consider Dynamic Programming (DP)

If the previous algorithms don’t work or the problem doesn’t fit graph-related scenarios, you might face more challenging algorithms. Two types worry me the most. First, problems related to game theory, which aren’t common. These involve two players competing and determining who wins. These problems sometimes are like brain teasers and lean more toward mathematics than programming. Second, dynamic programming (DP) frequently appears in interviews. Although schools rarely teach it, and it’s rarely used in work, interviews love DP because most candidates fail to recognize DP questions. To identify a DP problem, check if it can be broken down. For example, if the problem asks, “How many permutations of a string with length of 20 ?” modify it to, “If we know the permutations for length-19 strings, how many permutations for length-20 strings?”. If you can deduce this, you can recursively build from known answers to find the answer for length-20. So, the key to solving DP problems is breaking down complex questions into smaller ones and working backward from the simple answers. Although it sounds easy, expressing it mathematically and writing code can be quite challenging.

I’ve experienced sleepless nights due to stress a few times in my life: before middle school exams, high school entrance exams, my first time as a teaching assistant for physics classes, and the night before the Google interview. On the interview day, out of the five questions, one was easy, two were moderate, and two were difficult. The challenging ones were DP problems. I managed to solve all of them because I knew DP was my weak point and I practiced many DP problems beforehand. The moderate questions included one graph problem with the usual approaches I mentioned earlier and another recursion problem, which is a very common type of question. After the interview, I felt relieved—I had likely made it.

The HR told me I have passed, and I entered the stage of choosing a team. Google HR sent me information about three teams currently hiring, along with their contact details. I interviewed with each team and then informed Google HR of my preferred choice. The team lead also had to decide whether to accept me. It felt a bit like matchmaking—when both sides are willing, you sign the contract. Finally, I chose the YouTube team responsible for integration testing, officially transitioning from hardware to software engineering.