How I (almost) got an internship at Google | Hacker News Reader

How I (almost) got an internship at Google

ecarmi.org

171 pointsehc132 comments

My story: After my technical phone interviews, I got "accepted" as an intern, meaning I was in the Intern Pool of Rot, where I waded and waited for a team to fish me out. I waded and waded for a couple of months, hoping for a kind suitor. The HR woman always told me that she was "optimistic" about my prospects, so I rejected offers from other companies.

Then a really cool opportunity came, and I accepted that offer because you can't just sit in a rotting pool for two months.

A friend of mine stayed in the rotting pool and was told at the beginning of summer that no one at Google wanted him.

This was 2009-2010. I hope Google changed their ways.

I had a pretty similar experience just recently (so I guess they haven't changed their ways). Sounds like the process was a bit different but basically the same net result of Google telling me they wanted me, then not actually matching me up with any group in time for me to take an offer from them.

Unfortunately, this has happened to many friends of mine. I much prefer the way Microsoft, Amazon, Facebook, and Zynga do their recruiting. However, if Google actually does accept you, it's a steller experience.

i had an identical experience just a month ago - took 2 months to hear feedback on the technical interviews, followed by a whole bunch of nothing. compared to other offers i had, google moved by far the slowest

Somewhere in that pool of rejected interns is the next Bill Gates...

i doubt future-bill-gates would have the patience to apply and wait for big company internships. he would probably be spending that time hacking, hustling, and creating his own software business.

I doubt it. The next Bill Gates isn't hoping to get noticed by some company. He's out making something and/or hustling for deals like the actual Bill Gates did. The next Bill Gates is most definitely NOT languishing unnoticed in some intern pool waiting to be discovered like some Hollywood wannabe starlet.

The Woz worked at HP where he was well liked but hardly seen at CTO material...

And the statement "Somewhere in that pool of rejected interns is the next Woz..." would be far more realistic than "Somewhere in that pool of rejected interns is the next Bill Gates..."

The Woz type and the Bill Gates type are different by miles.

Even today Woz is not regarded as CTO material for a large company.

Mad scientist with lots of cool toys? Definitely.

Stick him in a suit and make him give presentations to the board? Definitely not.

Woz should be the guy in the basement in the lab coat who occasionally makes the lights in the building flicker with some bitchin' tesla coils... the guy that the CTO goes to in order to find out what is going to be important in tech trends, and who occasionally coughs up a wonderful invention that revolutionises everyone's life.

I think it is important to note that Woz is still listed as an Apple employee as an engineer

But to actually be the next Bill Gates he or she will have to not get picked. Then 30 years from now the story will be "If only I'd gotten that intership at Google I'd never have started this amazing company. What? You've never heard of Google? Well let me tell you about how it used to be..."

The process isn't too different now. My first interview (on campus) was mid January of this year. About a month later (mid February) I had another technical interview, after which I was put into the pool of possible interns. Then in mid March I had a "host interview" with my eventual manager, which resulted in an offer. A two month intern hiring process, when other companies make decisions within a week of the interview, seems arrogant (i.e., they don't think they need too be quick because people want to work at Google). FWIW my recruiter was very friendly, and she explained that she had a pool of about 30-40 intern candidates she was managing.

My process was the exact opposite. I did my two technical interviews back-to-back on a friday afternoon (4-6pm EST, so late in the day), and had been accepted to the applicant pool within the hour, with a host matching interview being setup 30 minutes after that. I interviewed Monday with my host and his manager, and was told that they were willing to host me and were going to start the approval process for an offer. I had the official offer by the end of the week.

So in under a week, I went from initial interview, to official offer. This is by _no_ means typical (and my recruiter even commented on how unbelievably fast it was), but it _does_ happen.

I think you'd have to try pretty hard to consciously design a worse intern recruitment process than this.

Getting them to write code is actually pretty good.

As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.

Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.

I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.

(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)

I enjoyed your quip about TDD. I always thought the same thing about mandatory "rough drafts" in high school.

"Unfortunately, I only know how to design something that works, I don't know how to fake a bad design"

I was once given an interview project where they wanted to see how I did with their current code structure. They gave me this really horrible template of data that could never be used in the real world or for anything other than this project. I decided to restructure the template so I could make a useable application for it. After turning it in they were astonished that I reformatted it to look exactly like their production data and code.

The problem was that they didn't like that I didn't use certain basic function like require_once, autoloading or something else which i forget (this was in php). Instead I used c style programming in php which ends up being faster. They chastised me for not using the builtin php functions because they assumed they must be better and didn't hire me. The company (well whoever the recruiter worked for) sayed in the email that I just wasn't the right fit because I wasn't up to the skill level of the guy giving me the test and they needed someone "that good" because they were way behind on their deadline. I sent them an email back basically saying that they're retarded (in a MUCH nicer way of course) and showed them some benchmark results I made comparing the different ways of doing it (which showed my methods as being much more efficient).

> Instead I used c style programming in php which ends up being faster.

Faster in performance, or faster to develop and maintain?

Most PHP apps I've come across have little need for CPU optimization. Not using built-in functions in those situations is likely to have no practical benefit except making it harder for other PHP devs to work with the code.

actually easier to maintain and faster in performance. For example, instead of doing require_once() doing a

if ( ! defined('SOMEINCLUDE')) require('file.php');

then defining SOMEINCLUDE in file.php.

Only saves 3% if i remember correctly but when you're including a hundred includes it adds up and when your site is spread across 30+ load balanced web servers every bit counts. As far as it being easier to maintain, it's easier to debug this way if something goes wrong.

However for things where you've gotta build some huge function (or any function really that's more than a line or 2) to replace a built in for such a small gain in performance I would agree with you.

PHP leads to premature optimization. The root of the root of all evil.

By "other forms of testing" do you mean something like integration testing or do you mean manually checking things?

If you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it, then besides being poor coders, they're also poor testers. Since presumably the result that you're looking for is what they should be testing.

A while back I worked on a web app with developers who used TDD exclusively. In the entire time they worked there they never viewed the web app locally, but they had complete confidence in their changes and almost never broke anything. It was a bit extreme, but it worked for them and they were very effective.

By other forms of testing I mean ALL other forms of testing. People sometimes fall into traps of thinking that their favourite form of testing is better than all the others, and so they neglect the others. I'm not talking about throwing out automated tests (for instance), they are great for doing regression testing amongst other things. But to only have your automated tests and nothing else seems like folly to me.

