Well hopefully there's some layering in the question if it matters to the job. If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate.
> If you have an engineering position in which a high degree of CS competence is required and the candidate can't even make it past the initial layer of "regurgitating binary tree operations" then you have the wrong candidate.
Or you have a candidate who understands binary trees, can implement it but can't regurgitate binary tree operations from the top of their memory.
For me the point would be that a no-frills binary tree is simple enough that any dev qualified for such a position should be able to figure out what needs to be done from the specification, without needing to regurgitate anything.
If they can't recall how balancing is done that would be fine with me, as long as they mention it.
Exactly. And that's the reason you'd probably layer the question with some more complex asks after the initial answer. If somebody has memorized the algorithm but then can't explain further, it's obvious they've "regurgitated" without really having a deep understanding of the problem being solved with the data structure. By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly.
> By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly.
I know dozens of good candidates who can't get there pretty quickly but are really good. I also know dozens of good candidates who can get there pretty quickly but won't be good enough on the job.
Maybe they'd be really good at other engineer positions, but if they can't get to a binary tree algorithm reasonably fast I wouldn't hire them for backend positions that require CS reasoning.
> Maybe they'd be really good at other engineer positions, but if they can't get to a binary tree algorithm reasonably fast I wouldn't hire them for backend positions that require CS reasoning.
You not hiring for backend positions doesn't mean they are not good at the positions. It just means they aren't good at your signals.
For me it's a strong signal, but it shouldn't be the only signal. And I do think it's good to have a diverse team.
Some of my coworkers are not nearly as strong as me when it comes to "CS details" like data structures or programming languages, but they have other attributes which complement me and which are good for the team.
Having a bunch of me's (or any of the others) would be a disaster.
find = lambda k, t: t if t is None or k == t.k else find(k, t.left) if k < t.k else find(k, t.right)
I mean, figuring out how to rebalance a red-black tree after insertion is more demanding, and you could legitimately quibble with my golfing here, but I feel like the reasoning required to write that function (given the tree definition) is just not that advanced. It's like the FizzBuzz of pointers.
