The 5.4e+03 Second Litmus Test

This is a blog post from my late friend and mentor Frank Madrid. Posted February 24, 2018.

To a computer science student with no industry experience, few things are as unnerving as a technical phone interview. An interviewer must determine if the interviewee is slightly more proficient than a monkey using vim and implicitly assign a value to 4+ years of theoretical education and technical experience in under 5400 seconds.

Two days ago, I underwent such a litmus test with two Google interviewers and barring the heavy accent of my interviewers and the poor cellular connection, the interview process was a positive experience.

The Google Technical Internship Interview

A quick Google search immediately reveals the mystery and confusion surrounding the technical interview process. Forums are riddled with variants on the question, “What questions are asked during the Google Technical Interview?”

I assume the daunting and all-encompassing list of candidate topics indicated by Google in their 8-page Google Slide presentation is what solicits such a response.

In summary, these topics include:

• Algorithms
• Data Strucutres
• Operating Systems
• Mathematics

Though a list of four topics may seem far from all-encompassing, any second-year computer science student with 10 fingers (yes, a binary joke) can count how many classes do not use some subset of these topics. The possibly sole class meeting this requirement includes Introduction to Programming where the concept of an algorithm is barely introduced amidst the hurried foray to understand proper C++ or Java language syntax.

Preparing for the Technical Interview

Two weeks were spent reviewing and practicing these concepts in preparation for the technical interview. I attempted to find sources which offered a breadth of knowledge but didn’t require tremendous effort to understand any particular topic, and a slew of problems to reinforce the concepts learned during the review.

Reference Material

The first, and highly recommended text is The Algorithm Design Manual. This text offers an introduction to the most important data structures and sorting algorithms without being weighed down by heavy symbolic notation. It also offers a catalog of algorithmic problems which is useful for solving challenging coding questions. It also offers amazing interview questions but lacks a corresponding solution manual. This text is is available from Amazon for about $40.

The second, and widely popular text, Cracking the Coding Interview, boasts good insights into the interview process and includes detailed solutions to many important (but publicly available) problems. This one is available from Amazon for about $30.

Practice Problems

Cracking the Coding Interview included many problems targeted at a specific topic but most of my beneficial practice was found on websites dedicated to hosting a plethora of programming questions such as LeetCode. These problems did not necessarily indicate the appropriate data structure or algorithm to solve the problem and were sufficiently vague enough to be thought provoking yet not misleading. Solutions to some of the more interesting problems may be featured in future posts but many, if not all, of my solutions can be found on Github in my public repository.

The Interview

After the usual introductions and pleasantries, I was excited to finally begin the technical interview and witness what exciting problems the Google software engineers would be challenging me with. The questions were of average difficulty, completable within 30 minutes, and didn’t require a brilliant or archaic solution. The three solutions required string manipulation, the use of basic repetition structures and binary arithmetic operators, recursion, dynamic programming, and Big-O analysis.

I was not explicitly asked to withhold any information regarding the interview, but the specific content of the interview was indicated to be confidential.

As is commonly stated in their publicly available presentations: the interviewer is more so interested in interviewee’s ability to analyze and solve a problem than their ability to code. A fundamental understanding of the chosen programming language is of course required, but my interviewers allowed the use of loose pseudocode to explain ideas which would have required multiple lines of instructions. After each implementation, the interviewers indicated particular instructions which would have resulted in errors and allowed me the opportunity to identify and correct the error before moving on.

Final Thoughts

Being my first internship technical interview, I allocated a large percentage of my free (and not so free) time to the review of concepts which had the potential to be discussed during the interview. In actuality, hardly any topics I specifically reviewed were discussed. All questions would have been answerable without the review but not with the level of detail I was able to provide. In hindsight, the amount of preparation, though appropriate for a full-time position, was overkill for an internship.

Within two weeks, I will hopefully hear about candidate projects which are viable with my skillset. If not, then I will have to consider other internship opportunities.