[deleted]
Google: 90% of our engineers use the software you wrote (Homebrew), but...
531–540 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#532Earlier quoted context omitted.
What specifically are you objecting to? That specific question? Writing code on a whiteboard? How would you interview software engineering candidates?
I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.
I once got asked to spin off an ec2 instance from an image provided by the company I applied to, and then answer certain questions about the dataset on that thing. I had to write actual code to obtain the answers. All that had to happen within 24 hours. Then there was an on-site interview where they asked questions about stuff like JVM garbage collector fine-tuning and such. That was the best interview I had, ever.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#533Good engineer you didn't hire is not much of a cost to the company (other than resources wasted on hiring process and perhaps some bad publicity).
On the other hand bad engineer will stay at the company, lower standards, damage morale and set bad precedent to other engineers.
Being engineer myself, I feel much more motivated working in an environment where you can just assume, even before meeting, that the other person is intelligent and motivated. You trust hiring process to filter everybody else so you don't have to subconsciously distrust every person you meet.
This comes at the cost of situations like that.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#534Earlier quoted context omitted.
I think you may have left with the wrong impression. If you ask Googlers or Xooglers alike, most agree that the people here are actually the best thing about Google. Like anywhere else, there are some bad apples, but compared to most other places the people here are on average more talented, nicer human beings and more helpful. Certainly compared to your typical startup or other BigCo. In my nearly 3 years here, that…
As far as my specific interviewers are concerned, I liked 7 of the 8 as individuals, which is great. What I didn't like was the company felt like a monoculture. Same schools, same majors, same pre-education background. Everybody looks the same, dresses the same, etc. The process, on the other hand. Ugh. I have zero respect for Google as a company after that. It starts with the standard phone screen/day-long onsite/ha…
Maybe I'm wrong but I think HR's pushiness might be a result of their process yielding so few offers, then even fewer people accepting offer letters. It could be resulting in HR having to work A LOT harder than the industry average to fill positions.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#535Earlier quoted context omitted.
Is a binary search tree a problem that the Dev would have needed to solve? In over 5 years as a dev, I have never once needed to solve a binary search tree. Why not ask the candidate how to perform a kidney transplant.. That's solving a problem too. White boarding algorithms is not relevant to the majority of Dev jobs. It's related, but not particularly valuable as a screener.
I'm not sure how asking someone who's going to be working in computer programming something about computer science is equal to asking someone who's going to be working in computer programming something about medicine. Those two things aren't equivalent. Could you perhaps clarify? Engineering is the use of knowledge/science to solve problems, right? So why is asking someone to use knowledge to solve a problem not appl…
The act of creating a, say a self balancing binary search tree, is something you should know about. If you ever have to implement it, you go look it up. Engineers are exactly the same - you would rather have one that know where to look up all the stuff, or search for information, than one that can regurgitate the entirety of his education theory.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#536To be fair, inverting a binary tree is a pretty easy question. Google also tells you BEFORE you start the interview process that it'll be very data structure/algorithm oriented and asks that you please prepare (and take as much time as you want doing so). They even say that they want you to prepare because they know a bad candidate that prepares can look better than a good candidate that doesn't prepare - then want a…
I am dismayed by the way all the reactions on Twitter are piling on with outrage and/or relating similar experiences. Inverting a binary tree is pretty easy. It is not quite as trivial as FizzBuzz, but it is something any programmer should be able to do. If you can't do it, you probably don't understand recursion, which is a very basic programming concept. This isn't one of those much-maligned trick interview questio…
I'm a CS major, and I'm not even sure exactly what they're expecting. I mean a binary tree is just nodes with no more than 2 children. A linked list is a binary tree. Do they want a search tree? Do they want a self balancing tree?
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#537At 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…
The fact is, that reliably separating bad from good engineers is incredibly difficult at best.
For big companies that want to scale hiring process, there's really not much you can do.
You put difficult questions and you hope that bad engineers will not be able to solve them. Then you absolutely have to commit to not hiring the guys who can't solve the assignment, otherwise it's all for naught.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#538Earlier 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…
"Finally after wasting other people's time for 9 months, a manager made the decision to get him out."
Why did the manager wait so long?
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#539At 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…
The fact is, that reliably separating bad from good engineers is incredibly difficult at best. For big companies that want to scale hiring process, there's really not much you can do. You put difficult questions and you hope that bad engineers will not be able to solve them. Then you absolutely have to commit to not hiring the guys who can't solve the assignment, otherwise it's all for naught.
'Bring in something you've built and we'll go through it' is getting pretty common.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#540Earlier quoted context omitted.
Why would anyone who has a job waste a vacation day to interview at a place that previously rejected him? If your flawed process rejected a good candidate the first time around, what makes you think the same flawed process won't reject them a second time?
I've heard that it's not uncommon to have to interview twice before getting in to Google.
Of course, people hired after their second interview are more likely to be mediocre, because people with more options are more likely to not re-interview (like mxcl https://twitter.com/mxcl/status/608687283869503488)