Hiring a Programming Staff

The Phone Interview

Few would argue against the notion that the people on a project are the single biggest factor affecting its success. You could have an effective software development methodology in place, but inexperienced or unsuitable coders could destine a project to failure.

The task of finding a good programmer to join your team can be quite difficult and time consuming. I have to admit, I've done it the hard way in the past. A few years ago my boss and I spent an entire week trawling through resumes and interviewing people. We received around 240 applications and ended up interviewing 18 people. Needless to say, we got nothing done that week as far as our regular work went. This experience lead me to believe that there had to be a better way of finding top-notch programmers.

A starting point would be to post your job ad on a popular recruitment website (e.g. SEEK, or whichever online service has the biggest market share in your region). The structure and content of your job ad is ultimately up to you, but beginning with a short paragraph describing your company culture is a good idea. A common feature of job adverts for programmers is two separate bullet point lists; one for 'must have skills' and another for 'highly regarded' skills. You may also want to ask people to fill-out a skills matrix when they apply, this does two things: firstly, it weeds out 'job spammers' (i.e. people that just blindly apply to everything), and secondly, it provides a normalised method for comparing people instead of just relying on information which may or may not be contained in their resume.

After a few days, resumes should start arriving. Generally what I do is open up a resume, press Ctrl-F and perform a keyword search for the most important requirement for the role. For example, if I wanted a .NET programmer, I would look for the keyword '.NET' in a person's resume, if that particular word didn't appear anywhere in the resume, next (i.e. the candidate lacks the most basic of requirements).

There is an optional step you can do before contacting an applicant, and that is to ask them to complete an online test. In this situation, you would first review someone's resume to ensure they have the minimum skills for the position, then email them a URL to your online test. Based on the results of their test, you would decide whether its worth investing further time for a phone interview.

An online test does however require commitment of time to mark answers, but it will ensure that only the most technically competent people are progressing further. And yes, I am aware that a person can 'cheat' on online tests. For instance, they could have a friend sitting beside them helping them out, or they could be Googling the answers. But personally, that's what I call 'being resourceful', besides, they will still have to survive a written test when they eventually come in for a face-to-face interview.

If you find a resume that seems to be a match for the position you are trying to fill, then its time to consider a phone interview. This is where many people go wrong, they organise a face-to-face interview straight away. I believe this is totally unnecessary, you only need to meet perhaps 3-5 people from the total pool of applicants.

Now onto the phone interview. I work from a predefined script, a document about 2-3 pages long with questions relevant to the position. The first set of questions are what I call the 'deal breaker questions'. If any of these fail, then you wrap up the interview and move on. The very first question always concerns communication. If you can't understand what the person is saying over the phone, there's really nothing you can do for them (you would terminate the interview).

The remaining questions would either relate specifically to the technology you are using within your organisation (e.g. "how would you rate your C# skills?") or would be made up of very common interview type questions (e.g. "give an example of when you had to work under pressure"). To keep things simple, you generally rate a candidate's answer as either 'Bad', 'Fair' or 'Good'. As to how you asses an answer, that's fairly subjective. However, each question can have a different weighting on its score. The reason for this is because a good answer to the question "what would you do if a project was running behind schedule?" is far more significant then a good answer to the question "why did you leave your last job?". Conversely, if a candidate answered the question "how would you handle a difficult client?" in a negative manner, that may result in an actual deduction of points.

After concluding the phone interview, there is a Post Interview Analysis where you score the candidate on factors such as what their attitude and demeanour were like. These characteristics may be relevant if you are intending for the programmer to interact directly with clients. Finally, you tally the candidates score - the highest scoring people are the ones you want to interview face-to-face.

Where do recruitment or employment agencies fit into the picture? They are fine for the preliminary process (i.e. résumé review and talking to a candidate on the phone). They can be very effective in helping to short-list quality candidates. Do they need to be meeting and interviewing a candidate in person? I don't believe so, it's unnecessary and adds to the expense of the whole process.

A topic worth mentioning is the choice between hiring someone with a few years of industry experience vs. a recent uni graduate. There are pros and cons to both options, but it generally comes down to two things; personal taste, and how much money is available for the new staff member's salary. Unfortunately, in-depth discussion of this topic is beyond the scope of this article, but I will say my own personal preference is to hire new graduates because they cost less and often have excellent production potential when given clear instructions.

The Programming Test

The ability to hire good programmers isn't a skill generally associated with a project manager, but if a project manager isn't sourcing coders, who is? It's likely that it will be senior management or HR. Senior management should definitely be involved in the selection process, but hiring new programmers is best done in conjunction with someone coming from a technical background.

So what is the key to finding that great programmer? Testing. Giving a candidate a written programming test is the only true measure of their capabilities. The main things to look for are competence in the languages you develop in, be it .NET, PHP, Java or whatever. In addition, logical and deduction skills are a must.

