How to get a job at Google, interview questions & process | Hacker News Reader

How to get a job at Google, interview questions & process

dondodge.typepad.com

123 pointsddodge125 comments

How and more importantly why the process works.

I interviewed with Google for a SRE position earlier this year and their screening process sure is tedious: Lots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture, like how to write good, maintainable software. I like nerding about graph traversal algos as much as the next guy, but not for 90 minutes on the phone after a long day of work.

I'm sure the screening process filters out duds but it's bound to generate a lot of false negatives as well. People that would otherwise be a perfect fit but who get fed up with the interminable interviewing or simply don't do well under that kind of stress (for me it was both).

Maybe they didn't have people readily available to interview you on topics more relevant to your position.

Or maybe they care more about IQ and the sort of interview you got is better at estimating IQ.

False positives are way worse for most companies than false negatives. Interviews processes are generally designed around this principle.

They've actually said as much. They understand that their process generates false negatives but they don't want any "crud."

Lots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture

They understand that their process generates false negatives but they don't want any "crud."

But quizzing on random trivia is irrelevant to the process of eliminating crud. It's quite likely that a cruddy performer will be able to rattle off all known sorting algorithms or all the option flags for GNU grep -- that has absolutely no bearing on true intelligence or any of the other qualities that Google professes to be interested in.

Having some insider's knowledge of Google: the process does not appear to be working. There is a lot of crud in there now, and the crud only seems intent on hiring more crud. Lots of power struggles and posturing; less and less innovative thinking.

Ah, but this is not your normal unix trivia, the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem and other questions along those lines.

This is not just flags to give to a process to make it do something, this is system internals. When I mentioned that I knew FreeBSD fairly well I was asked questions specifically about UFS and the likes.

I never did get asked about flags to grep and other UNIX tools.

the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem

Precisely what I mean by unix trivia. What's the difference between /dev/mem and /dev/kmem? I think it's memory vs kernel reserved memory, but in my 16 years as a unix admin I have never once needed to know that. If I did, I'd go look it up. That is why I consider those questions trivial: they're not fundamental, although you can make them sound like they must be.

Exactly.

They've also said that their high false negative rate is why they clear out their records every couple of years. If you got rejected a couple years ago you can apply again and they won't be looking at your previous attempt's performance.

This is the first time I've heard of this. I interviewed back in 2007 for SRE, and again in 2010 for SRE. I was told "we'll keep your resume in our database and let you know if anything comes up."

It kind of goes against Google's entire corporate culture to ever delete information like this. Sometimes I wondered if their interview process isn't designed more as a data mining process to find out what interesting things technology leaders are working on.

What Google should do if they want to hire really good candidates is to go with a contract to hire approach. Find good candidates, do one phone interview and a second in-person interview in the space of a few days (not 4 or 5, stretched out over months). If they pass your initial 2 interviews, hire them as a 6 month contractor.

See how much they accomplish in 6 months. If they are contributing and integrating effectively, hire them full time. If not, just wish them the best and don't renew their contract.

This is the way it works in most effective large companies. The cream that rises to the top gets offered a full time job within a 6 month to 2 year timeframe. My current job is like that. I've worked there for 4 years and started as a contractor. It became so expensive to pay my hourly rate that they were begging me to become full time after a while. I was doing a valuable job for them and was very effective at it, so I got the full time offer.

Not to mention that in a couple years you can become a much stronger hire anyway, especially early in your career going from 0 experience to 2 years. Experience = Time * Density [1]

[1] http://stevehanov.ca/blog/index.php?id=105

I see lots of assertions to this effect. Is it really true?

One point that no one seems to consider is that frustrating interview processes are a big contributor to smaller applicant pools; that is, a would-be good employee has applied a couple places, been filtered out by false negatives, and is thus disincentivized from even continuing to look for a better programming job.

Personally, I don't like my current job but am growing frustrated with job hunting. I'm very close to just looking for a bartending job to go along with the part-time valet work that I picked up between jobs, and then maybe doing hobby programming in my spare time for pleasure and profit. I'm serious here: ridiculous interview processes are making the quality of the programmer pool worse by nudging programmers out of it altogether.

Why is it so unreasonable to bring people in on an intern-like trial basis?

Maybe programmers nudged out of the process is a feature not a bug. People who self select out of a hard hiring process may meet not Google's criteria for certain attributes they want to see in their candidate.

Reminds me of property management: When screening possible tenants, merely saying that you will conduct background and credit checks will deter some people from even applying, most of them being people you wouldn't want to rent out to anyway.

