Comment by kenrikm

Those are simple numbers, but they don't get at the real issue. People say that because 1 bad hire can have negative effects on the whole team, causing others to get less done and leave. Missing a good hire doesn't poison your team.

> Counterintuitively, if you pass on too many of the "good" candidates, in your overzealousness to reject bad candidates, you're actually INCREASING THE ODDS OF A BAD HIRE.

Yes, but what hiring managers are doing isn't passing over candidates that they know are good, they're passing over candidates that they're not very sure about.

> Because "good" candidates are rare, every time you pass on a good candidate that increases your odds of making a bad hire! This is simple Bayesian reasoning!

Similarly, of course this is true, but again hiring managers aren't passing up candidates that they know to be good, they're passing up on candidates that they're not sure about, whom the acknowledge could be good.

Under certain conditions, every time you pass on a candidate you're not sure about, you decrease your chance of making a bad hire. The conditions are that increasing hiring standards must weed out more bad candidates than good candidates.

Let's work with your model. Suppose 1% of candidates coming for an interview are good and 99% are bad.

Hiring strategy A manages to hire all good candidates it interviews, and 1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 1 good candidate and 1 bad candidate.

Hiring strategy B is more conservative and hires 50% of all good candidates it interviews, and 0.1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 0.5 good candidates and 0.1 bad candidates.

The claim is something like, the team produced by strategy B is better than the team produced by strategy A, even though team B has less good candidates than team B.

This is not about numbers.

A bad hire can easily cause more friction than if nobody was hired at all. Net effect for the business is negative. You're also probably severely overestimating the likelihood of a bad hire going through.

Not really. The population is large enough that you're treating each potential hire as a random variable. Given the amount of possible good new hires the effect of passing on one actual good hire has negligible effect on the next potential hire.

The theory behind the "raise the bar" argument is that obviously good hires are easy to spot (this is the part most people reasonably take issue with), so people who do not pass that bar of "obviously good" aren't worth taking a risk on. The conclusion is statistically reasonable if you accept the premise (which, again, you probably shouldn't).

The difficult thing with hiring bad candidates vs not hiring bad candidates is that you get to experience the bad hire every single day, so it is quite apparent that you made a mistake. With not hiring a good candidate, you don't really know what you were missing. You may just assume that the best applicant you reject is no better than your average employee. But there is a chance that that person would bring something to the table so unexpected that you can't even imagine the world that would have been had you hired them.

Apparently you hadn't been recruiting anyone in Europe. Once you've hired a bad candidate, it is very hard to get rid of it (borderline impossible in Scandinavia, for example).

You're conclusion rests on the numbers you start with, those aren't a given.

I understand your point, and I'm not trying to be a troll.

Humans are more complex than that. I don't think you can assume that candidates will perform the same all the time. Sometimes an excellent candidate can perform badly for multiple reasons (e.g. nervousness, poor preparation, bad interviewer, personal problems, etc).

It seems to me, that rejecting a good candidate, and have him/her interview again after some time, if that candidate was a 'good-hire', then it would increase the chance of hiring him/her, since it is most likely they will prepare better, and know what to expect.

I agree.

I recently interviewed for a security engineering position at a startup, and while I got offered the job, the interview was quite silly.

The first thing I was asked to do was to write a lisp interpreter. It was a pretty trivial task, but it left me scratching my head since not only did it not tell them about whether I would be qualified at all, but I had explicitly avoided writing parsing code since I found ANTLR during undergrad.

In the end I wrote a basic stream abstraction and wrote my lisp interpreter on top of it with no real difficulty, but it was a completely stupid question. I told them on the third interview that they weren't asking me anything relevant and I still got another question later on about how to iterate over a tree in a specific order.

Part of the issue was that most of my interviewers were fresh out of college, it was literally their first job and they had no idea what to ask besides the kinds of questions they had been asked in their own interviews.

That's a great point.

Infatuation with "coding competitions" and high flux intelligence tasks is often an anti signal.

