>Shifting to CS, how do you even know a specific algorithm/data structure might help with your problem if you don't have a rough idea of its specifics?
In general, these things are well implemented in either the base language or a library, and thus both easily searchable and well covered in practical examples. It's unusual for 9-to-5 non-R&D developers to be solving a problem which hasn't been solved before at the algorithm level, the job usually revolves around connecting pre-made components together and specializing them. As such, you really only need a loose knowledge of the fact that things like binary trees exist. Being able to hand-write one isn't useful and may be a liability depending on the temperament of the developer.
Your hand-rolled implementation is unlikely to perform better by any metric than the pre-made one, and it'll probably be less platform independent and more buggy simply because it's newer and looked at by fewer people.
In 95% of all software development today, rolling your own version of any off-the-shelf algorithm is a mugs game and actively bad practice because it places the foundations for technical debt. You really don't want to be hiring people who roll their own just because they can.
Now, if you're going to be working in the R&D or experimental areas of software development, kind of where the Oculus driver crew are at the moment (as an example), then sure, you definitely need to know the inner details of these things.
The problem is that we're interviewing everyone as if they're going to be writing high-performance drivers, when most of them are never going to work at that level and wouldn't want to.