I've conducted a lot of programming interviews over the past three decades. I think that it's easier to do at places like Google where the objective is to avoi

I've conducted a lot of programming interviews over the past three decades. I think that it's easier to do at places like Google where the objective is to avoid a Type I (false positive) error and it's expected that a lot of time and money will be spent to identify the best hires. It's harder in other contexts where Type II errors matter more. I have a big portfolio of technical questions, but I usually stick to a small set that I consider to be well calibrated by posing them to smart coworkers and seeing what they do with them. I've found, counterintuitively, that the best indicators are the questions that deal with "programming in the small", such as coming up with a predicate expression to describe a test for a simple relationship between a few values, because either you can do it easily or you can't do it at all. And programming in the large depends on a lot of cases of programming in the small.