Personally, I'd walk out of an interview if they started asking me these types of questions.
Unless of course, if it's a job where it'd be very algorithm-heavy to begin with, but that isn't where my interest lies.
Unless of course, if it's a job where it'd be very algorithm-heavy to begin with, but that isn't where my interest lies.
To my mind, the point isn't whether or not the job is algorithm-heavy. If you don't have this stuff under your belt, there are limits to what you can do. If you have to concentrate on working out which algorithm to use, or which data structure to use, if you have to spend time researching these things, that doesn't make you a poor programmer, but it stops you from spending time on the real problem solving aspects of the job.
The programmers I hire don't often have to do major algorithm stuff, and some of them are not comfortable with algorithms and data structures, but that's OK. They have other strengths.
But even if the job doesn't require deep knowledge of algorithms and data structures, knowing them helps more often than you think. One needs to know these things to recognize them when they turn up unexpectedly and in disguise. Well, in my experience anyway. Your mileage may|will vary.
But when I hire, I interview for, and care most about people's abilities to get things done, to work constructively with others, and to extend their knowledge, skills, and abilities. To walk away when someone asks about something you don't (yet) know, says that we wouldn't be a good fit anyway, and not because you don't know about algorithms.
Edited to remove some unintentional snark.
Additional edit: I don't know why you've been down-voted. Many people feel the way you do, and while I don't agree, you're entitled to your opinion, and I'm pleased you voiced it. I've up-voted you to try to offset the down-vote(s).
I ask people to code something trivial, on a whiteboard, in any pseudo-code they care to invent on the spot. Then we talk about the strengths and weaknesses of the code they wrote. We end up talking about algorithms, data structures, project management, quick hacks, technical debt, comments, function and method size, functional programming, and more.
The idea is to find their strengths, to make sure their weaknesses are covered by people we already have, and to see if we could work together. Sometimes we don't even agree, and it's the way they discuss the points that matters.
I'd love to see it made into a science, but I'm nowhere near clever enough to do that.