How to interview a programmer. Thoughts about hiring process.

You might also would like to read a related article How to recognize a good programmer.

Just a few thoughts...

I cannot remember how many various job interviews I have passed in my professional career. Maybe fifteen, or twenty, or maybe more. Some of them were successful, some of them not. However, very rarely I have met a really good recruitment process. Whether in Eastern Europe or in Canada – I noticed that everywhere.

Sometimes it was just a waste of my time when, for example, the potential employer declared something like: "Actually, we are looking for a specialist with a slightly different skills set" or "Unfortunately, we are limited with our budget and cannot offer you the salary that you are seeking. How about a salary 20% less than you are making now?". Seriously?!! Guys, you were aware about my salary expectations before you asked me to come for the in-person interview!

Keep in mind that for every such interview candidate should make some time to prepare, leave early from the current job (or come in later), and maybe even take a day off. Also, potential employers are spending their time too! So, why should they both waste time if a short phone call may help to figure out whether it makes sense to meet or not?!

Furthermore, dealing with recruiting agencies I noticed that some of them try to send to their customers every single CV that in their opinion more or less fits customer's requirements. Apparently, their formula is “The more CV we send, the better!”. It looks like they don't actually care too much about candidate's skills, experience, etc. Eventually, this method can make employers crazy because they lose time contacting candidates, interviewing and eventually refusing them.

All that made me think about a really good and effective recruitment process. Then, based on my own experience I created some kind of strategy on how to interview programmers and save time for both: candidates and employers. These are very simple steps that I used in my life and that I suggest other employers to use.

Step 1. Explore candidate's CV.

First of all, take a look at the candidate's CV. Pay your attention to skills and experience. Other information such as summary and education is, actually, often useless because programmer can be very smart and really good even without Bachelor's or Master's degree. At the same time, a very good student in the past is not necessarily a good programmer in present.

Also pay your attention to CV's structure. If the resume is clean and well structured, and also gives your all the information you need, then you can assume that the candidate is more-likely self-organized, responsible and is able to provide structured and clean information. However, if the resume is messy, then it might be a bad sign.

Think of preparing a CV as a first task – if you're satisfied with the result, then it might makes sense to proceed.

Step 2. Phone call. It doesn't hurt but saves hours!

Second step is a short phone call. You can do it even during your lunch break. This can really help you to save your time! In fact it saves time for both of you: yourself and the candidate.

Call selected candidates by phone and ask them a few quick questions that could give you an idea about candidate's experience and skills. Such a phone interview should not take more that 10-15 minutes. Based on your overall impression after this call you decide whether you want to invite this candidate for an in-person interview or not.

Phone call is such an easy thing to do! I don't know why a lot of employers still ask candidates to come for an in-person interview right away, without even trying to understand if the candidate at least fits minimal requirements.

Step 3. Good questions for a good start.

In my professional career I have passed through many different job interviews. Some of them were quite easy - just a couple of simple technical questions and a couple of personal questions. Some of them were really difficult - massive technical tests, code reviews, logical tests, etc. What's the most proper way? I think something in between. 

On the interview ask your usual technical questions based on the technologies and methodologies that are used specifically in your company, or that your company is planning to introduce. Do not ask the candidate common questions! See if the candidate really fits YOUR company's requirements! 

Then maybe offer the candidate a quick and well-structured test. Divide test by sections: low difficulty, middle difficulty and high difficulty. For example you could have the following test sections:

- Programming Language Syntax (the one used in your company)
- Common technologies (e.g. software design patterns)
- Databases and SQL (suggest to write a few queries)
- Problem solving (e.g. suggest to think about some abstract project)

Put 3-5 questions to each section from low difficulty to high difficulty. Based on results you can make your decision about candidate's skills set and his/her seniority level.

Step 4. Making decision.

Make your final decision: make an offer or give an official rejection! :-)

If you refuse a candidate, do not hesitate to explain why you did this. Most of people want to know why and where they did fail. It gives them a chance to find what skills they need to improve. Maybe in a year you can get back to this candidate and give him/her the second chance.

Hope it will help some of you to save some time hiring programmers.

Good luck! And as usual your comments are welcome!

PS: You might also would like to read a related article How to recognize a good programmer.