{kode.play();}

I’ve always wanted to discuss algorithm problems here but a quick look over at my posts (even just the tags) reveals that I haven’t really done much of that. Over at Github, I have a repository dedicated to solving Programming Praxis problems¹ and I’ve thought of discussing my answers here but I haven’t had the time. My interview with Google is, I think, a good chance to dish out something similar to my intentions.

(Author’s note: Of course, I won’t discuss the specific problems I encountered during my interview. For reasons that will become clear if you think about it for a moment, Google clearly prohibits that.)

There are three stages I encountered during Google’s interview process. The first is a short initial (phone) chat with a recruiting coordinator. Next I had a phone technical interview which, aside from taking a longer amount of time, had me coding on a Google Doc. The third part is where they flew me to Mountain View, an interview which Google terms as “panel interview” but I will forever stubbornly refer to as a “circuit interview”.

My interviews, in general, looked at my problem solving skills. For a company like Google, I expected that they will be more interested in my engineering competence, i.e., questions like “How do you get things done?”, “What frameworks have you used?”, “Why would assembly trump everything?”, “Concurrency, Cloud Computing, Parallelization, Multi-core issues, Efficient Caching Mechanism, High-Throughput Responsive MVC Framework Layer MOAAARRRRR!!!”² .

Watch this short video featuring Laszlo Block on the type of people Google is after. It may be hard to believe, as it was for me, but based on my experience, this is so true.

Overall, I’d say that my Google interview was 85% algorithms/problem solving and 15% engineering.

I found the second phone interview a bit bumpy that afterwards I did not really expect much. I was just happy that I got a Googler asking me technical questions. My interviewer’s voice wasn’t very clear through the phone (as opposed to the first one). It did not help that I was having coughs that day which later developed into a slight fever.

And, as you may know, Google Docs isn’t really made for coding. I wish Google used a platform more suitable for writing code than a word-processing document. My interviewer wasn’t meticulous about syntax but it was still awkward indenting my lines.

That said, here are some tips:

1. For this part, do not use Python (or any similar whitespace-based language). I was intending to use Python even though I’ve already expected indentation to be difficult. Thankfully, my interviewer stated at the beginning that he’d prefer me to use Java. With Java, you can skip indentation for small blocks of code. Convenient when your line is getting long or the nesting goes deep³.
2. Indent using two spaces. This is the indentation style of my first company. Tab is too wide and your lines might easily bleed off the edge, especially if you follow my first tip (new BufferedReader is already 18 characters!).

   Why indent at all? Well, no one’s forcing you but I find it easier to debug if I have indentations. Moreover, code is easier to read.

3. Don’t hesitate to use the Google Doc for things other than code (like clarifications). Remember I said that my interviewer’s voice through the phone wasn’t very clear? Well, this is exactly what saved me.

As for the onsite, Google will be kind enough to fly its candidates in two days before the actual interview so you can settle down. Due to PyCon Philippines, I was unable to take full advantage of this. Nonetheless, I felt little to no jetlag that I even had time to explore a bit on my first night.

Here’s a little tip though: when coordinating with Google’s recruitment team, be clear and patient when it comes to your travel requirements. Based on my experience, Google’s recruitment team is very accommodating and helpful but that is not to say that they are 100% knowledgeable on the arrangements their applicants have to make for travel. (Cut them some slack as I’m sure they handle applicants from more countries than what you can name off the top of your head.)

In my case, I raised the point of needing a Visa for USA travel early on but it was ignored in the email thread so I assumed it’s okay. Thankfully, the issue came up when I coordinated with their preferred travel agency. This delayed me by almost a month. I should’ve been persistent because I’ve been raised since childhood knowing that Filipinos entering the USA need a USA Visa.

Google would really want you to focus on your interview so there is very little that you need to mind during your stay. They’d have your basics covered (accommodation, reimbursable food allowance, reimbursable transportation allowance) so just keep your receipts.

Here’s the interesting part. The onsite interview itself will last for five hours, lunch included (for comparison, the longest job interview I’ve had lasted for, I think, three hours, and it was more a personality interview; HR was talking to me). The reason why I will forever term it as “circuit interview” is because you will have five sets of interviewers, each of them in turn, as opposed to having all your interviewers in one panel.

