As someone who
does not do programming as part of his career -- I'm a UNIX SA, and thus am what I call a "practical programmer" -- here's my take on it (because I get asked programming questions pretty much any time I interview at a place of work):
When it comes to interviewing candidates, ask them real-world questions, i.e. practical things, not hypothetical.
Give the candidate a scenario that has actually happened in the past, such as a case where someone not understanding operator precedence resulted in ill-effects, or where bad design choices turned out to be catastrophic later on (i.e. a "programming scalability" question). Don't probe them about silly things that really have nothing to do with the job. A lot of the places I've interviewed at (including where I work at now!) tend to pose hypothetical or theoretical problems, not actual problems that are relevant to the group/division or role the individual is applying for.
For example, at my current workplace,
here's one of the problems candidates are asked to solve. When I found out we were using this as an interview question (it's not a question my group asks), I took it upon myself to try to solve it. I asked myself "Could I even do this?" because I really didn't think I could. It took me an entire day to write, with all sorts of edge cases not handled (and this is intentional on the part of the challenge, believe it or not -- for example the lack of an ABNF that defines what the term "word" meant posed serious problems for me).
After I submitted my results, I asked the guy who wrote that scenario the following: "is this something that we actually had to solve here at work?" The answer was "No. It's just to determine the candidate's familiarity with programming and problem-solving". So to me, it was a highly-glorified fizzbuzz test, and generally-speaking I don't think that's a worthwhile test. Well, it is and it isn't I guess -- if you aren't sure if the candidate even knows how to program, maybe asking them something like this is worthwhile, but otherwise I don't think it acts as a good indicator of the quality of work you'd get from the interviewee.
Fizzbuzz is one of those questions you ask someone to see 1) if they have ever done programming at all, and 2) if they have basic math skills (specifically have familiarity with the modulus operator). Fizzbuzz otherwise is kinda pointless; for example, in my entire life and career, I've only had to use modulus a few times. But that's based on my background and what I do, and as I said above I'm not a professional programmer.
Funnily enough, the only time I've ever been asked a fairly low-level programming question was when I was interviewing for a UNIX SA position at an ISP -- I had two Russian guys grilling me about assembly language after reviewing my resume. One of them asked "So if you know all this, then tell me fastest way to swap two registers without temp variable", to which I replied immediately "XOR?". The other Russian started laughing at his colleague, since apparently nobody had ever gotten that question right (and they'd worked at previous jobs together), followed by a really big smile. Did I ever do any assembly programming at that job? Not a single line.