> Why is it so unreasonable to bring people in on an intern-like trial basis?

We do that, in addition to an interview process biased towards false negatives. We still find it expensive to make hiring mistakes, enough that we are still circumspect about candidates.

Not only does it take a lot to build up someone new, it's emotionally costly to tell them at the end of the evaluation period that they didn't make the grade -- and still give them full support and a real chance the whole way, in case they can turn it around. It does happen; sometimes it just takes time for ambient culture values and priorities to sink in before people "get" what's important to succeed.

It's much harder to do this trial period with option to buy, than for interns who are going back to school, where the expectations and time frame are clear. It also seems that the most capable candidates aren't as interested in being hired on a trial basis, since they have other options willing to commit more fully to them.

These are a few reasons it doesn't work as well as you might hope.

(* note, not talking about google here)

It is really true. As you would know if you'd been on a team that needed to fire the wrong hire.

As for why not to try people before you hire them, a lot of experienced people already have jobs. They aren't going to want to accept a "maybe yes, maybe no" position without a really strong incentive.

That said, a number of companies do have policies of liking to hire contractors, then make some of them permanent. This kind of works. But the best contractors they'll find generally are contractors from choice, and so aren't likely to want to make the transition.

To me, this is one of the big unspoken about benefits of working in a startup. There is no room for slack and if someone isn't doing their job it's immediately apparent. Nothing kills my motivation more than working with someone who is technically incompetent and/or generally unpleasant to be around.

Are those interviews so frustrating that you are willing to take 2 low-paying jobs instead?

As a bartender and a valet, I've easily averaged $15-25 an hour. Right now I'm making $25 an hour when I'm billing, and once I get home I'm not in the mood to do much computer work. Additionally, you can find service jobs anywhere, and start up very quickly.

I'd rather have the flexibility to move anywhere, the stimulation of constantly meeting new people, and some leftover desire for personal projects when I get home than to have a programming job I don't like.

Fair enough. Note that I'm not looking down on your choice of jobs (recently I've been thinking it would be cool to get a part time job as bartender but it's not feasible now) but I suppose they inevitably come with some hassle and that will be worse over time than the one-time hassle of the interviews. Besides I assumed your programming job would pay much more (well, it should).

Want to work in Chicago?

Our interview process mostly consists of asking you questions you should know the answer to. If your answers make sense and you seem pleasant, welcome to the team. Oh, did I mention you'll probably make twice as much here than at Google?

Incidentally, more people want to work at Google than want to work at Bank of America, even though there is plenty of interesting code to write at the Bank, and plenty of boring paperwork to do at Google. It doesn't make sense to me.

I love Chicago... that sounds good to me.

Could you please give some examples of interesting code at Bank of America?

Fraud detection.

So, BoA wants to detect itself then?

What language(s), tech, framework is used for the software (web-apps? desktop? etc) at BoA?

There are something like 70,000 developers and 300,000 total employees, so it's hard to say anything other than "all of the above".

I mostly use Haskell and Perl. The rest of the department is mostly Perl. Sometimes I do C. Other groups are Python-heavy. There is a big Java and C# presence, and of course a lot of people that think C++ is the only real programming language.

There is some initiative to standardize on C++ and Python, but I doubt that is ever actually going to happen.

You forgot to mention that you would be working for a giant corporate behemoth that is evil to its customers.

How exactly are they evil? They borrow your money at a certain rate, and loan it to other people at a higher rate?

Without getting into the evil/not evil argument: This is not quite correct. A bank can lend more money than they have/borrow. The bank must only maintain a specific ratio of equity and loans. For more details see Basel I, Basel II and the upcoming Basel III, which (should) regulate the loans of banks.

I recently went through financial difficulties that involved problems paying 5 different credit cards. Bank of America was by far the most helpful company, actually recommending that I enter into debt management to allow me to pay off my cards at a markedly lower APR without taking a huge hit to my credit.

This is asserted as a truism, and perhaps in Google's case it is, but if the difficulty in the hiring process dissuades enough people who have other options from applying I can see it hurting the job pool.

