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

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

#501

Post by kogepathic » Thu, Jun 11, 2015, 6:47 AM UTC

enraged_camel wrote: post #455

krschultz wrote: post #414

Earlier quoted context omitted.

But 1 bad hire is easily correctable - you fire the person. You won't know that you missed on the good hires. I personally have worked with several awesome people that have interviewed with Google, and none of them got hired. They all said the interview process was flat out insulting. Interestingly enough, most of them ended up at Facebook.

>>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 letting them go would mean I was wrong."

> As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.

Which is ironic because so many job descriptions I see today are basically written as "we want to hire someone with exactly these skills, who requires zero training, and can become an expert in our systems in their first week."

No one is that way, unless your system consists of pressing one button all day, but then the job description would probably require that the person have intricate knowledge of the button and is friends with the engineer who designed it so they know what to do if the button suddenly stops working.

If companies actually treated people with respect and dignity, I'd get the training I need to become a better employee, instead of going to management and begging them for any training every 6 months like the industry is now.

/rant

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

#502

Post by ThrustVectoring » Thu, Jun 11, 2015, 6:49 AM UTC

fsk wrote: post #435

liberatus wrote: post #361

Earlier quoted context omitted.

Doesn't understand bayesian logic! Doesn't understand risk management!

Idiot: We don't want to make any bad hires! Therefore, we reject a lot of good candidates! FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire. Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster! FSK: But, if you want t…

It's actually fairly reasonable. The manager doesn't want to avoid hiring bad candidates. The manager wants to avoid being blamed for hiring bad candidates. They want to be able to say "I looked really really hard for reasons why Bob was a bad hire, and didn't find any, so you can't blame me for Bob being a bad hire."

Whether or not this actually reduces the number of bad hires is beside the point. It's a classic principle-agent problem.

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

#503

Post by jpatokal » Thu, Jun 11, 2015, 6:51 AM UTC

jwecker wrote: post #475

jpatokal wrote: post #400

Earlier quoted context omitted.

Your previous work is what gets you in the door, but interviews at Google are explicitly structured so that you need to demonstrate competence right then and there. And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.

Makes sense for google. And it's not that I didn't appreciate doing all that (and I did do well), it just struck me how they knew nothing else about me afterward except that I could answer academic questions, and how different that was from the startup world- where, at the very least, you want to know what they're passionate about and that they are productive. Asking an engineer what their strengths are and then to d…

For broad-spectrum roles like software engineers, Google hires people first and then figures out what team they should join later. If you want a specialist role, then you'll need to find one on their jobs page.

To illustrate, here's the kind of thing Mr. TCP kernel module should be applying for: https://www.google.com/about/careers/search#!t=jo&jid=107205...

And here's the kind of generic role they probably shouldn't be: https://www.google.com/about/careers/search#!t=jo&jid=34154&

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

#504

Post by mymacbook » Thu, Jun 11, 2015, 6:51 AM UTC

jd3 wrote: post #7

Dewie3 wrote: post #4

Why is his profile picture the attractions road sign as seen in Scandinavia? :-)

Perhaps he's a fan of Susan Kare :-)

I don't get the message you're trying to send by this reply... and yes I know who Susan Kare is.

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

#505

Post by ThrustVectoring » Thu, Jun 11, 2015, 6:57 AM UTC

seiji wrote: post #195

falcolas wrote: post #140

Earlier quoted context omitted.

If only whiteboarding interview processes actually weeded out false positives. In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill. I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic…

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 genius and you coast through. If you're a genius and you work your ass off, you get a doctorate or found a startup, and aren't in the candidate pool. So you wind up with a choice about what to compromise on: work ethic, or smarts.

Ideally, you compromise on whatever makes the least difference to your organization, compared to your competitors. Hiring smart/motivated people out of non-traditional backgrounds is a great option for this.

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

#506

Post by kele » Thu, Jun 11, 2015, 7:01 AM UTC

Aloisius wrote: post #470

fishnchips wrote: post #230

[Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. That being said if I ask…

> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. It is a terrible quest…

> First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree

Just because someone wrote on Twitter with limited number of characters that the problem was to "invert a binary tree", does not mean there were no clarification from the recruiter.

> And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.

If you're thinking about making a real structure, I believe you should recurse down and swap. If you don't do this, rotating, joining etc, could be a real pain.

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

#507

Post by AstroChimpHam » Thu, Jun 11, 2015, 7:01 AM UTC

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…

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

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

#508

Post by gaustin » Thu, Jun 11, 2015, 7:02 AM UTC

jbrukh wrote: post #474

Frenchiie wrote: post #427

I dont want to be an ass but how do you not know how to invert a tree? Anyone who knows how to write a tree and traverse it should be able to do this. If you ran out of time coding it then that's different.

Not even. If you know what a tree is, and you've written a couple of recursive problems on trees in your life, then you know most of them are approximately 5-6 lines of code. If you're spending 45 minutes writing 5 lines of code, it is not definitive, but certainly a red flag.

Nobody in this thread has even been able to define what inverting a tree means. (Reversing or mirroring? Sure.) My search for how to invert a tree led to a bunch of fairly hairy academic papers.

If you have a definition, please elucidate.

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

#509

Post by gaustin » Thu, Jun 11, 2015, 7:05 AM UTC

blahblah3 wrote: post #262

mikek wrote: post #15

At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…

inverting a binary tree is a pretty basic question though, if you understand recursion. i can understand why google would ask simple algo questions

Could you illustrate? I can find plenty of examples of mirroring/reversing a tree (below the root node) but none that really invert it. I haven't even found a definition of what inverting a tree means (aside from some academic papers I haven't been able to read yet), despite quite a bit of googling.

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

#510

Post by gaustin » Thu, Jun 11, 2015, 7:09 AM UTC

Aloisius wrote: post #470

fishnchips wrote: post #230

[Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. That being said if I ask…

> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. It is a terrible quest…

Would a multiply-rooted tree still be a tree? I thought a single root was part of the definition of a tree. Would it instead be a graph?

Sorry for the elementary questions. I'm bad at algorithms and just trying to get a grasp here.