How to interview a programmer. Thoughts about hiring process.

Posted by Stanislav Furman  on August 26, 2012
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.


Martin Nicolas Handfield says:
March 9, 2013 at 12:49 pm
Couldn't agree more with you Stan... Especially on the phone call bit. Being a headhunter myself, calling ahead has saved me tons of time in useless interviews... It is also a mark of respect of one's time to make sure ahead of time that an in-person meeting actually makes sense.
Flag as SPAM  |  Permalink
Dubravko says:
October 21, 2014 at 06:51 am
First I agree with your statements about the recruiting agencies... also I'm not sure but I believe the biggest problem here is that non-technical recruiters are selecting the candidates and I believe it is mostly done by looking at candidates CV and searching for the keywords of technologies that their customer requires...
Now regarding your strategy, well... to me it does not look like a time saver at all. You are browsing through every CV and that is time consuming.
Also you make phone screen with each candidate for eliminating the ones that do not fit minimal requirements and that will also take some time.
Instead, another approach that you can use is to send them some preliminary coding tests. Nothing fancy, just some basic problem that the candidates need to solve. For example in my current work we process XML a lot, so one of the questions is simply read a specific node and attribute of a given XML. This approach turned out to be great negative filter, I mean for us XML is minimal requirement so we can say for sure that the person will not be a good fit if he is not familiar with it.
After candidates pass the tests (like these ones: they are invited to a follow-up interview and thus employer doesn't waste time filtering the candidates that are invited to in-person interview.
Flag as SPAM  |  Permalink

Leave your comment

Fields with * are required.

* When you submit a comment, you agree with Terms and Conditions of Use.