I take the point about them being poor coders and testers, though one of them was very highly regarded as a programmer (he presented well). The thing with testing is that you cannot predict everything in advance. Even with full code coverage you cannot cover every path through the code, and as soon as your code escapes into userland all sorts of whacky interactions can take place. The last, and best defence is to actually run the code and see what it does. your eye will pick up problems you never would have otherwise predicted.

With respect to the excellence of your TDD colleagues, perhaps they would have never broken it if they had less overwhelming confidence and more "well, it doesn't hurt to check"? That minor nitpick aside, I congratulate them. I think as programmers we should aspire/strive to be better than average, to be good at our art, and it sounds like they found a way that worked for them and fulfilled that goal.

Without the flashy salaries they supposedly offer to entry level CS graduates, and perhaps a bit of the clout their name still carries in the tech world, there's no way they would have any success with recruitment. I wonder if their process is working for them as it is.

My gf is in that rotting pool now. Killed the interviews, but hasn't found a right team yet.

One way out of the pool might be to reach out to potential teams herself, if you have any friends of friends within the 'plex who can send out tendrils internally. (Or just contact friendly people who post on HN... >.>)

Yeah she's been advised to go through Google's projects herself and let the recruiter know what she might be interested in.

Wouldn't it be an idea to team up with other 'pool rotters' and create a product for Google? i.e. form your own team proactively, and operate like a kind of Skunk Works in Google...

Same here. Twice in a row.

First time, I was told a manager would call me to explain me which team I was being matched with. I received the call to tell me I had an offer... two days after the deadline set by the University. And it is not like this deadline is unknown to employers.

Second time, again, I received an offer. This time, I had to call, one week before the deadline, after two weeks of hearing nothing from them. Two students in my class were in the same situation, one had to send a hate mail to finally get a reply. The other one got one only after the deadline.

To be honest, this really isn't the best way to go about it. Makes you fell like crap as an intern. I interned at fairly large and well known tech companies in the past (Facebook, heading to Bloomberg this Summer) and got offers from many more (Amazon, Microsoft, Zynga, EA, etc.) and my worst experiences were always with Google. As a freshman, Google looked like the dream internship, the company to aim for. Four internships later, it is now pretty low on my list.

Definitely not impressed by their recruitment process. And this all happened in the past 12 months.

Yeah I agree about Google making you feel like crap. Another thing, they don't pay for the relocation flight or provide corporate housing, so before my first internship with Google I was pretty bummed out by the whole process, but after actually working there I can't wait to get back.

Renaud, I think you should give them another shot if you're still up for it.

At least this summer, that's not true. They pay a relocation bonus that's more than enough to fly you out and back for the summer, as well as ship whatever you need out with you.

The lack of corporate housing is kind of unfortunate, but the internship pay is enough that it isn't something I'm terribly concerned about.

Weird story here. MS, Qualcomm, Intel etc. everyone shows up really early @ our school. Google comes 2 months later after the offer deadlines have passed. What gives ? I couldn't even interview because I had to accept another offer.

Compared to MS, Qualcomm, AMZN (I'm headed to MS) Google's process is pretty weird.

Perhaps Google only wanted the people who specifically want to work at Google... Once they have no other choice, Google has its pick of the remaining fish, right?

I wish it didn't play games in recruitment. I had already accepted an internship at Facebook by the time Google called. In the end I'm glad I did, because I really enjoyed Facebook and am going back full time.

Strangely, I've had a different experience. I've heard promptly from Google, but nothing from Facebook. Perhaps they just aren't interested in me, however.

And it is not like this deadline is unknown to employers.

Sadly the recruiter who knows this deadline and the managers who have "Look for suitable interns" as one of very many todo list items are not one and the same.

I did an internship at Microsoft and now work at Google; the MS internship hiring process (in 2002) was awesome and very, very fast. Your comments about Google's relative standing are definitely interesting and clearly not an anomaly, the issue is fixing them =)

>Your comments about Google's relative standing are definitely interesting and clearly not an anomaly, the issue is fixing them =)

Why is that an issue? I know from experience that Amazon and Microsoft have the problem pretty much solved. Just do what they do.

I've had bad experiences with Amazon, Facebook, and Microsoft. Amazon's recruitment process was lengthy and somehow all records they had for one of my interviews mysteriously vanished and I had to start all over again. With Facebook, I didn't get too far into the process, but our campus recruiter has a reputation for being disorganized.

I'll give MS recruiters the benefit of the doubt, as all other candidates I met had positive experiences. They just matched me with the wrong team, and it seems like the recruiter overlooked some paperwork related to scheduling and traveling.

Other sloppy recruitment experiences include some with trading companies such as Jane Street; one such company rejected me by saying "we're only looking for juniors" after calling me on-site. The only truly positive experience I've had is with a YC startup (I was eventually rejected).

Nothing, however, compares with how bureaucratic and mismanaged Google was. I went through a smooth but lengthy recruitment process the first time, and was given a rejection letter after 1 month. Second time, I had to do some juggling between 4 recruiters before getting the paperwork settled for my first interview. I was out of the country and clearly told a recruiter that I should be reached by a different phone number, after which I was asked "are you legally allowed to work in the United States?" even though I'd already answered that in the paperwork they had given me, and I had clearly stated I was studying in the US. Then, I end up scheduling interviews for 2am and 3am my time. The 3am interviewer is not informed about the change in phone number, and is a no-show.

A couple of interviews and 6 weeks later, I get no response. So I end up sending a follow-up mail to my recruiter, who, the very next day, tells me I've been put in the rotting pool. I get no more feedback after 3 weeks, and send another mail. Apparently, I'm still in this rotting pool. I'm guessing this is just equivalent to getting a rejection.

As for interview questions, Google isn't any different from other large companies. I found it odd that they still require candidates to code in Google Docs rather than some Etherpad equivalent that formats code.

So far, searching for an internship has been just a ridiculous time sink. I'd probably get more experience by hacking on my own projects, but that's no guarantee of job safety.

I finally got contacted today after 2 months in said pool :).

I expected better from a company like Google. Asking candidates for pre-canned code snippets to cutesy little CS problems on the whiteboard is miserable and the outcome depends too much on what the candidate studied in the last few weeks before the interview. It actually tells you very little about the kind of programmer a person is and the interview itself can get quite horrible on a personal level very fast.

A while ago, I used to conduct job interviews like this. Sort this, insert that, search for the other. I still feel sorry for some of the candidates I did this to. That process was the largest single mistake I made when hiring people. I should instead have asked for the code of some projects they had been working on recently and maybe discussed a few more creative things with them.

In fact, if I could ask a candidate just one question, it would be "what projects are you working on in your spare time?"

If someone isn't working on something in their spare time, it's a big red flag to me. You need to have the hunger. I'm more turned on by what you have in your github account than whether or not you can do a binary search in your choice of languages.

