7 ms·
My Google Interview Experience
I recently went through the full breadth of the Google Interviewing process for the Software Engineering role. I didn't make it through, but that is not what made me upset, instead it was the lack of proper feedback on Google's side.
While I understand that they have legal issues giving out feedback, but I don't see why they can't dish out simple numeric scores for each of the interviews. That will at least make the candidate aware of how much he needs to improve, or if he can even improve enough to apply again, or it's just not worth retrying. This is specially expected from Google since they ask you to prepare a ton of material for around a month which is real hard work.
Anyways on to the real stuff. I cleared the only phone interview, which was very basic, shared Google Doc coding for about an hour. I was then called for a set of 5 onsite interviews, which were 45 minutes each. While I won't give out the exact questions because I want to abide by the confidentiality agreement, I will just try to summarize.
Two were design and implementation, two were algorithms, and one was algorithms and implementation, all of them required writing on the whiteboard. I think I did well on 3, ok on 1.5 and bad on 0.5. The average level of questions on a scale from 1-5 was a 4, 5 being the toughest, and I thought me doing good/ok in 4.5 was enough for an offer. Although I should make it clear that I did use hints from the interviewers sometimes, but not always.
If you ask me why I think I wasn't given an offer, I would say it must have been a combination of
me not being from an ivy league university, although I am masters in computer science from a within top 50 state university in US, with a near 4.0 GPA and I have around 5 years of work experience. Or it could have been that I might have not paid attention to little details which I thought were not important, but they really were, like forgetting an obvious parameter while designing a method of a class which I quickly rectified once pointed out by the interviewer. Or it could have been that in all my solutions I started out with the most basic worst time complexity algorithm (because I didn't want to stare blankly at the whiteboard for half an hour thinking about an optimal solution), and over time improved it, sometimes with hints and sometimes without. But I have to say I was really proud of at-least two non-trivial solutions I came up with. This sort of uncertainty is exactly the thing that could have been avoided by a simple feedback email from Google instead of them just informing you on phone that you weren't good enough.
I hope your Google Interview experience wasn't like mine, but I would really like to know how it went for you?
Thanks.
- eta_carinae 15y agoGoogle employee here. Let me clear something for you: your rejection has nothing, repeat nothing, to do with your education. As for not giving feedback, like you hinted, it's purely for legal reasons. It sucks, but that's how things work in the US.
- shanehudson 15y agoI have a phone call planned for next week about becoming an intern for my Year in Industry (during my third year at uni)... hopefully it will not require such a high level as yours did!
- throwawayttt 15y agoPersonally the phone interview was much easier for me and I guess much lenient on any initially sub-optimal time complexity solutions, this doesn't mean you should relax though :). All the best for your interview.
- calvin 15y agoAttention to detail matters. Spending time looking at the code, and talking about (and explaining) your solutions matters. If an engineer misses details and won't spend time looking for a more optimal solution on a white board, I wouldn't expect them to do it in the day-to-day work of their career either.
- throwawayttt 15y agoWell if that is what they expect, then they should make it clear. Something like don't say you are finished till you have verified your solution. They didn't. "If an engineer misses details and won't spend time looking for a more optimal solution on a white board, I wouldn't expect them to do it in the day-to-day work of their career either." What a foolish generalization. This is exactly the kind of attitude that I don't like. Just because someone starts with a sub-optimal solution doesn't mean he can't/won't improve it. Also my approach was to start with a sub-optimal solution so that we have a foundation to build on, which I think is much better then spending your entire interviewing time thinking up a dynamic programming algorithm and leave a blank board at the end. Optimizing a solution is an art, and can take varying amount of time, and sometimes even your sub-optimal solution might be better than a more complicated optimal solution.