[jes5199]

While this list does correlate highly with the list of good developers I've worked with, it makes me a little uncomfortable to use any of these as a filter - none of these are essential. There are probably other questions you could ask that are just as quick and actually are skill-related (how do you list the disk volumes on a unix machine? what's a good library to parse HTML?) - maybe it will still have some of the same biases (e.g. I don't know how .NET people parse HTML, their answer might not convince me), and maybe it will end up selecting the very same set of people - but it's just easier to defend as being about technology rather than about fashion.

[probably]

I agree with you, but I'm assuming technical questions are asked too. But given several candidates who seem to do well on that portion (which is more of an academic exercise), you have to differentiate them on metrics which you have not (or possibly would have a difficult time) capturing. Hence a set of heuristics which rely on the observation that correlations between practical developer quality (or possibly just the archetype the poster prefers) and seemingly meaningless series of choices exist, you can (hopefully, favorably) bias your decision based on the latter. Choices to speak a lot about the person, especially when it deals with something you work with for such a large fraction of your professional life (e.g., OS, go-to language, sources of information). Sure, you could be selecting mostly mainstream developers and denying potentially stellar candidates, but there is also risk in taking chances with people who fall outside the norm (or what might be the norm for "solid" developers) too. Having said that, I guess I just want to make the statement that while the premise of the post sounds appalling, I'm not entirely against it.