Doing a string reverse is so trivial that it's not about needing that skill, but rather what not being able to do that speaks about the candidate's general aptitude and skill level.
If that question can't be answered then your opinion on someones skill level is irrelevant. Also, if you've got time, answer the questions in my first post:
"How old are you? Have you hired developers before? Truthfully, have you ever had to reverse a string under pressure at your current job."
The only way this question wouldn't be useful is if you had a good filter such that almost everyone who gets to that point would answer that question correctly. But apparently, this is not the case. There are people who fail such tests (despite apparently good paper qualifications and ability to talk BS). It's fairly important that you not let through such imposters.
And yes I've hired people and all of them have had to answer much more complex algorithmic questions to get the job and all of them turned out to be competent. And "have you ever had to" questions are ingenuous - interview settings are never going to be replicated exactly in a work setting, unless your job is to go around to be interviewed for different jobs. Good interview questions don't simulate work setting - they extract most critical work-relevant information about the candidate without wasting time.
So...I'm hiring someone that can reverse a string because this demonstrates that they can program real things that real people use?
"And yes I've hired people and all of them have had to answer much more complex algorithmic questions to get the job and all of them turned out to be competent."
Out of interest, what did this job entail? I assume that you quizzed them on their knowledge of basic algorithms because they are required to write them, right?
The difference between reversing a string and pulling data from a database are, literally, completely different tasks. The killer is that the latter is something that a candidate will do in a job.
You're more than welcome to ask those questions, and you're probably likely to weed out the lowest common denominator types. In my experience, they're a waste of time and the best possible interview you can give to a developer is a frank face-to-face discussion about programming, and then getting them to work on a test project for two hours from your own code base. If they can do that much they can program.
Why can't you do both? Seriously? Pulling data from a database is orders of magnitude harder to get right than reversing a string.
And this is where you misunderstand the purpose of these types of questions. Programming is a very dynamic field where you're likely be required to solve novel problems daily (not novel in the grand scheme of programming, but novel to you). You need the mental flexibility and fluidity to solve problems you haven't entirely encountered before. Testing specifically what you do at the job is the wrong approach. You need to test the required mental faculties to solve novel problems. Programming is not pulling data from a database, writing glue code, and shoving it to the screen. It's solving new problems every day.