Hacker News new | past | comments | ask | show | jobs | submit login
My Google Interview Experience
79 points by throwawayttt on Feb 25, 2012 | hide | past | favorite | 86 comments
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.




As someone who was rejected by Google the first time, and hired the second time through, I went through a similar range of emotions during that first rejection. (I did not have an Ivy league education and only had a 3.2 GPA)

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.


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'm yet another Google engineer.)

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.


"Google has plenty of employees already"

With an attitude like that, it's no wonder employees are leaving Google for Facebook.


>> (and the bar is continually lowering),

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


Google 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.


"Or it could have been that I might have not paid attention to little details which I thought were not important"

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.


It irks me that people think that being able to pay attention to detail in a stressful job interview while standing in front of a whiteboard has any strong correlation with their ability and desire to pay attention to detail while doing real-world programming. If this were true, wouldn't MIT and Stanford and CMU grade you while you code at a whiteboard, instead of grading you on significant programming projects?

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.


I am not necessarily advocating the whiteboard, but am advocating attention to detail no matter what the situation is. I agree the whiteboard can be stressful, but so can a server outage and needing to get a fix out quickly. I don't want a programmer that generally has good attention to detail unless they are under pressure... under pressure is when you need it most.


The idea that every programmer should be able to write runnable programs under extreme stress without any errors is ludicrous. That has nothing to do with "attention to detail". It's like professors who give you a failing grade for making a single sign error in the middle of a complicated three page Laplace transform that is otherwise correct. What they really want is to just humiliate you for the power trip.

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.


Not sure if this helps, but as an interviewer I found "masters in computer science from a within top 50 state university in US" to be very weak signal of programming skills. Many candidates from schools which I would consider to be top 20 (like USC) even could not even get past a simple programming question a la "fizzbuzz" test. I would probably trust 5-10 US schools, but it seems for many American universities Masters program is just a money making engine.


2 years isn't enough time to learn how to program. Then again, I'm not really sure you can reliably make programmers with a substantial degree of success. In my undergrad CS program, we had 300 freshman at the start, and I graduated with 29 others at the end. For people with a CS undergrad, an MS program is quite good. They shore up on depth and theory that they didn't get while working on their programming chops in undergrad.

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.


A terminal masters degree by itself is a signal for the ability to write a pair of $20K checks. The requirements for a masters are far less rigorous than the requirements for a bachelors at the same institution.


Absolutely true. As strange as it may seem, a (terminal) masters degree is almost always less indicative of programming skill than the undergrad degree. I'd expect to be more impressed by a random UWashington Bachelor with no Masters over a UWashington Masters degree holder with a bachelors from somewhere I didn't know.


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.


> I would probably trust 5-10 US schools

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.


cletus, eta_carinae, and everyone else already gave great points, but I want to add one more to the pile: Google really cares about culture fit.

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.


Since the interview process doesn't include any sort of personal question or assessments other than one's ability to memorize algorithms and such, How do you measure "culture fit"?


Culture fit is judged by the candidates personality. Some of the signs of bad culture fit are arrogance, lack of curiosity, or a combative attitude. These kinds of traits usually becomes apparent during general conversation in the interview.

(I am an ex-Googler)


From most interview accounts, arrogance and combativeness are a very large part of google's culture.


I haven't seen Google worse than similar companies on that front. Interviewing is stressful for everyone. Remember that Google hires engineers and makes them interview. It doesn't hire people for interviewing talent. (But they probably should choose an train interviewers more carefully, and so should the rest is of the industry. )


> Since the interview process doesn't include any sort of personal question or assessments other than one's ability to memorize algorithms and such, How do you measure "culture fit"?

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.


Having been on both sides, what the applicant often forgets is that you are being compared with the other candidates. It's not about reaching an absolute level. Maybe you were very good that day, but another candidate just was so amazing that she got the job. But you can't know, you just don't have enough information.


That's not true at all. Very few candidates are being considered for positions known in advance.

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."


That doesn't really seem applicable. Google is more than big enough that they can hire both people if they are both good unless you're applying for a particularly specialized role which it didn't sound like was the case here.


I don't think this is true at all. I'm not saying that they will never hire an extra person in case they find two truly exceptional people (exceptional as in they feel like they really are missing out sending one home, not just that they are good programmers), but I'm sure that most of the times the hiring mechanism is quite compartmented.

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.


"I'm sure that most of the times the hiring mechanism is quite compartmented...It's not like the people who interview you are interviewing you for the entire Google."

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...


This is from 2006, 6 years ago. If you work at Google maybe you can say more about your experience.

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 do work at Google, and I'm saying that Norvig's description is still accurate. It was true when I was hired in 2010, and it's true now for the candidates I interview now.

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.


No, sorry, I didn't meant it in a provokative way. I was just saying it in relation to Norvig's statement.

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!


I wouldn't call the interview process at Google broken. While some of my coworkers are better than others, I've yet to encounter any that truly aren't at the top of our field. Whatever we're doing, however we may fail in other areas, the primary goal of interviewing--to find and hire highly qualified people--is something we're achieving.

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


Thanks for your explanation!

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.


Note that we do expedite the process for people who receive competing offers; I had an offer from another company the day after my Google interview; I told my recruiter about it and she had me an offer from Google within a week.

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


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.


Attention 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.


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.)


It's tragic that engineering interviewers extrapolate a candidate's mistakes on a whiteboard during a tense, time pressured interview situation to the calm day coding at a keyboard during a real day at work. It's almost as if we forget what it's like to be an interview candidate when we're the interviewer.


Tragic? What's the alternative? Should we ignore mistakes made at the whiteboard because someone was under time pressure?

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.


Hi,

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.


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.

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 remember your blog post[1] about Google interview. Love your answers on SO though.

