Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's interview system: it's not about solving the problem

threader.app

Post reply on HN
Print view View original

91–100 of 432 posts

Re: Google's interview system: it's not about solving the problem

#91

Post by closeparen »

colechristensen wrote: post #78
ganeshkrishnan wrote: post #39

Earlier quoted context omitted.

Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure. The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground. The poster is correct that open ended questions that reveals the work ethic of team…

My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.

I want to think that’s a terrible question - checking whether they have the signal table memorized is a hilariously bad way of trying to assess someone’s fitness as an engineer.

On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.

Re: Google's interview system: it's not about solving the problem

#92

Post by rhizome »

kerng wrote: post #34

I like how the article tried to portrait these interviews as super professional and as if they have like a plan or something. My experience is that most interviewers dont prepare, they probably have been asking the same question for years. And no, they are not simultaneously interviewing for multiple skills, the just try to sound professional. If you are a dev, better leetcode. That's all that matters at Google.

10 years ago I was at EA and they would throw me into interviews with a couple hours notice and no resume, so.

Re: Google's interview system: it's not about solving the problem

#93

Post by tjpnz »

I've heard a lot of really positive accounts on their interviews but mine was nothing like those. My interviewer showed up late and basically spaced out for the entire 40 minutes. He clearly wasn't listening to a thing I was saying - I was verbalizing everything and I had to keep prompting him when I wanted to clarify something. Certainly not a conversation despite everything I had seen and read about their interviews. The cherry on top was when I asked the interviewer at the end what he liked most about working at Google. All he had was that he liked the commuter allowance. Incredible.

Maybe the guy was just having an off day but having spent a month preparing I felt cheated.

Re: Google's interview system: it's not about solving the problem

#94

Post by tytso »

cletus wrote: post #70

Hiring continues to be a favourite whipping boy on HN and honestly I kind of wish it would die because it's the same arguments every time: - Inconsistent interviews - Luck of the draw questions - "I don't do well coding on a whiteboard" (often framed as "coding on a whiteboard proves nothing") - Bad experience with the process - Etc Personally I don't mind coding on a whiteboard but only if you understand why you're…

The problem with FizzBuzz is that it's too well known. So it's basically something which has very little signal because people can just google it and memorize the solution.

Two of my favorite phone screen questions (now unfortunately banned because the have been identified on various web sites like Glassdoor as being Google interview questions) were "validate a UTF-8 string" (the interviewee is given the UTF-8 rules), and "add an integer to a bignum" (the interviewee is told what a bignum is if they don't know that term).

Both of these are really simple programming problems that the experienced coder should be able to knock off in 5 minutes. The absolutely terrifying thing is that there are fresh graduates with a CS degree who couldn't deal with either of these in the full 45 interview slot. I'm not sure what colleges are teaching these days, but it's certainly not programming as I know it...

The reason why these were my favorite phone screen questions was if the candidate couldn't hack a question like that, I could very confidently write up my interview report and tell the recruiter --- don't bother with the expense of bringing the candidate on site and asking 4-6 software engineers to spend 2-3 hours interviewing the candidate and then writing up a comprehensive set of interview notes/report.

Re: Google's interview system: it's not about solving the problem

#95

Post by ganeshkrishnan »

colechristensen wrote: post #78
ganeshkrishnan wrote: post #39

Earlier quoted context omitted.

Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure. The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground. The poster is correct that open ended questions that reveals the work ethic of team…

My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.

This is really absurd question to ask. Besides kill -s SIGTERM or even htop does the job. But like other commenters have pointed out the questions really depends on the person as there is no specific decided questions.

Re: Google's interview system: it's not about solving the problem

#96

Post by Hysterisis »

jakelarkin wrote: post #22

"its not about the problem" but if you cant correctly code one of these 200 algorithms on a whiteboard in sub 15 minutes while under extreme stress youre not getting an offer either.

You generally aren’t asked to implement a specific algorithm. You’re asked to solve a broad open ended question.

You get 45 minutes, sometimes more if the interviewers can see that you’re close.

These days Google offers the option of a chromebook instead of a whiteboard.

Re: Google's interview system: it's not about solving the problem

#97

Post by pmiller2 »

SquishyPanda23 wrote: post #37
starpilot wrote: post #24

Yet another "trust the system" message from the authority figure who enables the system. Similar: - Police officer: Just follow our instructions, be cooperative. - Car salesman: Just be upfront with what you want. Tell us about yourself, and we'll earnestly try to help you. The message is the same; the authority "just wants to help," but in reality the relationship is adversarial to a larger degree than it is coopera…

FWIW, I went through the interview process and I actually really enjoyed it. My attitude going in was that I was evaluating what it would be like to work there, and I treated the interviewer as a coworker solving a technical problem, where I was taking the lead. The questions I got were pretty much exactly the sort of hing you see on LeetCode, but I hadn't seen any of the questions before. I know from studying for ot…

Here’s the thing: patterns you will spot doing Leetcode problems are almost useless for anything else. The only purpose for working enough problems to see those patterns is to have more successful interviews.

Re: Google's interview system: it's not about solving the problem

#98

Post by Cursuviam »

closeparen wrote: post #91
colechristensen wrote: post #78

Earlier quoted context omitted.

My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.

I want to think that’s a terrible question - checking whether they have the signal table memorized is a hilariously bad way of trying to assess someone’s fitness as an engineer. On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.

Yeah, the only reason I can remember SIGKILL (9) is because of kill -9.

Re: Google's interview system: it's not about solving the problem

#99

Post by sigstoat »

tjpnz wrote: post #93

I've heard a lot of really positive accounts on their interviews but mine was nothing like those. My interviewer showed up late and basically spaced out for the entire 40 minutes. He clearly wasn't listening to a thing I was saying - I was verbalizing everything and I had to keep prompting him when I wanted to clarify something. Certainly not a conversation despite everything I had seen and read about their interview…

> I asked the interviewer at the end about what he liked about working at Google and all he had was that he liked the commuter allowance. Incredible.

the interviewer i had couldn't even manage to come up with anything he liked about google, when i asked. then he went on to complain about being forced to do interviews.

Re: Google's interview system: it's not about solving the problem

#100

Post by chaosite »

colechristensen wrote: post #78
ganeshkrishnan wrote: post #39

Earlier quoted context omitted.

Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure. The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground. The poster is correct that open ended questions that reveals the work ethic of team…

My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.

The non-technical recruiter needs these trivia questions because they need questions with single answers that allows them to separate people with no technical knowledge and people with technical knowledge. The easy way to get past this barrier is to get a referral, then you start at the technical interview.

When I was at Google, I worked in a tiny office, and I was friends with the recruiter who worked that office. A couple of times she asked me to vet the answers to the non-technical questions, because if the candidate went off-script in any way, she simply couldn't tell if it's a wrong answer or a more in-depth answer than the script anticipated. This wasn't part of my job, and if our office wasn't so tiny we wouldn't have had any contact, and she wouldn't have had any engineers to ask.

Post reply on HN