If you were to get 100 applicants, and you were only interested in hiring the top 5% (5 people), and 3 of the good people decided to accept decent jobs they could get without giving blood samples and their first born, and 20 of the less capable people decided not to bother (Incompetents don't know they are in competent and have less choices), then now you have 2 good people out of 77.

Now what if one of those two is a false negative?

Google is attractive enough that good people go through all the trouble anyway, but is this always true? Since we are able to fire people easily in this country, is a bad hire really so ruinous?

I don't actually know the answer to the question, but I am skeptical of your statement. Maybe the assumptions in my numbers are wrong (they almost certainly are), but what are the real numbers?

Your argument holds weight in general but Google is a special case.

I'm sure they knowingly turn away bright & competent engineers simply due to the large size of the applicant pool.

Smaller companies would be wise to heed your advise though.

Perhaps the position they were interviewing you for actually involved writing efficient software, and thus required thorough knowledge of the fundamentals of computer science (data structures and algorithms &c) and systems programming?

And certainly your day-to-day work would involve answering questions about those data structures and algorithms in real time, with your future career depending on it, without external references.

If you know something well, you can reason about it in real time.

Pressure is an artifact of the interview process that is controlled primarily by the attitudes of the interviewer and interviewee regardless the subject matter.

External references are useful for things you don't know cold. For something basic and fundamental to your job (eg. basic graph traversals, the suitability of a hash or a balanced BST to some lookup task, etc), you shouldn't need them; for something more arcane which is accidental rather than essential to your task, or something relatively advanced (eg. specifics of tries for incremental string operations), a competent interviewer will help you out and supply some information so that he can evaluate your ability to reason, design and code.

None of these things have any bearing on whether or not it makes sense for Google to focus on knowledge of the fundamentals of computer science and systems programming in their hiring interviews.

I think not. Your day to day work involves sitting in front of an editor of your choice and writing code that may or may not compile or interpret properly, may or may not contain bugs, and may or may not have the correct logic. Simply having a computer at your disposal with the Internet handy, a step debugger, or the ability to run a shell or interpreter in an interactive mode puts you light years ahead of someone struggling in front of a white board trying to remember the arguments and proper order for some obscure function they haven't used in months.

How many people actually solve problems in their day to day jobs without every looking anything up online? Or at least checking to make sure they are correct. Just having a syntax highlighting editor is light years ahead of a white board and dry erase marker.

edit: Sorry, my sarcasm detector doesn't work. I think we're agreeing.

> I think we're agreeing.

Yep. Sorry if my sarcasm broadcaster had a weak signal

SRE (Site Reliability Engineers) according to Tom Limoncelli (a Google's SRE) is a kind of sysadmin, I doubt that this would ever be the case.

Right. I interviewed for SRE at Google. It's basically a sysadmin job. You're expected to be proficient at scripting in some language (Python, Perl, bash, etc), but I would assume you're not expected to write code for most Google applications.

I would think the senior SRE engineers know enough about the code base to poke around and make suggestions ("found a bug in module.py at line XYZ that causes bad performance when thousands of users hit it"), but I got the impression that most of their top developers probably would be bored in SRE.

The thing that is ironic is that most of the people interviewing me were not in SRE, but were pure developers. How many companies do you know that let the developers interview sysadmins? I had guys asking me CompSci questions I hadn't heard since college. If the tables were turned, do you think I'd be asking a prospective developer a question about how to configure DRBD replication and heartbeat from one Linux server to another? Even though some devs might know these things from hobby-like experimentation in their free time, they are not going to be doing it on a day to day basis.

It just strikes me as a very broken interviewing system when you have developers interviewing sysadmins.

An important distinction that's missing in this discussion is that you can be either an SA-SRE or a SWE-SRE. You can figure out which is which from how the SRE job postings on google.com are phrased.

SWE-SREs have to pass SWE interviews. I work down the hall from Tim. Nobody keeps track of who came in through which side (SA or SWE), but some of the SREs I work with wrote large parts of the services they support.

> It just strikes me as a very broken interviewing system when you have developers interviewing sysadmins.

Sounds like your recruiter messed up.

I had the same issue.. was kinda like, wtf..?

And how many systems does a google sysadmin administer? :)

(Answer: a lot.)

Not entirely true. There are two sides to the SRE positions. The sysadmin side is indeed what you say they are, they work on the systems keep them running and do hardware related tasks as well as UNIX level tasks.

The software engineering SRE's work on products to make sure they are ready to scale or if something fails to fix the point of failure. They work alongside the product development teams to make sure the product is stable in production.

The two positions require two different skill-sets (I was interviewed for both sides of SRE). One requires very much computer science, data structures, programming languages, and all of those, the other sysadmin requires more knowledge about Linux, its internals, and the command line interface.

I interviewed two years ago and I think it was pretty reasonable: one 45min phone interview and two 3h on-site interviews. I interviewed for a stat position and the questions were mostly a "see how you think on your feet" problems, talking through how you would solve some problem. I thought it was quite a pleasant experience, the whiteboard-discussion style was quite similar to what we do in academic research.

When I interviewed with them for the SRE position I was extremely nervous (I was right out of college, and Google had contacted me rather than me submitting my resume) and the guy on the other end of the phone for my first interview seemed uninterested, had a really bad quality phone (I could hardly hear his questions), and kept asking the same questions over and over in different terms, and I really couldn't figure out what he was looking for as the "right" answer.

The Unix trivia was not nearly as bad, that was easy as I had done a lot of reading on it, however some of the data structures I was asked about I had never learned in school and had just read about on Wikipedia so I didn't really understand them well enough.

The second interviewer was absolutely fantastic, and was genuinely interested in me as a person, had checked out my resume and looked at some of the previous projects I had done (Near Space balloon launches were discussed). I felt much more at ease, but I did seem to have somehow mixed many of the different programming languages I know (C++, C, Python, Java, F#, Scheme) thus my code was less than clean.

Ultimately after 5 different phone interviews I was unfortunately told that I was not a fit, that they would keep my resume on file and that I could try for another position when I had gained some more professional experience.

The Google interview did help me get through many other interviews I had the pleasure of going to. I was less likely to be caught off guard, especially since it was my first MAJOR interview with an extremely large company. I do wish that Google had not been my first interview as maybe then I would have gotten further into the hiring process and maybe just maybe I would have been working at Google.

That is an awful lot of maybes and it is not worth brooding on what could have been. I am extremely happy with my current job, I love what I do and the people I work with at a small new startup. I feel with a small company I can make more of a difference.

Why would anyone want to work at Google at this point? They can't hold onto their people, have very high churn and dissatisfaction rates, etc.

I could see maybe wanting to put in a year to learn the google stack, or if you have a particular area you've been researching and they will pay you to do exactly what you want, but beyond that... there are lots of companies offering better salaries and options with serious value, with similar challenges, that are going places. When you have people leaving despite half million dollar retention offers... why would you jump on that ship? Don't get me wrong - I think Google is fundamentally a good company. I just don't get why people aspire to work there, given the other options available.

Is it a mensa thing, with a brand recognizable outside the valley? Like you pass the interview, you're in the IQ club, stamp of approval, all that?

> there are lots of companies offering better salaries and options with serious value, with similar challenges, that are going places

Genuinely curious. What companies are you talking about?

Facebook, LinkedIn, Twitter, Zynga, etc.

Which places are they going?

Up.

They can't hold onto their people, have very high churn and dissatisfaction rates, etc.

Do you have citations for this?

What better way than to link you to google? :) http://www.google.com/search?sourceid=chrome&ie=UTF-8...

And specifically http://techcrunch.com/2010/09/01/google-making-extraordinary...

More generally, this is common knowledge around the valley.

I think Google has about 10,000 engineers, so this article is saying that over the past 5 years, approx 1% of Google engineers have moved to Facebook. I think this article is light on facts and high on sensationalism.

And it is "common knowledge" that Google has "very high churn and dissatisfaction rates"? Is that because Techcrunch or Valleywag says so? I think there is a large vocal minority of (in most cases) non-Google employees who are so quick to talk about how Google is a terrible place to work and everybody hates it. And internally at Google, there are a bunch of happy employees who just laugh at all the made up stories about how they are supposed to feel.

Look, people are going to leave Google. That is what is going to happen when you have a bunch of really young and talented engineers working in a big company, but don't think this is because Google is some terrible place to work. I'll bet the satisfaction rates of Google employees is among the highest of any large company.

That article, yes. Check out any of the many in the google search. This one stands out: http://online.wsj.com/article/SB124269038041932531.html This is well covered.

As to 'common knowledge,' it is common knowledge outside of google that tons of people are leaving because every week someone new shows up from google at these companies. Enough that people notice, kinda like Yahoo. Google is melting.

The other oft cited metric is the headcount freeze, while there is still aggressive hiring. Put that together... turnover.

If you like it, I don't think Google is a terrible place to work. The opposite is true I'm sure. You're getting a disk golf course that we're not allowed to use ( bastards ;) ). But for whatever reason, dissatisfaction and turnover are high. This could simply be attributed to being all growds up.

