I suppose George Orwell predicted this in some fashion in his book 1984

As a former manager of a small Engineering Support Group that specialized in custom and 3rd party tools…, I’ve always wanted to weigh-in on the fallacy of depending on “skills match” during the hiring process.

We’ve become so lazy that we turn over common sense to database procedures that specialize in pattern matching.  The idea being that we need a very special skill-set to do a job, therefore, if we find a candidate who is a close match in skill-set, we should move that individual to the front of the line for consideration.

The first more obvious problem with this strategy is… people lie.  Often times skills are listed on a resume that when you ask for details, the candidate has only had minor exposure to the tool or application in question.

Another key point to consider is, how long would it take for a potential candidate to learn the tool/application/language in question?  Claiming knowledge of a particular skill might help a candidate get more ‘hits’ on the pattern match program, but it doesn’t necessarily equate to hiring the candidate with the superior intellect.

Back in the late 1990’s, during the high tech boom when stocks were sky-rocketing at unprecedented levels, high tech workers had one up on employers.  They could be choosy.  I had a hard time recruiting traditional Computer Science graduates into my group at Xerox due to there being so many legitimate software development opportunities for them to consider.  We were an Engineering ‘Support’ shop.  A group of folks that specialized in supporting 3rd party applications, supporting users’ needs with an eye toward making them as productive as possible, and occasional developers of custom in-house tools ourselves, usually in the form of Perl Scripts or PowerBuilder applications and the like.

It became so difficult to hire the traditional candidates I had to come up with a different strategy.  I reasoned that what I really wanted more than anything else, was smart individuals.  The smarter the better.  Easy to work with counts for a lot too, but raw intelligence was extremely high on the priority list.  Since we did a fair amount of programming in shell and Perl, some programming background was going to be pretty important, but more on a conceptual level than the specific language.  So I decided I wanted them to have some programming experience… in something… but I didn’t care what language it was.  At all.

I then sat back and thought about all the really smart people I’ve had the privilege of working with over my career.  I discovered that the came from many different backgrounds.  Math, Physics, various Engineering disciplines like Computer Science and Software Engineering, EE, and ME.  A light bulb went off after I realized that some of the most brilliant folks I met along the way had math and physics backgrounds.  Coincidentally, math and physics were subjects in college that were a tremendous challenge for me.  Physics more-so than math.  But just the same, I reckoned that anyone with a degree in either of those majors was a damn sight smarter than me to start with, no doubt had to do some programming along the way to get their degree, and could learn Perl in a snap.  I decided to give it a try.  I also noticed that many EE’s and ME’s who had taken an interest in a language like Perl had, in a very short period of time, accomplished writing some fairly useful utilities.

As a side note, I had had a conversation with a colleague about Microsoft’s hiring practices.  The gist of it was, Microsoft doesn’t care at all what you’ve done in the past.  They aren’t doing that now.  They are inventing the future.  Makes sense.  Consequently their hiring process is more of a test about how an individual can think on his/her feet instead of the dreaded “behavioral interviewing” technique of “Tell me about a time when  you …”

So I put into practice a new process whereby I requested that Math and Physics grads be included in the pile of resumes I was considering, and I started bringing candidates in.  During the face-to-face interview I would have a section of it where we’d “go to the white-board” and work on a problem.  It would be a real-world problem with a variety of things to figure out, some technical and some non-technical.  This ended up being a very clear-cut way to differentiate between candidates I was interested in vs. not.  The ones that eventually were hired were engaging during the white-board session, asked good questions, helped us get to the right answers. You could easily see how their minds worked.   How the wheels were spinning.  It was enlightening to say the least.

As far as how they performed, the ones who didn’t know Perl were writing useful utilities and applications in just a few weeks.  They were familiar with CS concepts and were quick studies.  That’s all that I cared about.  To a person we had people with tremendous troubleshooting capabilities, who could rule out what’s not the problem easily and move on the what the problem might really be.  And … they came cheap!  One individual who had a Master’s degree in Math and had spent time at Oxford for her Graduate studies.  After returning to the States she initially had a hard time landing a career job and was working as a barista at Starbucks.  Her starting salary nearly doubled, which for her was great, and for the company I worked for ( Xerox ), it was a steal as well because it was a little below what traditional CS grads were commanding at the time.  Everybody wins.  The happiest person in the bunch was me, the manager, who no longer had to try to do a sell-job on the Engineering support role to CS grads.