Hiring Programming Staff (Part 2)

Note: this article is split into two parts due to its length. The two segments are related, but each can be taken as a stand-alone article. Part 1 deals with phone interviews, part 2 focuses on testing.

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.



Another approach is a trial period, where you bring a programmer on-board to do a small segment of coding on a project, for perhaps 24-48 hours. I doubt they would make much of a contribution to the overall progress of the project in such a short space of time, and in fact would probably reduce productivity because of the hand-holding required, but what it will reveal is how they interact with other team members.