I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc.
For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in fact, for the most part algorithms are probably not even part of the interview. I may ask them to still start solving a really simple problem -- it may or may not make it all the way to code. If someone starts writing/mapping out their database first that tells me something, I can ask why they are breaking their objects where they are, etc.
I like to ask "what's important" in the context of components - I use the example of a bunch of HTML documents to frame the context. If I'm looking at 10 similar HTML documents, what can I do to find important information? (Strip out things that are the same). So if I'm doing 10 interviews, what do you think is going to be the same (user/session management if there are accounts would be an example) and what do you think will allow you to differentiate yourself? For some people, they'll think about what they're strong in and how it applies to the problem, for others they'll focus on the problem space.
At this point you've spent 15-25 minutes talking if they're a good candidate and written no code by starting with the "write code" question -- I think you could get a great 60m interview without writing any code even though you started with a "write code" problem.
My opinion on interview questions is they're just conversation starters -- if you just go down a list of questions I just don't think its a successful interview. I really like VERY open ended questions where the candidate can have a chance to tell me why they're great. I really try to only have 3 or 4 questions for the interview and hope to only get to 1 or 2.