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.

>ex-colleague of mine who is not specially bright studied 3 months how to "crack the coding interview" and got a job at Google.

Sounds bright to me.

So how they did in one job interview says more about their intelligence, to you, than GP's witness from knowing them for possibly years?

I think your weights are way off.

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.

I’m trying to think of how many tree structures I’ve encountered in all the projects I’ve ever programmed on, in my entire career. Maybe one or two?

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

You probably aren't the demographic Google want/needs to hire by the sound of it.

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.