Sure, what they demonstrate looks good at face value, but unless you attach a micromanager over their tasks, they'll constantly deviate to the new-shiny every week instead of staying on task for the long haul.

I know even YC has been bitten a few times by accepting people who are top-performers in very narrow contexts (e.g. people obsessed with winning coding competitions every single weekend) only to see they can't do anything coherent for more than a week at a time.

Just because someone is great in a narrow context doesn't mean they can carry that over the months and years needed to deeply iterate (and suffer through the low points) on successful projects.

That's not what the interview process is like at all.

They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply.

It's not like they get you in a room and ask you to draw a linked list or a binary tree.

I think what Google tries to find are the engineers with creativity, skill and ability to work intelligently at a problem which they haven't seen before.

It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.

They have publicly admitted there's no correlation between their hiring process and outcomes. I'm not even clear [why] we're still debating this.

Other than to wonder why they still haven't done anything about it. (I interviewed there ~8 years ago, pre Android when they were looking for deep mobile expertise and got flunked out on a similar problem. I am not at all interested in working for them now)

None of the things you describe are part of the job for a rank and file bigco engineer. They already have filled all the leadership roles.

"filter out a bad hire"

Good teams have a balanced skill sets I've found. You need some uber-algorithm guys who can pass questions like this, but you also need engineers who can fill in all the rest of the tasks that make up a production worthy system. I have not found that the uber-algorithm guys always pay attention to detail, put in good comments, think of all the edge cases, communicate well with outside teams, etc.

Those types of engineers are what you consider a "bad hire", and won't be working at Google.

"they can afford to have strong filters which will definitely filter out a bad hire, may be at the expense of rejecting a good candidate"

Can they, though? Obviously they believe they can, but are they correct?

Google's not going away any time soon, but they could easily slip a long way down from the top of the heap. There are signs that's started to happen.

I don't think they can be nearly as casual about losing top candidates as they seem to believe. In five or ten years we'll know, I suppose.

>>However, in the recent years, I have seen this to be not working as expected.

It never worked, what do you think happens when you start asking these kind of questions in interviews? People just go out and spend insane amount of time memorizing solutions to interview questions on the internet.

They continue the same after you have hired them. So their on the job productivity remains low. Please note, they need to prepare for their next job in the current one.

So the only thing this results is in people spending insane amount of time preparing interviews doing very little work in their day jobs.

Triple up-vote for this. That said, As said before, I would say if they get more applications than anyone else, their pool of possibilities is larger, so, even if their hiring process is sub par, it's still possible to get more better people. They have a lot of good people and quite a few really good people. And, likely more of those really good people. Someone has done the numbers. It's a question of efficiency and maybe one of those smart ones is optimising it. It's quite possible that the process that looks shit on the outside is producing the right numbers.

Wait, only two strong online services? I can think of like five other excellent services including a maps site that is years ahead of the competition.

It's probably a pathological case centered around the mountain view office: https://news.ycombinator.com/item?id=3473308

Because there's no such thing as "the top 0.0001%". Software development is a collection of talents with multiple basis vectors, not a single linear talent you can stack rank.

And even if there were such a thing, you're not going to find the top n% by asking questions from an undergraduate textbook.

And you're certainly not going to find them by pissing off people with proven practical achievements. Acting like that is evidence of anti-intelligence, not a sign of being smarter than everyone else.

Do the math: 0.0001% of 7 billion is: 7,000. How many employees does Google have? Not to mention the fact that of those 7 billion, probably at least 6.9 billion have no appreciable training in software development, which would leave you with 100 candidates.

Primarily my inability to spell naiveté.

It's one of those "gift/curse" things. It's good they can challenge assumptions, but they don't realize how wrong they are when they are wrong.

There are some notes at http://www.amazon.com/In-The-Plex-Google-Thinks/product-revi... and it's also drawn up nicely in the book itself.

especially funny with another meaning of word "workers "

I thought Go was initially a filler project to keep the new hires going with some busy work, but they were too afraid to tell them, and released it. Hence the missing generics.