About PM4Web

The PM4Web blog was born as an outlet to return knowledge back to the web development community. My goal is to share my experiences as a project manager from over the years in a manner which helps you succeed with your own projects.

09 August, 2008

Hiring Programming Staff (Part 1)

Hiring great programmers for your development team (part 1)

Note: this article is split into two parts because of 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 written programmer tests.

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 résumés 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, résumés should start arriving. Generally what I do is open up a résumé, 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 résumé, if that particular word didn’t appear anywhere in the résumé, 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 résumé 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 résumé 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.

Hit the ground running cartoon

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.

Reviewed by Petras Surna

1 comment:

  1. have you tried any of the aptitude testing solutions? like codility, interviewstreet or testdome?

    ReplyDelete

Note: Only a member of this blog may post a comment.