That's the sort of thing that works just fine in a small company that only needs a few people but, it does not scale.

PS: All of the great developers I have worked with are both old (50+) and have a life outside of code. Spend some time around people with Genius IQ's and 30+ years of experience and you rethink just how important passion really is.

I agree that this is the most valuable way to judge a candidate, but unfortunately I don't think it would work for most students and most companies (been through it all) because: a) students have a fair bit of school work to do, and: b) most companies can't afford the kind of talent that finds the time to work on other projects outside their normal coursework.

Now, for Google that might not be the case — they certainly should be trying to find the top talent they can get their hands on. All the more reason to ask about the extra projects, GitHub account, code samples etc. But just as many people, when they're students, don't appreciate or value the extra work you talk about, they won't do it when they work for Google and are tasked with hiring others. If all you spent time studying were algorithms and C, you won't appreciate the value of open-source contributions and feverishly learning new languages as much as someone else. And you won't hire based on that.

And yes, that's disappointing.

Students can (and should?) put the school work on Github or Bitbucket or whatever. Plus side to that is higher chance of getting to look back in later years. I desperately regret losing track of some old projects, just for missing out on poking fun at my undergrad naivete.

Definitely, but unfortunately a lot of one-off code meant for school assignments isn't valuable for anything else. And I wouldn't want GitHub to be littered with random things that aren't — and don't need to be — FLOSS projects, but instead serve as résumé pieces.

In my spare time I'm working on making the next million for my company. Oh, when I'm not working for my company? I'm with my family or friends.

I feel like the energy I could spend doing a side project is probably better spent getting these last two features in, or fixing those lingering bugs, or getting that automation solid, etc....

It seems really odd to actually penalize someone who leaves it all on the floor. It's like a basketball player saying, "If you really want to see my skills, come to the park. The NBA is just my paycheck." -- is that the guy you want on your team? The guy who will tell his next employer, "Company XYZ paid the bills, but my real cool work is this GitHub project I did on the side".

I think you make a good point. But I also think that in high school, yeah, I want the guy who spends a whole lot of time in the park playing ball, because he's the guy who's gonna make it into the NBA. It takes a big time investment to get really good at something. So, do senior devs need to have a github account? Maybe. Should a junior dev? Definitely.

Your analogy breaks down because the NBA is televised. If you're allowed to show some of your daytime work to an interviewer, by all means do that.

Only part of sport is televised. You don't see camp or practice, which is a big part of the game too. The game you watch on TV is like the shipping product. The code is like the practices, camp, training, etc...

My point is the lead dev for Angry Birds ends up at your desk and it seems almost pompous to say, "Where's your GitHub app?" This person broke his neck to ship, upgrade, and maintain a product that you can look at (the NBA game), yet a lot of people still seem to be saying, "w/o seeing your code (your practice sessions) I need the GitHub repo" (I need to watch you play at the park).

I guess as an employer this works to my advantage if more startups require GitHub accounts, since I can pick off proven talent that doesn't have this requirement. So yeah... it's a great idea! :-)

EDIT: And I should add that I was responding to someone who said that if you aren't working on something in your spare time that this is a red flag. So according to that poster, simply having great code from my "daytime" job isn't sufficient. Kobe Bryant NBA footage isn't sufficient. If he doesn't also play pickup games there must be a problem?!

It also breaks down because virtually no one in the NBA has only the NBA as their employer. At the very least they have sponsorships, many own businesses.. successful people just tend to be hustlers. Hustlers do lots of things.

is that the guy you want on your team? The guy who will tell his next employer, "Company XYZ paid the bills, but my real cool work is this GitHub project I did on the side"

I'll bite. Yeah. I want that guy. I want that guy because he's got energy and enthusiasm to burn, and I'm confident I can give him a place to use it.. Additionally, we'd love to see more open source projects come out of what we're working on..

I feel like the energy I could spend doing a side project is probably better spent getting these last two features in, or fixing those lingering bugs, or getting that automation solid, etc....

Awesome, if this was how it works, but it's not. The people that get itchy enough to bang out these projects on the side need to keep building stuff. Great stuff. I burn out on bug fixes, and automation.. and sometimes I feel like working on something different, so I bang on a new cache library for Django, or write something a little tangential to what we're currently iterating on. In my case, I'm really stoked with all of the problems we have that need doing, so none of my 'side-projects' are totally sideways to the values of our company... but lots of them aren't exactly high priorities :)

Awesome, if this was how it works, but it's not. The people that get itchy enough to bang out these projects on the side need to keep building stuff. Great stuff. I burn out on bug fixes, and automation.

This actually might the crux of the difference. While we have an open moonlighting policy the people that work here are a lot more likely to use the extra coding energy on something directly related to the priorities we have. There's no shortage of things to do. And t's not like you spend three straight weeks fixing bugs -- there's plenty of diversity in things that we need to in the business -- and I suspect most companies I'd want to work at are similar.

And again, I'm not necessarily against side projects. But it seems like an odd way to measure a potential employees passion to the job. It does seem like a great way to measure their passion for side projects, but we generally aren't hiring people explicitly to work on side projects. It seems like a much better way to measure their job passion is to see what they actually did at their job -- look at what they shipped.

If they shipped a crap product, but had a cool side project, what is that really saying? If anything its telling you to NOT hire them, but to get them interested in your product on the side! :-)

It really depends on the situation. At my last job the pay wasn't great and there was no profit sharing or stock options. At least they had interesting projects for me to work on, but still they got me for 8 hours and I did my own projects on the side.

My current employer has profit sharing, I love the work we do and there's always more interesting work to do than a 10 hour day allows. So now the projects I do at home are my pet projects for work that excite me but aren't part of my core tasks.

The question is "Is this someone passionate about programming?" and involvement with open source projects are a great way to find that out, but it's not the only way.

Some one who shows initiative and puts in extra work for a company they're excited about show's just as much passion for programming.

It's that programmer who puts in their hour and a half of coding in between reddit posts and forgets about it when 5 oclock hits that you want to stay away from.

Uh, your company is already paying you -- unless you're getting paid a bonus proportional to the stuff you're writing I see no point to give your company that. You made your company money, but your best ideas and projects should be for you. You work hard and earn your salary, but that's it.

I think it depends on what someone's day job is. If their day job involves really interesting programming challenges which are interesting and require creativity to solve, a programmer's passion and creativity can be invested in that.

If, however, a programmer's day job is maintaining a legacy system that doesn't involve a lot of creativity then there's a greater likelihood that they have untapped passion which will express itself in a side project... and ultimately with them finding a new job that does require creativity.

