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

341–350 of 683 posts

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

#341

Post by exacube »

ciupicri wrote: post #335
exacube wrote: post #254

Firstly, you're not entitled to any job you want just because you wrote Homebrew. If you accepted an interview with Google, then you accepted the fact that Google will judge you based on your problem solving skills, just like every other person was asked. Secondly, I don't think this is a hard interview question; it's certainly fair. Did you expect to be asked knowledge-based questions that Google knows you're alread…

If 90% of Google's engineers use his software, it's reasonable to expect to be hired for continuing to work on that software.

That may be somewhat true, depending on how crucial and dependent Google is on Homebrew. But 90% of Googlers don't rely on Brew for work.

It is just a figure he made up to make a point about how popular his software is. Using his software outside the context of our jobs is no means to justify a hire. He should go through the same interview process as 90% (much higher than that actually) of Googlers.

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

#342

Post by [deleted] »

ciupicri wrote: post #335
exacube wrote: post #254

Firstly, you're not entitled to any job you want just because you wrote Homebrew. If you accepted an interview with Google, then you accepted the fact that Google will judge you based on your problem solving skills, just like every other person was asked. Secondly, I don't think this is a hard interview question; it's certainly fair. Did you expect to be asked knowledge-based questions that Google knows you're alread…

If 90% of Google's engineers use his software, it's reasonable to expect to be hired for continuing to work on that software.

[deleted]

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

#344

Post by fsk »

thethimble wrote: post #74
kenrikm wrote: post #43

Earlier quoted context omitted.

These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.

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 "good" candidate, that is greater opportunity for a "bad" candidate to trick you into hiring them!

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.

This is management porn. "It's better to reject a good candidate than hire a bad candidate." It makes the manager feel good. "Wow! That candidate seemed smart, but I rejected him anyway! I'm such a great leader! I make the tough decisions!"

tl;dr summary

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!

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

#345

Post by SubuSS »

Actually my pet theory is this: Interviews for experienced folks are more meant to keep them in their current companies rather than to filter the incoming new ones. This acts as a gentleman's agreement between the giant companies to keep their own talent pool semi-intact :) /s.

I mean imagine the amount of extra work someone has to put in to start interviewing. Take a break from your current work, Prepare your CS basics again, Prepare from interview question dumps online, read up / analyze everything the new company is doing and form reasonable opinions, practice white board coding / coding without an IDE, allocate time for any homework projects given, Psych yourself up if you are introverted etc. The alternative is just to stay in the current role and hope stuff gets better. 90% of the folks I know choose the alternative over the dehumanizing process of interviews. So many folks I know are good engineers get chewed up in interviews (both in my current company and elsewhere) because the process is pretty cooked. We are trying to see how this can be improved, but yeah - I just keep going back to my pet theory :)

I do agree with one of the commenters here though: At one point your resume should speak for itself. These are the kind of problems I would like LinkedIn to be solving instead of finding ways to spam me with recruiter deluge.

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

#346

Post by bitkrieg »

CydeWeys wrote: post #173
el_fuser wrote: post #53

Another instance where silicon valley favors the young... he probably would've nailed this question if he'd been only a couple of years removed from school. He also would've nailed it had he been given 10 minutes to do some research to refresh. Silicon valley (and the numerous companies that mock the interview style) are testing for the wrong thing when they hire, then complaining about not being able to find good en…

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?

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

#347

Post by eva1984 »

aaggarwal wrote: post #167
waterlesscloud wrote: post #121

Earlier quoted context omitted.

"they can afford to have strong filters which will definitely filter out a bad hire, may be at the expense of rejecting a good candidate" Can they, though? Obviously they believe they can, but are they correct? Google's not going away any time soon, but they could easily slip a long way down from the top of the heap. There are signs that's started to happen. I don't think they can be nearly as casual about losing top…

In the long run, this could affect Google, but, then again, if they change their hiring policies for better even after long 5 years, the best talent that might had been rejected before would still go to work at Google. So, still I don't think Google really consider it as an issue for them. Though, I have been burned once myself by them.

Google is not the Google it was. I mean I still consider that working for Google is attractive, but things I get from tens of my friends who work there are to say the best....mixed. Google might still have the vigor and excitement at its core, but unless you are an already exceptional engineer, the work you get assigned there, often times, ranges from bland to boring.

Like I said, Google is still an amazing company, but it is by no means the only one out there. Talents won't come to work for it just because it is Google, without great compensation and interesting projects.

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

#348

Post by MaulingMonkey »

Aloisius wrote: post #310
jblow wrote: post #225

Earlier quoted context omitted.

Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often. If you're writing scripts, or JS code for web pages or something like that, then maybe you don't use CS stuff, but ... are you able to write a web browser if you had to? Are you able to write an operating system or navigational software for a spacecraft? If not, then maybe just see this as revealing sect…

> Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often. Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel. I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I d…

> Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel.

Ditto. Those who decided to reinvent even basic data structure stuff left me a huge string of bugs to fix, which I eventually got so fed up with, that I started replacing their code wholesale with off the shelf solutions to stem the flow at my last job.

Aside from fixing an untold number of implementation bugs, the replacement caught several usage bugs as well, due to actually having some error checking built in.

We had just plain broken hashtables, "lock free queues" that didn't use memory barriers... or interlocked intrinsics... or even volatile, if my memory is correct - and not a debug visualizer to be seen before I got my hands on them, of course.

> I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I did was 20 years ago and not only will I never do that again, I will laugh at anyone who does it without a damn good reason.

Besides laughing, I'll tend to -1 the code review as well.

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

#349

Post by decisiveness »

ZanyProgrammer wrote: post #316
decisiveness wrote: post #284

Earlier quoted context omitted.

I think what Google tries to find are the engineers with creativity, skill and ability to work intelligently at a problem which they haven't seen before. It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge o…

I think you want to think that way, that whiteboard interviews have a shred of competency about them. I bet you dollars to doughnuts though 9/10 times a company will hire someone who can regurgitate algorithms rather than an eccentric who can't get them right but thinks really cleverly.

It seems this criticism is of the interviewer making a poor decision based on missed/incorrect observations, not with the whiteboard interview itself.

Whiteboard interviews might miss eccentrics who can't express their clever thoughts verbally or visually, but it can depend on how tuned in the interviewer is to these eccentricities or how much value their team puts on expressive skills.

Algorithm/data structure interviews, whiteboard or not, also have the added benefit of being exceptionally good at eliminating candidates that:

1) Drastically misrepresent their skills

2) Give up easily at difficult tasks

3) Don't seek help from others

4) Frequently have a bad attitude

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

#350

Post by wdewind »

robbrit wrote: post #324

I'd like to present HN with a challenge. Come up with an interview process that matches _all_ of these requirements: Objective - the process avoids human bias (this guy was in my frat, therefore is awesome). Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview. Risk Averse - Avoids false positives. Relevant - it properly tests the abilities needed for a…

Create an online game/project/test that people must solve in order to get an onsite interview. The game can be customized for individual teams to have more appropriate domain challenges. Spend the onsite interview walking through the code the people wrote for that game. Devil is in the details, but that's the broad strokes of what you are asking for.
Post reply on HN