Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

571–580 of 683 posts

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

#571

Post by grahamar »

As someone who struggles to learn by rote as opposed to learning by practical means and has been both hired and declined by the Google recruitment process. I can't help but agree with his sentiment.

The recruitment process (at least for experienced engineers) should be little more then "can I work with this person". The 6 month probationary period that follows the hiring process should be used for "can this person do the job well". But that's just my experience, and it seems to have worked well.

Regarding the same academic questions everybody gets asked in every development interview, I feel Einstein said it best with "[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think."

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

#572

Post by belorn »

rbanffy wrote: post #384
jwecker wrote: post #252

Earlier quoted context omitted.

I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted]. It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few except…

> not a single interviewer had looked at or asked about any of my publicly available work It could be dangerous. Let's say you explain some interesting techniques you used on your GPL'd software and a Google product starts doing something suspiciously like what you showed them. You may even sue and end up making their source public after some litigation.

You can't make anyone making source code public, only stopping them from distributing copies of code which you have authored. Copyright and patents works very differently, and its quite hard (impossible) to copy source code wholesale from a interview by accident.

If they did makes copies of an applicants copyrighted work and distribute it, then they could get sued. Some companies has been know to explicitly ask applicants to bring source code from previous work places (also called industry espionage), and those been clearly intended crimes and not something that just happened to company during the process of an interview.

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

#573

Post by tommorris »

kogepathic wrote: post #501
enraged_camel wrote: post #455

Earlier quoted context omitted.

>>But 1 bad hire is easily correctable - you fire the person. Not sure if you have ever been a manager, because firing someone is NEVER easy. It hurts everyone emotionally. The person getting fired feels awful. The person doing the firing feels awful (unless they are a real sociopath). And team morale tends to take a big hit. Here is my stance: if you hire someone who isn't a good fit, unless they actively deceived y…

> it is your god damn job to find a way to make it work. No, it isn't. This is why probation periods exist. If you hired someone and they aren't working out, then at the end of the probation period you don't keep them on. Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org. It doesn't make you a "good" manager to say to everyone "I know this sucks but deal with it because lettin…

> Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org.

Doesn't this rather presume that your "team dynamic" is actually good to start with?

Let's say you had a team of not very good engineers. Then you hired quite a good engineer who looked at all the terrible practices (e.g. no version control, shitty or nonexistent testing, poor build processes) and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".

They might not be a very good team fit, but that's because the team is filled with idiots who haven't figured out how to use version control or whatever.

So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?

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

#574

Post by jules »

eoJ1 wrote: post #569
craigyk wrote: post #487

Earlier quoted context omitted.

One of my interviewers at Google asked me to implement a balanced tree insert on the whiteboard in C. After doing so he immediately told me it wouldn't work. I searched futilely for a minute or two to find the problem before he condescendingly pointed out I had left out a semicolon on one of my statements... Another in the same interview got in my face (this should be easy) when he thought it was taking me too long t…

RE your second paragraph, it's easier than it sounds. 637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560. Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548. 2548 * 10 = 25,480. 25,480 + 7 = 25,487 25,487 + 30 = 25,517 25,517 + 600 = 26,117. That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have b…

Of course multiplying two numbers is easy: primary school children learn how to do it. Doing it in your head under pressure in an interview is entirely different.

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

#575

Post by zodiac »

fsk wrote: post #344
thethimble wrote: post #74

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…

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

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

#576

Post by eoJ1 »

jules wrote: post #574
eoJ1 wrote: post #569

Earlier quoted context omitted.

RE your second paragraph, it's easier than it sounds. 637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560. Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548. 2548 * 10 = 25,480. 25,480 + 7 = 25,487 25,487 + 30 = 25,517 25,517 + 600 = 26,117. That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have b…

Of course multiplying two numbers is easy: primary school children learn how to do it. Doing it in your head under pressure in an interview is entirely different.

What primary school did you go to, where you had to multiply those kinds of numbers in your head?

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

#577

Post by rbanffy »

bphogan wrote: post #469
rbanffy wrote: post #431

Earlier quoted context omitted.

Interviewer time is expensive and candidate time is cheap.

Running git blame is faster than waiting 30 minutes for the results of a whiteboard test.

Running, then cleaning and then having a dataset that still needs interpretation.

I'd take the 30 minute interview route and risk not hiring a clever programmer.

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

#578

Post by dottedmag »

fsk wrote: post #344
thethimble wrote: post #74

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…

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

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

#579

Post by Silhouette »

dlandis wrote: post #449
Silhouette wrote: post #426

Earlier quoted context omitted.

In The Plex is great read for insight into their entire process. Basically, Google is run by people who have never been told "no" to anything in their lives, so they continue to think they are the best at everything until reality forces them to reconsider their delusional assumptions ("montessori naivety"). Which is unfortunate, because objectively Google doesn't actually have a very impressive track record of creati…

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 seems we have different definitions of "excellent".

Google Maps is certainly widespread, but it's hardly the only on-line mapping service available. They keep messing around with the UI, often not for the better. I often find the data itself and the live route planning/traffic news to be inaccurate.

Maybe it's better for those in the US, but here in the UK it's exactly what I meant by unremarkable. The local data from OpenStreetMap seems to be just as good for general mapping purposes and sometimes more accurate and/or current, and for car journey planning and real-time traffic news the dedicated satnav devices still seem to do a far better job.

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

#580

Post by jimmaswell »

ThrustVectoring wrote: post #505
seiji wrote: post #195

Earlier quoted context omitted.

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

I'd generalize your point a little more - for a given level of life success, intelligence will anti-correlate with other hire-ability skills like work ethic, diligence, attendance, emotional stability, professionalism, etc. Basically, imagine that there's two ways to graduate college with a CS degree - you're either the kind of person who's smart enough to get things if you work your ass off for them, or you're a gen…

You hardly need to be a genius to get through a CS degree without 'working your ass off'
Post reply on HN