Judging someone based on their side projects is the wrong approach -- judge them on their creativity and passion. Some are fortunate to have a job which gives them the ability to be creative and passionate during work hours. Others aren't as fortunate and need to express their creativity and passion outside of work hours. The big red flag to not hire is when someone has neither creativity nor passion inside or outside of work hours.

What's your opinion on asking questions like "describe binary search"? I've asked that several times only to get stares or "are you serious?". (I still think it's critical to see someone attempt to code, as well.)

My feeling is that if they are claiming to be "programmers" but seem uncomfortable with basic algorithms/data structures, there could be a problem...no?

There is nothing wrong with asking a person to describe binary search. However it's not a relevant interview question. I assert that the number of times a programmer must single-handedly implement binary search without access to an editor, a parser, and the internet, from scratch, is very very low. You could make some argument about how incompetence in binary search algorithms betrays general incompetence, but I'd rather test for that general incompetence directly by looking at a person's projects.

I think that it's highly likely that a person who can't work out a binary search algorithm probably cannot solve interesting problems in pet projects, unless by interesting, you mean simple web applications or something of that nature.

This is a fair point. I make a point of not asking "CS exam" questions, but I do expect candidates to be familiar with fairly common computer science concepts. (Not-an-Example: In my own interviews I was asked about things like O-notation, and I have run into many, many programmers who don't know what this is.)

I think a question talking about the Django templating system when the interviewee mentions they use Django is fair game, though; and questions that revolve around 'here's a real world problem I want to do with a string, can you write a quick algorithm' are ok, but then I do things like the Greplin programming challenge for fun and I'm not even an engineer =(

> I think a question talking about the Django templating system when the interviewee mentions they use Django is fair game, though

I agree, but it was the only good one I could find in the article.

Thank you. You're not alone.

Many candidates wrongly assume they failed to get a position because they got a question wrong. Unless the question was trivial (i.e. what is the height of a tree?), most of the time these questions are intended to see how well you can carefully think through, create, clarify, and debug your code.

For example, when I was reading your writeup as a former interviewer (lots and lots of college candidates for MSFT -- I was a dev manager and did both my own hiring and was flown to colleges for those "interview days" for several years), I was far more worried that you had trouble finding the bug in binary search than that you got it wrong. Everyone gets problems wrong the first time unless they have just implemented them recently. Superior candidates are good at rapidly trying good normal and edge cases, hammering out a good solution, and writing inspired code when given hints at how to improve their solutions.

I'm almost certain this is why I failed my phone interview. It wasn't that I implemented an inefficient sort right away, its that I didn't talk about how/why it was and what I could do about it with more time.

I really don't like the idea of solving contrived puzzles, but I'll never make the mistake of keeping my thought process hidden again.

If you can, track down somebody who has done a lot of these interviews before to give you a test one and some feedback. I do that for the undergraduates at our school (I went back for my Ph.D. after retiring from MSFT), and they claim it has helped them prepare.

I don't claim any responsibility for their success, though! The University of Chicago undergrads are a hard-working bunch. Much more so than when I was an undergrad :-)

I wouldn't bother applying. Why the hell would you want to work a company that runs you through the gauntlet like this, only to give you the chance that maybe you'll get hired? I mean, this is obviously a really skilled guy who has lots of prospects.

Why are Google so popular anyway? I genuinely don't get it and would love to know from someone who has specific knowledge. Do they pay better than everyone else? Work on more interesting problems? Better perks, work environment, more status? I can understand it from the perspective of someone who joined years ago, when you got stock options and didn't have to do a full circus performance in order to get in, but not any longer.

The experience would have to be twice as good as the alternatives before I willingly submitted to this kind of process. A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.

For an _internship_? If you're turning down other offers for the _chance_ to work at Google, you're selling yourself short and not getting full market value.

I'm not a Googler, but I know many and yes, Google pays well, they work on very very interesting problems. Ex-Googler does have a ring to it when you apply for jobs. There are awesome benefits like amazing facilities and lunch everyday, on-site massages, fitness centers, etc. The environment is that everyone around you is incredibly intelligent so just being there is intellectually stimulating and feels like you're a student. Though working at Google is definitely not what it used to be, it certainly has its perks.

I keep hearing programmers at google work on very interesting problems, but I honestly wonder if all of them do. I mean, how many programmers does google employ by now? can they all really be working in creative, challenging problems?

> Why are Google so popular anyway?

I've been a Googler for a little less than a year and so far I absolutely love it. Compensation is good, the perks are fantastic, the caliber of people I work with is stellar, the work is challenging and interesting, and the culture and processes are the best I've seen.

> A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.

I believe it's the opposite. You have to run the gauntlet to get in because once you do, you won't be closely monitored and you'll be given a lot of autonomy. The hiring process is stringent to try to reduce the number of internal gates you need once you get in.

Why the hell would you want to work a company that runs you through the gauntlet like this, only to give you the chance that maybe you'll get hired? I mean, this is obviously a really skilled guy who has lots of prospects.

Because at this point in your career, you have no degree, no experience, and no income? He's a sophomore in college, not someone with 30 years of industry experience.

In my experience, though, I would make someone with 30 years of industry experience answer the same questions. Because I've asked people like that those questions and they have absolutely no fucking idea. The number of people that can start with a blank file and start writing a computer program is probably somewhere around 5% of programmers.

> The number of people that can start with a blank file and start writing a computer program is probably somewhere around 5% of programmers.

What?! There's no way this is true... is there?

Wouldn't surprise me. Most of the code written these days is modifications or additions to pre-existing codebases. Projects are usually started from scratch by just one or a few coders, then as it grows a great deal more are hired to specialize in building out certain parts of it - front end, backend, db, etc. The ratio of from-scratch engineers to codebase developers is probably pretty small.

I'd wager it's more "5% of people currently interviewing for jobs" than 5% of all programmers.

(Joel puts it well in this article: http://www.joelonsoftware.com/items/2005/01/27.html )

As of second year, I've now written dozens of mostly trivial school assignments from scratch, and I can't see it being different anywhere else. There is, however, a difference between being able to pump out a command line calendar for processing .ics files or program an alarm clock in assembly, and being able to make something that people would actually want to use from scratch. Having never done the latter, I'm sure I would struggle initially.

I think part of the problem is that CS programs simply aren't structured for large projects. It would be far more realistic to say on day one, "get in groups of three and hand in a functioning program by the end of the term", but that structure just doesn't work for school. Or, if it would, then nobody has the brass to try it.

I agree that Google has a terrible recruitment process for internships. The first year I applied, I made it past both "technical interviews" and had a "host interview" scheduled, only to have it cancelled. My recruiter said he was pretty sure I'd get another, but I never did.

The second year (last year), my experience was similar, except this time I bugged my recruiter pretty much every other week until I had a host interview (got TWO of them cancelled on me but finally the third one actually happened) and I got the job.

Despite the terrible process, it is an absolutely amazing place to work. Everything you've heard is true: the food is amazing, the work atmosphere is amazing, the people are geniuses. Also, the compensation is absolutely absurd for undergraduate interns (last year it was $69,600/yr prorated to $1338/wk, and this year they bumped it up to $80,000/yr prorated to $1538/wk, with a $3500 lump sum relocation stipend on top of that. I know it's even higher for grad interns but I don't know the exact numbers).

Despite the admittedly awful process (easily the worst I've been through), it was absolutely worth it to me and I'd recommend anyone stick with it and hope you get lucky like I did. It really does come down to luck whether or not you get a host interview once you've passed your two technical interviews.

I hate little programming puzzles that you have code by hand or little word problems, or trick questions that you have to think "out of the box".

In many years of programming I don't remember having to write a binary search in C, by hand, in a text document, without being able to compile and test. Or having to dictate a Python program over the phone to someone.

I certainly do not remember ever having to solve stuff like:"One train leaves Los Angeles at 15mph heading for New York. Another train leaves from New York at 20mph heading for Los Angeles on the same track. If a bird, flying at 25mph, leaves from Los Angeles at the same time as the train and flies back and forth between the two trains until they collide, how far will the bird have traveled?" NEVER.

I had to implement & modify algorithms from scientific papers, I had to work with complicated lockless versions of data structures, but I probably couldn't write the binary tree search in C over the phone. If that's that Google uses to hire then I will never work at Google.

EDIT: Alright, got a angry and used the 'fuck' a little too much.

So, to be fair to Google, I was not once asked anything like the train question nor was I asked to write a binary search in C then to read it out over the phone. I did implement a few things in Google docs, which is kind of ugly, but it wasn't anything ridiculous, and most of the functions were fairly short (20-30 lines).

They did, however, ask a whole bunch of conceptual questions, but I don't think this is all that surprising.

I'm an intern right now. Just today I saw Neil Fraser [1], who wrote MobWrite [2]. I shook his hand and thanked him, he's probably one of the reasons I actually managed to pass! My third phone interview had code in MobWrite, not Google Docs, and it was so much better.

I'm going to try to find a way to feed it back to HR, because it really is much easier to think about code when what you're doing looks like code.

[1] http://neil.fraser.name [2] http://www.mobwrite.net

That's awesome! I'll have to play with this, and suggest it whenever I hear the topic of coding interviews come up.

As a side note, if there's any chance of you being in the bay area this summer (Mtn. View specifically), I'd love to grab lunch with a fellow HNer. I'll be interning at Google starting early May and know a sum total of 0 people out in the area. If you're interested and possibly going to be around, my e-mail is on my profile page.

I interviewed with them recently (got through phone interviews and am waiting for a visa for my onsite interview), and I never got any trick/puzzle questions that need no programming to solve. I did get questions about simple CS concepts and had to write code for programming problems on a shared google doc. Nothing any ordinary CS graduate wouldn't know. I made mistakes, which my interviewers always guided me to correct. They don't expect you to write a flawless binary search - they know you'll make mistakes. What they want to see is how you think and how you code, and how you recover from mistakes. Also, that you know what binary search is in the first place.

That was my first interview, and they said at first it was going to be a coding interview. My next interview was a design interview. We talked at length about designing a simple web application, which got increasingly sophisticated as we progressed. But my interviewer did ask me to write code to demonstrate what I had in mind from time to time and I had to code up some small methods and classes to show him. No puzzles. No CS theory or abstract problems. Just what I would do if I were building a real world application.

Oh, and they asked about what projects I had worked on both interviews.

I have been an interviewer in the place where I work currently, and I always asked candidates to write code. Some guys here ask puzzles, but I don't like that. Puzzles (like how to find you who's lying in an island on people or something) don't really show anything in an interview situation. But a short programming problem, demonstrating the ability to identify and use a well known data structure or algorithm, or to use good sense and understanding to design a solution to a problem does go a long way to show that a candidate can actually code and get stuff done. I've seen lots of bad candidates impress us with their knowledge of tech buzzwords, past projects in their CV and even talking about design patterns, but fail miserably when asked specific questions or writing even the simplest amount of code.

But if someone asks me about trains and birds, I would seriously reconsider working there

> I have been an interviewer in the place where I work currently, and I always asked candidates to write code.

Agreed. It doesn't have to be perfect. They should be able to talk and explain it. Whiteboard design sessions are my favorite A good marker and a whiteboard are indispensable for me, and I use it in interviews as well. I present the situation as here is a typical problem we are solving, let's solve this together.

I also give plenty of chances to let the candidate tell me or teach me something they are excited about.

Google's loss is some other company's gain. Apply to places like Facebook or Microsoft or Amazon instead. Or in your case The New York Times.

Personally I was in between jobs recently, so I sent Google my resume using their online application site. After about a month, Google still didn't get back to me -- meanwhile I managed to interview at 6 different places (all the way) and found a new job.

"I heard nothing for a month and a half" is the key problem I think. It's going to be very hard for any full time employees that are any good to stay off the market that long, they'd have to apply to Google before quitting their last job.

As for interns, I am not overly surprised since you applied in December. At my school we had the hiring booms in October/November and then again in March/April (that's when we had the 2 engineering job fairs), so anytime between that people weren't really finding a new internship (unless it was on their own).

One last thing, what exactly is a Google spreadsheet beta candidate form? Is that the same one as the optional Google "survey" where you had to rank your skills (1-5 or 1-10 was it)?

Having done the internship application process this year, I believe that's the one he's talking about, yes. It basically asks you to rate skills on things relevant to Google, and give location preferences and such.

I don't think it was optional, though perhaps I'm mistaken and filled it out assuming it was required.

Yes, I just looked at the form again (the link still works) and it asks: University, Major, GPA, strongest programming language, second programming language, and preferences for location, and then a five-option part where you rate yourself out of: Not my thing (none) Can make do (fair) Comfortable (good) Comes easily (better) World Class (best)

On the following: 1) Applications and Services: this is Google's term for the software that is directly visible to end users. People who focus on applications and services typically work on improving our capabilities in a variety of areas that span the range from new features to increasing performance and efficiency at Google scale. They will be tasked with devising and building new approaches to Google's problems, and exploring their effectiveness.

2) Systems: People who have a systems focus are oriented towards behind-the-scenes software and systems, often building them from underlying components and services. Systems work spans from platforms (hardware, OS, networking) to infrastructure (shared services such as storage, cluster management) and everything in between.

3) Sys-admin: Our system administrators keep all of Google's systems running, and help deploy new ones. They deal with issues involving single machines to those involving huge numbers. They work with native Linux environments, and Google extensions and services.

4) Verification and Test: Our test teams helps make our systems resilient and reliable - we put a lot of effort into this. Building world class applications at world class scales doesn’t happen by accident. It takes insight, innovation, and precision to verify our systems perform as expected.

I was disappointed by my interview process earlier this month for a potential summer internship at Google. I'm sure part of it is driven by the result (I didn't get past the phone screens.) My main complaints are

