My Google Recruitment Journey (Part 1): Brute-Forcing My Algorithmic Ignorance

Introduction

About 2 months ago, an email from xwf.google.com dropped into my inbox, referencing an application from a year prior that I even forgot about. My initial classification was that it is not possible and that this is just spam. But after the screening call, the reality hit: I will have two online interviews (one technical, one behavioral) in just a week. And not just a regular interview to another company, these will be interviews for a company that I still consider as one of the top-of-the-world factory of engineers.

This was a critical state. I’ve worked as a software developer in telecommunications for a few years, focusing on high-level abstraction: routing, message processing, and writing business logic. In my hobbyist gamedev projects, even though sometimes I liked to make some pathfinding algorithm or to do a CPU 3D rasterizer by hand, at the end of the day my metric for success was simple: if it runs at >60 FPS without drops, it ships.

My data structures were pragmatic: flat vectors, statically sized arrays, sometimes simple maps, and for hard problems "SQLite". And all of my attempt at writing fancy algorithms or data structure was a cool learning journey, that unfortunately did not have a direct impact on my job skills, and there were always better ways to spend this time if I wanted to optimize for a telecommunications career as well as for a gamedev career.

Classical algorithms and strict LeetCode-style data structures were always outside my area of interest. My earliest attempts at learning them had failed completely. Even in my earliest memories on all primary school programming contests, I always failed at them.

I had one week, a day job, other regular obligations and a fundamental knowledge gap.

Day 0: Making the plan and procrastination dressed as learning.

After some initial thinking (I mean procrastination on YouTube and online forums for at least a few hours for few days), I realized that the most successful strategy would be to learn as many patterns as possible - to at least be able to identify the core problems. I was aware that I had a very small chance of resolving it in the most optimal way during the interview, so I wanted to at least understand what was expected from me to do (for my brain that is trained on writing software and resolving useful problems, mathematical description is not clear in a lot of places, and for me, it hides the clue, especially behind artificially created, non-real problems).

• I knew that if I start reading an algorithm book, I would fail because I didn't have time to deal with concepts obscured by pure math.
• I knew that if I start reading online articles or watching YouTube explanation videos, it would just be a form of procrastination.
• I knew that if I just start doing LeetCode problems (like in my previous attempts), I would burn a lot of time and energy without much outcome.

The main problem at this point: I was unable to solve even the simplest LeetCode problem. But this time, I knew the goal was not just to solve the problem (like during a game jam), but to learn as many patterns and concepts as possible even blindly without fully understanding all quirks for now.

Day 1: Initial setup and warm-up

I started actual learning on friday. Based on previous thought I decided to give a Large Language Model a chance to be my algorithmic teacher, since I never had a human one before. I fed Gemini Pro chat with my exact situation (with my CV and preparation material provided by google in mail that i received) and set the following parameters for our session:

**Protocol:**Iteratively explore and teach me new algorithmic concepts. Act like human private teacher that are fully commited in teaching me new concepts that I am not aware of.**Constraint:Do not output any codeObjective:**Provide only conceptual hints and attack vectors for LeetCode problems, provide real-world examples to problems, and if it is easier to describe a problem using some metaphor - just do it.

These attempts resulted in successfully completing this set of problems suggested by LLM: Best Time to Buy and Sell Stock, Contains Duplicate, Valid Anagram, Group Anagrams, Product of Array Except Self.

With hints, it occurred to me that these problems were simple usages of for-loops and arrays - but this gave me something that I never had before, courage that I am able to do even the simplest algorithm tasks. And I think that these are a very solid starting point because they bridged the gap between algorithms and problems that I had to do in "real" software, without being overwhelming. Moreover they showed me, not fully clearly for now but as a small hint, that sometimes a data structure like "unordered_set" in these examples can be used in a not direct way to solve a problem in a clever way by using its not obvious properties. This also provided me some insights that a simple indexed lookup table like in Valid Anagram maybe from this perspective is equal in some property to an unordered_set in such a way that I never thought before.

Also, I think that equally important is the fact that I started to show my full code solution to LLM, and ask for a better approach, and the pros and cons of each possible implementation.

Day 2: As much concept as possible

This was Saturday. Assuming this might be my last deep-learning session, I changed the protocol to maximize throughput.

I started a new chat where I instructed the LLM:

• First, the LLM will select the next concept; the goal is to learn as many common interview patterns as possible.
• After a strict 10-15 minute timebox, I will show my attempt. If I couldn't formulate an attack vector or crack the pattern, I will blindly accept the LLM's conceptual solution, asking for it in a second prompt while providing all my code attempts so far.
• The goal of the AI is to restructure my solution into an optimal and valid one.
• After I rewrote the LLM's solution, the LLM's role was to judge it and provide an alternative solution with code.
• Then there was space for discussion and clarification.
• And at the end, I rewrite the best possible solution to this problem in "my style".

The hard rule for me was to never blindly rewrite AI code: I had to write the code myself, using my own variable taxonomy and logic flow. I believe that forcing the solution into "my style" mapped the concepts deeper into my muscle memory, and (possibly I use this terms wrong) I believe that by doing this, I refactored my idiolect without forcing it to drop old behaviours. Later, I learned that forcing "my flow" actually made me write code patterns that were not always valid, whereas keeping a strict order (like in BFS) is very useful and frees up a lot of thinking space for thinking about the problem (like checking "business" conditions before adding to the queue). But now, looking at this from a wider perspective, I believe that this was a necessary part of the process.

I gave myself a maximum of 30 minutes for each problem: Reverse Linked List, Linked List Cycle, Valid Palindrome, Invert Binary Tree, Longest Substring Without Repeating Characters, Valid Parentheses, Maximum Depth of Binary Tree, Merge Two Sorted Lists, Same Tree, Number of Islands, Find if Path Exists in Graph, Flood Fill, Reverse Integer, Single Number, Climbing Stairs

In doing these problems, I learned that:

• Lists seem logical for more cases, and it is possible to just deduce a solution that is not the best, but not brute force, in most cases.
• I realized that tree problems are, under the hood, very similar to previous problems that I wrote earlier. Most of the traversal is a combination of BFS and DFS that I had done earlier in inter component logic and GUI DOM traversal.