If I was asked to give my opinion on what the single most important attribute of a good programmer is, I wouldn't be able to answer. That is because its a minimum of two qualities. They are; 'is smart' and 'gets things done' (see The Guerrilla Guide to Interviewing by Joel Spolsky). Of course, there are many other favorable qualities to look for when adding to your technical team, traits such as: attitude, communication skills, how well they fit into your office culture, etc. But if you don't have both 'smart' and 'gets things done', all bets are off.

What does 'smart' and 'gets things done' mean? I will try and explain what these traits mean by presenting two fictitious examples:

Tony is a university graduate who loves to talk technology. He spends a couple of hours each day chatting with the other programmers about how AJAX is going to bridge the gap between traditional desktop applications and the limitations of the web. There is no doubt Tony is a smart guy, but if he's spending so much time theorizing about technology rather then doing it, not much is going to get done (i.e. he is smart but does not get things done).

Sarah is a dedicated programmer who appears to be a model team member. But after a number of project postmortems, it becomes apparent that approximately 50% of all bugs are attributable to her (this is out of a team of 5 programmers). This taken together with other anecdotal evidence points to a pattern; Sarah is lacking the fundamental skills required by a programmer. She is 'getting things done', but the quality of her output is very low.

Now onto the test. It shouldn't be too long, about 5-6 pages at most. It shouldn't take a candidate more then an hour to complete. The questions are divided into a number of categories: logic, programming, SQL, JavaScript, XHTML/CSS, and people skills.

Logic questions - these questions set out to test a candidate's reasoning and logical deduction faculties. Some would say that these are the most important questions in the test because they are a strong reflection of a person's capability to think in an abstract manner (and therefore tackle any kind of programming or technology problem thrown at them). I even know someone who immediately terminates the interview if the candidate fails these questions. An example question would be: "if I asked you to build me a house, how would you go about doing this?". A correct answer for this would be along these lines: "I would begin by ascertaining who the house is for, what sort of budget is available, if their are any time or material constraints. Once that is done, I would organize the contracted labor to undertake the work, ensure proper planning permits are obtained, ...". What you are trying to gauge is if a person is thinking the problem through in a systematic sequential manner. Other questions could be: "How many petrol stations does the city of Melbourne require?" or "How much does the Golden Gate bridge weigh?" With these questions, there isn't really a correct figure, the point is how did the person derive the figure, and what logical process did they use to get there?

Programming questions - these questions will be specific to the development environment you use, but an example would be; "Using .NET/C#, write a function to find out how many words are in a sentence". The coding questions shouldn't be overly hard as many programmers are reliant on reference material. A candidate's response to such a question will make it clear whether they have used that language or not. Another good question is to present a slab of code which has a bunch of bugs in it, then ask the candidate to locate the bugs. These questions are where you will spot the above average programmers; where one programmer writes 10 lines of code to do something, another writes a one line regular expression or uses recursion (obviously the better choice). You would also be on the look out for error-checking and optimization.

SQL - I don't believe you need to ask a super complex SQL question involving inner joins or embedded SELECT statements (especially since many IDEs generate SQL these days). The point is to determine whether they understand the basics of SQL. A question like this would suffice: "write a SQL query to return the surnames of all the people under the age of 30 shown in the above table. Ensure the results are ordered alphabetically."

JavaScript - you want to check for a basic understanding of JavaScript. A simple question such as this will be fine: "Write JavaScript code to check that a user has entered a value for the Username and Password fields. If not, present an error message to the user". Again, it will be very obvious if the candidate has never used JavaScript before.

HTML/CSS - you need to determine that a person has a fair understanding of HTML and CSS. I would do this by presenting a few short snippets of unrelated HTML/CSS code. I would ask the candidate to say what each snippet does and also to correct or improve each one if needed. For instance; a basic image tag with no alt attribute (nb. the alt tag is required).

People skills - the question I generally go for is this: "You're the only one in the office when a client you've never dealt with rings. They say in an aggressive tone; 'my website is down, I was told all the problems with it were fixed, what the hell is wrong with you people?' Considering you know nothing about their project, what would you say to them?" A good answer would include these key statements: allow the client to vent, apologize for the inconvenience, empathize, tell them you will look into it immediately and call them back in a half hour, etc. Having a candidate answer well on this question is really just a bonus. Personally, I would still take a candidate with superior programming skills over someone who has good 'soft skills' (after all, coding is what you need done). But this may be a distinguishing factor if you have evenly matched candidates. You never know when you may have to send a programmer out on site or have them gather requirements from a client.

One thing to look for is how well a candidate has followed instructions, have they read the question properly? Have they answered it exactly or did they get off track? Obviously a person's ability to read and follow written instructions accurately would be a tremendous asset at any organization.

I have come across a few other ideas for improving your chances of nabbing a great programmer. Personally, I have not tried all of these approaches, but they do seem like sound pieces of advice. One suggestion is to look for programmers who do coding on open source software.

A person's involvement in the open source community is a reflection of their commitment to the computing industry (i.e. they don't just code for the money). Obviously, you would want to investigate what their contribution is; for instance, if you were especially looking for a UI designer, then UI design is what they should be doing on the open-source project.