(Disclaimer: happy Google employee here.)

I do know the numbers, though I can't share them, and Google's turnover is ridiculously low. Much lower than I would expect from any company in Silicon Valley, which has a notoriously fluid job market.

It's also false that there's a headcount freeze: the total number of employees at Google has increased significantly over the past year.

It is false that there wasn't a headcount freeze, it did however end.

But in the time period when there was a headcount freeze, Google was not hiring "lots of people".

That is at odds with what I saw in that google search. Google was hiring lots of people to replace people that left

When will people learn not to believe everything they read on the Internet?

When will people learn not to believe everything they read on the intranet?

These are anecdotes, not real data.

My goal is always to work with highly intelligent people. People always talk about the big fish in a little pond but I think there is more value in being a little fish in a big pond because their is more room for growth.

I've noticed that if I'm not learning I'm not happy and its much easier to learn with smart people.

Its generally known that Google hires smart people.

But are they happy smart people?

They wouldn't be very smart if they remained in a job that was making them unhappy, would they?

Seriously though, all the (limited sample) of google employees I know seem to be happy with it. I'm sure I'd rather work for Google in 2000 than Google in 2010, but it's still a much better place to work than a lot of other places.

Personally, I wouldn't want to work there, either, but for different reasons. I don't want to work at an organization where I can't get to know everyone there, at least on some level.

