A Google recruiter contacted me after finding my LinkedIn profile.
My initial phone conversation with the recruiter was followed by the first phone interview with a manager. Each manager I spoke with stressed that they were totally hands-on, just like other developers, and also carried managerial responsibilities. I'd say this was probably true based on the types of questions he asked. He mostly inquired about my current and past jobs, projects, accomplishments, approaches to design, teamwork, etc. – pretty much "traditional" relaxed, semi-technical interview questions. According to my recruiter's feedback, this interview went extremely well.
The next interview also went well, this time with the team lead for the group I was being considered for. There were a few design questions and one technology question: "What do you think of using technology X for solving problem Y?" Plus, there was one pretty simple algorithm I was asked to explain over the phone, although my recruiter had initially mentioned coding using Google's online collaborative tools. It was awkward to just "talk" through the algorithm instead of writing and talking as I normally do.
Finally, I had the on-site interview. They mentioned that only four people would interview me, and a fifth person would take me to lunch to answer any off-record questions. Bummer – I thought there would be more people, meaning more challenges but also more chances to show my skills. Four people seemed too few.
Personal interviews immediately became a problem.
First, no one seemed to care about my professional career and accomplishments. This took me off guard – is it because they think it's irrelevant to Google? In any event, it's their process, so after figuring out their style in the first half-hour, I tried to just accept it and move on.
The second problem turned out to be a killer: in most cases, I totally misinterpreted the intent and scope of their questions, and I'm still not quite sure if it was my fault.
One interviewer asked me to sketch the design of some distributed system. I enumerated all the typical issues – distribution, scalability, database synchronization, etc., and how to approach them. The interviewer kept asking more questions, but I thought he was not satisfied and had no clue why. Finally, after a good half-hour, he said he basically just wanted me to write the algorithm that would perform the core function of the entire system, which was computing some statistics on data collected in real-time by that very distributed system. All the challenges of distributed systems design turned out not to be what he was after! Why not scope the question clearly from the beginning?
I gave my best shot at the algorithm, which was trivial compared to the types of algorithms I do at work. By then, I was slightly peeved by what happened, so I got the right answer pretty slowly by my own standards. It almost appeared as if I spent the whole interview trying to write one trivial algorithm!
In that and some other questions, I should have basically ignored much of their content, focusing instead on identifying some core algorithm working on idealized data sets – while the way the questions were stated would make you think that the core was designing distributed systems collecting such data!
One week later, the recruiter told me they had passed on me due to insufficient algorithmic skills. With algorithms as simple as the ones asked, that was pretty ironic. I was told everyone liked me on all other accounts, and that the recruiter would contact me in six to eight months to try again.
I'm not sure if I want to pursue it, but I might.
Knowing what I know now (not specific questions, but the expectations behind them), I would have probably passed that interview easily. The take-away lesson for me: they are into algorithms and little else, even for senior positions. When approaching their questions, try to start with some simple algorithm expressing the core idea and ignore everything else – even if this "everything else" constitutes the main challenge in real-life development! If you just write this algorithm down correctly, you score. If their question was more involved, they will probably tell you, but you'll score anyway.
Regardless of whether I personally think Google's interviewing practices are conducive to hiring the best people (I don't), it is their way, so you just have to accept it if you want to get in.
The following metrics were computed from 1 interview experience for the Google Software Engineering role in Palo Alto, California.
Google's interview process for their Software Engineering roles in Palo Alto, California is extremely selective, failing the vast majority of engineers.
Candidates reported having mixed feelings for Google's Software Engineering interview process in Palo Alto, California.