This is still a terrible problem. It's simple exactly because it is familiar to the interviewer. It's easy for them to believe that anyone with half a brain should be able to answer it because they've practiced it a hundred times and have forgotten exactly what it is like to not know the answer.

I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you. They're looking to avoid causing you to press the big red button that gives them the electric shock and sends them home feeling like they're the most stupid person on Earth for not solving the easiest algorithm problem known to human kind.

I get it though: as people who have to interview potential hires it gets tedious wading through the muck. Personally I don't understand how you can interview someone for a senior position without reviewing their prior work. I also find it rather insulting to assume that we should just separate them from the wheat just like all the other chaff. It's just disrespectful IMO.

I'd done a lot of interviews about a year ago. All but one of them used a programming test of some sort. From fizzbuzz to fibonacci to splitting words, finding palindromes and implementing FIFO queues. I did it all. Some of them I got right. Some I didn't. Even the ones I had practiced and came to know really well... sometimes even then I would blow it. It was a really disheartening experience and I almost gave up programming forever when I started to believe that rigmarole about how any programmer worth their salt should be able to solve these problems without thinking about it.

Which got me to thinking. I can solve these problems easily. I've got my algorithms books, I practice code kata, and I can generally golf some problems off the top of my head and they'll often compile. Why can't I do this in front of other people?

The psychology of the situation is what gets in the way. If you give a candidate a problem they're going to immediately begin to think about what you want them to say. You say it's not trivia, but that's the exact mental process that will happen in most people. Given such a problem I'm certain a good number of candidates I interview would be able to solve them on their own. They might even be able to white board them once we start working together and they get to know me. But while we're in the interview room I'm the gatekeeper with the big red button and they've doing everything they can to keep me from pressing it. That doesn't work for me because I know that's not what I want from them.

When I hire someone I look for initiative, experience, and intuition. I look for people who have taken what they've been given and made something more for themselves. If at their last job they weren't happy with something I'll ask what they did to change it. I also like to test their experience. I ask design-type questions, ask them what they like about their tools, what they don't like, patterns they've seen, how they practice... things like that. And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code. IMO, these are the sort of things that I think demonstrate a person's knowledge of programming.

And from my experience I think it's a better way to find good candidates.