Even the marketdroids.

Google is one of the top 5 software companies in the world, it is chok-a-ful of world class talent including many of the luminaries in computer science, they are changing the world with massive innovation every year, and to top it off they are famous for their employee perks and flexibility ...

but you'd rather go work for zynga making dumb games?

To each his own I guess.

I wouldn't work at Zynga, but your dismissal of them is pretty on par for Google's social media strategy, so it does make sense :)

When I saw this I felt like I had seen this exact thread play itself out before, so I Ducked around to check my feeling. It was correct:

http://news.ycombinator.com/item?id=1130984

http://news.ycombinator.com/item?id=784479

http://news.ycombinator.com/item?id=374722

http://news.ycombinator.com/item?id=145035

http://news.ycombinator.com/item?id=1520323

http://news.ycombinator.com/item?id=135666

(And for future reference, for when I inevitably re-post this in some future Google interview thread and forget to include this post itself in the list: http://news.ycombinator.com/item?id=1690792)

> Google offers are very competitive, some might say generous, and very thorough.

Interesting, I've always heard Google doesn't pay very well. Similar to game companies, they can take advantage of the fact people really want to work there and know candidates will accept lower pay because of it. I've heard that from several Google employees past and present. Perhaps things have changed?

Google didn't pay well in 2007. A friend and me went very far in the recruitment process and it stopped as soon as we explained we expected more money.

Meaning that you received offers?

We didn't get any formal offer, it stopped when the recruiter was testing the waters.

I won't discuss my personal story as I'm not anonymous here.

For my friend everything was very sweet until he mentioned that taking the job would require his wife to drop hers resulting in an income loss and he was concerned about this. Maybe he wasn't very subtle about it, but the minute he told that to the recruiter everything went black (got a "thank you mail" the next morning).

That being said the recruitment experience was very nice and I got a lot of good interview questions out of it.

I think Google is past the point where it can attract talent on reputation alone. They're already public AND their stock has probably peaked which makes stock options worthless. I imagine Google, like other companies, are having trouble attracting and retaining the top talent. There's a lot more opportunity right now in building a startup, and all the top developers know it.

As a recent Google hire, I think the article gets this point right, the offer was competitive if not generous. At the new-grad level at least I'm in the high-end of what I was expecting to be making.

I know that the reason I wanted to work at Google was to learn how to solve problems involving scale and massive parallelism. There really isn't anywhere else that can teach you that stuff as well.

Amazon and Facebook both come to mind when I think of scale and massive parallelism. Microsoft as well, but it doesn't get as much attention.

Whenever I read about these interviews, I get the impression that they are designed for recruiting students - that is, they are loaded with theory and don't test experience.

This was my impression when I interviewed with them. I passed two phone screens and interviewed on-site, but my resume died in committee. The on-site interview was pretty brutal for me, because it was very heavy on CS theory and I interviewed "cold" (meaning I did no preparation beforehand).

I subsequently read Steve Yegge's tips on getting hired there:

http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

His post made me feel simultaneously better (he also failed in his first attempt) and stupid (how could I think I would breeze through the Google hiring process without first boning up on CS theory?)

The interview questions would have been better suited for me 12 years ago when I was a new graduate and sorting algorithms and low-level file structures were fresher for me.

I don't blame Google, though. These are important concepts for them and it's my fault I didn't freshen my knowledge (or keep those skills honed over the years).

I've heard several claims about Google: 1) They hire less than 0.5% of applicants. 2) Their interview process is extremely time-consuming. 3) They pay below-market salaries in many cases. 4) They're a reasonably nice place to work, by big-company standards.

The current article supports (1) and (2), disagrees with (3), and supplies no data about (4).

For a talented engineer, what's the expected payoff of actually going through this whole interview process? If there's only an 0.5% chance of getting hired, it seems like a poor investment of time. If, on the other hand, Google is throwing out 98% of applicants as completely unqualified (which is typical in the industry), then the expected value of applying might be high enough to be worth the effort, provided you're in the remaining 2%.

Also, what's the upside of actually working for Google, compared to a startup? Do they give out enough Founders' Awards to make their base salaries irrelevant to people who would otherwise be launching successful products at a smaller company?

I recently interviewed with Google and I'd dispute (2). I have a friend at Google who vouched for me, so they didn't bother with a phone screen. The interview process consisted of two half-days where I spoke with 5 interviewers in total. That seems about the norm for tech companies. I certainly prefer splitting it across two half days rather than having one giant wall of interviewing from 9 to 5.

Also, your payoff/cost calculation is off since they choose whether to invite your back for the second round. I was told that because I got called back, the odds of me getting an offer were much, much higher. So if you get flushed early, you only blew half a day. If you end up having to spend two half-days, then the chances you'll get an offer are quite high.

I've heard some anecdotal support for (3), but they also seem to have very generous 401k matching. Plus, getting good food for free every day has to be worth something too.

Also, what's the upside of actually working for Google, compared to a startup?

One can generally work on different classes of problems at an established company with enormous problems and tons of really smart people like Google. Most startups aren't dealing with data anywhere close to the scale that Google is, and there is no startup in the world that can give you access to the internal talent pool Google has assembled.

Thank you for these answers! Two half-days of interviews is quite reasonable. I had the impression that things took longer than that, though perhaps I was mistaken because Google takes relatively long to make an offer.

If their interviewing process is anything like the ones I've helped organize, at least 49 out of 50 applicants could be dismissed out-of-hand, either because they didn't read the position description, because they can't write fluently in their native language, or because they can't write simple programs. So taking that as an estimate, Google is accepting perhaps 5–25% of "serious" applicants.

I think the large fraction of non-serious applications is caused by a survivor bias—the qualified candidates get hired quickly, but the unqualified ones keep applying to hundreds of jobs.

And you make a good point about interesting problems—Google certainly works on some neat stuff at an impressive scale.

Having an in is always nice, for those of us on the outside the interview process is tedious and does take a while. Various different phone interviews, talking to recruiters, emailing back and forth. It is all rather time consuming.

Oh, I actually did have several email and phone conversations with two different recruiters. The only thing that my Google contact saved me was having to do one phone screen. That's it.

And yeah, applying for a job just about anywhere is rather tedious. But all the recruiter job-type/schedule coordination probably took less than two hours spread over two weeks. It didn't seem all that burdensome. Ce la vie.

Do they give out enough Founders' Awards to make their base salaries irrelevant to people who would otherwise be launching successful products at a smaller company?

This seems like a highly speculative question.

What percentage of potential employees that would have begun a startup would be "successful"? How do you even quantify this?

What's different about "working for Google compared to a startup" versus working for any other company rather than being your own boss? Why do you ask about Google only?

> We set impossible goals and achieve many of them.

I suppose they keep setting impossibler and impossibler goals...

Personally, I think Google's recruiting process can become very long and tedious. I interviewed with Google 4 months before my graduation and went through 6 different interviews (all technical) for two different positions. The HR person told me that she would like to schedule another hour for interviews and took my availability for next 2-3 weeks. I got no response back. I contacted the HR person again, and she told me that they were going through reorgs and things were getting lost. She then took another 2 weeks of availability. No response. I didn't have much time to wait any longer, I decided to join another company.

From friends and colleagues who interviewed and/or are working at Google..I found out that the interview for college hires can become very long. One of my friends took 6 months to get a job. If this is still happening at some part of Google, they must improve this process. People don't usually have time to wait 6 months to know whether they got a job or not.

My experience was much smoother. A phone interview, a day of in-person interviews (5), and then the decision. The whole process took a month or so, but I wouldn't say I was strung along.

Yea, that's what a recruit candidate would expect. It's just that I was one of unlucky ones to be in such loop along with some others. I also think the "reorgs" played some part there.

Ya, you're not the first such case I've heard of, so I know it happens. It is unfortunate, but I think you slipped through the cracks. I definitely don't think it was intended to go that way.

This interview process sounds like searching for reasons to reject a candidate

They are very clear that they feel it is better to have false negatives rather than false positives, I don't think this should be a surprise.

Exactly. The process is designed to reduce false positives. The downside is there will be some false negatives.

It is not 100% accurate and it can take months to get through the process, but if we do it right we will be spending years together. So, it is worth the investment in time.

Don

They still get a lot of false positives.

However, the real problem is the amount of bias they introduce into the process. Few Google products have a lot of polish and they really don't get the social networking side of the web. Conceder how much effort it would take for a standalone version of gmail that could easily replace outlook everywhere and make Google a ridicules amount of money.

Don, IMHO, you're using the wrong techniques. Tests of random knowledge and focussing strictly on quick answers to logic problems will get you lucky left-brainers -- they're the ones who happened to know what command options are available for sed and awk, and are good linear thinkers.

Google should be doing better than that -- much better.

I just got done interviewing for an SRE position, and while there were a few small "trivia" questions, most of it was about general Linux userland tools, and were mostly used as a lead-in to having me solve some sort of practical, real world problem. For the few cases where I didn't know the answer, the interviewer just moved on to the next portion. It seemed rather balanced IMO.

I've had two rounds of interviews at Google and I would not characterize a single one of the individual interviews I experienced as requiring "random knowledge" or "quick answers to logic problems".

I think there is a real danger here of extrapolating the experiences of one or a few people to a statement on hundreds or thousands of interviews/interviewers. At the rate Google is interviewing candidates it should be expected that some interviewers are not good interviewers.

After doing a lot of research on the subject (to prepare for my own experience) I can say with some certainty that based on reports from people that actually went through the experience, interviewers asking for brainteasers or "random knowledge" are in the clear minority.

(At least for software engineering interviewing. The questions for product managers seem to be a whole other beast.)

From what I've understood from countless stories on the web and from real-life friends and associates, your story is the anecdotal one. Brainteasers, logic problems you're expected to solve in seconds, and random quizzes on arcane facts is the norm at Google. It's how Google makes its hiring decisions: can you remember arcane facts quickly? Are you good at solving logic problems on the spot?

Are you objecting on the grounds that you think you know how they should interview better than they do, or that you think they actually are hiring the wrong people? I've always heard that Google is chalk full of amazing programmers doing really good work, so I'd say evidence is on the side that whatever they're doing is working.

False negatives means you are wasting a talented person's time (on both sides) because your interview process sucks. From the stories I've heard, Google needs to work on reducing that.

How do you reduce false negatives without increasing the rate of false positives? Do you have any suggestions on how they can do this? The balance of standards of an interviewing process is a really tough problem. Surely the solution you'd suggest for them is more than just "be perfect"?

I'm not an expert making the Google Bucks. If the people they hire are so triple-verified awesome, they should be able to figure this out.

Given that the final hire rate is less than one half of one percent of received resumes, they can probably afford to.

Hmm that makes me wonder what the funnel analysis is between each of those steps...

I also want to be able to compare myself with the % of people that fell out of the same step in the funnel as I did :)