- Every step of the process involved a new person. Overall, I had to be handed off through 4 different people, each one wanting a bit more information or a filled out form, until I was scheduled for the phone interviews. This was especially confusing when I had a recruiter assigned to me, and I was being emailed by both her and someone with whom she worked with at the same point in the process.

- The first interviewer was apparently a fill-in for the intended one, which is unfortunate, because he and I were a complete mismatch. He seemed to be a C/C++ guy and I have more high-level language experience, and we ended up doing what I would consider advanced bit manipulation / number theory. (The second interview was much more reasonable, and it is my own fault if I did not pass it.)

- The amount of time time that it took from the "Hi, we would like you to apply online" email to the you are not "a close enough match" email was over a month, which is much too long for simple back-to-back phone interviews. Waiting for their responses was the most frustrating and nerve-racking part of the process. I am glad at least the OP had quick responses.

Should I go through the process again, I would strongly consider asking them to expedite it in one way or another.

On a more optimistic note, I do feel like the interviews do help highlight weaknesses in your programming skills and resume presentation skills.

Mirrors my internship experience almost exactly. Three rapid-fire technical interviews that I thought went quite well, then a "sorry, no dice" email. Someone else I know just went through the same thing, also for an internship.

Google sure makes a lot of noise about how they are hiring and competing for talent, but continue to turn away good people for unknown reasons.

