Live data from Hacker News

Google: 90% of our engineers use the software you wrote (Homebrew), but...

twitter.com

661–670 of 683 posts

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#661
post #660

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.

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...

#662
post #344

Earlier 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…

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

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#663
post #395

Earlier 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…

Doesn't that question answer itself? Because a good engineer might have other things to do with that time. I take my job seriously, and I'd rather devote my surplus time and energy to activities that make me better at the job I have.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#664
How can we see if this technique works? There are two methods try to know something: deduction and induction.

First 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

[2] http://en.wikipedia.org/wiki/Falsification

[3] http://techcrunch.com/2015/05/07/triplebyte/

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#665
post #70

Has 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…

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.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#666
post #660

Earlier 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.

That's what I meant by problems, things like when everything went wrong and you had to fix it.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#667

Earlier 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…

"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 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...

#668
post #620
post #575

Earlier 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%.

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 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...

#669
post #212

Earlier 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)

To show that there is a correlation you have to quantify both hiring process evaluation and job performance. Since both are elusive quantities that are hard to quantify, showing there is no correlation may just mean that measurements are done poorly. E.g. when job success is measured by boss satisfaction.

Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...

#670

Earlier 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.

Yes, in fact that is exactly what happens. Many of the people at Google who are level 3/4 SWE's (about 70% of engineers are at that rank, it is considered a junior level) feel that they are under-utilized, and there is a lot of angst at that level. Those people would probably have more important/impactful roles at other companies. Some do in fact leave for other companies, but many end up tolerating the situation as other aspects of working at Google compensate (stable, brand name, perks, etc.).

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.

Post reply on HN