Live data from Hacker News

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

twitter.com

281–290 of 683 posts

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

#281
Disclaimer: GoogleFanBoy here, feel free to ignore or downvote.

So, I've interviewed with Google twice. Once was 3 years ago, the other was like 2 weeks ago. They contacted me. The way I see Google's interviews is like referee in Football(soccer or "Futbol"). Sure, you need a certain amount of skill to play in the World Cup but you winning or losing can, and often enough does, come down to a controversial referee call. You end up losing out to a team that did a handball - https://www.youtube.com/watch?v=-ccNkksrfls , but that's just how it is. What makes me like watching soccer so much is the same thing that excites me about Google's interview process. Yes, there is heartbreak and anger. Just like World cup fans get angry when their team loses because they were denied a point for an off-sides call even when the player was nowhere near off-sides.

--- Is Google's interview process fair? Nope.

--- Would I subject myself to their futbol-referee style of judging candidates again? You bet.

--- Do I think they should make their process more fair? Nope, let the drama and _justified_ rant posts continue. Just like I want the unfairness in futbol to stay as is. I was one of the people against putting the microchip inside the ball to know for sure if it crosses the goal line. I want the drama of a ref having to call it and sometimes getting it wrong.

I know people, especially on HN, love reliable & repeatable. I do too, except when it comes to dealing with humans.

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

#282

Earlier quoted context omitted.

the tweet is made to trigger that discussion. but you can rephrase the tweet to something like: even though I made a popular tool, I didn't get a job at Google because I'm not good at other things they need. Google probably has a lot of factors counted into the final decision, including algorithm skills, other software engineering skills, human skills, contributions to open source projects. It's never 1 reason why yo…

I am speaking from personal experience here, they don't count a lot of factors while rejecting a candidate, you make one mistake on their particular set of questions, you are out. They don't even look at your resumes until all your 4 interviews are completed. However, selecting a candidate is a different matter, in that decision they might consider everything.

Does your personal experience include actually being involved in the hiring process at Google?

Because in my personal experience - as both an interviewer and a hiring committee member - what you said is completely wrong.

> they don't count a lot of factors while rejecting a candidate, you make one > mistake on their particular set of questions, you are out.

Completely false. I have personally seen many people get hired despite doing poorly in an interview or making mistakes.

The hiring committee looks at all of the available information - resume, recommendations, and interview feedback when making a decision. There is no "one-thing" that will make or break a candidate.

> They don't even look at your resumes until all your 4 interviews are completed

I have no idea where you are getting this from. All interviewers receive the candidate's resume prior to the interview. I always review the resume's to get a sense of what the candidate has done so I can ask appropriate questions.

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

#283

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…

Yes, exactly, since it's Google, 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. Their policy might expect good candidate to get absorbed in Google one way or other, but they definitely want to filter a bad hire. However, in the recent years, I have seen this to be not working as expected. Still, I don't think it matters to Googl…

>>However, in the recent years, I have seen this to be not working as expected.

It never worked, what do you think happens when you start asking these kind of questions in interviews? People just go out and spend insane amount of time memorizing solutions to interview questions on the internet.

They continue the same after you have hired them. So their on the job productivity remains low. Please note, they need to prepare for their next job in the current one.

So the only thing this results is in people spending insane amount of time preparing interviews doing very little work in their day jobs.

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

#284

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…

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…

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 over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.

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

#286

Earlier quoted context omitted.

Devil's avocado: if they're truly CS fundamentals, then they should be baked into you good and deep during the course of your college education. It shouldn't be painful at all.

I graduated this spring and I don't know how to do that. Now, I am not a boy genius but I doubt it is a CS fundamental.

What material did you spend time on that you don't know how to reverse a binary tree?

It isn't a difficult problem, even having never seen it before. This is one of those warmup problems to test how comfortable a candidate is with basic concepts such as recursion.

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

#287
post #204
post #104

Earlier quoted context omitted.

I don't necessarily agree though, I think if you can reason about a problem, you are infinitely more valuable than someone who memorizes problems and just applies them blindly. Correct me if I'm wrong, but a binary search tree is a very simple data structure. It has rules, and just by it's definition, and the definition of "inverted", you should be able to come up with an iterative solution, even if it's just walking…

It depends how your interviewer is ranking/scoring you. One interviewer might be impressed with your ability to talk through and solve the problem from first principles, where another might ding you for not instantly knowing the answer. The former type of interviewer would be happy to give you hints and prompts, the second is a stone wall. I try to be the first -- it helps assess how a candidate responds to coaching…

> where another might ding you for not instantly knowing the answer

While there certainly are incompetent interviewers, I think ones that extreme are rare.

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

#289
Great, another self entitled engineer who thinks Google owes them a job because they are sooooo good (Which, maybe they are good at some things)

But how about Google didn't give them a job because this is how they handle failure, embarrass an entire company on Twitter to punish them.

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

#290

Earlier quoted context omitted.

By re-learning computer science concepts you haven't had to use in real life without Googling in a decade.

(I'm at Microsoft, FWIW, every engineering team here does hiring their own way) My team does whiteboard questions, but we try to keep them practical. Typically they are the types of problems that we'd expect new engineers to have to look into on their first day. Oftentimes the questions are less "come up and an answer" and more "let's explore this problem domain and see what we can uncover." As an example, the interv…

I'd like to interview at MS next year, I have no formal CS training. Can you give me any hints?
Post reply on HN