Google’s recruiting system is famously brutal. Many workers think it’s failing • Hacker News Board

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#51

Post by praptak » Fri, Oct 08, 2021, 7:06 PM UTC

dolni wrote: post #5

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed. Well why the hell not? The ans…

I think that about a decade ago they still used horrible "why is manhole round" questions or "guess the trick" ones. The kind which puzzle-obsessed geeks like to ask eachother but which are horrible for evaluating fitness for a job.

This changed. I interviewed 7 years ago and they have fixed this, judging by the questions I got and the interviewer training I received. Using trick questions and fixating on "the" solution was explicitly called out as bad.

Of the questions I received two were open ended design questions and the rest was about algorithms and implementing them.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#52

Post by kongin » Fri, Oct 08, 2021, 7:07 PM UTC

tylerhou wrote: post #36

akgerber wrote: post #14

Earlier quoted context omitted.

I had a similar experience in a problem in which I was requested to extract the digits of an integer before performing some other task. I proposed doing this by converting it to a string and extracting the digits from the string, and that was rejected arbitrarily even though it solved the problem at hand just fine. So I spent entirely too much time during that session recreating an algorithm to extract digits via rep…

> repeated division/modulo operations that would likely be much slower in practice. … but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed. I don’t know enough about the question, but it’s possible that the interviewer wanted to test this specifically. I’ve had interview questions which were literally “implement itoa.” In this case where itoa was part of…

>… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed.

https://github.com/lattera/glibc/blob/master/stdio-common/_i...

It's all bit-shifts, bit-masks and a lot of other hacks to get the maximum performance out of the system you're compiling the code on.

Could I write something with better performance on my system? Yeah, after a week to run tests and write esoteric macros.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#53

Post by dolni » Fri, Oct 08, 2021, 7:07 PM UTC

pengaru wrote: post #45

dolni wrote: post #5

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed. Well why the hell not? The ans…

Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc. If you just fixate on your specific first solution and choose to dig in and argue ov…

> Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc.

Trivia questions like that are absolutely awful for demonstrating any of what you're talking about. There isn't any creativity involved. And it's not like the guy followed up with something like "where would you go to determine the answer?"

There were 6 or 7 other interviews I went through that had interesting, open-ended questions that allowed me to bounce ideas off the interviewer and share my thought process. This particular interview was not one of them.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#54

Post by tablespoon » Fri, Oct 08, 2021, 7:08 PM UTC

rudedogg wrote: post #22

tablespoon wrote: post #7

> It was the design of the recruiting system itself that became his problem: At some point, Google decided Watt (who was working as an associate professor at the time) was interviewing to be a site reliability engineer, despite never indicating an interest in that role himself (he was interested in a more management-focused position). > "It just never seemed to get through. They were so focused on whatever categoriza…

> Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them? You're probably thinking of Max Howell, the maker of the Homebrew package manager. https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

>> Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them?

> You're probably thinking of Max Howell, the maker of the Homebrew package manager.

My memory is very fallible, but I don't think that's it. I'm sure there are several similar incidents, and the one I'm thinking of definitely involved a sysadmin role and maybe even an offer. The issue was that the role was an insultingly bad fit, not that a talented person got rejected.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#55

Post by krisoft » Fri, Oct 08, 2021, 7:09 PM UTC

tablespoon wrote: post #9

dolni wrote: post #5

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed. Well why the hell not? The ans…

> He was fixated on this one very specific piece of knowledge. IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers . If you only know one, your question is shit and you might as well have the applicant play guess the number.

That is silly. Trying to know all the possible answers is a losing game.

If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code.

These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know?

And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#56

Post by kongin » Fri, Oct 08, 2021, 7:11 PM UTC

johnwheeler wrote: post #8

I don't get it. University tests are brutal too and have the expectation the student will devote large amounts of time and energy. It seems like a job interview is fair game for the same, no? I feel like this is a very bruised ego here. I'm not saying any interview process is perfect, and I think a lot of them are very, very bad at accessing the capabilities and value someone provides, but same for University.

I pay universities to get a degree.

Companies pay me to work.

They are welcome to pay my consulting rates of $300 per hour for interview questions.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#57

Post by Brian_K_White » Fri, Oct 08, 2021, 7:12 PM UTC

jimbokun wrote: post #34

dolni wrote: post #5

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed. Well why the hell not? The ans…

> The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again. That should never pass any code review.

I almost wonder if he was really looking for an objection to that proposal, and specifically the reason for the objection.

It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview.

I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don't just go up to room temp. So a sneaky question that only a truly insightful and thorough person might get, and ballsy enough to challenge the interviewer, and with good enough judgement to know when it's right to talk back, that I myself might not get, is fine. But it's there to identify the exceptional, to provide room in the plot for the spikes instead of clipping, not to kill everyone else.

I sometimes give people way too much credit though. I bet it was all face value.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#58

Post by tablespoon » Fri, Oct 08, 2021, 7:14 PM UTC

krisoft wrote: post #55

tablespoon wrote: post #9

Earlier quoted context omitted.

> He was fixated on this one very specific piece of knowledge. IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers . If you only know one, your question is shit and you might as well have the applicant play guess the number.

That is silly. Trying to know all the possible answers is a losing game. If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I…

> That is silly. Trying to know all the possible answers is a losing game.

That's why I also said "(or at least recognize) all the answers." You're describing some heuristics to recognize a valid yet unfamiliar answer.

The point I was making is it's silly to make an applicant guess one answer you know out of many.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#59

Post by dolni » Fri, Oct 08, 2021, 7:15 PM UTC

Brian_K_White wrote: post #57

jimbokun wrote: post #34

Earlier quoted context omitted.

> The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again. That should never pass any code review.

I almost wonder if he was really looking for an objection to that proposal, and specifically the reason for the objection. It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview. I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don'…

> I almost wonder if he was really looking for an objection to that proposal

Nah, he wasn't. Near the end of our time slot, he shared the behavior of open() with me (that's how I learned about it).

I told him that doing it that way was silly, because it made the code's intent less clear. He didn't seem impressed.

Re: Google’s recruiting system is famously brutal. Many workers think it’s failing

#60

Post by angelzen » Fri, Oct 08, 2021, 7:19 PM UTC

clairity wrote: post #11

dolni wrote: post #5

I interviewed at Google about a decade ago. I made it far enough that they flew me out to interview on-site at their Kirkland office. I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed. Well why the hell not? The ans…

i had a similar experience wrt a product position. interviewer was fixated on a particular 'right' answer to a trivia-based question. was gladly not a fit there.

The interview loop is not necessarily an indication of the work environment. It is a chore, 1-2 interviews a week, about a couple hours each including prep & report writing, evaluating a candidate that will not work on your team, except in rare instances. I can see interviewers zoning into a specific answer simply because they have no energy and no interest to explore alternative avenues.