What I learned interviewing with Google
wesbos.com
wesbos.com
I know all you fanboys out there will say "you need to know this stuff to be a generalist software engineer" but c'mon, hire experts in sorting algorithms if you need that for some obscure bigtable ultra-performant section of code and leave it at that.
Need another example of wasting everyone's time: "She told me they primarily hire strong C++ and Java developers, something which I have very little experience with." Gee, Google, glad you still brought him in when he clearly has no interest or background in that.
Interviewing is one of the purest Bayesian actions people do. We have to take a bunch of limited and incomplete information about a person and try to determine whether they are likely to succeed or not. Most interviewers would love to find people that are smart, able to learn quickly and well, and motivated, excited energetic. The best measure of these things isn't whether the person seems smart, or energetic, everyone is trying to seem smart and energetic and positive in an interview. The best measure is whether they were smart and energetic in the past, and the best guage of that is how deeply they learned in previous experiences. If they are a 'javascript programmer', not knowing javascript syntax by heart is a strong indicator they just kludged through without much deep interest in what they were doing.
Being unable to program on a whiteboard means you don't really know the language you are using. Relying on an IDE to prompt you every time you make an error is a huge crutch, and IDE's can only help you with obvious cases, there are many times where you can get code past the IDE as syntatically correct but logically wrong.
This is nonsense. I have a degree from MIT. I've spent the last 15 years programming in C++, Python, Scala, Lisp, Java, SQL, and JavaScript, etc. I've worked on compilers, space telescopes, and brain surgery software, and I know all of these languages fine. There's no way that I would be able to program on a whiteboard without a lot of practice, however. Most likely, I wouldn't be able to remember my own name if you made me stand at a whiteboard to program in an interview situation. Fortunately when I interviewed at Google they let me use pencil and paper.
Btw, I use Emacs much more than an IDE, and much of the knowledge I have for syntax is built into my typing fingers.
Btw, as far as I'm aware, Google didn't traditionally allow coding on paper--they always required coding at a whiteboard. As I understand it, Google Boston softened this requirement because it's rather counter to MIT culture. In four years of undergrad schooling at MIT and quite a few additional classes as a special grad student, no one ever made me work on a whiteboard, or do any kind of work at all with someone staring over my shoulder.
I have two whiteboards and a chalkboard at home; I never code on such contraptions. (I like to draw pictures for programmers, but using Balsamiq or something.)
Now, obviously if I were in a situation where showing off whiteboard-coding were useful to me, I'd practice until fluent. But it's so bizarre, this fetishization of whiteboard technology.
Maybe it's good to communicate using pictures, rather than symbols. But if that were the real reason for whiteboard interviews, interviewers would speak of pictures; not whiteboards, nor syntax. Or one can argue that companies like rely on whiteboard tech to communicate; but then why not ask prospective workers to practice it as they would vi or emacs? Or spread the gospel somehow? Is this some weird entrance test, to see if a candidate proactively adapts to this weird obstacle?
As an interviewer, I'd feel I've ironically failed a meta-test, if I didn't accomodate a significant number of people's feelings on this matter. I would therefore not be fit to judge anyone's ability to think effectively.
Is this really because of the whiteboard though? Interviewing is a stressful thing to go through, and no process is going to be perfect for everyone. I agree that in general it can be harsh on candidates who are not glib and extrovertive, but this doesn't have much to do with the whiteboard.
Yes, I have no problem at all with a "traditional" job interview. Even ones where I've been given a paper exam and then left alone for a while have been okay. Though I also find that kind of interview to be rather distasteful, I've never actually had any problem doing well on the exam. Doing well on written exams (with solitude) is a skill that anyone who has graduated from a good school probably has already been forced to acquire.
then why did you say
> Fortunately when I interviewed at Google they let me use pencil and paper
There was the occasional exam with some coding, but the coding was typically rather easy (i.e., to demonstrate a CS concept that you would have been recently taught, and practiced on a problem set) and not time pressured. There was also certainly no one staring over my shoulder.
i don't think the top comment means literally a whiteboard. i think his argument is that if you can't program relatively basic things away from a computer, you don't really know how to program.
Someone standing behind you, looking over your shoulder, might be a bit intimidating at first, but if you have your reasoning figured out for yourself, there is no reason why you couldn't speak out your thoughts out loud and let others know the way how you came to a solution.
When you would ask me how I came to the answer, I wouldn't be able to tell you: I primed my brain and then eventually a lightbulb turned on.
But doesn't this just show that I'd never come up with a timely answer? Not at all. I took many tests as an MIT student in which I got A's and which I worked in precisely this manner. I didn't know how to solve a certain question, so I moved onto another question and then came back to the unsolved question. Often by the time I did, I just now knew the answer. On other problems, I'd do work and then cross it off and start over.
I could work this way because I didn't have someone staring over my goddamn shoulder asking me what I'm thinking every goddamn step of the way. If I have to explain myself constantly, I just get flustered when I realize that I said something completely stupid, and then I can't continue with my natural thought processes.
I cannot assert strongly enough, that the process that you claim that anyone smart should be good at, does not work for me.
The first two interviews were OK, basic UNIX admin and software type questions, I could answer most off the top of my head. The third was with someone who certainly had a maths degree and wanted to make sure I knew it.
It all left a rather bad impression.
in over 10 years of front-end development for non-trivial business applications, i have yet to encounter a scenario where ignorance of bubble sort prevented me from doing my job well.
i can tell you what i value when interviewing a front-end developer - in depth knowledge of cross browser quirks and coding techniques to address said quirks (sans jQuery). someone who can tell me what OOCSS is and why it's beneficial. someone who values every pixel, http request, and div like it was their last and uses them wisely.
i don't discount the value of standard comp sci knowledge, but i get rage face if someone judges my skill as a front-end developer based on how well i answer those types of questions
lastly, ever view source of any Google app? that tells me all i need to know about their idea of a front-end development
So, its less that you know that particular subject, and more what you being able to pick it up is an indicator of.
My point is that most of the very best front-end developers I've met don't have CS degrees. So it seems unfair to penalize them for something they've never been exposed too. There are other ways to assess someones conceptual ability.
Don't you think it's better to hire compiler experts for that exact problem rather than worrying about whether some frontend dude can write his own JS parser?
After a few weeks went for an interview at their MV campus, awesome place. Of the 4 interviews of 45 minutes each and one lunch session that I had, I would say I did good in 2, fine in 1 and goofed up 1.
I did not get an offer, I had guessed that with how my interview went, but my hopes were high :-). All in all I learned new things, met some excellent people and had a great time.
I had read online about the white board process, so I was prepared for that. I really feel for the interviewers that they had to sit for 45 minutes looking at my bad handwriting ;-). The only thing that I could not understand was why when I was not being interviewed for a traditional engineering role, I was being questioned about Big O, algo design etc. The HR lady told me it would be related to the area of my work (Web development, Javascript, Open source contributions etc), but the interview at MV was not at all like that.
Having read other peoples experience with interviews at Google and the scale of their APIs, I think at some point they are looking for people who can do whatever is thrown at them and not just be bound to the technologies they know. All the CS questions they asked me, I feel they were justified to ask them, they wanted to find out if I will be able to work in other areas if need be and not just be "a frontend developer". The interview was easy, I was just not prepared to answer those questions.
Given a chance, I will do it all over again, but this time will go mentally prepared for a CS 101 interview as well.
This is probably the best piece of advice you can give for starting the job application process. Having an internal person already working in the company recommend you to HR will immediately put you on the top of the queue. At the very least, you'll get an initial phone interview quickly. This is, in fact, the only way that I've able to have successfully get in the door, at both small companies and also larger companies like Google and Microsoft.
The other option is the "career fair", but that tends to only work if you're still a student or near-student status.
Edit: Instead of down-voting, why don't you explain to me why you would want to code on a whiteboard when it's completely pointless. Might as well throw in some of those pointless questions like why are manholes round?
Whiteboard coding is good because interview questions are not about specific 100% solutions to complex real-world problems like programming usually is. Interview questions are about general problems whose solutions will fit nicely onto a whiteboard. You lose the ability to get realtime syntax highlighting, but you gain the ability to have multiple trains of thought, the ability to draw diagrams and arbitrary symbols, and the ability to point at things as you explain your thoughts to the interviewer. Do you really enjoy it when someone comes over to your laptop to ask you a question about code? Now imagine that for four hours in a row. That's what a laptop interview would be like.
When I was interviewing at Google, someone asked me a question that required me to remember some math. I did not remember it, but I knew how to derive the answer I needed. So I went to another whiteboard, talked my way through the sub-problem while drawing some math symbols, and then transferred the answer back to the original problem, halfway completed on a different whiteboard. Try doing that while hunched over your laptop.
I agree that this process is nothing like the job you're interviewing for. That's because it's an interview, not the job. We try to get a picture of who you are and what you know in a few hours, and that's just not enough time to let you loose with a laptop to see how you approach real-world problems. Not to mention, real world problems don't often involve much "computer science" knowledge. But you still need to know that so you can confidently attack problems that venture into that area.
And largely, the process works. There are very few programmers at Google that can't program. If I have an idea, I can explain it to pretty much anyone, and get good feedback. At other jobs I've had, I've had to explain thing like arrays to coworkers. That means I'm not going to get any feedback on my complex idea, and that sucks. Google is not like that, because we filter those people out at the interview.
> Try doing that while hunched over your laptop.
1. It's a good indicator of how much you know for simple problems.
A few weeks ago I started helping a friend with a particular language and framework. He claimed to know it, having read several books on it. So I said great, go to the board and write a function that adds two numbers together. And he couldn't do it. Who knows, maybe he could have done it on a computer? Maybe he would have Google'd it quickly, or relied on code autocompletion, or the muscle memory from his fingers typing it, etc. But that's not what I wanted to know. Anyone who's written thousands of functions in a particular language could write a simple one like this on a wall, using paint, while hanging upside down. His inability to do so told me: he is not well-versed in this language. PERIOD.
2. You can practice.
"So what", you protest. "Google isn't going to ask simple problems. They'll ask hard ones." And maybe they will. And maybe having to solve it in a foreign way really will fuck you up. But my question to you is: If you know you're interviewing at Google soon, why the hell would you allow whiteboard coding to remain foreign to you? If you suck with whiteboards and you care at all about getting the job, then buy one and practice solving problems on it. Why would Google want someone who doesn't care enough to prepare for their interview? It's not that hard of a skill to pick up. And I daresay it will make you a better, easier-to-communicate-with programmer.
This.
If there was one thing I could tell all applicants at Google, it's to read up on the process, and practice. There is a huge amount of information out there[1]. I feel sad interviewing really smart, capable people who could have breezed through with just a few hours of review and practice.
[1] eg. http://courses.csail.mit.edu/iap/interview/materials.php
Google doesn't solve simple problems.
> 2. You can practice.
Maybe if the interviewee was still in college they could "practice" coding on a whiteboard, but considering they may have other obligations like family and work they probably won't have time to practice such a pointless skill.
Personally, I wouldn't need to practice in the first place as I interview extremely well and could easily code on a whiteboard, I just find it antiquated and pointless to do so which was the reason for my comment - not because I am bad at it.
Google doesn't solve simple problems.
they may have other obligations like family
and work they probably won't have time to
practice such a pointless skill.
Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
The relevant job skill here would have been the willingness to do anything for the great pay and food. I wasn't and I had other employment options I chose after it became clear I would not be allowed to jump to another project anytime soon.
Day-to-day work is necessarily collaborative and productive... Whereas when at the board in an interview one person knows the "answer" and is across the table testing the other. It's a completely different set of pressures and requires different skill.
Further, I must have one of those faces people pity because its often that when I end up at the whiteboard the interviewer wants to "help" me if I don't spout off the answer immediately (I've learned to at least start talking so they will give me a second to think). This sometimes entails them trying to lead me down a path which is not the way I would have approached the problem. I'm confused, they think I'm an idiot, now I'm flustered, could this interview go any worse?
I've learned to politely ask for a second to consider and usually that completely solves the problem. I've been successful in technical interviews -- but the idea that it's the same thing as when working out hard problems with team members seems a little silly?
... will typically code better with a keyboard and
editor than someone who relies on the keyboard
and editor to be able to code
So you're basically encouraging people that rote-learn solutions and that line above is bullshit.
Startup idea: a device on which you can write code which you can subsequently edit by inserting, changing, moving around, and erasing lines
That is very subjective and I'd love to see some evidence of this.
Which brings us back to the whiteboard interview. I ask: If I am correctly interpreting what the psychologist said, why force interview candidates to use their brains differently than they normally would while coding?
At the risk of making myself look stupid, is that because of O(n) vs O(n^2) (should be testing for \0), or is there another reason I'm not picking up?
Yes they do. I've still got my Google 'Hire Squad' t-shirt somewhere (when you get trained on how to do interviews at Google you used to get a t-shirt) And they expect the interviewer to transcribe what you write on the white board into your feedback so that the hiring committee can read your notes and know what you're talking about.
You see the part you've missed here is that at Google, the person doing the interviewing has nothing at all with the person deciding if you should be hired. They interview you, using the techniques they were trained to use, they transcribe the whole thing like a court reporter, adding what color they can and a float between 0 and 4 (0 is 'run way', 4 is 'walks on water') And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.
Writing syntax accurate code on the white board is always a plus. Although one candidate on seeing the dozen different color markers, wrote both syntax accurate and colorized code. That was good for a chuckle (and strangely I think it got them points in the committee).
Doesn't most of the personality of the person get lost in this setup? I mean, hiring people purely on technical merits may sound fine, but I'm not sure if that makes for a very pleasant working environment.
I think the whole hiring committee removes a lot of biases that people may have and the end result, in my opinion, is a workplace that's a lot more diverse than any other I've been at.
There is a difference between forgetting to put a semicolon at the end of a line (totally harmless on a whiteboard interview), and not knowing that semicolons end statements in C.
Of course, not knowing say, part of the standard library, say the semantics of rand(), without a man page or Google search is much more excusable.
In all seriousness, I really don't get whiteboarding in interviews.
I code in a variety of languages and every time I use .indexOf(), I can't remember if it's (needle, haystack) or (haystack, needle). Of course, my IDE shows me the correct way and I go with it in 0.3 seconds.
On a whiteboard, if I were marked down for getting that the "wrong", I don't think I'd like to work for those kind of people anyway. I have no interest in memorizing the exact syntax of every standard library call in every language. When I can look it up almost instantaneously, my mental efforts are best spent elsewhere.
I don't care if they can't remember order of parameters, or really even the name of the methods. But if you can't write syntactically correct code without an IDE, it seems like a problem.
But I personally wouldn't dock a person if they screwed up the syntax on a whiteboard coding interview - I really use it more as a way to extend the conversation. I do have the bad habit of correcting syntax, though, because I find it too distracting once I see it.
Also, if you do interview, keep in mind you'll have to travel to MV for a full day interview and also a full day interview in DC. Which is actually nice if you have the time; the DC team is so small that they want to be selective with future team members.
The DC projects were cool too, one was google code I believe, and the other was a tool to allow the collection of data sets such as water well tests in developing Africa, etc.
Perhaps someone should take a look at your resume to find out why?
- These interviews are easy to give for someone without good interviewing skills, which is basically everyone.
- These interviews are relatively easy to score.
- Google acquires superstars through acquisition. If you need some competent rank-and-file (i.e. a "pool") to support the superstars, whiteboarding is maybe an okay way to weed out people who definitely won't rise to the occasion.
It's a little insulting, but their pay scale probably balances that out.
Regarding their interview questions, you either know it or you don't. From my personal experience, Google's rounds of questioning are intentionally designed to weed out the people who fake it or try to cram up beforehand. For software engineering, they are interested in applicants who naturally demonstrate keen skill when it comes to CS fundamentals (algorithms, data structures, discrete mathematics, etc.).
Throughout my phone interviews, Marissa Mayer's quote "A good student excels in all subjects" kept running through my head. After interviewing with them, I believe Google holds all their employees to a similar standard.
Does your NDA allow you to post these guidelines? Is so, please do.
Because they're Google. I know that's tautological, but I remember a blog post from some time ago about a guy complaining that all his friends that had been hired by Google had suddenly stopped chit-chatting about technical issues that they encountered at their workplace. They stopped doing that during the usual "at-a-drink-complaining-about-our-daily-job-ordeals" sessions, or on their blog, or anywhere else that might be publicly shared (and, why not? , maybe help other people learn from their (Google's) mistakes). The guy even compared Google with a "vortex", if I remember correctly.
HN discussion at the time: http://news.ycombinator.com/item?id=2362207
Don't do it. It's optional, you have the right to refuse. By signing you are putting a huge amount of liability on your shoulders for no reason. You're giving that company the right to sue you for practically any reason they can conjure up.
Them: We're going to tell you secret stuff during the interview. Promise not to blab? Me: Yeah, sure.
As far as non-competes and IP-assignment, from what I've seen these have gotten much more reasonable over the past 15 years. If you write or invent it on the job, it's a "work for hire" and the company owns it. What's wrong with that?
If you don't want to sign, that's fine. But there are probably 400 to 1000 other people interested in that open position, and 99% of them are going to sign the NDA.
Them: Please sign this NDA. You: No, I don't sign NDAs. Them (looking at the next guy in line): NEXT!
Yay!
It wasn't even offered to me - and this was for an engineering job. So I wouldn't say it's 'standard', even at Google. That said, I've also never seen anyone blogging about their Google interviews who hasn't signed one, so maybe they just forgot the paperwork for me!
Be very good at off-the-cuff 80% solutions to topcoder problems on a whiteboard, which I am. So much so, that when they told me to use whatever sort algorithm I wanted to, I used bubblesort on purpose, to prove a point, and got away with it. Later on, I reduced another interviewer's search problem to a polynomial equation that had integer roots when a solution existed (at which point he asked me what I'd do on an architecture that didn't have a square root or a divide function and I replied "and what modern architecture would that be?"). Which is to say their interview process is a computer science puzzle game IMO. The skills displayed here have at best a loose correlation with one's engineering skills, and that non-correlation shows up like crazy in their codebases (but Steve Yegge already covered that far better than I can).
So if you are a demo coder at heart, and you've been paying attention to whatever technologies are the flavor of the month at google interviews by reading blog entries like this (apparently javascript these days), you'll do just fine.
In my case, it only took one round for me to get the offer which I (unfortunately) accepted (but the tale of my 4 godawful months at google thanks to naively letting myself get blind-allocated into the wrong team is a different story).
Google is a great company, really it is. I know lots of relatively happy people there, but focusing on the interview process is a mistake. The real challenge is to get yourself hired onto a good team by resisting all the pressure they exert to persuade you to jump into the blind pool, which is a recipe for russian roulette. The solution, which in retrospect I smack myself for not doing the due diligence to find out, is to insist on getting allocated to and speaking with your future team as a condition of accepting an offer. Do not compromise on this point.
Later, after talking with an engineering manager and getting agreement to be assigned to one team, they tell me I'll be working for some other team as if our conversation never happened. It's almost as if the attitude is that I should be lucky to have been offered a job and I should be happy with whatever I'm given.
The time to negotiate teams is after you get an offer. If you have any sort of negotiating leverage at all, you can probably exert some influence there. Basically, multiple managers "bid" on Nooglers, and then the manager from the highest-priority focus area gets him, modulo some input from the prospective employee himself. When I was hired, I was told I'd be working on Google Search, but the recruiter also said that if I didn't like that there were multiple managers in GMail and Apps that also wanted me, and I could go there.
In general, your goal should be to avoid getting marginalized. Typically, the highest-priority projects go to the best managers, who try to surround themselves with the best engineers, so your experience will be noticeably better on a high-priority project than a low one. The disgruntled Xooglers I know typically left because they got assigned to somebody's pet infrastructure project who somehow got headcount for a team of 3 or 4 but then has no idea how to run a software development project successfully, and no support for their ideas outside of their team. The happiest Googlers tend to be people in core Search, Ads, infrastructure (eg. MapReduce/Bigtable teams), research, or Chrome. These departments tend to feature large groups of loosely-knit, largely self-organized teams, and very hands-off management.
It could actually be a good thing that you ended up getting reassigned; it usually means that someone from a higher-priority area noticed your resume and swooped in with a bid. But you should be able to talk to the new prospective manager, or at least someone on his team. Every good manager I know will be happy to talk to a prospective Noogler that they want on their team if it means the difference between having them accept the offer or not.
BTW, I've noticed an interesting pattern where the culture of a focus area depends a lot on the first employer of the founder/SVP for that focus area. Search culture is Stanford culture. Chrome (which started from a bunch of ex-Firefox people) has a very open-source culture. Android culture is Apple culture with some Googliness thrown in (Android founder/SVP Andy Rubin worked at Apple for his first job). Google+ culture bears an unfortunate resemblance to Microsoft (Social SVP Vic Gundotra previously was in charge of .NET for Microsoft). Apps culture is a hodgepodge from various other companies (most apps were acquisitions). Infrastructure culture bears a strong resemblance to Bell Labs culture (former infrastructure SVP Bill Coughran was a VP at Bell Labs). I suppose the resemblance makes a lot of sense, and I wonder if other large companies have a similar effect.
It is amazing how quickly a company's ecosystem can change when you bring in a big name from a different environment.
Unfortunately, two days into working at google, I was informed that my entire team was going to physically relocate in a few months and leave me with an 80-mile commute each way. So I said that was unacceptable and ended up with the third project, which I've already described elsewhere.
Do not let them do this to you. Hang tough.
ARM?
What did I win?
well, you can reduce any computable problem to that form
Whether it is a fast algorithm depends heavily on the sizes of the first and last coefficients, as you have to factorize them.
You should have gone with bogo sort to really stick it to them :) (http://en.wikipedia.org/wiki/Bogosort)
"Next step - we sort it".
"How?"
"It doesn't matter. You just sort it. I'd use the inbuilt sort function".
"OK, but we still want to know you can sort a list."
"OK ... sigh ... what algorithm? Quicksort? Bubblesort? Mergsort?"
"We don't care."
"Um, OK, if you want me to roll my own sort algorithm, but don't care about performance, let's do it this way ..."
The best alternative I've heard about is something like a trial period, internship, or culinary "stage." That's a big investment for both parties to make without even finding out if someone can write and debug a simple program to solve a well-defined and familiar problem.
This is kind of silly, and the candidate decided to be a smart-ass and rub it in by demonstrating a really bad algorithm.
They should ask "well, what do you think the trade-off should be? Given that, what's the best algorithm you know for this set of trade-offs?".
Interviewing is hard to get right, because it's confrontational. Bad candidates want to fool you. Looking at the total system, the best bang for your buck is getting better candidates to apply. I've met very few managers who do anything other than a piss-weak job at getting good resumes onto their desk. They often throw a rough job description to a some liberal ars major in HR, who puts the ads up then tries to prune down the candidates who's buzzwords don't match the requirements.
There've been times where I've had a candidate code up a solution and I didn't care whether he got the solution right or not. Because other interviewers had already given him coding & algorithm questions, and I figured their feedback would show whether or not he could do that. I was looking for familiarity with JavaScript language features and DOM APIs, and how he approached a vaguely-specified problem and what design choices he made. That was the part that hadn't been tested in earlier interviews.
Interviewing doesn't have to be confrontational. When we're trained, we're told that our job is to get the candidate to show us their best side. That aligns with the interests of both good and bad candidates. It's just that good candidates will be able to show us a really good side, while bad candidates simply don't have that ability. Then it's up to the hiring committee to set a really high bar and only accept candidates that have demonstrated it.
My answer: I'd change the hardware
Also, they need tools to help them develop different sorting algorithms and link lists. Plus they are having trouble with binary trees, but link lists and bubble sorts are their number 1 priority!
Instead of more advanced performance modeling, they want to use this non-sciency thing called Big O notation. Once they write a Big O notation on the IDW(Integrated Development Whiteboard) they expect it to go that fast. If it doesn't go that fast... they just chuck more servers at it (we supply their servers too, so Big O makes us happy).
They also want us to provide them with flannel shirts and dr martins for uniforms. They say that 90s clothes help them with their interviewing techniques, because it helps them remember how interviews were done in the day; when they were edgy.
So why is this completely unrelated activity so important for measuring football players? Because it takes ten seconds to measure, and a guy who can run a 4.2 forty can almost always play pretty damn well.
Tech interviews today are a low cost way of getting a rough idea of ability to code. Judging from Google's output, it's pretty damn effective for them.
Similarly, coding algorithms on whiteboards doesn't tell you much other than how good the candidate is at coding algorithms on whiteboards. Given that the vast majority of their revenue comes from either search (which was built over a decade ago) or companies they've acquired, and the numerous well-hyped failures (Buzz, Wave, +, etc.), I don't think it's actually working all that well for Google either.
So is it more likely that Google is filled with idiots that can't see the err of their ways, or that, across tens of thousands of individual hires, this is the most cost effective and produces the best results (minimizing false positives) on average.
College-admissions style interviewing just doesn't make sense for a company like Google.
FWIW, there are a couple edge cases (like javascript/frontend engineers) which my company (Facebook) has completely separate hiring tracks for. It works for us, but I'm sure Google has its own reasons for not doing that.
The players invited to the combine are the ones teams are considering drafting anyway; all the 40 times do is move players up or down the list by generally small amounts. The point isn't that 40 times are useless, it's that they provide very little additional information about a player. Champ Bailey was going to be a high draft pick no matter what he did at the combine, and everyone already knew that Trindon Holliday was fast but probably too small to succeed in the NFL.
Likewise, someone with a 3.9 from MIT or a bunch of good open source work who's coming for an in-person interview is already qualified, and the whiteboard doesn't tell you anything new. I'd guess Google sticks with them for the same reasons teams tout 40 times - it's good marketing both internally (making decisions seem less arbitrary) and externally (look how tough our interviews are is a more socially acceptable way of saying look how smart we are), and it allows people to deflect blame if a hire doesn't work out. Judging by the number of posts about Google interviews I see here and elsewhere, the marketing is certainly successful.
Also, I think your view of the interview pool is somewhat skewed. Most of the candidates I see do not have 3.9s from MIT (BTW, I believe MIT has a 5-point GPA, so it really would be 4.9), and a lot didn't go to Ivy-League universities.
I'm kinda curious what it'd look like if you took the 2002 version of Google and used it on today's Internet. My guess is it would feel incredibly dated and virtually useless because of spam. We have a couple archived UX studies that were done with the old (pre-2010) UI; I remember that when we launched everybody said "Eww, I hate the new UI. Why change a good thing, Google?" and now when they look at the old UI they're like "Omigod, I can't believe I ever managed to look at that. It's like something straight out of 1998."
That's a pretty fantastic hit rate, especially given how rare it is for any draft pick to work out. Similarly, if Google tries a bunch of projects of which only 10% are expected to work, but 20% of them end up working, then they still did a great job even though 80% of their projects are failures.
For instance, 225# reps, vertical leap, reach, etc (all NFL combine measurements). Great, you are measuring and ranking, but are you doing anything meaningful? Are you actually looking at the right things? Probably not.
If they were, Wes Welker, Tom Brady, Victor Cruz (all in the past superbowl) would have been first round picks, probably top 10. Not undrafted, or late round picks. And JeMarcus Russell and Ryan Leaf wouldn't have been drafted #1 and #2 overall (all the physical tools but not the mental - flame outs).
The point is that we as people tend to think we know what to measure and track, but we likely don't. Frankly, we are probably making it up on the fly and we convince ourselves and others that these are good measures, and until someone figures out the next best thing, they actually are. But, as I said, they are probably not the best, or maybe even good, in the infinite wisdom sense.
But, think about it this way. Both football and programming have ways we can actually see if someone can do what they say that can do: literally, look at the film. Look at game day film on a player. Look at github or other places for programmers. And, just like with football players, give them REAL scenarios that test their ability to think through a problem, in real time. Do the same with a programmer. Put these two together and you get rid of the people who can't think (Russell and Leaf) and you get rid of the "physical specimens" that can't play (Most any Oakland WR drafted under Davis).
I personally think this is a much better way that weeds out the most people. Refine your questions and technique and you can spot the people who can and can't perform pretty quickly. If you are unsure, give them a simulated game (programming problem at home) to see what they can do.
The 40yard is a better metric of the ability to change directions and accelerate.
Working on a whiteboard is definitely a skill, but one that's worth developing if you plan to work with others on a complex project.
That said, they really shouldn't have been giving this guy standard CS questions. Sure, you want to make sure that he understands why writing his string concatenation loop the wrong way will result in O(n^2) behavior, but he was interviewing for a front-end position.
There are also a bunch of algorithmic questions that come up in the browser as well, because unlike a lot of sites, Google actually cares about latency. You often can't use a library function if it involves pulling in a 300K library, nor can you write an O(n^2) algorithm if it involves locking up the browser.
Newer numbers would be good :)
[1] http://www.yuiblog.com/blog/2007/01/04/performance-research-...
That's because today a term called 'Productivity' has become massively more important than any thing else. Its something like this, Lets say there is an archer. He can shoot the red dot 9/10 of times with his bow and arrow. You take away the bow and arrow and give him stones and ask him to match the same 9/10 hits on the red dot. Guess what, he won't be able to, May be with time he can. But for the time being he can't.
What does this say? Does this mean he is a bad archer? No. Tools and their usage is part of the trade.
No skill can be tested in Isolation.