Real programming jobs usually spend a lot more time in the requirements gathering and clarification and solution analysis phases than they do in actual coding. On the other hand, it does weed out the people who don't actually have a clue, at least if you provide enough time rather than trying to get speed. Shouldn't be necessary, but HR departments are usually run by people who understand contracts, not technology.
My department recently tried to hire a lab manager contractor to do router gruntwork and organize a lab move. We quickly found that after the candidate's contract shops and our HR department had both reformatted their resumes, we couldn't tell much except who they'd worked for (e.g. "working on CCIE" meant "didn't have CCIE", not "had CCNP, working on CCIE", and "worked on X" might mean "developed the X system from scratch" or "used the X system to enter data without understanding what it was"), and most of the people who really did know their stuff found better jobs so we didn't end up getting second interviews (good for them, we really needed somebody to do unexciting gruntwork.)
We ended up asking everybody the question "You've just typed "google.com" into your browser, tell me what happens on the wire in as much detail as you can." It should be elementary, but way too many applicants didn't understand the OSI stack enough to talk about Layer 1 vs. 2 vs. 3, much less about arp or broadcasts, or didn't get the concept that typing things into your browser makes stuff happen on a wire, and the technically competent people could talk their way through it pretty quickly.