> the kind of people who need to cram leetcodes and memorize algorithms are not the kinds of people who Google wants to pass these interviews.
I thought it was exactly those who Google wants to pass. Anecdote: ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google. His knowledge about algorithms and data structures was like mine: I know what a tree is, I know there exists operations one can perform on them and some of them are more performant/efficient than others... but I would need to Google how to "reverse a binary tree" if I had to do it in less than 1h.
I read an article recently about Google’s fairly awful interactions with HBCUs (historically Black colleges and universities). One thing that caught my eye was Google’s disapproval of seemingly standard CS programs in favor of a syllabus for cramming algorithms into student heads. That was one of their excuses for hiring differentials.
The "reverse a binary tree" problem gets often brought up as one of these tricky algorithm problems that you just have to know. However, the "algorithm" is to just swap all of the left pointers with the right pointers in each node.
The biggest difficulty for most seems to be that they don't know what "reverse a binary tree" actually means. It sounds kind of mathy and opaque, so I get it, but candidates should be able to have a dialog to figure out what the requirements mean. And on the flipside interviewers should be ready to have that dialog and not count not knowing the term by heart against the candidate.
This problem to me feels qualitatively different than the "rabbit and hare" algorithm for finding a loop in a linked list mentioned by another poster. That one needs a non-trivial algorithmic insight that just might not come to you during an interview. The solution to "reverse a binary tree" flows out of the structure of the problem statement as long as you have the fundamental skills for walking and manipulating data structures and the conversational skills to understand the problem, both of which seem fair to test for.
I think being able to pass a FAANG level coding interview with 3 months prep is a better indicator of their intelligence than one coworker's opinion, which could be clouded with biases.
And I think the vaunted "FAANG level coding interview" is a prime example of a setting where three months of hard swotting can make even a relatively dim bulb shine brightly.
A tree for performance? I've used a rope once or twice.
Plenty of times where I've used trees because they're the logical representation of the problem (ever had a field called "children" in your code? HN comments are a tree. Etc.)
A perusal of Google's recent software track record would indicate that optimum efficiency aided by a wide knowledge of a library of algorithms and manual implementation of the same is either not what Google actually cares about, or if it was what they think they care about, not effectively delivered by the steps they take to achieve it.
I thought it was exactly those who Google wants to pass. Anecdote: ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google. His knowledge about algorithms and data structures was like mine: I know what a tree is, I know there exists operations one can perform on them and some of them are more performant/efficient than others... but I would need to Google how to "reverse a binary tree" if I had to do it in less than 1h.