My Google Interview Experience

If not having the right credentials were the issue, they would not have wasted their time or yours to begin with. It has to be another reason.

Companies usually don't provide feedback for several reasons. One is they don't want word to get out on what the correct answers are to questions - people will game the system. The other is legal protection. They don't want to open themselves up to a lawsuit from someone who thought might have done well in some areas, but not well in others.

My Google interview experience:

Google Internship January 2008: Had a phone screen. First question as I heard it: “Given a binary tree tell me if it is a binary tree?” I was a bit confused and said I didn’t understand the question and requirements. Given A tell me if it’s A. Yes? The interviewers response to my confusion was: “Do you even know what a binary tree is?” Yes, I do. When he restated the question as “given a binary tree tell me if it’s a valid binary search tree” I understood the requirements efffed up something in the implementation though. Then was asked to do another problem. Something with number sequence and iteration. Got told “division is slow” so don’t use it. Couldn’t see a solution without division on the spot. Then got asked if I know about Java serialization. My response: “implements Serializable” and you can write out or read in objects but I have never really used it in any serious way before.

I got the reject. Which I expected more or less. Kind of frustrating since I felt the interview was pretty much done in the first few minutes since I was asked: “do you even know what a binary tree is.” Kind of an uphill battle from my perspective.

YouTube February 2010: Applied for YouTube because I saw an ad in gmail. Why not.

2 phone interviews. And 4 onsite.

I thought I did ok solved everything to the best of my ability. Frustrated that I didn’t get it. Really enjoyed it. Seemed like a lot of fun. One interviewer told me my current job sounded boring. Not at all professional.

Google Kirkland June 2010: I applied for a developer position after I saw a Google Kirkland is hiring ad. Applied for Software Engineering role and said I’d like to work on Google Chrome.

Eventually a recruiter got back to me and would set me up with a phone call. Yep, I thought it was the initial HR phone screen for a software development role. The HR phone screen was rescheduled and I was told that in the mean time they would be happy to set me up for a call with an engineer for a test position. So the things got pushed off a few days. I still ended up talking with an HR rep before the engineer. She seemed a bit surprised that I had just interviewed at YouTube a few months before. All I thought was wow your HR software sucks. So I jumped through the HR phone screen and technical phone screen.

The onsite in Kirkland was interviews with two developers and two testers. Standard interview technical interview questions. First one was count number of bits in a 32 bit integer. I sent straight for the mask. Add the bytes in parallel. Then add the 4 bytes together. Interviewer was shocked I got that so quick. Ya, crazy when you have been asked the same question in the past, in school... you tend to memorize it from practice. The other interesting thing from the interview was the interviewer worked on the video tag of Chrome. Said the hard stuff was video and audio synchronization and doing that right across 3 different platforms. When I was at YouTube they said they used H264 because it was a good codec for quality and bandwidth and didn’t foresee themselves switching anytime soon. When I asked the Chrome guy if the company was willing to align on not h264 would it happen. The response: oh yeah we are on the same page. Yeah, and then shortly after my interview this was posted: http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html. Oh yes Google, you are a BIG company. Admit it!

The last interview of the day I remember slugging through and just not doing well on. Yeah, didn’t get the job.

My recommendation to Google: Phone interviews and Google Docs don’t mix. There is no auto-indent (that I know of) and I have mentioned that during an interview and got a yeah I know type of response. I would recommend: http://collabedit.com/ or something Google owns: http://etherpad.com/.

Books have been written and sometimes speak of the problems Google faces. In my opinion the biggest problem: “hubris”. I say that from my own experience as well as this book: http://amzn.com/1594202354. They live in their own insulated bubble it seems.

Professionalism is important. Sentences with phrases “do you even know” or “your job sounds boring” are rude.

Your HR software seems to suck. I am not actually interested in a role in “Test Engineering.” Yet, whenever a Google recruiter digs my name up and emails that is the role it is for. My recommendation to someone starting their career: Never ever ever take a job as a SDET/SET. It will hang over your head for years and hold back your career.

I used to really want to work at Google. After a few years in industry and these interviews I no longer have that interest isn’t there any more. For me, it depends on the team and people I’ll be working with more than the product or the company. Part of what has changed my mind: working at Microsoft a startup and this: http://www.youtube.com/watch?v=k2h2lvhzMDc.

Thank you all for your insightful comments. I do feel a little better and more informed. I will try to write an unofficial summary using what others (mostly the official wordings from Googlers (sigh)) have said, mainly for people in the same boat as me.

1. You don't have to be from an Ivy League university to get recruited by them. Yay.

2. Internal references are very very important for both getting recruited and getting feedback after the interview.

3. Getting recruited by Google can be very very competitive at times (not necessarily always), and you can be unlucky enough to be interviewing in those times.

4. There is no easy solution to the shallow feedback problem, which sucks very much for the candidate, but I guess threads like this can help you get some insight into the process and the very many variables involved in the recruitment decision.

Let me ask you this? How much time did you spend coding the sub-optimal solution?

For many of the questions I use during the interview process, I have a pretty good calibration level regarding how long it should take someone to answer a question. If the last couple of times I've used the question, the candidates were able to come up with an answer in 5 minutes, and then another candidate spends 10 minutes writing down an O(n3) solution, and then tries to come up with an more optimal solution, it might be understandable why I might give that last candidate a somewhat lower score.

One thing that can help is to also keep talking so the interviewer knows what you are thinking. That way if you outline an O(n2) solution very quickly, and then say, I think I can get a O(n log n) solution this other way, then you're showing your work, and it's a lot easier to get partial credit on a question.

In general it's better to explain the approach you want to take before you start coding. If an interviewer knows that you're going off in the weeds, perhaps because you misunderstood the problem, that will be an opportunity for the interviewer to clarify the problem, and perhaps give you a hint to steer you in the right direction. (Remember, most of the time the interviewer has used this question multiple times in the past, so s/he know where people are likely to get stuck, and very likely has hints prepared if people stumble --- and one or two stumbles does not a No Hire make; the goal is to see how someone codes and how they think, you don't get a 0 or 1 grade.)

>> (and the bar is continually lowering),

Oh goodie. I'm thinking Google has more "hubris" now than Apple.