Just went through a recruiter screen myself. Contrary to what I've always heard, they said they don't care that I don't have a relevant degree given enough years of experience, though I'm intimidated by the prospect of what kind of grilling I'm going to get from the actual interview.

I had an honor of being interviewed in Mountain View CA for a basic in-house tech support person, but didn't make it. It was in May 2006. I was one of the finalist, but just not good enough. The experience however was fantastic and a huge ego booster. They flew me over to California for few days and gave me a tour of GooglePlex. I have to say that my interview process was consistent with the article. My "google question" was: "How would you fill out exact 4 liters in a Can of 5 liters and another Can of 3 liters, with unlimited supply of water?" I was able to answer it: Pour the content of the 3L can to the 5L one. Repeat the process again until the 5L can starts overfilling. So now you have 5L can full of water and 1L left in the 3L can. So now, empty the 5L can, and pour in it that 1L leftover water from the 3L can. Now you have 1L in the 5L can. Fill 3L can with water and pour it again in the 5L can. So 1L + 3L == 4L :) Still it wasn't enough for the job as I may have failed the regular expression part of my interview...

I know that the larger more prestigious companies will require more intensive hiring processes but I think this kind of attitude is really hurting smaller companies. The process for getting hired at smaller companies is getting so convoluted for one particular reason. It is hard for a company to simply hire and fire. In the most logical situation, you hire the best application, work them for a week and throw them out if they don't fit. As it is now, people whine, sue and pitch a fit when they get fired so that companies have to come up with aggravating hiring practices to get the people that will work out.

