Hiring a Great Programmer

Introduction

This is a general article with great recommendations on how to hire only the best programmers

Background

This article is intended for both non-technical and technical IT staff including management.  This will give you a great starting point on how to hire only the best programmers available.

By Chris Johnson @ intrin.sc

Hiring a Great Programmer

Soft Skills:

Hiring the right programmer for your organization is probably one of the most important tasks you may have been assigned to do.  It should never be taken lightly and only the most experienced developers with the best communication skills on the team should even attempt to interview a developer.  Having any non-technical person lead the interview is asking for trouble.  Some may be surprised at this, but most of the developer's time is going to be spent coding, so most of the interview should be technical.  Developers also spend a lot of their time performing requirements analysis (usually requirements are incomplete, so a developer always has to refine this directly with the user), understanding high level design, and completing technical design. This should be one of the first interview questions.  You can ask them simply "What do you do when someone gives you a set of requirements and documentation?"  If they don't answer this with something like "I normally have to take incomplete requirements and technical design and refine them until they can be used directly by a developer", they should not be considered as a candidate!

There are essentially three(3) types of programmers that I've been exposed to working with:

1) "Code Cruncher":  This person may spend a lot of their time, or all of their time coding, without much thought to the outside world, and usually without giving much thought to the technical design (that is probably not complete.).  They want to start coding right away, so they make many assumptions, and try to finish the work as quickly as possible, and usually any complications along the way are simply met with more assumptions to get the work 'done' faster. 

2) The "Architect":    This person always seems to have the right answer and dazzles management by their ability to answer any and all questions right away.  They spend a lot of their time 'researching' new technology, so, they always want to suggest a better way of doing something, and don't necessarily have any experience in this area at all.  They most likely won't complete their project on time, but they have a great answer for management which will explain in detail why they never get their work done.

3) The "Creative Developer":   This kind of developer will always ask the right questions up front.  They will normally have the correct answer to your first question as mentioned above.  When confronted with a challenge, they don't start coding right away, and they don't seem to know all the answers.  They do however always ask questions up front, and always clarify any ambiguity before starting any development.  They don't seem to know all the answers at any given point in time, but they normally get the project done on time, and more importantly get it done right the first time.  It's critical that a developer asks the right questions, and refines the requirements and technical design.  If this is not done at the beginning of the project, it will most likely fail, and any stakeholders will lose their trust in your ability to deliver a project in the future.  This developer, of course is creative! Yes, you DO want programmers that think of more than one solution to a problem, and will learn any new technology inside and out to accomplish the best solution to any given problem.  This type of programmer will always want to outdo any of their past work, and try to 'make a name for themselves'.  They enjoy sharing their knowledge, and will do whatever it takes to make the project succeed.

Just in case you haven't figured out what developer to hire, it's number 3!  You want to steer clear of 1's and 2's.  They may seem to know the answers up front for a given problem, but that's usually not the case.  Type 1's and 2's can usually fool any manager and sometimes developers when you ask them a particular question.  But, that's not important when you are just beginning any task.  You want number 3;  They ask questions, they ask the right questions, they learn any technology that they don't know inside and out, and don't try to deceive anyone with smoke and mirrors.  It's important to weed out the 1's and 2's before you proceed further in the interview.  This may take up to an hour or so to accomplish, but it is well worth the time.  You also want to keep the interview as enjoyable for everyone as possible.  You want the person to feel comfortable and be able to express themselves without feeling too nervous.  In general, you want to mimic the environment that the developers at your company experience on a daily basis.

Communication Skills:

If your team communicates in English, their English must be exceptional.  And, that goes for spoken and written English.  It's just that simple:   Communication issues result from developers not understanding other team members or other team members not understanding developers.  It's not at all fair for the rest of the team, if one person's communication skills are second rate.  Their performance will be far below acceptable, and it may take 2 to 3 times longer to complete a project, because of the miscommunication.  A manager should understand that even if they are paid a lot less, most likely the output per dollar($) will be far less than a developer who's probably paid a lot more, but who's performance is much greater.   Don't forget that if a project is done incorrectly, it is extremely costly to have another developer rewrite it.  I have been hired in the past to rewrite another developer's work, as it did not meet expectations.  It was clear to me that they should have hired the best available programmer at the time, and NOT the cheapest, as you are guaranteed to spend a lot more money fixing those developer's mistakes when the project doesn't go according to plan.  So, as you can see, communication skills are another critical part of being a developer, and should never be overlooked.

This is all of course before the technical part of interview:

Technical Skills:

Once you have spent the appropriate amount of time with your 'Soft Skills' portion of the interview, you can then proceed to a technical interview.  This can take from 30 minutes to 2 hours.  You can also allow them to do the technical portion at home, but they may be tempted to plagiarize  their solution, so you need to have a method to check this.  If you are performing the technical portion of the interview in person, you can start off with some basic technical questions to allow them to get comfortable answering these types of questions.  They can get progressively harder, but you should mix in questions similar to "How would you approach this situation?"  Keep in mind that, if you are asking detailed technical questions about a particular technology that's on the developer's resume, but they haven't used for 3 years, even the best developer would most likely not answer correctly.  An exception to this would be if you hire for a 3 month contract position, and the developer needs to start working in that particular area right away, then they need to know the technology intimately.  If you are hiring for a longer term contract or permanent position, then the depth of knowledge becomes less important, as usually a good developer can pickup new concepts fairly quickly, and that won't affect their performance.  Also, keep in mind that the amount of knowledge a programmer is expected to memorize these days is not something that is humanly possible!  If you are asking someone about every single area of Microsoft's .NET technology (for example), sooner or later, they will not have the answer, as I doubt that any developer would be able to memorize every single concept in that particular technology stack, even within 10 years or more.  It's far more important to see how they approach solving problems, and how they learn any particular area that they are lacking knowledge in.

How NOT to Interview:

When interviewing a developer you want to make your team of interviewers look as professional as possible.  Don't allow junior developers to attend interviews.  If the interviewee answers with a question, the junior person may not be able to clarify their question, which always looks bad!  Never have a manager ask technical questions.  I have seen a manager ask questions that were written down by other developers, along with the correct answer.  However, if a developer answers in a slightly different way that the manager expects, or that doesn't match their written down answer, the manager may assume the answer is wrong, when it may be correct!  That is unprofessional, and usually the interviewee will catch on to this, and assume that their team is disorganized.  Don't have people with poor communication skills ask questions.  You want to ensure that the developer understands every question, and that the right questions are asked depending on their answer.

Making the Offer:

When you have finally decided on a developer(s) that you think fits your organization, you want to ensure that they will want to stay with your organization for the long term (unless of course it's for a short term contract.).  You don't want to lowball or pay them less than they (or you) think they are worth.  They may accept the position, but start looking for something better, which is not good for both parties.  As I mentioned previously, it is usually OK to pay someone more than average, if their past performance warrants it.  Usually, their higher output far exceeds those developers who are paid less but perform well under par.  Having any project fail because of shoddy development work is something you always want to avoid at ANY cost.