Live data from Hacker News

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

threader.app

381–390 of 432 posts

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

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

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

I can't speak for rlpb, but it's how I read it, albeit not with much confidence. Why? Because "he pauses and says ..." doesn't fit with the interviewer interrupting and not waiting for the answer to be finished -- there must have been enough of a gap for the interviewer to pause and then ask that question.

[EDITED to fix a typo.]

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

#382

Earlier quoted context omitted.

And how would an outsider have any idea of the cost do you just mean the plant costs how much does google pay per MW in each locale how much does labour costs what allowance for accrued pension rights.

Wow. Feel free to use some punctuation here and there. That's annoying to parse as written.

I wonder whether there were some line breaks that C1sc0cat was hoping would remain as line breaks instead of being treated as spaces...

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

#383
post #245

I wonder if they have done the experiment where after some basic screening, a relevant work history and decent personality that if you just randomly admit them if they do just as well as anyone else. You could still do the algorithm problem solving style interviews but just don't make a rejection decision based on them. The idea here would be to randomly approve people who would normally be rejected and see if they d…

That’s sounds like a very interesting, expensive, and borderline unethical experiment. I don’t think it’s fair to play with people’s lives like that, and firing those who don’t work out sounds like a nightmare, but I’d love to see the data that would come out of such a study.

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

#384

I'm reminded of an amusing rant by Adam Carolla: "I had no idea how… f*ckin horrible most people are at their jobs." https://www.youtube.com/watch?v=i6GVt35Eoz4 Definitely includes tech-interviewers. As I get older I've started pushing back on these bad interview decisions, but can't help feel it's a losing proposition without support from fellow developers.

Can you give a couple examples of questions you’ve pushed back on? How and why did you do so?

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

#385

This is ridiculous, you will be given a no hire recommendation by the interviewer at a FAANG company if you do not provide an optimal solution. This is very well documented on sites/apps like Blind and accurate from my personal experience. It's corporate double speak to state otherwise. Can't give an O(N) solution but come up with a correct O(N^2) solution? Too bad - go do more Leetcode.

For most companies, it’s not doublespeak, it’s outright lying. My successful interviews have been 100% correlated with times I’ve gotten to the optimal solution.

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

#386

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…

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).

I work for Google as a software engineer and now also engineering manager.

There is no plausible mechanism by which a decision that anyone makes on whether to hire a candidate could affect that person's promotion prospects.

Interviewers don't make hiring decisions directly, they merely individually make recommendations to a committee that reviews these recommendations (along with other info like the candidate's resume). I have never heard of hiring committee "reporting" someone for recommending they hire someone "weird" or "bad" -- it would be kind of absurd. If you don't like the recommendation, don't take it! Similarly, hiring committee members are not going to be "written up" for making "weird", or "bad" recommendations. There isn't even a group of people who could plausibly do this.

There is plenty to criticize about how Google hires. But I disagree with what I read as the thesis of your post that we have to choose between a biased process and an effective one. Indeed the problem you identify is what I would describe as bias against people who don't fit a particular mold, people who are unusual or "weird", and so really what I think you're saying is that in trying to fight e.g. gender bias, we have introduced new biases.

I also don't think that's true. The counternarriative I'd propose is, we have always been biased against what we consider to be "weird" people, that's human nature. What we've been trying to do is change people's perception of what is weird, so that e.g. female or black coders aren't. That's what unbiasing is about.

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

#387
It's very clear that the interviewer bias is very important on the process. It shouldn't be. On my case, I got a relapsed interviewer that was working on his laptop while I was designing the service he wanted and another that wanted a very specific and canned solution for the very specific and canned problem he threw at me, instead of trying to understand my different approach for the problem.

2 of 5 bad interviewers. I left with a bad taste on my mouth, with the feeling that I didn't failed because I was not skilled / prepared enough for the company, but just unlucky for getting a bad set of interviewers. If was just me with that feeling, I would agree that I was biased for not receiving an offer, but I see this happening a lot with good engineers and throwing all the responsibility on the interviewees shoulders with "You are bitter for not receiving an offer" or "gitgud" arguments is just avoiding the discussion.

Anyway, it's their process and if it's working for them, they have no reason to change. Just stop advocating as it is a nearly perfect hiring process: it's very clear that is far from it.

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

#388

