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.
