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

211–220 of 432 posts

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

#211

Post by akudha »

Someone1234 wrote: post #5

> Your interviewers try to understand what it feels like to work with you on a daily basis. If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is? I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design th…

5-6 years ago, I went for an interview in a real estate company. The introductions lasted all of 2 mins. Then they took me to a computer, showed me a bug in the code base that I would be working on, if I got hired. Then they said "please fix this". Took me about half hour or so to hunt the bug down and fix (it wasn't hard, but it wasn't a cosmetic bug either). Then they asked me how I found the bug. I explained, they told me I'm hired, and the paperwork will follow in a day or two. No other questions were asked, they didn't look at the resume at all.

The entire experience lasted less than an hour - from the time I walked into the reception till I walked out. Best job interview ever!

This codebase was probably 0.0000001% as complex compared to Google's (I can only imagine). Still, there is no reason more companies can't follow this style, at least for one of the several "rounds" of interviews, instead of whiteboard, trivia etc.

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

#212

Post by nness »

esoterica wrote: post #65

Anyone who interviews at a "prestigious" company and then complains about how difficult the interview is kind of hypocritical. Google, and other FAANGs/unicorns, make you solve hard algorithms questions because they believe - correctly or wrongly - that in order to succeed as a company they have to filter out the vast majority of candidates who have poor algorithmic skills. They also pay a lot of money because that's…

I'm going to provide no justification; but just say that that sounds very "drink the cool-aid."

If you have such a high hiring bar — and you still get a sexist memo, or vocalised hate-crimes on your platform, or salary suppression, or workers being disallowed from using the bathrooms, or 20,000 employees staging a walk-out because of bonuses awarded to perpetrators of sexual assault... Maybe your a hiring bar is lower than it should be.

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

#213

Post by lowercased »

yitchelle wrote: post #209
lowercased wrote: post #11

Earlier quoted context omitted.

I had a google recruiter reach out a couple years back, and I asked for just some ballpark idea of salary range. No dice - they wouldn't discuss even a ballpark range until I'd flown and and given up a couple of days or my time for travel and interviews. I didn't followup.

Alternatively, and to show that you know your own market value, you respond back with your salary expectation.

alternatively, to show that they're not wasting my time, they could just answer the question.

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

#214

Post by kaidax »

akudha wrote: post #211
Someone1234 wrote: post #5

> Your interviewers try to understand what it feels like to work with you on a daily basis. If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is? I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design th…

5-6 years ago, I went for an interview in a real estate company. The introductions lasted all of 2 mins. Then they took me to a computer, showed me a bug in the code base that I would be working on, if I got hired. Then they said "please fix this". Took me about half hour or so to hunt the bug down and fix (it wasn't hard, but it wasn't a cosmetic bug either). Then they asked me how I found the bug. I explained, they…

Some companies abuse this style of interview to get free work done by interview candidates and then reject them.

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

#215

Post by rlpb »

periferral wrote: post #81

I interviewed for a Product Manager role at Google and my experience was awful. Put this things in perspective, I was a Director of PM managing a team at my current role and working a lot with customers, presenting in speaking engagements etc as part of my day to day. I get into the interview and the person on the other side seems to know very little of my background. He says he is a PM and starts with how much is go…

> He pauses and says give me a dollar value.

He asked you for "how much is google's spend" and you finished your estimations without giving him a dollar value? Did you forget his question?

> He doesnt want to understand the logic behind the calculations.

From your description that sounds like a false assumption to me. It sounds like despite your estimations you didn't give him an answer to his actual question, and so he had to prompt you.

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

#216

Post by swypych »

kaidax wrote: post #214
akudha wrote: post #211

Earlier quoted context omitted.

5-6 years ago, I went for an interview in a real estate company. The introductions lasted all of 2 mins. Then they took me to a computer, showed me a bug in the code base that I would be working on, if I got hired. Then they said "please fix this". Took me about half hour or so to hunt the bug down and fix (it wasn't hard, but it wasn't a cosmetic bug either). Then they asked me how I found the bug. I explained, they…

Some companies abuse this style of interview to get free work done by interview candidates and then reject them.

Sounds like a pretty inefficient way to fix bugs.

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

#217

Post by d--b »

I have never interviewed for Google so wouldn’t know if that’s actually how it goes. But that sounds like how I run interviews myself. I think of myself as a fairly good interviewer, and I’ve accepted people who totally bombed the actual question, but in the way they behaved and talked and thought seemed to be a good fit.

Hiring is hard, and I do think asking hard questions (on any subject really) does show a lot of the candidate...

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

#218

Post by rademacher »

All anecdotal evidence points to arriving at the correct, optimal solution as being key to passing the interview. It also seems like often times the interviewers are not even going to be working with the candidate so their opinion on a 'working relationship' is mostly irrelevant.

The objective of asking these leetcode style questions is to find candidates who are willing to put in the time to study. Success signals that this person is willing to commit to performing well at something that is reasonably challenging. The end result is that they are trying to hire worker bees. This makes sense as the bulk of work at any large company is largely mundane and relatively routine. I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense, although at that point the candidate is already well known in the industry most likely.

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

#219

Post by tomhoward »

throwawaymath wrote: post #103
dominotw wrote: post #20

Earlier quoted context omitted.

I interviewed there last year. Definitely didn't get brainteaser type questions.

So what, we downvote people for volunteering contrary anecdotes now? Come on HN.

It's not downvoted.

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

#220

Post by dsr_ »

akhilcacharya wrote: post #154
Someone1234 wrote: post #5

> Your interviewers try to understand what it feels like to work with you on a daily basis. If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is? I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design th…

>If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is? I hate this meme so much. I personally have seen situations in my own work several times in the last few months where knowledge of algorithms, even on the leetcode medium level, was immensely helpful in finishing the job. If you can do it quicker and more fluently, yo…

Depends on how narrow your specialization is.

I remember that there are test patterns built into T1 CSU/DSUs, but not what they are or how to turn them on -- if I need to know, I'll look it up.

I remember that there are three QoS bits in the IPv4 header, but not where they are. Probably pretty early, because of hardware implementations.

I remember that lots of people look down on Perl 5's object system, but not why. I remember the existence and purpose of lots of Perl modules, but not the interfaces.

I edit JSON and YAML every few weeks, but I don't have a conscious recollection of the rules -- they're prompted by looking at what's already there.

I can guesstimate Big-O notation on most chunks of code, but I'll be fooled when there's a function that's hidden in a library because I generally don't have those memorized.

I can tell you the bandwidth of lots of hardware interfaces, and the relative efficiency of speed and efficiency of storage for a handful of RAID configurations -- the ones that I set up, and the ones that I avoid.

I know one firewall configuration tool reasonably well, which means that I look up esoteric bits, and have used so many that I expect to do common things in all of them with a quick examination of the language.

I currently know a fair amount about GDPR and why it doesn't apply to my company (and how we can assist customers with their GDPR requirements) and lots about the Massachusetts and Virginia data privacy law. Very little about PCI compliance, but my point is: if my company wanted to do card transactions, I can figure out what I will need to learn to write a good policy and get it implemented in a way that won't embarass anyone.

In short: when the job is the same thing over and over again, you memorize the details. When it's always something new, you need a broad overview about what can be done and where to find the details.

Post reply on HN