Hiring/Interview process is broken and not only in Google
Google: 90% of our engineers use the software you wrote (Homebrew), but...
481–490 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#482At 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…
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…
Replying to myself- too late to edit. Some other comments in here lead me to believe there would be experience-related questions ideally these days. Again, my experience was a few years ago :-)
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#483Earlier quoted context omitted.
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…
Basing all of your management decisions purely on statistics is a bad strategy. You're assuming that the weighting of good vs. bad candidate is the same, when they're not. Hiring a good employee is not nearly as impactful as hiring a bad one. If you can have a strategy that filters out 100% of bad employees, but unfortunately also filters out 90% of good employees, this is preferable to filtering only 50% of good emp…
People have an irrational belief in their ability to tell the difference. This is how one gets such flawed thinking in the first place (regarding priors and probability distributions).
Firms are hierarchy-based entities. "Technical Merit" is about a third or fourth order away from what really drives the hiring decision. Its also very imperfect predictor of actual performance.
The issues is that companies use the term all the time. They want people to believe they were hired for their merit, but merit is almost always 'fit' and not technical in nature. The technical hoops are just a CYA for when the 'fit' doesn't work out (mis-judgement) and they need something to point to as to that is not arbitrary in nature to explain how other people were not hired instead.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#484Earlier quoted context omitted.
You can fire a bad hire. You can't hire someone you already rejected because a few weeks later they already have a job.
Easier said than done. We had a really bad hire about 2 years ago. So bad it caused us to review our entire hiring process to understand how he got in. It took almost a year before he was fired (and he was a contractor so it should have been easier). In that time, he used up untold resources while we tried to find work he could actually do, people helping him "just in case he just needed a helping hand" and so on. Fi…
The mistake was simply not getting rid of that guy faster. Not that he was hired in the first place.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#485Earlier quoted context omitted.
We don't have all the details. You might not hire the best computer programmer in the world if he was also a psychopath. Heck, you might skip on him even if he wasn't a good culture fit. I'm not saying this person is / was any of those things, but there's more to hiring than just talent.
Yeah, the twitter rant was a little unnerving. Might not have anything to do with inverting the binary tree.
He was there and that's what he felt it was the cause of his rejection. We haven't had the opportunity to witness his hiring process.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#486Earlier 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…
> you need a system to quantify how good they are
But do you? How catastrophical would it be if Google accidentally hired not the top 0.001% but instead somebody from top 0.01%? I mean, same people that build everything else around us and the world still didn't collapse yet? I get it, you have to have standards, and you don't want to waste time and money on somebody that can't pass fizzbuzz test. But once you've moved past that - do you need to obsess so hard on ranking and quantifying it? There are probably some positions in Google that require people to invert binary trees (speaking figuratively) day in and day out, but my decades of experience in the industry shows that most positions aren't like that. I've not worked for google but I'm pretty sure it's also this way there. If you hire smart and competent people, it's OK even if they don't reverse a binary tree here or there.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#487Earlier 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 not what the interview process is like at all. They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply. It's…
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 too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#488Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0. What I would do if I had to invert a binary tree: look it up.
>Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0 Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years. >What I would do if I had to invert a binary tree: look it up. Unless you're already good at algorithms, it would net you a mediocre…
>> Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years.
Quite a range of stuff, unsurprisingly. I started on an HP3000 mainframe in 1976, if you want to go back to the very beginning, writing BASIC programs on a teletype or one of the two early CRTs, and storing my programs on paper tape.
Since then I've worked in DOS, 16-bit Windows, 32-bit Windows, 64-bit Windows, Ubuntu, iOS, and Android, using Pascal, 8086 assembler, C, C++, C#, javascript, Python, and Java. I've worked on applications in multimedia, telephony, banking, insurance, pharmaceuticals, cosmetics, health care, and I'm sure a few other things I've forgotten.
All of which will mean jack squat if, tomorrow morning, the most important thing I have to do is invert a binary tree. But I'm fairly certain I would be able to figure out what I needed to do, and I am fairly certain I could manage to implement it well. It's what we're supposed to be able to do, and if you think that having studied up on it so that you could pass a Google interview means that, a few years down the road when you actually need it you'll just whip it off the top of your head, then I think life may hold some surprises for you.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#489Earlier quoted context omitted.
You can fire a bad hire. You can't hire someone you already rejected because a few weeks later they already have a job.
Easier said than done. We had a really bad hire about 2 years ago. So bad it caused us to review our entire hiring process to understand how he got in. It took almost a year before he was fired (and he was a contractor so it should have been easier). In that time, he used up untold resources while we tried to find work he could actually do, people helping him "just in case he just needed a helping hand" and so on. Fi…
Here I see the same logic that caused the TSA. Some rare and bad event happens, and people rush to rebuild the whole system to never let that happen again. Not even considering maybe accepting that rare and bad events happen and dealing with them more efficiently would be better? Maybe rebuild actually doesn't even prevent bad events, just specific type of bad event that already happened and is unlikely to repeat anytime soon? Maybe dealing with imperfection is better than trying to be perfect every time?
I.e., I don't know your particular situation, so I wouldn't dare to assume the reaction was wrong, but too often "we much at all costs make sure it never happens again" overwhelms any attempt at reasonable approach and cost/benefit analysis completely. Maybe getting one bad apple in occasionally is a reasonable price for quickly and efficiently hiring a lot of good people?
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#490At 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…
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.
>not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Any mature company should focus on finding those specific candidates - the ones who fit the company and specific team, on several dimensions beyond standard skillsrequired for the job. That's someone who will be called the best candidate in that specific company. And it's absolutely natural that s/he won't be considered "best" insome other company.