> If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.

Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.

There are different approaches, but you can come up with any simple programming task. Doubts are fine, so just run them through some of your existing engineers, especially those you think are really good. If people you consider excellent engineers fail them, then it's back to the drawing board.

That's an exercise I do for hiring in general. For example, every time a hiring process change is proposed, I run it through my existing engineers, and make sure I would have hired them by this process.

For example, in a place that was starting to get a lot of great candidates, someone proposed tightening the education requirements of the preliminary screen. I quickly observed that would have disqualified one of my best performers, who didn't have a CS degree at all. The proposition was therefore struck down.

> There are different approaches, but you can come up with any simple programming task.

My challenge internalizing this phrase is that I have a hard time latching onto the idea of simple. It's a highly subjective measurement. For example, if I ask an to implement FizzBuzz & they can't do it, to my satisfaction, are they a not worth hiring? I suppose it depends on what satisfies me. If my criteria for hire/no-hire is whether they wrote concurrent & streaming FizzBuzz, maybe my expectations are unrealistic. If I'm expecting someone to write FizzBuzz in as few characters as possible, am I going to flunk anyone who implements a verbose concurrent & streaming FizzBuzz? Is there a case where it makes sense to hire someone who implements Enterprise FizzBuzz? I may struggle myself with keeping things simple, so there's that to consider :)

Why ask any questions? Sit them down to a simplified version of a real world class your company is working on with corresponding unit tests and tell them to make the tests pass. That was one of my favorite type of interviews and I've used it before.

I do like practical exercises.

For simple questions to verify a person has basic programming competency, I'd keep it very simple. Any simple problem which requires you to use if / else if / else or switch case, or something involving simple for / while loop. This is something any programmer should be able to demonstrate.