I think Google receives around 20000 resumes per day. If you've got that kind of interest (and what I've heard, justified interest) you'll have to turn most people down (ie. >99%). I don't have inside knowledge about the Google hiring process, but with that many people applying, you're bound to have some false negatives.

The problem is that they do the exact same thing for people that they reach out to. Their recruiters go out to mailing lists and linkedin and harvest emails, then contact those people and offer them positions. If you say yes, they start you on the exact same anonymous interview process, the interviewers having no clue that you didn't apply yourself and treating you just like any other generic wannabe. That's why a lot of the best programmers won't take offers from Google, they know they're going to be treated like cattle throughout the whole process by people who have no clue who they are or what they've done and don't really care to know.

It's important to know that googlers are encouraged internally to do interviews (for extra cookie points? I don't know :P), they're assigned randomly to candidates for most of the process, so they're not a part of the whole process, just a piece of the machinery. No one oversees the interviews to make sure questions are not repeated and that there's a logical thread from one to the other (especially the onsite interviews), and you might not even be asked the questions that are actually relevant for the position they're considering you for, when you're in the latter stages of the process.

The stories I've heard from the hiring trenches are all pretty much the same. It's a great company, but their hiring processes are very weird.

They've contacted me twice, 5 years apart for SRE positions, which aren't really a great match to my experience. I've never actually applied.

First time, first phone screen, not that bad. Second interview, they push on bash, and I said, essentially, that I wouldn't use bash, I'd use python. So much for that process.

Second time, same phone screen, same self evaluate, same damn questions on the first part. This time, of course, I know the answers to the tricky questions, because they asked me the same damn questions the last time.

This time though, the process has taken nearly a month for about three calls, including the one actual phone screen. Nothing more for a couple weeks, then the "sorry, not gonna happen, and were not going to tell you why".

I'm a little confused. They call me, looking for something that I'm not a good fit for, again. I do better this time. I'd really like to know if it's me, or if their ai is just that whacked.

From my POV, I felt that the phone interviewers for my internship were chosen arbitrarily (mine were from New York, when I was trying to get a spot in the Mountain view campus).

The reasoning appears to be that you're either good enough or you're not, and that it doesn't matter who interviews you for that to be true. However, the difficulty was really variable: interviewer 1 asked lots and lots of algorithms questions which I wasn't doing well on, caused him to become obviously annoyed with me. 2 seemed fairly ambivalent throughout. 3 really worked with me to try and get answers out of me (even though I was incredibly nervous).

I don't see why phone screens are not with prospective teams; they're the ones that will have to deal with you and have the best idea of what skills they need. Maybe they're trying to avoid people building up little fiefdoms? I generally came out feeling the way you do (and the way the OP does). It seems random, and for a company that (rightly) prides itself on the quality of its data and making data-led decisions, it makes it sting doubly.

     The problem is that they do the exact same thing for people that they reach out to.

As someone who does technical interviews for a technology company, your "they"s have two different antecedents.

HR goes through resumes and reaches out to people. Engineering does technical interviews. I my experience, I have seen very low correlation between "HR liked this candidate" and "candidate was good."

A few keywords in your resume will get you reached out to by the vast majority of recruiters. Those same keywords do nothing for the guy asking you to solve a problem on a whiteboard and finding your answer wanting.

I went through the Google process too and it didn't come out nicely.

First, I have had almost no actual CS lessons in my university, because it was more focused on general engineering and IT management than on code writing.

However, I've done quite a bit of code in various open source projects and I've touched quite many technologies...

