Live data from Hacker News

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

threader.app

281–290 of 432 posts

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

#281
post #227
post #215

Earlier quoted context omitted.

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

I'm fairly sure that he was speaking his calculations aloud in the process of reaching the dollar value when the interviewer stopped him and asked for an answer. It's a great interview question in the sense of a Fermi problem (I was once asked by a startup "how many window washers are there in [CITY]?"). The premises you choose and how you evaluate them, however, are so much more important in a Fermi problem than a c…

Fermi problems are terrible questions when asked about things the questionee has no concept of. The point of a Fermi problem is to make an educated guess, and doing so requires knowledge of the problem space the guess is being made in. Pulling random constraints out of your ass for a domain you do not know does not demonstrate this ability.

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

#282

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 work in a startup, with a team of 8, and you will 100% work with those that interview you :)

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

#283

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…

Actually you just have to say "Hashtable" three times and they have to give you a job.

Actually the spell is „hashtable hashtable stack pop pop push”.

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

#284
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 fined, and have obstacles put in your path.

So what does a rational BigCorp do? They make everything "fair". So everyone has the same opportunities, everyone is colorblind about cultural fairness-obsessions x, y, and z, and the hiring process becomes as effective as cardboard cake. Tick the boxes and you're in. Otherwise, there's the door.

Of course, the irony of all of this is that they end up discriminating against the very people they need: The different, the strange, the quirky, the innovative - everyone who doesn't perfectly fit the criteria of a safe hire where nobody can criticize the hiring decision (and impact your promotion prospects).

This is the social process by which BigCorp stagnation works, and it's always how it worked.

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

#285
post #227

Earlier quoted context omitted.

I'm fairly sure that he was speaking his calculations aloud in the process of reaching the dollar value when the interviewer stopped him and asked for an answer. It's a great interview question in the sense of a Fermi problem (I was once asked by a startup "how many window washers are there in [CITY]?"). The premises you choose and how you evaluate them, however, are so much more important in a Fermi problem than a c…

Fermi problems are terrible questions when asked about things the questionee has no concept of. The point of a Fermi problem is to make an educated guess, and doing so requires knowledge of the problem space the guess is being made in. Pulling random constraints out of your ass for a domain you do not know does not demonstrate this ability.

If you're saying that in regards to the window washer question, I actually enjoyed it!

The point of a Fermi problem is to arrive at a reasonable estimation for a fairly unknown value by extrapolating and connecting from known values (by known, I mean there's a more narrow lower and upper bound).

I wouldn't say that a Fermi problem about how many window washers are in a city is a terrible question; it is more challenging than something in which you already have domain expertise, but that just makes you have to extrapolate further, which is the real point of the Fermi problem. In fact, pretty easy (and knowable) starting points are the population of the city, windows per individual, etc.

Doesn't a Fermi problem without domain expertise display more critical thinking and reasoning style, while a Fermi problem with domain expertise is less of a Fermi problem, and more of a knowledge test?

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

#286
post #214

Earlier quoted context omitted.

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

That would be hilarious. Most of the value of a developer doesn’t straight out come from the code they wrote, but everything around that (design, maintenance, hardening). Getting free code isn’t actually that helpful without a lot of other stuff around it.

Not that you are wrong, but you are underestimating the dumb assholes who assume they would be cruising right on path only if someone could solve this tiny niggling problem for them.

I had to tell one moron on phone interview that they are looking for free consulting or what because they keep harping a very specific project (Java/xml etc) setting that they were struggling with. It could of course be solved in hour or so by closely looking at product documents instead of endless googling.

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

#287

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…

Weird to me how a certain type of mind sees "Political Correctness" in everything they don't like. It's a very conspiratorial mindset.

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

#288

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…

I realize you asked about people in general and not Howell himself, but he said[1] almost exactly that about his product:

Well, no I didn't [write something worthy of Google]. I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.

But he goes on:

On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user. When things go wrong with Homebrew it tries as hard as it can to tell you why, it searches GitHub for similar issues and points you to them. It cares about you.

1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin... (Quora link, sorry)

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

#289
post #285

Earlier quoted context omitted.

Fermi problems are terrible questions when asked about things the questionee has no concept of. The point of a Fermi problem is to make an educated guess, and doing so requires knowledge of the problem space the guess is being made in. Pulling random constraints out of your ass for a domain you do not know does not demonstrate this ability.

If you're saying that in regards to the window washer question, I actually enjoyed it! The point of a Fermi problem is to arrive at a reasonable estimation for a fairly unknown value by extrapolating and connecting from known values (by known, I mean there's a more narrow lower and upper bound). I wouldn't say that a Fermi problem about how many window washers are in a city is a terrible question; it is more challeng…

> Doesn't a Fermi problem without domain expertise display more critical thinking and reasoning style, while a Fermi problem with domain expertise is less of a Fermi problem, and more of a knowledge test?

A Fermi problem is both a test of knowledge and a test of reasoning skills. The types of estimates Enrico Fermi was known for were only possible because he had the domain knowledge for his reasoning to leverage. If you remove the domain knowledge from the problem you remove a significant amount of the signal from trying to concoct the estimate. It is a much easier problem if you can just make up numbers rather than infer accurate guesses from the domain.

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

#290

To any hiring managers that might be reading this, please watch this alternative method of interviewing: https://www.youtube.com/watch?v=cfyWvJdsDRI

Thanks for posting this! I tend towards the much more conversational interview to get the candidates talking, though this has some handy examples of going beyond the candidates CV and drilling down into the technical details that I'd like to appropriate.

I also have the tendency to take a bunch of whiteboard pens etc into interviews I'm running in case the candidate explains things better using visual aids.

Post reply on HN