[1]: http://www.cforcoding.com/2010/07/my-google-interview.html


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.

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.


"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.


I would love it if Google spent some time re-interviewing a bunch of their current employees, to see how good their interview process is compared to random chance.

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 interviewed over 100 candidates for my current company, thereby participated in post-interview meetings hearing other interviewers views on the candidate. I definitely feel that the selection process would fail many of the current, even some high-performing, employees.

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/


As far as releasing interview scores goes, that isn't going to happen for good reason.

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.)


> 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

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".


Given how things work in the US, I guess that might be true. But on what grounds does someone get sued for saying "we don't think you know enough about template metaprogramming"? (that's less frivolous than getting sued for saying "we don't have a position for you at the moment", that is, since you don't need a reason to sue.)


A week later, the candidate discovers that the company instead hired someone else that happens to knows absolutely nothing about template metaprogramming. Except that person is whiter / younger / less married than said candidate.


What does metaprogramming have to do with that complaint though? It is trivial to generate lawsuit without regard to feedback. Watch:

Does Google have family leave? --6 weeks, paid.

Did I get the job? --No

Because I plan to have kids??? See you in court!


My company's was sued by a candidate because we offered him coffee and he glommed onto that as religious discrimination. There is no legal exposure from giving feedback. Some people will sue if they want, and some people will discriminate (and deserve to be sued).

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?


Am I off in thinking it's horrible for the interviewers to not provide feedback during the interview?

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!


Imagine this from the perspective of an interviewer. Alice is interviewing Eve for a job at FooCorp. Eve rocks the interview. Alice is happy and gives Eve a high-five and some glowing feedback.

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.


This implies that feedback can't be provided throughout the interview. Reduce feedback loops, etc etc.

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?


For legal reasons, most employers will tell interviewers not to reveal any information at all about how you did. Unfortunately, the US is a highly litigious society, with lots and lots of lawyers egging people to sue over just about anything....


As an interviewer, to indicate things are going well, you can smile, nod, give happy words of encouragement, get excited, etc.

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.


> You don't need to go to an Ivy League or otherwise top school [..] I didn't even go to school in the US.

Because there are no good schools outside the US?


I didn't make it as far as you did, I just had a phone screen. I was quizzed a lot about how I would set up a server architecture (something I've never done before) so my answers were obviously a bit basic. Then I was given two algorithms to describe. One of them I knew and described okay, the other one I didn't really know at all and did poorly.

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.


Ya that is the other thing, I too felt that anything else didn't matter or mattered very less other than your performance on that day.


Five problems in five interviews sounds low. Obviously this is pure speculation, but perhaps the concern was that you didn't solve them fast enough. Interviewers are supposed to ask more than one technical question; the candidates I am enthusiastic about hiring tend to solve 2-3. That said, some problems are multi-facted enough that an interviewer can run with the same basic theme for the whole interview, I just think it would be unusual for that to be the case in all five interviews.


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.


My primary question after reading all the comments is; have you ever gotten feedback on an interview? I've worked a lot of jobs and been on a ton of interviews and I have never gotten feedback, so I don't even slightly expect it. My biggest expectation is the company giving me a "yes" or "no" in a reasonable time frame.

My friend just interviewed at Google and had a much different experience. He had one call and one onsite and got an offer after that. He isn't from a top school, more middle-of-the-road, but he is smart as hell.

This brings me to a point: It really sucks to say this, but sometimes we aren't as smart as we think we are and sometimes we aren't good enough for a job. Coming out of an interview saying that you did well, but didn't get the offer leaves yourself an excuse that maybe you were just unlucky or that someone just didn't like you for some weird reason, whatever it is. In reality, you probably didn't do well in the interview compared to other candidates and you aren't good enough for the job (on THAT day). It doesn't mean you don't try again, but giving yourself and excuse is an excape that really doesn't help you improve. I've been rejected on an interview and I learned more from that experience than any acceptance I've gotten.


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.

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.


"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.


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.


The university you are from pretty much doesn't matter for most software companies


I've been through a couple of Google interviews. My last one, I didn't even apply for, they contacted me a couple of months ago, asking if I wanted to interview. Why the heck not. I guess my previous interview was good enough such that they didn't require a phone interview, so I skipped that. Although it's perfectly reasonable to think that they were just trying to hurry the process up for everyone so that's why they had me skip the phone interview, and there was nothing particularly special about me.

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.


Try again next year. Consider the math (not exactly how it works, but you'll get the idea):

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?


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.


I 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!


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.


Facebook gives interview feedback. It reflects their core value of sharing. It's one of a few ways you can see that their process is thoughtfully and intentionally improved upon their predecessors at Google and Microsoft, and reflects the culture of information sharing that defines Facebook.

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.


Related: http://news.ycombinator.com/item?id=2800538


Screw Google. Go do a startup or get yourself into consulting/freelancing (like me) and earn big hourly bucks.


Just like you can't give out the questions to us here on HN, Google won't give you the feedback!


It's amazing people still want to work at Google. You don't have to be an employee at a certain place to do amazing things or good work. And wouldn't you rather work in an inclusive, supportive environment? Yeah, they pay a lot and have slippy slides and colorful bikes. However, If you do good work the money will come to you and the google types will stay at google.


Google is an inclusive, supportive environment, and though. The vast majority of hires (but perhaps not no-hires, of which there are more voices) say Google is the best job they ever had.

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.


There's so many exciting start-ups out there right now, why would you chose to go to Google?


The problem with silence is that it is inconsistent with the premise of the Google Interview (that it finds good programmers) and the unofficial Google Motto ("Don't be evil"). If these are true, then there's an opportunity for us to learn about our strengths and weaknesses, at least according to Google's POV.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: