Very interesting. And it agrees with the one unique piece of advice I give people who are considering whether to go to work at a new firm, "Try to determine if they can fire people."
One quibble:
"It takes time to glean an employee's pithy attributes: work ethic, intelligence, attention to detail, enthusiasm, even personal hygiene."
You should be able to judge at least initial enthusiasm in your interviewing process or you're not doing a good job of selling your company or it's an impossible sales proposition. Either of which you should do something about at a high priority.
But I'll admit that sustained enthusiasm is what really counts and of course only time will tell WRT to that. And I'm not sure what you'd do with people who take some time to warm up to a situation (ADDED: well, make sure they've been enthusiastic about at least one prior job; if they're too young to have any/many and are already cynical you'd probably best pass on them :-).
For programmers you should be able to get a reading of intelligence and attention to detail in the interview as long as you do minimal testing (perhaps Fizzbuzz, my preferred 3 tests of reverse a linked list (pointers), recursive factorial and find error in this block of code, etc.).
Having them work out loud with you a relevant design problem is also good, although recognize that only 1/5 of programmers "get" abstraction (according to the Antipatterns book and my personal experience); if you need/can afford having programmers who don't get it, you'll want to gauge their ability to follow orders and "do it this way" "just because" the architect says so.
(There are potentially lots of slots in an organization including a startup for all sorts of competent people, e.g. look at the 2nd Coders at Work interview Brad Fitzpatrick, the Live Journal Founder. They had an older employee who produced awful code, but they loved him since his forte was quickly figuring out difficult integration problems which no one else liked to do or was good at. He handed them messy solutions filled with duct tape and bailing wire and they mined the interfaces from them and made clean versions that fit with their system.)
Anyway, my advice is to pay close attention to what this author says, just don't let it cause you to significantly relax your hiring system since hiring, working with and then firing duds is always debilitating for all concerned.
Personally, I'd take a good understanding of functional programming as a substitute for a good understanding of pointers. I mean, the point of the exercise isn't to find out how well they know pointers (they'll rarely use them anyway). It's just a way to figure out how smart they are.
When I was doing this, groking pointers was required and functional programming unfortunately just wasn't an option. E.g. during this period LISP was anathema (even to the point where one project at the beginning of this decade died because it could only be done in something that productive but use of it was rejected for no good reason).
So my test was for understanding pointers as well as figuring out how smart they are at programming.
Plus as noted when things get ugly (e.g. in some debugging situations) groking pointers is required and as long as Johnny von Neumann's initial hack architecture rules that will remain true.
Today, I would most certainly take someone with "a good understanding of functional programming as a substitute for a good understanding of pointers", I'd just make sure a few also grok pointers and other low level stuff.
(I am so happy we have exited the Dark Age of Programming Languages.)
Back when I was doing this C and/or C++ was required (in general and for the job).
Today, I don't know what I'd do (besides ask them to do it with pointers anyway, pseudo-code is fine for this problem). Someone from a Javaschool might work out well, but they'll be lost in some harder debugging situations, so I guess I'd try to make sure they'll ask for help when it gets that messy and make sure I had some uber-programmers to support them (such as myself :-).
I have a friend whose test is to sort a linked list using any sorting algorithm (it can be bubble sort) and any language (excluding trivial calls to library functions). It's fairly hard in C, trivial in ML or Haskell, and this is the point of the test: if you're able to use a high-level language, this is a benefit.
Errr, one of the points of my test is "do you grok pointers?" Which is an hard or impossible thing for many people and is needed in some subset of programming jobs.
But I'm sure many fewer today, note that I started out with punched card FORTRAN "IV" on an IBM 1130 and then did a lot of UNIX on PDP-11s. Fortunately I was able to play with LISP starting a couple of years after that first experience.
Today the world is almost entirely different, e.g. it's hard to buy a processor that had less L1 cache than the max address space of those machines' macroarchitecture.
ADDED: Or as I like to say, echoing someone I forget:
One quibble:
"It takes time to glean an employee's pithy attributes: work ethic, intelligence, attention to detail, enthusiasm, even personal hygiene."
You should be able to judge at least initial enthusiasm in your interviewing process or you're not doing a good job of selling your company or it's an impossible sales proposition. Either of which you should do something about at a high priority.
But I'll admit that sustained enthusiasm is what really counts and of course only time will tell WRT to that. And I'm not sure what you'd do with people who take some time to warm up to a situation (ADDED: well, make sure they've been enthusiastic about at least one prior job; if they're too young to have any/many and are already cynical you'd probably best pass on them :-).
For programmers you should be able to get a reading of intelligence and attention to detail in the interview as long as you do minimal testing (perhaps Fizzbuzz, my preferred 3 tests of reverse a linked list (pointers), recursive factorial and find error in this block of code, etc.).
Having them work out loud with you a relevant design problem is also good, although recognize that only 1/5 of programmers "get" abstraction (according to the Antipatterns book and my personal experience); if you need/can afford having programmers who don't get it, you'll want to gauge their ability to follow orders and "do it this way" "just because" the architect says so.
(There are potentially lots of slots in an organization including a startup for all sorts of competent people, e.g. look at the 2nd Coders at Work interview Brad Fitzpatrick, the Live Journal Founder. They had an older employee who produced awful code, but they loved him since his forte was quickly figuring out difficult integration problems which no one else liked to do or was good at. He handed them messy solutions filled with duct tape and bailing wire and they mined the interfaces from them and made clean versions that fit with their system.)
Anyway, my advice is to pay close attention to what this author says, just don't let it cause you to significantly relax your hiring system since hiring, working with and then firing duds is always debilitating for all concerned.