I went through the sets of interviews, and I really seemed to work quite well, even if many design-patterns where unknown to me (I didn't know their names). But the last one wasn't the best one.

Therefore, I got the mail telling me that they got no positions for me, which I understood and accepted easily (I had another engagement at the time).

However, I dared to ask "why?". Was it my technical skills, my personal skills, my logic skills or the way I answered the process, the cause of my rejection?

They refused to even discuss about it, which is not even reaching the minimum of politeness I expect from a company. When they asked if they could keep my Resume, I told them to go away...

This recruitment process does not seem enough respectful for me and gave me a very bad opinion of the company.

Some companies refuse to discuss that on principle as a way to protect themselves from lawsuits. So you shouldn't take that too personally.

Since they doubtless treat everyone that way, I guess you're technically correct that it shouldn't be taken personally.

But the fact that it's only "[s]ome companies" that do that still suggests that it's rude and unprofessional behavior.

In my experience, it's not some. It's all.

In my experience, Google was the only one.

I only said "some" because I can't speak authoritatively on that, but I suspect it's the overwhelming majority.

Sure, some of them don't, but then I don't want to work with such kind of companies...

And, sure, I don't take it personally :D I just don't like this behavior.

I didn't ask for details, just a general idea.

I've done a fair deal of job interviews, in order to get this kind of feedback and improve my skills; and Google was the only one that was that little polite on the feedback (even MS was nicer)

They didn't even say: "we can't tell you because of general policy or because of fear of lawsuit"...

I went through a phone screening with them recently, and they had a first phone interview set up. But the more I thought about how the screening went, the more it irritated me. I would not have sat through that were it not for the "Google" label. I decided that label or no, I have better things to do with my time than play "20 questions" where you're not allowed to use reference materials. That's not how I work at all. So I politely let them know that at the present time, their firm had been declined an opportunity to work with me, or something to that effect.

I found this interesting because I went through part of Google's internship process not too long ago.

If you're just a sophomore, you shouldn't feel bad about not getting an internship at Google.

Another reason not to "feel bad" about it is that AFAIK the people interviewing you just take notes, and then other people review those notes to decide whether or not to take you. So the people you interviewed with weren't even the ones that made the decision.

Perhaps for the C program, you should have done something simpler than a binary search, at least to begin with. The way you described it, they didn't require you to do a binary search.

I've often hated writing implementations of searching and sorting algorithms with someone looking over my shoulder.

I think it tests specific knowledge of an algorithm more-so than anything else.

To be fair, binary search is pretty simple. It's not like he was asked to code max-flow (e.g. Ford-Fulkerson) off the top of his head.

The problem I'm sure, was being rusty at C, not the algorithm implementation. I make all kinds of silly mistakes on the whiteboard if it's with a language I haven't used for a while.

Lucky him, atleast he got to face tech interviews. As for me I never got the chance to prove myself.

I got my call, was inquired about my projects and current offers by HR and then got a rejection letter next week. After I inquired, it turned out that my low GPA [ 7.03/10.0 ] was the cause. They want academically bright freshers with shining GPAs and with strong CS101 skills.

This was exactly my experience. Everything from the two technical interviews with the addition of a third to the technical questions with queries about bugs in the code. I think 2->3 conversion is exactly what you said. The first two interviewers split on their opinion of you, so you get scheduled a tie-breaker interview. Unfortunately for me, the tie-breaker interview was my worst, partly due to me and partly due to non-existant feedback for 45 minutes on the part of the interviewer.

But, I believe there is a method to the madness. They have so many qualified applicants that they would rather err on the side of caution. They would rather reduce the false-positives even if the number of false-negatives grows. They can afford this luxury. They want the best and they can afford rejecting good candidates.

My favorite way of thinking about this was from Steve Yegge's blog post about the interview process : "Because of the inherently flawed nature of the interviewing process, it's highly likely that someone on the loop will be unimpressed with you, even if you are Alan Turing. Especially if you're Alan Turing, in fact, since it means you obviously don't know C++"

With a process like this (based on this story as well as others), does Google actually consistently employee competent talent? Obviously Google has landed some serious rock-star talent, but of the scores of college graduates they hire for internships or entry-level positions, does anyone know if their hiring process is working for them?

No.

They employ a lot of people that can write code on boards, and can certainly churn it out at high velocity. But when you start looking at the actual code... it's bad. When I first looked at the chrome code, the layer they dumped on top of webkit to make it out-of-process, the only thing I could think of was "this looks like something a kid fresh out of college would cobble up together". Same thing with most of their projects - lack of clear design, hacks, hard to maintain, lack of standards, no portability. The projects that get visibility end up getting better (more competent programmers assigned to them), the rest lingers in crappiness mode.

They're not all like that, obviously. They have very smart and very competent people there. But the general low quality of their code, the lack of polish in their products, it clearly shows the consequences of hiring people based on how fast they can dump code on a whiteboard.

Hmm. I had a very different experience. Most of the Google code I've seen them release is very, very high quality, like the Guava libraries: http://code.google.com/p/guava-libraries/

     given two full hours and any high-level language 
     (including pseudocode) only 10 percent of professional
     programmers implemented binary search correctly, 
     according to Jon Bently.

Wow!

I'm not particularly intelligent and I'm not in the top 10% -- but I could implement an in-place quick-sort in C in 10 minutes that my interviewer could run with only a minor fix (forgot a semi-colon), and I even described the parallel version with OpenMP (although there I got the syntax slightly wrong). This was for my interview at Adobe, when I got hired by them a couple of years ago; went on to other things since then.

By that logic that should place me in the top 1 percent ... but so are my ~ 100 friends that are also software developers from my city, and statistically speaking, something smells like shit in those statistics thrown around.

Maybe binary search, when discovered, used to be a hard to understand problem, but now it is taught from high-school. And sure there are lots of idiots out there, but many of those idiots also believe they are in the top 10%, because some statistic told them so.

So cut the crap and build stuff. Only by that metric you can prove yourself.

-- EDIT --

I'm not referring or addressing the article's author directly. I'm also not saying that you SHOULD be able to implement binary search, or quick-sort or whatever metric du-jour -- in interview conditions. I get it that you may be stressed by eyes watching you, or that you may be bitten by edge-cases other people haven't noticed for years.

I'm referring more to these metrics flowing around -- like, if you read HN you're in the top 5%, if you read this stupid blog you're in the top X%, if you can implement binary search ... etc, etc...

We are software developers, mathematicians, computer scientists -- surely we understand selection bias and should be able to recognize bullshit, even if it doesn't appeal to our ego.

Don't be so pompous. Most people know how to implement it, it's not a difficult concept. It's just that there are edge cases and intricacies of implementation that yield bugs.

The quote I'm referring to mentions pseudocode, which makes integers overflowing and stuff like that irrelevant, since that's dependent on the integer representation you're using.

It depends on how the test was given. For example, did they ask you to write quicksort == you submit a version and then they grade it. If so I can imagine a lot of little mistakes... from the integer overflow issue (if they did pick a language), to off by one errors, to not handling empty lists, or the case where the item isn't in the list, or other errors that if someone were to say, "it doesn't work with this input" you could easily fix it, but if not given a chance for correction many could easily get wrong.

It's not integer overflow that makes the problem difficult. It's off-by-one errors in the predicates (< vs. <=) and indexing operations (n/2 vs (n+1)/2).

@haberman, I've edited my initial post.

Not arguing with you as that gets many good people during interviews. But I'm going to provide some anecdotal evidence to the contrary ...

In binary search this problem comes from the length of an array, which is either odd or even, and then you're doing a division by 2, which should trigger alarms in your head all over. And just as when you were taught in your first CS class (either high-school or college) you pick 2 simple examples for both cases, and test with pen and paper (tools provided during any interview).

When I did interviews from the employer's side -- the people not doing this were either totally unprepared, failing most other questions, or brilliant (and lazy) people that considered the problem too easy to bother checking the implementation.

Surely, put into context it can provide a valuable filter, but it's not saying much about the top X% of the talent pool, which my post was about.

Thanks for the clarification on your post. I agree with the whole statistics being thrown around being a bit ridiculous.

Not that strange actually, as others mentioned, edge cases, etc.

http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

Ive choked on some very simple programming problems in circumstances where I am being closely watched. I need to be by myself to think about problems and attack the problem incrementally. Somehow having an audience seems to force me to attack the whole problem at once before writing anything. In short, I don't know if my experience is unique but there might be other programmers who under perform when being closely watched.

I sometimes just completely fail to function at a whiteboard. I've choked to comedic proportions on problems I'd solved easily only a few days before. There's not a doubt in my mind that my resume's been thrown in the "Non-programming programmer" pile due to my stage fright at least once. I can certainly sympathize with the need for a low false-positive rate, but as a candidate I can't help but wish that overcoming stage fright wasn't also such a prerequisite for working with good programmers.

There was a post a while ago on HN about how a very large of the people applying for a given job are in the bottom fraction of the total talent pool. Essentially, the good people get hired quickly (or are never looking for someone else to pay them in the first place), and don't apply for lots of jobs, whereas the people who don't get hired keep applying for other jobs, thus stinking up the statistics.

There was a post a while ago on HN about how a very large of the people applying for a given job are in the bottom fraction of the total talent pool.

The HN post led to this perennially popular article from Joel on Software:

http://www.joelonsoftware.com/items/2005/01/27.html

That's the one! Thanks!

I think you underestimate how mindblowingly awful many people who call themselves programmers actually are.

Jeff Atwood references a good example: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

The sad truth is that many people who program professionally simply cannot so basic programming tasks. If anything, I think top 10% might be overestimating how many can do it - I suspect 10% might have some kind of idea of how binary search would work, but most of them will fail with edge cases etc.

Agreed. Saying because you can do <insert easy/trivial task here> you are in the top X percent just means that the rest of the (100-X)% are incompetent. Being "above average" isn't really saying much when the average is dismal.

I'm surprised by the rapid succesion of the interviews. When I applied for an internship at Google, I think the entire process lasted about three months until I got a final acceptance email. Only had 2 technical phone interviews spread over a month period and they were both decisive (aka if you failed the first one, you didn't get in the second one).