Earlier quoted context omitted.

I wasn't implying that the interview was easier for candidates with recognizable track records. Perhaps two sigma was not restrictive enough. I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. Do you really want to remove bias for experienced candidates with a track record of substantial and nontrivial contr…

> I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. To put in bluntly, if you are such a candidate you are expected to know your algorithms cold and be expected to field your domain specific questions. So if you're a well-known compiler designer you would still need to know how to wield algorithms/datastruc…

> you are expected to know your algorithms cold and be expected to field your domain specific questions

...why?

You're holding candidates to high standards, fine, that's great. Compiler designers even need some deep algorithms and datastructures knowledge; you can't ensure your hashes are thread-safe unless you know exactly what they are, how they handle collisions, and so on. All that's totally fair to ask as part of their domain knowledge.

But the criticism of this sort of interviewing (and Google in particular) overwhelmingly describes interviewers judging domain experts on whatever algorithms puzzle they give every candidate from every domain. Why do we care whether a compiler design expert remembers how to implement Ford–Fulkerson on a whiteboard? Is there any reason to think that's predictive of talent? Might it even be anti-predictive because it favors generalists?

Google (and FAANG, and everyone else in that league) hires great people. I don't doubt that. But it was also hiring great people back when it posed random brainteasers and emphasized GPA, and Google has publicly said those things turned out to be totally uninformative. If you filter down to a list with more highly-qualified candidates than you can hire, I think there's a tendency to come up with random extra hurdles to avoid resorting to a coinflip that might work just as well.

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

#389

Earlier quoted context omitted.

> I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk. To put in bluntly, if you are such a candidate you are expected to know your algorithms cold and be expected to field your domain specific questions. So if you're a well-known compiler designer you would still need to know how to wield algorithms/datastruc…

> you are expected to know your algorithms cold and be expected to field your domain specific questions ...why? You're holding candidates to high standards, fine, that's great. Compiler designers even need some deep algorithms and datastructures knowledge; you can't ensure your hashes are thread-safe unless you know exactly what they are, how they handle collisions, and so on. All that's totally fair to ask as part o…

Without getting too pedantic, it can be difficult to define what encompasses "expertise". You could have worked on some backend payment system for years and conclude that you're a payment "expert". But that means different things to different people.

Not all current "experts" are necessarily hired into corresponding roles needing the same expertise. To put it more concretely with an example, it's entirely possible for you to be a payment system expert but have a recruiter reach out to you for a general SWE role (you're welcome to decline). The slate of roles that do require said expertise are limited. If there's 10 qualified candidates, they could all technically pass the hiring bar. But if there's only 7 positions that require that exact expertise, then what happens to the other 3? Well, they're broadcast to "matching" teams that have available headcount. This "match" could be approximate, but it underscores why getting a signal beyond just the domain expertise is important.

We could of course debate whether something "advanced" should be asked, but that would require us to agree on what constitutes "advanced". In general, it's difficult to pin point some threshold and unanimously agree that that's the level of difficulty of generalist SWE questions that a domain expert should get asked. For what it's worth, there's additional intervention by committee(s) that look at this on a case-by-case basis to make sure that everything's on an even keel. Concretely, if you're an ML expert interviewing for a role that specifically demands ML-expertise and you were asked some advanced question about data structures (ex: something needing the Hungarian algorithm) and you're upset that you bombed it, the don't be; the committee(s) would weigh that interview's score less if they expect something alone the lines of Maps/Queues to be asked instead. These are all made up examples, but I hope that it conveys why there's a need to extract signal beyond just core-expertise. Google doesn't just artificially create hurdles for sadistic pleasure ¯\_(ツ)_/¯

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

#390

Earlier quoted context omitted.

Recruiters ask horrible questions. If the recruiter has to ask you a technical question, it will be a bad question, because the recruiter doesn't have the expertise to understand the answer. So you're left with bad questions which have single answers, mostly involving rote memorization.

But the recruiters are told by the SRE team to ask questions like this to candidates before they get a phone interview. I don't see any value in that, but then I don't work as a Google SRE so I don't know what is important to them. It is also possible that they are lacking SRE interviewers so they need to ask stupid questions to get down the amount to reasonable levels.

Like I said in a different thread, the recruiters need simple questions that they can verify without any expertise.
Post reply on HN