Live data from Hacker News

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

threader.app

291–300 of 432 posts

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

#291

I have recently interviewed at most of these companies, eventually managed to get some good offers at some of them, but let's be honest, I had to invest months in getting prep for the tech screening, whiteboard coding exercise and the whole non-sense jazz. I am sick of reading this blog posts because everyone knows, that is not how the majority of these interviews are conducted. I have more than 10 years of experienc…

As much as I agree that the process is bullshit, it is no different than studying for an exam, something we took for granted during school, just as a mean to an end (a degree), except that in this case there is arguably a much higher ratio of payoff/effort.

There is no mystery involved, one of the more known books on the subject is "Cracking the Coding Interview", but really there is no mystery to crack.

There is a ton of literature, tools, examples freely available on the Internet, all that is missing is time and effort to go through them and learn them as if it were for an exam.

One of the main objection is "Why I should spend more time in doing something I already do full-time at my job, where I'm perfectly qualified?", but to me it's pointless: if you think getting hired by another company will improve your life significantly (or even marginally), it is something you should definitely put effort into.

At the very least, this process (aside from those lucking out) proves that the candidate is able to understand a non-trivial problem (getting hired) and have the ability and put the effort necessary to solve it (going through the bullshit excercise and questions), as it was in your case.

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

#292

Earlier quoted context omitted.

"If you browse my link you'll see that Google continues to ask off-topic questions, even if they aren't riddles or brainteasers. " I have read literally thousands of interviews at Google (both on hiring committees for 10+ years and in the group that reviews hiring committee decisions), and i just don't encounter them much. I can't even remember the last time i read this type of question. I suspect your definition may…

The problem is off topic questions, especially for more senior developers who have specialized extensively. For example, I haven’t used or seen used dynamic programming since college because my area doesn’t really use it. If I didn’t cram in interview prep for these questions, I’d be toast.

I get it (really!), but balance this against the fact that many companies promote people just for surviving at the company long enough.

I've seen principal engineers (where this was the top of their ladder) that literally couldn't tell me what a hash table is.

For domain experts, Google actually does target domain specific areas (in at least 1 interview) and weigh it against how good people are generally.

However, I suspect most people think they are specialized experts in things they are not.

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

#293
post #211

> 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…

My current company does this. But instead of leaving the interviewee on their own, we do it as a pair programming session where they are the brain and the interviewer is the hands implementing it. Gives you a sense of how they think and a better look into how they work day to day.

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

#294

Google believes, as so many before them have, that the ideal candidate can be found through numbers: pure, unbiased, beautiful numbers. Because once you reach a certain size, your biggest threat is no longer your competitors, but rather your regulators, and that means that you must not expose yourself to regulatory (at the core, social) risk. Bias is bad. Discrimination is bad. And if you're big AND bad, you get fine…

I think BigCorp prefers to bring on the strange/quirky talent through acquisitions and acquihires, rather than through the front door. That way, strange though the individuals may seem, their track record is proven.

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

#295

Earlier quoted context omitted.

Didnt the creator of home-brew not end up getting a job at google?

I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen. It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able…

You can also set up cloud storage quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. Yet, the Homebrew guy went out and made a package manager actually getting used but still couldn't get past Google's abysmal interviewing process.

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

#296
post #215

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…

Be straight with us, is that really how you read his story?

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

#297

Earlier quoted context omitted.

I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen. It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able…

Package management is a task filled with subtle pitfalls that is much, much harder than it looks on the surface. It's a lot like syncing files - e.g. how Dropbox looked similarly deceptively easy to build but really wasnt. IMHO the fact that the homebrew guy didn't get hired and that golang package management was a dumpster fire for years isn't coincidental. Both were part and parcel of a systemic bias that plagues G…

Google doesn’t do package management well because they don’t do package management at all; they have a monorepo. If anything, the systematic bias is that Google built their way around an entire class of problems that others still face.

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

#298

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 t…

It is true that you will almost never work with somebody who interviewed you. In some ways, this is absolutely terribly for hiring. I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". So we'd pre-screen people with the knowledge we needed, and then pass them off to others to officially intervie…

> I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially".

When a company policy is so obviously broken in this way and there is no way to route around it then something is very broken.

Here's how it should work. You explain the issue above to someone above you and they either have the authority to get round it or they pass it on to someone who does.

If a policy is failing in such a profound way and nobody can change it this implies a level of organisational dysfunction that must be affecting multiple aspects of the company.

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

#299

I wish someone at Google had the courage to admit how inconsistent and arbitrary the hiring/interviewing process is at Google. "Googliness" is just a qualitative lever in hiring that allows Google interviewers to enforce whatever biases they have.

[citation needed for any of your view]

The problem is that it isn't inconsistent and arbitrary, so that would simply be wrong to admit.

There is a tremendous amount of data/studies/etc to back this up, done repeatedly over time. Both independent of Google and not. Certainly much more than any other interview system i've seen suggested or used here.

As for the second, general "Googliness" is not used to turn people down - horrible communication skills/being an asshole/etc are.

Despite your claim, one interviewer noting an issue there will not get you not hired. Two or three noting it would. One noting it and then followup fit calls/interviews confirming it would.

So it's not an effective mechanism for single interviewer to enforce biases anyway.

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

#300

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 t…

Disclaimer: I haven't read the article, but I work at Google. Most interviewers will ask the same question to multiple candidates. They will compare how you the candidate is doing compared to other candidates on the same question. Most interviewers will provide hints. I'm pretty sure that all candidates go though the same interview process. There is really not much that is unique to Google's interviews. The only thin…

> There is really not much that is unique to Google's interviews

Having just gone through 10 days of on-site interviews (including two at Google), there are some things that are peculiar Google's process:

- No talk about software engineering,

- No talk about software design,

- No talk about project management, working on a team, culture of any kind, caring about customers etc etc...,

- No debugging,

- No using unfamiliar APIs, no reading documentation,

- No actually running any code.

In particular, Google was the only place I didn't actually test and run my code. It was the only place where I was given the option of doing all of my work on the whiteboard, too.

At least one time I had convinced my interviewer I had a working solution and then realised it didn't work and had to convince them of that...

Post reply on HN