News for hackers. Stuff that matters.
Re:How to hire engineering talent without the BS by rr808 on Sunday March 05, 2023 @08:54PM (#35036602)
Google is one of the greatest companies in history, measured both in technology and business performance. Sure, not everything is perfect.
Re:How to hire engineering talent without the BS by bee_rider on Sunday March 05, 2023 @09:09PM (#35036692)
When did they start doing leetCode style interviews? LeetCode looks to have been founded in 2015; of course, though, that doesn’t mean Google couldn’t have had a similar in-house format that predates that founding…

But it is hard to say how much leetCode style interviews helped. Post-2015 Google already had quite a bit of momentum.

Re:How to hire engineering talent without the BS by rr808 on Sunday March 05, 2023 @09:59PM (#35037040)
They always used to be famous for dumb questions that made you think like how many golfballs can you fit in a school bus, why are manhole covers round etc.
Re:How to hire engineering talent without the BS by YZF on Sunday March 05, 2023 @11:11PM (#35037448)
You're thinking Microsoft: https://sellsbrothers.com/12395
Re:How to hire engineering talent without the BS by urthor on Monday March 06, 2023 @05:38AM (#35039464)
Everyone did it.
Re:How to hire engineering talent without the BS by conradkay on Sunday March 05, 2023 @10:19PM (#35037153)
My understanding is that LC style interviews largely replaced "brain teaser", "how would you move mount fuji?" type questions so at least you're testing CS concepts and basic coding ability.

Cracking the Coding Interview came out in 2008 and had a short section talking about the Google interview process, which I believe was system design + a coding problem that would probably be close to a modern LC question.

Re:How to hire engineering talent without the BS by randomswede on Tuesday March 07, 2023 @03:24AM (#35052967)
I am cusrious what you mean by "LeetCode-style". My understanding is "present a problem, only take the resulting code, judge that".

I did a fair number of coding interviews (for SRE positions) at Google (I don't actually know how many in total, but 25-30 is probably a safe guess) and, yes, it started with a small problem that should be solvable in well under half the interview time. I only used problems that passed my "is this fair to the candidate" screening (look at problem, try to write a working solution, if that takes more than 7 minutes, the problem is not fair).

The value in the interview comes from (a) listening to the candidate narrating their thought process during the coding, (ii) discussing the solution with the candidate, sometimes in terms of complexity, sometimes in terms of correctness, depending on what is on the board, (3) refining the code written (add more functionality, change functionality).

For a language I knew, I tended to overlook small syntactic mistakes (a whiteboard does not have any syntax highlighting) and if there was any questions about library functions, I would give an answer (and note down what I said, so that would be the standard used when judging) and the bulk of the score came from the discussion about the code, not the code itself.

If that matches what you mean by "LeetCode-style interview", that's certainly been in place since at least 2011. If it does not, things may have changed, but at least the aim wit ha coding interview back when I was still at Google was less "get some code judge, on the code" and more "get some code, judge the discussion about the code". It is also entirely possible that interviewing for SWE positions was different frmo hiring for SRE positions.