Earlier quoted context omitted.
...or knows how to download such a thing and run it.
Such a thing doesn't exist, but besides, why not spend 30 minutes asking about what challenges they dealt with at their job instead? If they can't talk about what problems they solved, they probably didn't solve any.
Google: 90% of our engineers use the software you wrote (Homebrew), but...
661–670 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#662Earlier quoted context omitted.
Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview…
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…
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#663Earlier quoted context omitted.
"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, e…
> 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. What's to keep a good engineer like you describe from buying a couple of books and spending a couple of months working on becoming the type…
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#664First a little deduction. Let's try to be explicit about the theory behind this technique.
It's safe to assume that the job will NOT consist mainly of cranking out binary tree inversions on whiteboards while being watched over. So obviously we're hoping to make a correlation with something else. Assuming the candidate was not tipped off and learned this particular puzzle, perhaps we are correlating to an ability to rapidly create novel solutions of long-solved algorithms without reference tools.
But is that what the new hire will be doing? Probably not.
We could continue down this path, identifying ever more removed correlations until we get to something that the job actually demands. This probably involves solving hard problems like naming things. [1] But by now our theory stands on pretty thin ice indeed.
In any case, all of this deduction is theory making. It's not knowledge until we attempt to falsify [2] it via induction. The human mind constantly induces hoping to verify our deductions. We reason, observe, conclude and repeat. We're good enough at it to survive, but that's about it. Lucky for us, science came along. Today's technical hiring is at best alchemy.
A interesting company called TripleByte [3] is trying to apply induction (first for YC companies). They specially shun on white board coding and puzzle solving tests in general. I will be interested to see how they fare and whether their learnings are adopted more broadly.
[1] http://martinfowler.com/bliki/TwoHardThings.html
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#665Has no one stopped to question what Google may have been looking for in a candidate? The OP has written some great apps, sure, but there is a huge difference between writing a package manager for Mac (among other Mac/iOS apps and utilities) and writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc... In that context, knowing CompSci basics like Binary Trees (usual…
I used to do interviews at Google, and most likely, the interview process just failed in this case. Typically a candidate will do 5 technical interviews, where the Google engineers can ask basically anything they want to (eg. invert a binary tree in this case) and score the candidate. If the candidate trips up on one of these interviews, that can be enough to reject them. The process will sometimes randomly reject qu…
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#666Earlier quoted context omitted.
Such a thing doesn't exist, but besides, why not spend 30 minutes asking about what challenges they dealt with at their job instead? If they can't talk about what problems they solved, they probably didn't solve any.
I guess everything I do is 'solving problems'. That's pretty open-ended. Maybe 'describe a situation where things didn't work the way they were supposed to/documented to work. How did you resolve it?' or something like that.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#667Earlier quoted context omitted.
Don't be silly. As hedbo says, it's obvious google just doesn't know what they are doing.
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…
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 right people or whatever).
So i can't see an argument that they do it wrong as long as it's actually working.
I expect, if it's truly broken, at some point they will, but
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#668Earlier quoted context omitted.
> 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 inc…
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%.
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 wanted to say was that the statements you made like "every time you pass on a good candidate that increases your odds of making a bad hire!" is only true under certain conditions (namely that raising hiring standards eliminates more good candidates than bad candidates), and it's not "simple bayesian reasoning".
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#669Earlier quoted context omitted.
No, it doesn't. Say I pass the invert a tree question. Does that prove I am good? That I can design a product, listen to customer requirements, come up with ideas that elude others, read a research paper and turn it into something commercial, solder a circuit board, make a schedule, mentor junior engineers, write documentation? No. All inverting a tree tells them is I studied trees recently, and/or I'm at least super…
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)
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#670Earlier quoted context omitted.
I used to do interviews at Google, and most likely, the interview process just failed in this case. Typically a candidate will do 5 technical interviews, where the Google engineers can ask basically anything they want to (eg. invert a binary tree in this case) and score the candidate. If the candidate trips up on one of these interviews, that can be enough to reject them. The process will sometimes randomly reject qu…
Then why do they put people through those extreme paces? If you have the chops to get through the Google interview process, you are not "just another developer." If I were enough of a star to get through the process, got hired, and then was put to work maintaining some internal Java tool, I'd be pretty pissed off.
As for why management continues this interview process: probably because they can. Lots of people apply to Google, and they have a high acceptance rate for offers extended. There is also a historical aspect to it: "we have hired this way in the past, and it worked, so why change it?" and fear: "if we lower our standards, the company culture is at risk" The problem of low-level SWE discontent showed up on management's radar around the time that I left, so I'm not sure if they are doing things to change that.