My Google Interview Experience
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.
87 comments
[ 5.7 ms ] story [ 165 ms ] threadIf 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.
"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.
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.)
Sure, most software engineers (aye, even Google software engineers) are not under significant pressure on an average day. We get to work in the morning, we sit down at our desks, we hack on our code with our 30" monitors and customized editors, and we go home. It's a nice job, really.
But there are occasions when engineers are under pressure. There are deadlines. There are revenue-impacting bugs that need to be fixed while millions of dollars are at stake. There are segfaults in some new code you just deployed and the SRE team that's getting paged at 3am is threatening to burn your house down if you don't fix it before the weekend. Time pressure is not utterly foreign to a software engineer's life, and it's not unreasonable to do what we can to see how an engineer will function under such pressure. An engineer who can only properly function sitting at a desk with his 30" monitor filled with vim instances and ample time on his clock is lacking some measure of flexibility and capability that we reasonably expect to find in the best engineers.
No, we don't forget what it's like to be an interview candidate. You're just forgetting what the point of our interviewing is.
It would be good to get some feedback about how to improve and where you went wrong. It's pretty hard dealing with a generic rejection after flying for 14 hours to the other side of the world for an interview! If the rejection is because of technical skill, then I think they could figure that out from a few more phone interviews (although I guess a free trip to the US isn't too bad).
I don't think it's because of the university though. One of my friends from NZ got a job out there and he was from my university, which doesn't have a particularly high reputation for computer science. I think he just knew how to nail the technical questions under pressure, and is more interested in algorithms and low level stuff than me, perhaps.
I agree wholeheartedly, see my above comment about optimizing a solution being more of an art, and can take a varying amount of time.
I wasn't asked about any of my previous experience at all. I never felt like I had a chance to show off any of my skills and it didn't seem like they had even read my resume.
If you interview with a specific group/organization, they need some people to do something in that group/organization. Now, it's possible that they leave a good comment about the "second" candidate, and it's possible that other groups eventually will contact them I guess, but I find unlikely that they will just hire two people in a group if they need one.
It's not like the people who interview you are interviewing you for the entire Google.
Most likely for 100 positions they are interviewing several hundred candidates. If their reasoning was like you were suggesting they would end up hiring about 200 people each time. 100 of which would have to find a group to work for.
Not a good idea.
Absolutely, utterly incorrect. This has all been covered publicly by Peter Norvig[0]. Quoth he, "Another hiring strategy we use is no hiring manager. Whenever you give project managers responsibility for hiring for their own projects they'll take the best candidate in the pool, even if that candidate is sub-standard for the company, because every manager wants some help for their project rather than no help. That's why we do all hiring at the company level, not the project level. First we decide which candidates are above the hiring threshold, and then we decide what projects they can best contribute to."
[0] http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...
But what I know for sure it's not like that necessarily anymore, since I talked to many people about their interviews at google and I know some googlers as well that confirmed what I said (which is the reason I wrote it). Even when I talked to google myself, it was for an individual group, not the entire company (in my case, unlike my friends, it wasn't a software engineer position, though).
Also, and I can tell you this with 1000% certainty, even though they like to say sometimes the opposite, the people I know told me that Google instead has hired more commonly than you can think people that are sub-standard, it's not the normal usual thing, but it has indeed happened.
Also, the recruiters I met, had no clue about what a person with a certain specific Resume could have done in the company. They told me that they often decide whether or not to commit about trying to get a person interviewed based on if they believe they will get hired for a specific position (since that is how they get paid), not necessarily based on who they think is a good general candidate.
Now, I'm not saying that this is a rule, but even if you look at the positions posted now on the company website, they are so detailed and specific that it would make no sense to interview a person at the company level.
It can happen at the new grad level, but I doubt it happens on a common basis. I could be wrong, but I just speak by what I heard first hand.
Of course if with project you mean a specific individual project than I agree, but the company now it's rather big, there is many organizations and stuff that probably don't even know what the others do (still comments from Googlers). This is quite normal since Google can be compared to a campus, in any University nowadays you can be in the same department and do research in a field that is completely unknown to the person sitting next to you in the office since they might work on a different field and it takes years to actually start understanding something about it.
I'm not sure why it's relevant that Google has sometimes hired sub-standard people. Of course it has. Interviewing isn't perfect, and sometimes we make mistakes.
Although I really like Google and most things about how you guys work, I can't hide that I think it's becoming a common joke how broke the interview process is at Google.
One of my friends told me that they needed, really needed a person, but it still took four months to fill up the position. Another friend was contacted for a PhD software engineer position, and even though he had told the HR person that he was also interviewing for another company, he had time to go through the whole interview process with the other company (consisting on several meetings), and by the time he had an offer, Google still hadn't had the phone interview with him.
I'm just saying that I had the impression that the hiring system isn't not amongst the best ones out there, but I have big respect for how the company works.
Specifically, I think it's great, for example, that they aren't afraid of trying a million things and shut them down when they're not happy. Most companies are afraid of switching and are extremely slow at making any decent change.
But so, just to understand if you want to say something about it, do you really interview a person without a position? Just for the whole company? Or do you mean that if the candidate is good you say 'hire, but for a different position'? Or do you mean something else?
Thanks!
Yes, we may be rejecting highly qualified people who would do well at Google, but interview poorly. As has been noted in the comments here and elsewhere[0] it's far better to reject a qualified candidate than accept an unqualified candidate. Though we'd all be happier with a higher true positive rate, we're not willing to accept a higher false positive rate to achieve that.
What we're not good at, and what we get lampooned for so frequently (e.g., this story) is that in our pursuit of minimizing our false positive rate, we come off as arrogant, sometimes condescending, and a number of procedural and legal problems exacerbate that appearance. I've interviewed people that were right on the threshold between "hire" and "no hire", and like Joel advises, I wrote down "no hire". I'd love to tell these people what would have swung my opinion and ask them apply again in a year, but I just can't: it's too dangerous.
As far as interactions with recruiters goes, I can't really speak to those issues, since my experience in the hiring process was atypical (though not at all distinct in the ways we've discussed here so far, e.g. being hired for a company and finding a position after an offer has been extended).
Now, to answer your question, I have never interviewed anyone for a specific position. Every single person I've interviewed has been for engineering as a whole. People get interviewed for specific job ladders (e.g. SWE, SRE, SET, etc.) but the specific teams/projects a person will work on is decided after they've accepted an offer, as I understand it (and experience it myself).
[0] http://www.joelonsoftware.com/articles/fog0000000073.html
By the way, just to clarify because maybe it wasn't really clear, when I said broken I didn't mean at all that the interview process at Google fails at hiring good candidates, I just meant that sometimes it takes literally months and that's too long, and that often people in the meanwhile receive other offers. For many of them it's not possible to say no to another offer just because maybe they will get an offer from Google in two months (and career wise it's not serious to jump around and leave a place after two months unless the position is a lot better).
That's all, and I think it's cool that you interview that way. Maybe I've had a biased opinion given what happened to the people that I directly talked to. Thanks again for clarifying these points.
I explained in another thread here[0] one of the biggest sources of discontent from people who interview here, in case you're curious.
[0] http://news.ycombinator.com/item?id=3636746
Applicants' real competition is not other applicants, but other Google employees. As Peter Norvig detailed[0], the bar is set by the Google employees: as interviewers, we should reject any candidate who isn't clearly better than the average googler. And, in my experience, that's a pretty high bar.
[0] http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg... "First we decide which candidates are above the hiring threshold, and then we decide what projects they can best contribute to."
I am a Google engineer and have gone through the process twice (the first time unsuccessfully). It can be a frustrating and even exhausting experience so I certainly understand why you're bummed it didn't work out (I was the first time) but let me clear up a few things.
You don't need to go to an Ivy League or otherwise top school (actually most of the Ivies aren't in the top CS schools). I certainly didn't. I didn't even go to school in the US.
As far as grades go, if you're going in with 5 years of post-school experience, your grades probably won't even enter into the picture.
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.
I would suggest that anyone who wants to apply have someone within the company refer you. For one thing they'll be able to guide you through the process better and (hopefully) set your expectations correctly.
Plus a strong internal reference will help you much more than acing an interview question.
Starting with a basic solution won't hurt you either. You're right that staring at the whiteboard blankly for half an hour is the wrong thing to do. More than the code itself, the interviewer is interested in how you think and how you apply your knowledge to find a solution more than the solution itself. A suboptimal solution that works trumps no solution or even a more optimized solution with serious problems. It's totally fine to start with something that works and then refine.
One question though: did you have five interviews onsite one after the other or was one of them a lunch (or was a lunch in between any of them)?
Feel free to contact me if you have any questions or simply want to pass along any feedback.
EDIT: to clarify the calibration comment, imagine interviewers give a grade to the interviewee. If a given interviewer gives nothing but A+s then an A+ means less from that interviewer. Likewise, all Cs makes another C not necessarily a problem. That's why I say individual feedback scores only mean something in context.
Also, what an interviewer writes about you means WAY more than any given score. An A+ with no justification is simply ignored. A C- with no justification is likewise ignored.
Luck can unfortunately enter the process in a way different to what you might expect. If we're hiring a lot of people then at that time it can be easier to get a "yes". If headcount is tight, it becomes correspondingly harder to get a "yes".
Lastly, there are two different answers wrapped up into "no" that you unfortunately can't distinguish between from the feedback you're given.
The first is a definite "no" in that we're sure that at least for now we don't want to extend an offer. You may simply not be ready. There can be lots of reasons. We may well re-interview such people a year or more down the track. A very few are definite "no"s (eg they became belligerent or wildly inappropriate--yes it sometimes happens).
The second type of "no" is simply "we're not absolutely sure it's a yes". I must've fallen into this category because I was contacted two months later. You may well be in this category. Unfortunately there's no way to know. But we do keep records of those that applied and constantly go back through them.
As far as acing all the interviews goes, no you don't need to but you probably need to do really well on at least well (and can probably bomb one). Of course all of this depends on the position, current hiring needs, the particular hiring committee you go through and a host of other factors.
Don't forget you're not being judged in isolation either. There may simply be a strong pool of other candidates at the time you applied.
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.
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.
You are talking as if the default is hire. That isn't so. The default result is not hire.
If a couple of people gave you mediocre results, you won't be hired.
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.
[1]: http://www.cforcoding.com/2010/07/my-google-interview.html
This is true, but it sure would be helpful if they could give qualitative feedback like "the impression was that you were strong in a and b, but weak in x and y." That doesn't seem like too much to ask. (In fact, if he had good rapport with the recruiter I'm surprised that they didn't give that much information.)
Sadly, even this kind of feedback exposes the company on a legal front. There is a lot of precedent coming from rejected candidates who ended up suing the company because of this kind of feedback.
The only sane thing that a company can do from a legal standpoint is say "Sorry, we don't have a position for you at the moment, good luck in your search".
Does Google have family leave? --6 weeks, paid.
Did I get the job? --No
Because I plan to have kids??? See you in court!
Google reads your private email to "improve the product for you", why don't they want you reading their interview feedback so you can give them a better experience?
Because there are no good schools outside the US?
I want to underscore this. I have two friends (who didn't know each other), one who works at Google, another who applied at Google. The applicant had a similar experience (though he had two sets of phone interviews, since he wasn't in town), and he didn't get an offer. My Googler friend, however, was able to provide very good feedback, and the applicant walked away feeling motivated to try again in 6-12 months.
I'd also be curious how much throwawayttt probed for feedback during the interview process.
It always hurts to not get something you work hard for -- sorry mate!
When things are going poorly, you can frown, say "not quite", give sour words of encouragement, linger on the same unsolved problem, etc.
While HR / Legal usually have policies prohibiting direct feedback ("You're a 5 of 10 and we have 30 candidates who are all better than you. Also you went to Yale and that's lame."), there are many ways to provide feedback to the interview candidate without opening the company up to legal trouble. There are no laws against being human during an interview.
Then Bob interviews with Alice. Bob goes belly up. Never before has an interviewee done so poorly. Given the established precedent of providing feedback, what is Alice to do? We have a precedent in play. Would you want your employees telling candidates that they did a rubbish job? If she declines to tell Bob how he did, he'll interpret it as a negative. If she tells Bob that everything was dandy, it will set Bob's expectations.
The only reasonable choice is to bar your employees from providing feedback. Any other course of action is unfair to them.
In some of the 'worst' interviews I've conducted, it would become clear with 45 minutes to go that the candidate was a pass for technical reasons. After exploring for other strengths beyond the expected skillset, I focus the rest of these sessions on the really important things the candidate should know before their next interview with some other company. This is easy to present as standard interview questions, but with more explanation and context worked in to setup and 'next step' in multiparty questions. With no explicit "you've failed" ever stated, you have an opportunity to maintain a positive conversation, do the candidate a service and a favor by educating on what they need to learn next, and if you're really lucky discover that the candidate is a fast and eager learner who would be a great addition to the team despite current deficiencies.
Worst case, it's clear to the candidate where they're lacking without ever needing to state is as such. And who doesn't learn a little bit themselves every time they teach?
I know their best employees would likely pass the interview with flying colors, but my hunch is that there would be a large percentage of their employees that would fail. If they did a thorough analysis, my hunch is that their hiring process is likely determined by who their interviewers are, rather than who the candidate is.
I'm not bitter because I was rejected twice, but I do believe that their hiring process is a lot more random than what they believe it to be.
I have no data-points for Google, but do recall an open aptitude test they had made available with a few problems so challenging that I felt nearly 100% sure that many of the current Google employees could not solve. Folks from Wolfram Research (the company behind wolfram-alpha) showed how to solve the problems [1] using Mathematica, their flagship product. (Turns out Google themselves had one of things incorrect!)
[1] http://mathworld.wolfram.com/news/2004-10-13/google/
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.
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.
For the record, there are people coming out of MIT's CS program (or CS/EE or whatever has the most CS emphasis) that don't understand what recursion is.
Sadly, if you can't already program, you can get a master's in CS (because it's focused on depth and theory instead of programming), it's just completely useless. I have no idea what one can do with a MS-CS, if they can't program. It's honestly a little heartbreaking for me, that people to spend 2 years of their lives wasting it on that.
With all that said, I haven't found any degree (at least from any school I've interviewed applicants for) to be a reliable signal for programming. Even if they went to a really good school, there's a good chance that they spent all their time learning network protocols and low-level mechanisms, and will happily write up a sliding-window implementation for me, but will stare at me blankly when I ask for a simple recursive algorithm. It's just tough to find people that spent time studying and practicing general-purpose computer science.
It was only after I was later hired into Google that I learned from my original recruiter that I had actually done quite well in my first interview process. What I did not know at the time of my rejection letter was that they had narrowed down their pool of potential applicants to about 1200 resumes for three open positions they were looking to fill. Apparently, I made it into the last round of 10-12 applicants and just did not have the experience level with the specific tools for the job as others did. Thus, I received the same rejection letter the other 1196 people received, and never even knew I did as well as I did.
My advice would be to just stay in contact and keep Google updated anytime you have something new added to your resume or skill set. Based on what you have described, it actually sounds like you might have done pretty well. There are too many factors going on behind the scenes to say one way or another why you did not make it through this time.
Do you mind telling us if in the first interview you aced all your interviews, because I surely didn't.
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 think you are underestimating the importance of this. I have hired people before and this is a critical thing I look for. Attention to detail is very important as a developer, if you don't showcase it while on your best behaviour during an interview, I would be concerned what you are like day to day.
I think as a general rule you can assume every detail is important in an interview test.
Where I work, we give people a do-at-home programming assignment before having them come in for an interview. We then all code review the solution submitted. This seems to me a much more realistic gauge of a programmer's real-world abilities. Also, it clearly demonstrates that most people looking for jobs apparently can't program their way out of a paper bag.
The "server outage" scenario is a red herring. The vast majority of programmers don't have to fix server outages under pressure that is anything like that at a job interview. Also, you might try hiring programmers instead who write reliable software to begin with. I've written server software, for instance, that has been running continuously for the last dozen years without ever being touched by a human being since. I was also a sysadmin for a seven years, and had to deal with various emergencies all the time. Never was the pressure anything like trying to code at an interview, and the systems I designed and maintained worked great.
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.
If liability is an issue, have us sign a waiver.
Actually there are 4 possible attitudes about the Google Interview, according to what you believe: 1. Both claims are true: you don't have any problem with Google. 2. Only the utility claim is false: the interview is pointless, and can't be learned from. 3. Only the evil claim is false: the interview is not pointless, but Google is being evil by withholding valuable information 4. Both claims are false: you probably won't be interviewing for Google, and if you do you're a total cynic!
I think that the OP's position, and mine, is tentative support for category 3. I think there is value in the Google interview process, and after a long day of answering questions on a whiteboard, I feel like Google is being needlessly evil in withholding their feedback.
From the way I understand it, there are two main goals for hiring:
1. Always raising the bar by finding people who are better than the average Googler.
2. Find people who would fit in well and Googlers would want to work with.
This adds another dimension to the way you could perform in your interview. Keep in mind that not only the answer counts, but also how you answer, what kinds of questions you ask, what your attitude and personality is, etc. I have no idea if this was a factor in your outcome, but it's just another thing to consider.
Lastly: Don't be afraid to reapply after a year or so (I've interviewed at Google three times before joining)—prior results aren't held against you.
Disclaimer: I'm also a Google employee.
(I am an ex-Googler)
It's very subjective and falls clearly in the category of "You recognize it when you see it".
Typical example of a hiring committee deliberation at Google: "He didn't find the optimal solution but he looked very excited about the problem when he was trying to solve it".
Enthusiasm, interest, being personable, excitement about solving problems, all these things count when you interview, especially at Google.
Personally, in my interviewing I don't care at all about schools or GPAs. (I think the only time I've even considered the school is when candidates are from a big name school like MIT, where I will modify my interview to ask more culture questions to try to see whether they are too full of themselves.)
Instead, consider this: hiring someone who isn't good is much more costly than not hiring someone who is good. It's not only that you need to pay a person who doesn't do good work, but they're also a drag on everyone else who is already really busy. That is to say, it's much better to err on the side of "no hire" when you have any doubt; Google has plenty of employees already, and while they surely want more (and the bar is continually lowering), there's also no shortage of people who are willing to go through the legendarily Kafkaesque interview process repeatedly.
So it is possible that your one bad interview sunk you, even when it wasn't indicative of your skill. Everyone has bad days or bad luck sometimes, so don't feel too bad about it. You're in a good position in the world where there are many other tech companies eager to hire you as well and even compete on what they offer you.
With an attitude like that, it's no wonder employees are leaving Google for Facebook.
Oh goodie. I'm thinking Google has more "hubris" now than Apple.
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.
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...
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.
I had 5 interviews, and I didn't end up getting the job. I didn't do that great, and I knew it. I spent 2 weeks preparing and covered what I thought were my weak points, and still of the 5 interviews, 1 I nailed, 2 I did pretty good, and 2 I did just okay on, but not horrible.
I can understand why this got me rejected, though. I'm not whining that it's not fair, because obviously they have a particular type of person they want to hire, and I didn't fulfill the qualifications. I think I'm pretty smart with pretty good experience, but nothing entitles me to a job anywhere, especially at Google. The questions were extremely hard, but fair, because as I said, I guess they're trying to hire candidates who can answer them.
The thing I didn't like, however, was how some of the interviews were conducted. One in particular was a guy who asked me a fairly hard question, something that I hadn't seen before, and I was stumped for a bit, so I wanted a couple of minutes to think it through in my head. As I was trying to answer it on the whiteboard, he kept interrupting me, and kept steering me to HIS solution, not my solution. So because it wasn't my solution, I kept on trying to guess at what he was trying to say, and because of that I didn't have the benefit of having thought through it completely. This meant that I had a couple of bugs in my solution, because I spent most of the time trying to figure out where he was steering me to, and I didn't get the benefit of having thought through the process in my own way, where I probably would have caught the bugs.
It was also obvious from his tone that he was annoyed at having to provide me with the answer that he wanted to hear me say. This left a rather bitter taste in my mouth.
I would rather have finished the interview with a completely blank whiteboard because I was totally stumped, rather than play mind-reader and trying to guess at what the interview was pushing me towards. At least a blank whiteboard would have been a more accurate portrayal of my answer, instead of some half-baked solution because the interviewer kept pushing me towards a solution that I didn't get enough time to think through.
A job offer depends on 5 flawlessly decided "hire" votes. A mere 5% of interviews are flawed due to interviewer weaknesses (poor training, bad attitude, bad day) or miscommunications. What are the chances that a desirable candidate gets an incorrectly decided "no-offer" result?
The "legal" concerns about feedback are bogus.
Google doesn't make "good/not-good" decisions. They make "hire/no-hire" decisions. Huge difference.
They will call you back in 6 months and invite you to apply again. Just memorize the basic half of the CLRS Introduction to Algorithms book, and practice coding solutions to exercises, and you'll get an offer.
Google employees and management aren't perfect, but they aren't dumb. They know that Google is competitive with startups, and wins in many cases.