The problem with "what do you know" questions is not (or so much) that they may reject people who know stuff but recall it differently, but that they aren't selective for having the ability to stick with something for an extended time. Avoiding distraction with the internet, or the more subtle types of distraction into futzing with things rather than doing the most important but more discouraging tasks.

http://news.ycombinator.com/item?id=1690578

This article focuses on the process for a vanilla (by Google standards) candidates but does Google place any value on or change the rules based on the stature of an applicant it hasn't headhunted? Let's say Nat Friedman or Alan Cox decides he wants to work at Google. He's not going to be fielding "balls on a bus" type questions, right? Or is he?

Well, if they made Ken Thompson do a C programming test before letting him check in... (http://www.theregister.co.uk/2010/04/21/ken_thompson_take_ou...)

Um, that is readability. Everyone goes through it. Basically, "Do you know the Google style guide, and can you be trusted to know when code does or does not follow it?"

In a large code base it is important to have a consistent style. There are a million reasonable style choices. And knowing a tremendous amount about the C programming language tells us squat about whether you know what style choices Google has settled on.

I don't think Google's policy on this is unreasonable. (Disclaimer. I work at Google.)

I know. I imagine a similar argument for why no one bypasses the interview requirements. You have to be able to conform to the culture.

I had a round of interviews at the London office a long time ago, and another one recently. I think they are improving, but the fact they don't tell you where you failed is annoying. Also, some of my friends say they couldn't believe I had been rejected both times when they compare me to people they know who got accepted.

Does anyone know about interview process at Apple(for Eng/Design positions)? It will always be debatable which of the two(Apple and Google) are more innovative - I consider Apple to be a better mix of innovation and engineering, whereas Google comes out as primarily an engineering focused company.

Why anyone with the talent to get through the interview process at Google would rather work there than start their own startup I will never understand.

Some of us require more stability than the startup scene allows. Some of us also have wives that want to be able to afford decent living/eating conditions, and demand to be able to spend time with their spouses. Some of us also don't like the amount of stress involved, or the need to do things other than just working on software...

Someone might work at Google for a while to get both experience in working at scale as well as some nice bootstrap funding (basically, save your bonus each year).

You have to be very ambitious and determined to handle startup. Also gotta be ready for ramen-profitable (if any profitable at all) months.

And you may still fail eventually.

Working at Google or other well funded, yet young technology-at-the-core companies (which includes some startups too) means you spend most of your work hours doing what you enjoy: coding, code reviews, etc... On top of that, evenings and weekends are yours: if you don't get a chance to learn tools, technologies or concepts you're interested in your work hours (and if you chose the right place, you frequently do) you can do this on your own time. You also get to work with plenty of people smarter and/or more experienced, which is a great way to grow professionally.

Starting your own company (or joining a very early stage startup) means you'll be spending only a small proportion of your time coding: if all you do is as a founder is write code, you're essentially guaranteed to fail. Certain kinds of problems (core web search algorithms in post-Google era being the obvious one) are also, traditionally, are much more difficult for small startups to tackle than they are for big companies: certainly if you're passionate about these kinds of problems, than startups are generally off the table (in this case, your opportunity cost is much higher than money).

Obviously, it's still extremely rewarding for many people (it's something I'm still interested in doing at one point or another), but "start my own company" vs. "work at a great technology company" is neither clear cut in favour of the former nor mutually exclusive (witness "Xoogler" startups, Paypal Mafia, etc...)

don, awesome post. hope to see more of you on hacker news

i'am sick of hearing google's interview process.a company like google with kickass problem solvers should not hire a person based on his fucked up SAT scores{to me it sounds like sad scores!!} it has to be purely based on talent,his aptitude/attitude and skills.

In norvig page, norvig.com it is said that a good method to increase the power of the team is to choose someone that is better that someone at google. The author did a statistical simulation to show the positive effect of this strategy compared to another one. There is someone working at google that was working at apple and is good at social blogging (I don't remember now his name) but he didn't pass the test and he is working remotely (a exception). Also someone said that if you go before seven p.m. you are looked down, I am only remembering things I read on blogs.

The post you're referring to is here:

http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...

and the argument is that you should try to "only hire candidates who are above the mean of your current employees", rather than just hire people better than the worst you have.

I find the part where he talks about hiring for project vs. hiring for the company a bit more interesting.

This comment is interesting:

"This model seems to assume that people don't change, or that they perform in an interview and hiring process in the exact same way that they will perform on an actual team with a variety of personalities and any kind of manager."

Reply on news.ycombinator.com