Narrow Staff Selection Factors

Quite a few times I hear about "pet factors" that IT professionals use in selecting or evaluating staff. They emphasize such factors above all else, as if they are strong indicators of multitudes of factors. Examples include:

Spelling ability
Knows recursion well
Clean desk

Why do you think people do this? Barring some inside knowledge about neuron knots, logic would dictate that the more factors you test, the better. My best guess would be related to the known human nature phenomena described in HumansAreLousyAtSelfEvaluation regarding "Supercrunchers" book.

When you get a really good applicant, such criteria generally need not be considered. The applicant obviously appears professional, competent, confident, easy and fun to work with, articulate, knowledgeable, and intelligent. With such applicants, checking references and using various tests -- and/or applying the above criteria -- is, at best, confirmation of what is readily apparent. Where criteria like the above are sometimes valuable is in borderline cases, such as when the applicant seems to have a sound CV/résumé and appears to know his or her stuff, but does poorly on some evaluative mechanisms and/or gives a poor impression in an interview.

Let's address each in turn:

Spelling ability
- Good spelling is indicative of care and attention to detail; obviously important in software development. Poor spelling may be indicative of sloppiness, immaturity, a poor attitude toward maintaining a professional image, or at the very least a candidate who shouldn't be writing materials that will be seen by clients or other departments. For better or worse, poor spelling makes it look like you've hired idiots. In some cases, it means you've hired idiots.
  - It's important to separate poor spelling caused by carelessness, and poor spelling caused by medically recognised conditions such as dyslexia. It's still the case that it will limit the tasks the candidate can do well, but I know some exceptionally good programmers who can't spell.
- Look for those that spell "phonetically" as this is the mark of a logical and creative individual. Those that spell entirely from memory, may have great spelling abilities, but they lack creativity, and "think on your feet" type logic. The phonetical tend to be rather artistic, get their work done early, and always with pleasant, unexpected, and profitable surprises. Trust me, time and again, look for phonetic spelling -vs- correct spelling, works nearly every time.
  - Make allowances for people using their second language in your workspace. They may know the language fluently enough to communicate well to his or her co-workers, but lacks the decades of immersion required for spellings of weird words (which abound in English, at least). Reject not the guru because Yoda speaks he like.
- Proponents of RefactorEnglish?
Knows recursion well
- Knowing recursion well is generally indicative of sound academic training in software engineering and/or computer science, and probably a genuine interest in these. Lack of understanding of recursion may be indicative of poor (or no) in-depth training (and may raise suspicion if the CV/résumé claims otherwise) or lack of interest in the field, except at a superficial "it's just a job" level. In my experience, candidates who don't understand recursion might be adequate VisualBasic coders for simple, form-oriented applications, but their skills generally won't sustain complex coding in C, LISP, Haskell, C++, etc., or developing anything more sophisticated than data entry forms and (maybe) reports.
- But that's not necessarily a problem. Maybe they'll be happier and more productive doing fairly typical software. I find it can be good to have a mix of problem-solver personalities on a team. Geniuses tend to get bored with certain tasks and would be happy to help out if and when recursion is needed.
- Knowing recursion well is not an issue of "personality".
- I think you missed my point. Perhaps I need to rethink my wording.
Clean desk
- A clean desk may be indicative of a candidate with an organised approach, a concern for efficiency, and a desire to maintain a professional image. A messy desk may be indicative of a disorganised, careless, disinterested, and possibly unmotivated developer. However, I consider this last criterion the least indicative of the three -- I've known some superb developers whose offices looked like a bomb went off, and I've known some terrible developers whose desks were a paragon of cleanliness.
- I've worked with some pretty good people who otherwise had messy desks. I wouldn't trust them with a printed piece of paper, but they were the go-to person for certain tricky issues.
- From my long years of experience, the person with the clean desk, doesn’t get very much work done, and can only handle one project at a time. If you want high production, high innovation, and someone who can handle multiple problems at once plus a few "unofficial" projects on the back-burner, then you always want the messy-desked and busy individual. Over-organized people never seem to get much done other then organizing themselves and criticizing others. Other then the complete slob, messy desk = those who are working and get lots of work done. This is one of the main problems with modern USA corporations, where babies are put in charge who lack real life's experiences and so choose the flashy car with the blown engine and the flashy blond who turns out to be a lush and a whore.
- For some, clean desk = intense focus on the work; avoidance of distraction
- For some, a clean desk is a habit from working at a site where desks had to be cleared every night for security reasons.

If one does not have a lot to go on, then these kind of factors do tend to make a difference. When we cannot see the whole picture, we have little other choice than to make judgments based on the parts we can see. Sometimes we are forced into SovietShoeFactoryPrinciple.

  Wishing to teach his donkey not to eat, a pedant did not 
  offer him any food. When the donkey died of hunger, he said 
  "What a shame. Just when he had learned not to eat, he died." 
  (Dated to the Philogelos 4th/5th Century AD)

CategoryEmployment