As I’ve said, my interview was more algorithmic than engineering. One of my biggest anxieties was if they’d give questions the kind they give at ACM ICPC. I’m pretty sure I’d be tongue-tied had that happened. But fear not. The problems I encountered were less obscure and they won’t require you to provide full implementations for the more complicated ones.

Well, I did not make it so you may want to take the following with some grains of salt. But, hey, some tips:

1. Use Python, finally. Or, bring your own whiteboard markers, as Steve Yegge advises. I’ve read Steve Yegge’s post prior to my interview but I missed the point on his tip about the whiteboard markers. I thought he was advising it just for the “preparedness” factor but notice that he advises it for the sake of whiteboard space. And yes, whiteboard space can be a real blessing. I want to note that, when I was there, Google’s Mountain View office had those flat-tip markers in stock, the kind like highlighters. In my opinion, that’s worse for an interview than the “fat ones” Yegge refers to in his post.

   Nonetheless, with Python, I was able to squeeze in three functions plus lots of scratch and some illustrations in a whiteboard of standard office size. I cannot imagine how that’d look like with Java (or worse, C/C++), nor can I overstate how good a thing is this.

   For the record, I brought my own whiteboard marker but I did not use it, did not even show or mention it, because I got anxious as to coming across as “too eager”.

2. Use Python, again. This might vary from programmer to programmer but Python gave the advantage that I can focus on high level stuff. Given the nature of Google’s interview process, I believe this worked to my advantage. It’s really like doing runnable pseudocode.
3. Use Python, not. I think I know where the weak points of my interview was and I believe I was weakest during the last interview. You see, the interviewer started with “I heard you use Python so just keep using that.” So I did. But then he gave me a problem that would require some low-level manipulation and, as I was using Python, I took time clarifying what am I allowed to do and what am I allowed to assume.
4. Just keep talking. Remember my anxiety above that I might get tongue-tied? Well, here’s the tip: just keep talking, as long as you’re making relative sense. I’ve been told in a pre-interview email that they want to learn how I think so think out loud. Obviously, I’m not sure if this worked to my advantage or what but at least I managed to avoid that Great Wall of Social Awkwardness Produced by Silence. It might even help you; there was a part in my interview when I was like “Let me try some combinatorics here…so 2 will give this…3 will give that…but 4, oh wait—this is easier to to solve programmatically!”. No kidding.
5. Relax, this isn’t the ACM ICPC. This comparison might deserve a post on its own but for now, the most obvious difference is the time constraint. I realized that the people interviewing me would like to get a picture of me in just around 45 minutes. So, in contrast to the ACM, they’d give you problems that are solvable in 45 minutes or less. Moreover, your code won’t be ran so (at least I think, and this I did), you are allowed a certain extent of handwaving and just say this function does this and that. At times, high-level descriptions of algorithms will also suffice (read: implementation, with all the debugging that might entail, is not needed).

Finally and most importantly, Prepare with a capital ‘P’. Read the Steve Yegge blog post I linked above and follow his advice on having long-term and short-term preparations. I just said above that Google interview isn’t ACM ICPC but I think ACM ICPC is good standard practice material and not just for Google interviews.

What do you prepare for? In my case, knowledge of data structures like some obscure variants of balanced binary trees and even-rarer forms of trees and forests helped as it gave me some talking points. A good knowledge of textbook algorithms will also help. In one case, repurposing a textbook algorithm allowed me to reduce a naive O(n²) algorithm to just O(n).

That said, even if you’re not planning to take a Google interview anywhere in the foreseeable future, I still find preparations of this kind useful for everyday. So just keep reading up and honing your problem solving knack!

1. I have a similar private repository for the other algorithm problems I’m solving—ACM ICPC practice, to be specific. As a matter of principle, I’m willing to show my code solution to algorithm problems provided that the problem setters are expressly showing solutions, as with Programming Praxis. [↩]
2. Okay I’m trying to be funny here. But you get my idea of engineering vs. algorithmic skill. [↩]
3. Generally, I’d be cautious against getting too deep a nesting. When I encounter this in my code, it’s a sure sign that I’m getting lost and that maybe I need to refactor or re-read the problem [↩]