I've never understood the whole emphasize on testing technical skills during the interview phase. In most countries it's either easy to fire someone, or you have legal probation period.
One month of employment should be enough to find out if someone has the practical skills they've expressed in the interview, and catch the 1% that can bullshit their way through.
Of course that 1% becomes a lot bigger number if the interviewer doesn't know what they are talking about. But that's not a problem you can solve with tests.
Some people are good at talking about coding (or pen testing, or sysadmining, or architecture, or...) but when you put them in front of a blank black screen with a cursor they're incapable of making forward progress.
It's five figures cheaper to ask everyone to FizzBuzz than it is to fire someone even after a week, and God help you if they're in a protected class.
Sadly, I've been that person. I read pg essays, blogs about programming and watched various videos about programming for about 3 years before finally deciding to leave my relatively comfortable small-business as an EFL cram-school partner and start actually coding stuff. People have been absolutely amazed by how little I know compared to how much I sound like I know.
Fizzbuzz wouldn't have filtered me out of getting my first (and current) real software job, but any sort of Google/MS-style interview would have. It may not be the wisest thing to admit to on the internet, but I'm basically in the opposite boat of your general target on HN: I'm fine with selling, but limited (non-EFL) skills to sell!
That, along with seeing numerous senior iOS dev applicants struggle both with Fizzbuzz and with Macs in general, has convinced me that it's more than worth it to test candidates without code portfolios.
The opposite, of course, is true. I've never been in a situation in the real world where, given a problem, I jumped immediately to a white board and felt I had to come up with a solution while being tested by people I didn't know. I have, however, had the joy of being given questions that could literally not happen, with requirements that cannot be met, all with the intent on seeing how I can think. Oh, and with no time to think, either.
If you really want to test how someone thinks over questions like that, actually give them time. Give them the questions before they show up for the interview. Then go over their solutions. They aren't under pressure, they give you a thoughtful answer, and you get a better sense of what they can do in the real world.
Just last night I took an online test as a prescreen for a job I'm interested in. I guess this firm is C++ heavy so, of course, the test was entirely on C++. No algorithms, no problem solving. 30 questions with a max of 3 minutes per question.
I know enough C++ to write a decent GUI for a client (I mostly code in Qt, which is what hooked my resume in the first place). This test covered every possible wacky thing in the language, stuff I have no idea what to do with and is probably never even used in this company's day-to-day work. Nested namespaces? Template specialization?
Why do they do this? I'm totally discouraged from continuing onward with these people. I know I can do a perfectly fine job with this group. I think I'm going to take C++ off my resume and just give up looking for work in that arena.
One month of employment should be enough to find out if someone has the practical skills they've expressed in the interview, and catch the 1% that can bullshit their way through.
Of course that 1% becomes a lot bigger number if the interviewer doesn't know what they are talking about. But that's not a problem you can solve with tests.