This was quite a contrast to my Facebook experience, where I had a contract signed after I think 3 weeks. :)

I'm really quite surprised that binary search is considered difficult, have you ever tried to implement quick sort? I can write AVLs with less bugs than quick sort.

I feel for you - my advice is not to let it get you down.

I think an important factor in these interviews is the emphasis on talent in software development. Don't get me wrong - I don't deny its importance, it's more that I question the nature of the beast. To me talent is instinct, a feel for what you're doing, and the 'right' type of thinking for the thing. It's pretty obvious when somebody has it (or doesn't), and I think obvious whether you have it too if you're honest with yourself about it.

Tech interviews emphatically do not test for this. Nor do they, I believe, test for smartness; I think once you hit a certain level of intelligence the rest is far more preparation and experience (and yes I'm getting Malcolm Gladwell on your ass) - so all a failed interview indicates is (assuming you are an at least moderately talented, moderately intelligent candidate) one or more of the following:-

* Lack of preparation (knowing the stuff, and practicing the stuff)

* Poor/incorrectly focused preparation

* Lack of confidence

* Bad luck - e.g. haven't looked at binary search for x years they ask about it, or what Steve Yegge termed the 'interview anti-loop'[1] - basically the guy interviewing you just doesn't like you and that's that.

The biggest problem with these things is that people (and I'm kind of talking to myself here more than anyone) take these things personally and put it down to some idea of talent that you might just lack. Fuck that.

The problem is that - and I'm risking repeating a well-known cliche here - hiring good people is extremely hard, and a false positive is way more damaging than a false negative. It is right, IMHO, that (good) companies probe algos, os fundamentals, etc. as this stuff matters; however failing an interview emphatically does not mean you suck.

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

In regards to your comment about their recruiting speed, I wanted to chip in. While not Google, I interviewed with meebo and went through three phone screens as well within 1 week, and they flew me to Mountain View within 2 weeks -- by far THE most efficient interview I have been through. Great people.

I cannot emphasize enough how much more awesome it makes your company look when you have a streamlined recruiting process!

I would not appreciate a candidate spilling the beans on what we ask in our interviews, even if he didn't sign an NDA. Sometimes you do ask similar questions, and it's a waste of everyone's time when the candidate in front of you went through some programming interview books and a bunch of blogs like those.

Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere.

There are quite a few people out there who would enjoy working out on interesting questions. If you already know the question or have solved it previously you just give the solution and admit it that you had seen it earlier. But more importantly its about the thought process and how you got to the answer.

"Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere." - Well there are gazillion blogs and books written on technical interview questions including by ex google, msoft and apple employees. So is it really that bad that a sophomore student decided to blog about it for the benefit of fellow students.

It's bad for the same reason that leaking a midterm you just took for the benefit of fellow students is not helpful for those trying to conduct a test.

Having read a plethora of stories about the Google interview process over the years, from interns on up, it seems like it would be easier to build a company and sell it to Google than to get through the application process. Surely someone has done this at least once, given the number of companies Google has purchased.

Given the input and output, why isn't a linear search a proper solution?

Because linear is O(n) and binary is O(log(n))?

Oh, sorry - didn't notice that was a requirement.

I don't think it was an explicit requirement, it just would be very wasteful to do a linear search on a sorted list.

  > I got an internship with The New York Times
  > the following week.

Did the internship involve 41m$ in compensations and the instruction to build a pay wall secure enough to fend off toddlers?

In any case, well done. Technical interviews are hit-and-miss at any stage in your career, although I have to say that a coder worth his salt should be able to code up a binary search in no time at all. Even a college sophomore.

I have applied there for a fulltime position. I got a friend at Google refer and an HR called my immediately to set up a phone interview. It went well and they flew me in for onsite. After more than a week, they sent me an offer after the quite rigorous background check. The whole process takes about 3 weeks. Even though, it's not as fast as the company I will join (took them less than 2 weeks total to get me an offer) but I don't think Google process is slow.

Reply on news.ycombinator.com