This item consists of random observations, tips, and anecdotes. It is not a system nor systematic. Just a some things to think about next time you interview a candidate for a coding job.

Human Resources or People?

"A lot of them were fired. You know, fired. Management wanted to curtail redundancies in the human resources area, so many people are no longer viable members of the workforce." - George Carlin

Human resources, uh, personnel, uh, people, do matter as individuals to the Director of Development, whether or not they matter to the Invisible Hand. At present there is:

• no "automatic programming" at the top level.
• no failsafe methodology for development.
• no surefire curriculum for producing excellent developers.

Coding is still Art, and it's still performed by People. And they're Individually Unique People, albeit they share certain traits. I'm blogging today about identifying these individuals in a pack of candidates responding to your hiring campaign.

Teams vs. Unteams

We are talking here, in case it's not clear, about searches and candidates pertaining to forward-looking, well-managed development teams, not the cluttered unteams of poorly managed organizations populated by dead-end dullards who poke apathetically at perennially broken code without ever bettering the overall situation. Underachieving unteams should always hire individuals with low self esteem whom the Boss can browbeat and underpay. That way, nobody's spoiling the grade curve!

Skill Set

The grandest shibboleth in coder recruitment is the skill set questionnaire. The only interesting question which skill set questionnaires can be used to answer implicitly is, "Is the coder candidate engaged with our problem domain and the kinds of tools used in this problem domain?"

Any cross-connection is valid. Let's imagine that you are hiring for a web application running on Windows. Familiarity with coding web applications on Linux is enough to preliminarily qualify a candidate; so is any advanced Windows programming, especially Windows services. It almost never matters if the coder has actually written a web application on Windows.

To use an algorithmic illustration, when you are hiring, you're trying to do a pattern match between a gap in your project and the shape of the candidate. The pattern can match in a number of multiple dimensional orientations. The pattern may not match so well on the specific plane of the list of tools you are using. However, the pattern may match better in some other dimensional rotation. Searches are expensive, in HR as well as in algorithmic execution time. If you can rotate your perception and find a fit sooner rather than later, you have achieved economy.

Sometimes, for a very short time, tool expertise is critical to a team getting past an obstacle. Then the obstacle is gone and the team is rolling. In such crises, consider contractor or contract-to-hire tool experts.

Well-roundedness

How many programmers do you know who:

• Play Chess?
• Play a musical instrument?
  
• Speak one or more foreign languages?

Clearly some of the same "brain muscles" are used in Chess, music and spoken language as are used in programming. All three deal with branching trees expressed in symbols.

Say you've got a candidate for a high-end development job with all the right skill set. The question on your mind is well-roundedness. Well-rounded individuals make better team members. Ask about miscellaneous intellectual interests outside programming to get a glimpse of well-roundedness.

Two from Column A, one from Column B

You need a mix of personalities and capabilities to make a good team. Hire more than one type. You're going to need "B" players as well as "A" players. There's nothing duller than a room full of geniuses. Besides, no-one will take out the breakroom trash.