And usually, at the level you're talking about, you're probably going to be using a library that's been custom built for the problem you're dealing with.
Amazing how many people will yell out "don't reinvent the wheel" but would also not hire you because you'd choose to just use Apache Commons instead of writing your own sorting algorithms from scratch.
But these algos are developed during months or years of research, team meetings, white boarding and experimental prototyping.
These things are not developed under the pressure of a ticking timer (well, technically there is the time constraint, but usually the limit is more than 30 minutes).
Also, the problems are very palpable and concrete and the drive to solve them is much stronger than in an interview, where the anxiety of failing the interview hangs over your head.
Basic CS/Math/AI/Physics knowledge affords you a starting point that's further along in the development/tweaking of an algorithm. That is NOT the end point. Its simply - knowing whats out there.
If you start with "well let me go read about whats out there" you will only have time for superficial knowledge from wikipedia or what have you. Because that starting set of knowledge takes years to accumulate. Testing whether you have this starting set is a crucial setup in knowing whether a candidate is going to constantly end up wasting time reading up on basic stuff. You can't build a plane by opening a high school physics book.
One other thing is that when you have a broad enough set of domain knowledge in your head, its much more likely that you're able to connect the dots cross-domains. This is essential if you're going to be doing some interesting algorithmic work.
Of course, all of what I said is predicated upon you being interested in that sort of work.
More than likely you'll be working on a team, where you need to understand some of these concepts, and you'll grow in to them. Almost every single person on that team did not come in off the street with expert knowledge in those domains.
It is the difference between being able to say, "I can code anything... some things are just harder than others." and "I can only do web development, and cannot be put on project requiring CS or advanced math."
Which does not mean you need a CS degree - on the contrary, I find self-taught coders to be quite good. But self-tech yourself at least some CS knowledge as well.
I might not be the best programmer, I'd say that I'm about 'average', but I have about 20 years of experience building apps in a dozen programming languages and operating systems.
I could count on my fingers the number of times I had to solve a problem similar to these tech interview puzzles, like 'count the number of mushrooms that a person can collect in M steps' or 'How many jumps can a frog make' or whatever.
My issue is understanding the problems, because they have nothing to do with what I usually have to solve on a day by day basis. Added to that is the fact that many problems have some irrelevant clauses, just to fuck with you :).
Yes, you want the most efficient solution for a tight loop that runs on a list with a gazillion elements, but in a typical application, it's usually the only place where you need to apply deep CS knowledge.
And that thing has to be researched, usually a 10-minute investigation on google/stack overflow or just steal the solution from someone smarter than me on github, even if it involves translating it to a different programming language.
That's how the real world works.
99% of the code deals with APIs, UIs, file formats or network protocols, etc. Real, palpable stuff.
What worries me is that now these interview things are being automated and your 10 minute half-baked solution is being tested against huge datasets with all the possible corner-cases. Good thing in theory, I guess, but still irrelevant for the real world.
I've worked with interview ninjas who couldn't put together more than a console application.