Developing Programmers .com

David Clarke is an old friend of mine who among a seemingly infinite array of skills has many years experience in consulting work, programming and management.

Dave has been interviewing new employees recently and was complaining that it’s so hard to find, justify hiring, and then keep quality programmers. So I asked him about why that is.

There seems to be a few main points:

• Candidates having the right skills to do well long term.
• Candidates having the right short term skills.
• Honesty about what skills candidates have.

Long Term Skills

Being able to “amaze your friends” with your abilities on the computer doesn’t cut it when you need to turn out reliable, reusable code every day that can be and will be modified by 30 other people. You can make a house from straw and have people say “wow you can make houses!” but it just won’t be the same as a house of brick. Real effort and preparation is required here.

The long term skills I’m talking about are generally a little intangible and hard to teach or to evaluate well. They usually come from hard earned experience.

The kind of skills I’m talking about include:

• Being able to work and communicate in a team.
• Writing defensively (even “impossible” inputs should never cause a program to crash).
• Understanding what an application is for and not just the specs.
• Sound testing methods; both formal and informal.
• General principles of keeping code organised enough that it’s obvious when something isn’t right.
• Catching on to when two different tasks are really the same from a certain perspective and knowing when to abstract and when to just get the job done.

Short Term Skills

These are usually centered around particular “technologies” (gosh I hate that word) such as programming languages, libraries, and tools.

Why do I refer to these as short term? Well, in the late 70s you could get a programming job easily by knowing just FORTRAN. Ten years later the language was near extinct. While it’s essential to know specific languages and tools, they are always just “the flavour of the month”, few programs last in the computer industry and the ones that do last people generally would prefer didn’t.

By knowing the principles that underlie the specific language or tool you can pick up other tools very easily. If you’re feeling like it was so hard to learn Java you don’t want to learn C as well, remember that it’s the first language that’s the hardest. By seeing what they have in common and what is different the third language will be even easier to learn than the second. It’s about learning what’s superficial and what’s a fundamental principle.

Having expressed this, don’t go thinking that flavour-of-the-month tools won’t be important to you. It is very important to keep up with a variety of tools and languages because it keeps you practiced at turning theory into practice and it also means you don’t have to pick up a book and start reading when you get a job using a particular tool.

Dave says:

Every week I put the resumes of stunning people in front of my boss, and every week he rejects them because they don’t have some obscure skill that we need for our next job. Somebody with a completely stunning academic and commercial history is turned down because they have never used Hibernate in a commercial environment?? It staggers the imagination. But it is commercial reality.

The commercial reality is that the trend for our customers to use Outsourcing (cheap offshore suppliers) whenever possible is causing us to make decisions that we know we are going to regret later.

We have to compete with “Offshore” rates to win work. We have been left with no margin, so our company can’t afford to hire someone who is “almost right” - even when we know that a $60 text book would fix the deficiency in a couple of days.

The contracts we are getting are the contracts that don’t go offshore because they are nearly impossible. The latest to cross my desk is a job for [Company name censored for commercial reasons]. This contract needs to be delivered in 3 weeks, but requirements haven’t been finalised yet. Obviously the project has no time allowance for an “almost right” person to “get up to speed”, we need to find someone with the exact skill-set who can gather requirements and code up a result in 3 weeks…. which is crazy.

Long term this leaves us with sub-optimal people who have optimal skill-sets, instead of optimal people who could learn the optimal skill in a week or two.

I will continue to put resumes in front of my boss if they show an element of “flair” or creativity (for example, people who go off and work on their own projects in their spare time, people who win prizes, or have made significant contributions to Open Source projects, or…. etc) - and he will continue to reject them.

There are other reasons for rejecting a candidate. Sometimes our client pulls out of the contract at the last minute, leaving us with no choice but to stop the hiring process. All sorts of unexpected things can crop up, and when margins are slim all of them lead to one ugly truth - no matter how good the candidate will be long-term, we simply can’t afford the expense short-term.

This is no reflection on the candidate. It is a reflection on the insanity of commercial reality.

Although this sounds like the trick is to learn specific tools, there is more to it than that. By having a solid understanding of how and why the tools are created, you can learn many more of them in far less time.

Situations like this seem to be common but are not universal. Perhaps they’re a feature of consulting type programming. (If you agree/disagree feel free to add a comment saying so!)

I suspect that other software firms with a “bread and butter product” that is their own and they’re regularly making money from will have more of an interest in someone with long term skills, even if they have to study up on specific… tools. (I’m not going to say “technologies” again! Yikes I just said it!)

Honesty About Skills

Another problem that Dave and I were discussing was people outright lying on their resumes. If you don’t know a particular tool well but you’re confident you can pick it up in 2 days then say that instead of saying you already know the tool.

One of the frustrating things about people being dishonest for employers is that it so often works. You only need vaporware experience if you only plan to make vaporware products. Although the employer is unlikely to write a nice reference for someone that couldn’t really do the job, somehow the fact that they “worked on” the job appears on their next resume, helping to sell more vaporware experience.

Employers that have been bitten by this problem before will generally try to reduce it by testing your skills in some way. Either a take-home problem to solve, or a few probing questions added to the job interview. My favorite of these from personal experience was when I was asked the difference between “arithmetic and logical shift left”. I don’t know whether it was a trick question or whether they asked the question wrong but I was able to tell them the difference is only there in a “shift right” and what the difference was. Just make sure your general understanding of what you say you know is good enough that it shows naturally without having to specifically study up.

What Dave Looks For

A final word from Dave:

Some of the phrases or concepts that I look for in a resume include:

• Testing or unit testing mentioned somewhere - ideally a framework or methodology (or something that implies this - for example jUnit if we are talking Java, nUnit in .NET)
• Some sort of formal or scripted or automated build process (or something that implies this — for example Ant if we are talking Java, nAnt in .NET, or Cruise Control, Draco or whatever)
• A knowledge of architecture, “Patterns and Practices”, or modelling (or some implication that the concept is familiar — eg, one resume mentioned the “Model View Controller” pattern)
• A familiarity with process (I don’t care if it is RUP, Agile, ISO, XP whatever, but some process that gets you from chaos to a working, tested system)
• Some mention of experience with working within a team.