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.
If you want feedback, ask a smart friend (or a professional service) to mock interview you and give detailed feedback. That's better than what any official employer could do.
Wow, 1200 resumes for 3 positions, I didn't know that getting recruited by Google was that competitive, good for them that they can afford being that competitive.
Do you mind telling us if in the first interview you aced all your interviews, because I surely didn't.
The selectivity numbers I've heard for the whole process are about 1:2000, with about an order of magnitude decrease for each stage of the process (resume screen, phone screen, in-person interview, hire).
Keep in mind that like most statistics, these are misleading. Google gets a lot of applications from people who just want to work at Google and have no relevant skills, or who may be friends/SOs of current employees, or who ping their local Googler on Reddit or HN to submit their resume. These go into the system because who knows, we may find a gem, but realistically they have about 0 chance of being hired.
Getting to the in-person interview stage basically means we have reason to believe that you're a competent software engineer, but the acceptance rate is still something like 1 in 10 or 1 in 20 from that point. It's tougher than getting into Harvard and roughly on par (perhaps a bit easier) than getting into YCombinator.
I actually had a couple of interviews with more than one questions, but not others. I agree this could have been one of the reasons, but again an indication of this in the feedback could have helped.
Does being at the top of your class in one of the Top 50 Universities in the nation, with a near perfect GPA matter? I actually liked the CS program at my university, and being a state university the fees were pretty low compared to other universities, so I wouldn't call it a money making machine.
Honestly, if you want to do well on Google interviews, do enough Topcoder until you hit something like a 1500 rating steadily, and then I am pretty sure you'll make it through the interview.
Google style interviews are about being able to solve and code the solution to small, well defined problems quickly and correctly. This is really only tangentially related to being a good software engineer, where problems are not very small or well defined, and you are often working with large, complicated existing code bases. The interview process is not a great measure, it's just the best thing Google has come up with.
On the other hand, the interview process is basically the same exact thing that Topcoder is testing.
I had a high GPA from a probably not quite top 50 university (Rutgers) and got into Google. I saw a friend of mine with a perfect 4.0 GPA get rejected. I am sure you have the aptitude to get hired, you just need better luck or better training.
This is not completely true. There are other questions that will probe the candidates design skills, and ability to think about more complex problems.
One of the things that gets passed between interviewers is sheet of paper listing the questions that were asked by the previous interviewers. If I note that the previous interviewers have asked a lot of coding questions, I'll often assume that those interviewers have already covered that, and will ask questions that are more centered around design, and how the candidate goes about thinking about a bigger picture problem.
Thanks Cletus for taking the time to write that up. That really makes me feel better and provides somewhat more insight into the process.
My 5 years of experience was actually divided like 3 between Masters and Bachelors and 2 after Masters here in US, so I thought my Masters grade would matter.
My interviews were 3 before lunch and 2 after. Lunch was good :).
The interview conductor asked for references multiple times, but although I knew some people working in Google, but they had never closely worked with me, so I didn't want to make up references just for the sake of it.
EDIT:
"As far as releasing interview scores goes, that isn't going to happen for good reason. A score, by itself, is meaningless. Interviewers are calibrated against other interviews they've done and other interviewers. This is all in an attempt to make a fair assessment of the candidate. If a particular interviewer gives high marks to candidates where all the other interviewers don't, that gets calibrated. And vice versa."
So what you are saying is that for me to not have made it through I must have equally messed all my interviews or at least a majority of them. I surely didn't feel like that after the interview, but who knows, since I still don't have a way to know if that is the case. Then this really sucks.
> So what you are saying is that for me to not have made it through I must have equally messed all my interviews or at least a majority of them. I surely didn't feel like that after the interview, but who knows, since I still don't have a way to know if that is the case. Then this really sucks.
No, I don't believe that's what he's saying at all. All he's saying is that without knowing the past scoring of the interviewers, and the scores of other interview candidates, the numbers are meaningless. I could rate you a 6 on a scale of 1 - 10. This seems fairly average at first glance, but perhaps my median interview score is a 3. Now it's starting to look pretty good.
Nowhere in there did he say that you have to do poorly with all interviewers, or even most, just that they won't release numbers because without extra information those numbers are meaningless.
"So what you are saying is that for me to not have made it through I must have equally messed all my interviews or at least a majority of them. I surely didn't feel like that after the interview, but who knows, since I still don't have a way to know if that is the case. Then this really sucks."
Just a comment from another Google engineer who does interviews (and didn't do yours, since I haven't done any for a couple months now): your own feeling at the end of an interview may not at all reflect your actual performance in the interview, because you have no visibility into what questions weren't asked.
I like to interview candidates by asking them to solve a simple programming problem and then modifying the specification little by little, having them adjust their solution to implement new functionality. There are about 8 steps in my question, and frequently I'm gauging the quality of the candidate by how long it takes him to get through the first N stages; we fix bugs in earlier stages before moving on to the next stage. To calibrate myself, I've tried this question on several of my coworkers, and they were universally able to get about halfway through the question with bug-free code in about 10 minutes. Only one required prompting on my part to fix a bug. Most every candidate I've interviewed has taken 20-30 minutes to get to the same halfway point; by that time I've only got 15-25 minutes left in my interview, and the candidate seems so far like a "no hire", so I move to a different question to find out if the candidate has other strengths to counterbalance his weakness at solving this (simple) coding problem.
From the candidate's perspective, he only sees me ask a series of programming questions which he answers satisfactorily with a little prompting from me. If he answers another question or two satisfactorily, he may think he's done well, but he doesn't know that I wanted to delve more deeply into every question I asked him, and just didn't have time because the pace of his solutions was too slow.
I wish I could give this feedback to the people I've interviewed, but sadly, I can't.
"My experience was similar to yours. I interviewed at YouTube, and I was flown over from New Zealand for the interview. When I returned the next day, I got my generic rejection letter with Dear {Full Name}. While I got the general solutions to the 5 questions throughout the day correct; I struggled to code them on a whiteboard with someone watching me; I can never think well in those situations when solving problems, but I find that the optimal solution clicks to me when I'm in the shower or wake up in the middle of the night."
I agree wholeheartedly, see my above comment about optimizing a solution being more of an art, and can take a varying amount of time.
Well 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.
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.)
Personally 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.
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.