Something about the "non-programming programmer" articles gets under my skin. Sure, I can reverse a string without using in-built language features; hack together a recursive Fibonacci algorithm; and solve FizzBuzz. In fact I just did them to make sure. But it seems extremely limiting to use these as a screening process, particularly if they're being done on paper.
There's an elitism, a snobbishness here that I don't like. There's an assumption that people who don't think in a certain way aren't real programmers.
I had a working solution to each of the problems in a minute or so, but that included at least one incorrect iteration per problem. I know that the most efficient way for me to work is to roughly hack out the code then refine it. That's one of the reasons I like TDD so much - it makes my iterations quicker and more accurate. Writing code on paper is something I'd probably not enjoy, even for these simple examples. Rather than quickly iterate, I'd have to plan up front. Which of course I can do, but it's sub-optimal.
If writing code is going to be a part of the interview process, it should be done in whichever IDE the applicant is comfortable with. But even then it should only be one factor in the evaluation. Even for a straight up code monkey job, a developer's capacity to learn, explore and communicate are at least as important as how quickly they can solve trivial puzzles.