Programmer Competency Matrix

I agree with this - e.g not being able to bust out a dynamic programming implementation perfectly on a whiteboard doesn't make you a bad programmer - more important is to understand, "hey, looks like when I divide this problem up it has overlapping subproblems - let me research using memoization or dynamic programming". But that still assumes you have the right terms in your head to be able to do the research - and to me that's where some fundamental knowledge of algorithms and data structures comes in handy.

to be fair: It's both. You need knowledge and smarts. If you know everything but you don't know how to apply anything to new problems, you're screwed. If you're a genius but you know nothing about computers, you're effectively incompetent at that point, and it'll take you a while to learn everything you need to know to solve the problem.

> automated testing

I love how they non-chalantly squeezed "automated testing" in there... because to really do well in that area you need so much more than the average handful of junit-or-whathaveyou tests and the whole "comes up with good test cases" is just extremely shallow. While developers do well to implement some simple unit tests, automated testing includes SO MUCH more they just left out. It is a whole software project and includes a lot more people than just "programmers" and "testers".

Another personal pet-peeve of mine are those endless suggestions of how to pick and hire developers, how can you get the very best of the best for the likely average salary you are offering to begin with - yet we have a continuous stream of coding-related horror stories.

It doesn't take any magic, it doesn't even take a catalog of weird questions that might work for google. Ideally go with recommendations, people who know people that are good. Or pick the interesting CVs and cover letters, avoid the buzzword rally. Then interview them and talk about what they have done so far and go into some details there, scratch on the surface, get a feeling for what they got going on. By now you should have quite a good idea. Then hire them on a temporary contract and see how they do. Be ready to give the new-comers and graduates a chance and be ready to invest in them, both in trainings and compensation.

IF you are in a position where you just cannot afford to put good faith in a common sense choice for a candidate then you should not be hiring in the first place because that means you either don't have the money for one more hungry mouth anyway or your project is so far into the death-march that another pair of hands is not going to rescue the sinking ship even if you get a true kernel-hacker to work on it.

My lexical parser flagged the "apparently" as playful.

Interesting. One thing that caught my eye was "someone who knows most of the tools from Scott Hanselman's power tools list." I had never heard of Scott Hanselman, nor his power tools list and had to look it up. Frankly, it looks useless to me as a programmer and looks more like a list of desktop gadgets, and watered down versions of tools bundled with most Linux distributions. He also doesn't mention anything for Linux (or OSX), nor Emacs. The list is very Windows specific.