And then you could've been just cool all about it: http://www.businessinsider.com/facebook-rejected-whatsapp-co...
This. @brianacton's response was super classy.
Google: 90% of our engineers use the software you wrote (Homebrew), but...
671–680 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#672IMHO, I don't think it requires any practice to be able to invert the binary tree. It is so trivial that it only requires a very basic level of programming skills. I agree whiteboard is generally broken, but for this particular case, I don't think Google is doing wrong. We can think another way, if some company hires people based on his reputation instead of the ability of doing actual work, I don't think it will survive. In this particular case, you just didn't show your ability of doing actual work, that's it. I am glad to see that Google prefers ability of doing actual work to reputation.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#673Earlier quoted context omitted.
The slogan represents the opposite. You hire only 10% of the good candidates but the odds of hiring a bad candidate are cut to only 0.5%.
I agree with you that if hiring strategy B led to hiring 10% of the good candidates and cut the odds of hiring the bad candidate to 0.5%, compared to 100% and 1% for hiring strategy A, then strategy B is worse than strategy A. However 1) This means that by raising your hiring bar (adopting B instead of A), you eliminate more good candidates than bad candidates. You now have to prove this empirical claim. 2) All I wan…
The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy.
As long as good candidates are rare, and bad candidates have a small-but-nonzero chance of tricking you into hiring them, it's very expensive to pass on a good candidate.
Even if you pass on 50% of the good candidates (no matter how many bad ones trick you), you're doubling the amount of time you're spending interviewing.
The only way to be sure about how many "good" candidates your are missing is to hire some random percentage of the people who fail your interview. Only a large tech company would have the resources to do that, and I'm not sure if it would be ethical, or even get the employer in legal trouble.
NO employer knows how many good candidates they miss out on, which makes this analysis very difficult.
Also, I question the ability of most employers to evaluate employees AFTER they are hired, so any analysis of post-interview performance might just be reinforcing whatever biases are present.
Also, candidates fall into THREE groups: great, mediocre, and toxic. The catch is that the toxic ones are most likely to trick you into thinking they're great. That makes it even more expensive to pass on a good candidate.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#674Earlier quoted context omitted.
This has got to be the biggest hiring fallacy I've ever heard. "It's better to reject a good candidate than hire a bad candidate." That's completely false, and anyone who says that is completely ignorant of Bayesian logic. Here are some simple numbers. Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway. Every time you pass on a "g…
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 somethin…
Obligatory reference to tptacek's post at http://sockpuppet.org/blog/2015/03/06/the-hiring-post/ -- see the end of chapter 2 for an amazing example
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#675Earlier quoted context omitted.
My main complaint with the tweet is that it's almost certainly speculation. 1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason. 2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees dow…
Really? In the UK companies are legally obliged to reveal why a candidate did not get a job, if asked... in my understanding.
Huh? I've been rejected by an UK company with just "you're obviously a very experienced programmer, but "we are not able to take your application any further at this time".
I did get a code review out of it though, and it did point out a few real issues, so I'm ok with it.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#676Earlier quoted context omitted.
I agree with you that if hiring strategy B led to hiring 10% of the good candidates and cut the odds of hiring the bad candidate to 0.5%, compared to 100% and 1% for hiring strategy A, then strategy B is worse than strategy A. However 1) This means that by raising your hiring bar (adopting B instead of A), you eliminate more good candidates than bad candidates. You now have to prove this empirical claim. 2) All I wan…
The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy. As long as good candidates are rare, and bad candidates have a small-but-nonzero chance of tricking you into hiring them, it's very expensive to pass on a good candidate. Even if you pass on 50% of the good candidates (no matter how many bad ones trick you), you're doubling the amount of ti…
> As long as good candidates are rare, and bad candidates have a small-but-nonzero chance of tricking you into hiring them, it's very expensive to pass on a good candidate.
Yes, I agree with you. My point is that even taking this into account, even after taking into account all the other costs you mention into account, it might still be better to pass on candidates you're not sure about.
> The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy.
So going by the slogan, even if passing on too many good candidates increases your odds of a bad hire (say from 50% to 80%), it's still better than hiring a bad candidate, since if you hire a bad candidate, the odds that you made a bad hire is 100%!
My interpretation of the slogan seems different from yours, mine is something like: if you hire a good person the value of your business will increase by X, if you hire a bad person the value of your business will decrease by Y, and Y is much greater than X.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#677Earlier quoted context omitted.
If their goal is hiring from industry, as opposed to from schools, I think I could credibly defend an argument that they don't. (I think what they do now makes sense if they want the top of their funnel to be comprised mostly of recent CS grads, and I think that industry people with really high profiles, or that internal people really want, get to skip a lot of this evaluation.) I have a lot of respect for Google (ho…
"If their goal is hiring from industry, as opposed to from schools, I think I could credibly defend an argument that they don't. " I would agree ... if they were actually having trouble hiring from industry. IE despite everything everyone ever writes here, google simply isn't having trouble attracting enough of the right people that they want to hire (despite arguments to the contrary that they aren't hiring the righ…
I can't give you anything more than anecdotal responses to this, but Google is (a) missing (ie, failing to hire) specific excellent people in the industry, (b) cultivating a reputation that prevents people from considering them. There are bright spots, but my perception is that they work by circumventing/overriding the standard Google "backrub tickets for calibrated interviewer favors" process.
But yeah, I may not have been clear enough before: I do believe that what Google is doing is working for Google.
About the worst thing you can say for Google's recruiting as a business process is that it's somewhat inhumane, and pollutes the industry with faulty evidence (there appears to be a small cottage industry of consulting "porting" Google's recruiting process to other companies). But I mean, look at the rest of Startuplandia and Google's sins pale in comparison.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#678Earlier quoted context omitted.
You're given weeks to refresh your knowledge ahead of a Google interview. They tell you the basic CS fundamentals that are going to be covered. Binary trees are MOST ASSUREDLY on that list. They just don't have time during 45 minute interviews to let the candidate go on the Internet to look things up they should already have come prepared for. Anecdotally, at a previous company, we tried an "open book" (i.e. you can…
Out of curiosity, can you elaborate why the open book interview policy failed?
It may be that we didn't give it a fair shake, as everyone who we tried it with probably would've failed anyway, but it turned what would normally be merely failing interviews into completely excruciating situations. When Googling is an option, a lot of people were spending all of their time in the interview attempting to cobble together vaguely relevant Stack Overflow responses. It wasn't just "I'm going to look up the exact name of this library function because I don't remember it", it was wholesale Googling of data structures and algorithms.
If all someone needs is help remembering the name of a specific function, then I'd rather provide them with that if I remember it or just spot them it as something trivially Googleable. I wouldn't hold that against someone unless it seems like they're completely unfamiliar with the language they've chosen to use. There's no need to give an otherwise good candidate the chance to self-destruct over trivial details like that by obsessively Googling everything to make sure it's exactly correct when that's not what I care about, and in so doing they aren't paying as much attention to overall algorithmic details, which I do care about. If they need more help than trivial Googling, then they can't solve the problem anyway, and me watching them thresh around on the Internet isn't helpful to anyone.
A good analogy is laptops in classrooms. A lot of students will attempt to use laptops to take notes, even though they inevitably serve as a distraction, and study after study has confirmed that students actually learn better when they take handwritten notes. Somewhat paradoxically, studies of classes where professors have banned laptops and forced handwritten notes show higher student happiness; they're aware on some level that they're more engaged with the class and are learning better, and appreciate that the choice to distract themselves is removed, because if the choice were possible, they might not be able to exist. Well, providing someone access to Google in a coding interview is very similar to letting students use laptops in classes, in a lot of ways.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#679Earlier quoted context omitted.
I found actually using a whiteboard, or pen & paper, is the best. No computers. Pen only. For me, rehearsing an answer works out. Then, I try to see how to deconstruct it and apply it to a similar problem I don't know. I can deliver an answer sounding confident and competent because I practiced an answer. It's a bit of a crap shoot. What irks me the most is that people are doing the interviews. They can be fooled and…
How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#680Earlier quoted context omitted.
How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
> It's about gaming the system to get a job. When you are in a position to hire other people, you can worry about a less awful method to select candidates.
That's true. I have other features that reduces my chances of getting hired, but doesn't eliminate them. Still, I wish I had someone else's mind.