This blog has moved to Medium

Subscribe via email


Posts tagged ‘Interviews’

Interviewing? Keep it simple, stupid!

If any of you are intereview for a job any time soon, please take this advice to heart – just like KISS is a good principle in your every day job, it’s a great principle in a job interview.

Some people like to boast their skills when interviewing.

“I’m a Java Guru”

“I’m excellent at Big Data analysis on a NoSQL system in the cloud”

“I like well designed code … here are my favorite design patterns, I use them all the time”

Some of the above statements could apply to you … but be sure to be relevant to the job you’re interviewing for, and the tests you’re given. If you are asked to do a simple hands on coding session, know that your interviewer just want to see you code, he doesn’t need to you implement Map Reduce or show off your Uber Design Pattern skills.

Sure, it’s nice to sprinkle in good design, unit tests, and write scalable code … but before you do all those things, make sure you get the job done, on time, without bugs. Do the important stuff first, and show off later, if you have the time.

How I got hired by Google (this time)

(Yada yada, this post doesn’t represents any opinions except my own, and barely even that :))

For the sake of friends, family, and other readers who might be interested, I wanted to document the process I’ve gone through with Google. I find it a bit similar to the process Steve Yegg went through when he got hired by Google, because both of us were turned down by Google the first time we interviewed there. I hope this might help you if you ever decide you want to try to become a Googler yourself (here is why I chose it, but you should find your own reasons).

My history with the job market is rather short – before interviewing at Google for the first time, I have been “employed” by the Israeli Defense Force for six years, in the course of normal army service. I was doing professional and interesting work, but I wasn’t exactly free to choose (Israeli mandates a three years compulsory army service for guys, and I signed for three extra years at the age of eighteen as part of the Atuda program). While in the army, I started my Master degree in CS, and when I finished it (half a year after being released from the army), I finally had to make my first employment choice in the “real world”.

I didn’t know the first thing about what I wanted. Throughout my army service, I had the concept that I really wanted to do “research work” (not that I knew what this means, it just sounded cool). I also remembered that I really enjoyed studying algorithms and data structures back in my B. Sc days, so I considered working as an algorithm developer (I had assumed the job has some correlation to the problems I faced in Algorithms and Data Structures courses – which is not necessarily true). Also, I was really drawn to the startup world, having tried unsuccessfully to create one myself. And, of course, Google was on my list of possible employers, because, well, it’s Google.

I approached interviewing at Google like I would any other company. I ignored the emails they sent me on “how to prepare for the interviews”, and hardly did any any research about the Google interview process. Also, since I thought it’s such a good company, I interviewed there immediately – actually, it was among the very first companies that I interviewed for. Unfortunately (or fortunately), I completely sucked at the interviews (or at least this was my subjective feeling at the time). The interview problem I most distinctly remember is being asked to sort an array of integers. “Trivial”, I said, and blurted either “Quicksort” or “Mergesort”.

“OK”, said my interviewer, “that’s a good answer. Now please implement it on this sheet of paper.”

“What?!”, I staggered. Still, I didn’t completely freeze, and wrote down some implementation or another. I did understand the concepts of both sort algorithms well enough to explain them, but when I tried to put it down on paper, I made some annoying +1/-1 indexing error, which I was unable to track down in the course and pressure of the interview. This, and other errors like this one, was one of the factors that made Google decide I was not ready to work for them yet. “Please interview again in another six months” was the reply I got.

Of course, in another six months I was happily employed at what became my job for the next three years, so the thought of interviewing again didn’t cross my mind until now. Recently, when I decided that it’s time for me to switch jobs, I took a second, more mature look at Google. I thought long and hard about what my motivation for leaving Delver, and found that it’s a desire to learn and grow. I then concluded that Google was the best place for me to do this (not an easy decision, but a decision that had to be made nonetheless). Once these thoughts crystallized in my head, I decided that this time, I’m going to be hired. I knew internally that I’m good enough, and I could make it with the right combination of preparations and luck.

The first thing I did was grill a couple of friends that were hired by Google in the last year. They didn’t reveal anything secret about the interviewing process, of course, but talking to them did send me in the right directions – “go study data structures and algorithms!” was the clear message. I first implement Bubble Sort as a warmup exercises, and managed to include a horrible yet hard to detect bug that made me take things a bit more carefully from then on. I revisited Introduction to CS, Data Structures, and Algorithms course material, and actually solved exams by coding the solutions. I didn’t anticipate how difficult this would be – not the actual problems, but the act of mentally forcing myself to fill in all the gritty details and code algorithms that actually work (and prove it via test cases). “Google is looking for smart engineers who know how to solve algorithmic problems, and code the solutions”, I was told, and so I made sure I am one of these engineers. One of the most difficult things I had to do was mentally push myself to do things throughly and not take shortcuts.

I scurried the web, reading tales of other qualified engineers that went through the interview process. I solved several Google Code Jam problems. I thought about how I would build large, Google scale services such as Search, Gmail and Maps, and wasn’t ashamed to ask questions when I didn’t know the answers. When I was almost ready for a Google interview, I started interviewing at other companies. You can’t believe how bad at interviews we (I) get when we don’t practice it for a few years – interviewing with other companies was a good way to get a feel of the market, validate to myself my choice of Google, and get better at interviewing and solving technical problems. Finally, I submitted my resume via a friend that works at Google (a good recommendation from a Googler tends to help your chances … it certainly can’t hurt). All this time, I kept repeating the basics – I reread the material for Data Structures and Algorithms courses quite a few times until it all sunk in, and I must have implemented Quicksort and Mergesort a few dozens of time until I was sure I could do it flawlessly and under pressure.

A Google interview process is usually composed of a basic “screening” interview, followed by a series of more difficult interviews. I was actually told by my Google recruiter that because my results last time I interviewed, I could skip the screening interview and proceed directly to the more difficult ones. I chose not to, and took the screening interview as a warm-up exercise (I was surprised and encouraged to find that it was really easy for me, and this encouragement helped with the other more difficult interviews). Google usually schedules all your advanced interviews (5-6 of them!) into one long day. One important tip is that you can ask your recruiter to split these interviews into two different days – I found it much easier this way)

Finally, after several challenging interviews and nervous days waiting for Google’s response, I got the “ok, you’re hired”. The process I’ve gone through was, I believe, the right process for me. I might have been slightly over-prepared for some (not all!) of my Google interviews (and I was never actually asked to implement Quicksort or Mergesort), but it’s better to be 400% over prepared and succeed than be 10% under prepared and fail. I understand that not everyone can dedicate as much time for the preparation process as I have – it was relatively easy for me because I announced that I’m quitting before finding another job, and so didn’t have to hide the fact I’m interviewing and studying – this can be very stressful, thinking about your new job while nobody at your current gig knows you’re quitting.

If you want to apply to Google, you should decide what process works for you, and how much you really want it. And study up on your Mergesort/Quicksort – learning to implement them flawlessly is not an exercise in memorization, but rather an exercises in solid algorithm building using pre/post-conditions and an excellent “mental muscle warmer”. I took Steve’s advice of doing “short-term warm-ups” to heart.

I hope this has been a useful post for you, and I encourage you the look up the other available sources. Here are some links to get you started:

Good luck in your interviews!