Software Development Dilemma #3: I Have to Interview a Job Applicant. How Do I Go About It?
Recruiting the right people people who bring in the right skills, experience and attitudes to an organization is one of the single key ways that you can make it a more productive and more pleasant place to work.
If you are lucky enough to be recruiting people to your own team then of course you will have a big incentive to get it right. You will also have nobody to blame if you recruit someone who fails to perform or whom you can't stand working with after the first week.
Whether for your own team or not, recruiting people is a very good use of a team leader's time. If you find that you are not involved in recruiting people, I suggest that you try to muscle in on the process. Tell those that matter that you want to be involved. The time you put into recruiting people will be repaid many times over in the future.
Interviews and tests are usually the part of the recruitment process that team leaders get involved in, but it's worth being aware of how this fits into the rest of the recruitment process in your organization. If you
understand the background to the process, such as the wording that is being put into advertisements, what brief the recruitment agency has been given, how candidates' CVs have been filtered and so on, then you
will be able to give a better impression to candidates and to judge them more fairly. See if you can find out about these things from your boss or Human Resources department.
If you have not been involved in interviewing before, it can be quite a daunting prospect. But it's quite easy if you stick to a formula, going through the same process for each candidate. This makes for a fairer comparison of the candidates and helps to give the impression that you know what you are doing.
Always read the CV before the interview, and take it with you to the interview. It is rude and unprofessional not to do this.
If more than one person will be interviewing the candidate, then make sure you know who will be covering what, to avoid duplication.
The interview will need space, time and privacy. Make sure you make any necessary arrangements before the candidate arrives. Get the phone diverted if you are using an office that receives a lot of calls.
Preferably, go to collect candidates rather than having them 'delivered' to an office or meeting room. This gives you a less formal situation where you can greet them and put them at ease by chatting about trivialities such as the weather or their journey to find you. If you do go into an interview where the candidate has already arrived, you could offer a drink or a 'comfort break'. If the candidate declines then it's probably better just to press on with the formal interview.
Always play the part. You don't have to act like a stuffed jacket, but, for a candidate's first interview at least, you do need to keep things quite formal and under your control. This is what candidates will be expecting, and they will be more confused than pleased if you don't act like their preconception of an interviewer. Think how you expect to be treated in an interview, and act that way.
Remember that candidates will be judging you as much as you are judging them. You represent the organization, and candidates may extrapolate anything you say or do as applying to the whole organization. For example, if you forget to book a room for the interview and then have trouble finding one that is free, the candidate may have decided that your organization is 'totally disorganized', before the interview even starts. Impressions are as important as facts.
Start off by making sure that the candidate knows a little about the organization and what it does, and explain what the job is and why there is a vacancy now. Encourage the candidate to ask questions.
Go through the CV, starting with the most recent work. This helps put people at ease and gets them talking, as most people can talk quite readily about what they are doing at the present. Go back to previous work as well, but only ask about work that seems relevant; there is no need to cover everything.
Ask in general terms about the content of the work and how much the person enjoyed it, and then home in on more specific issues of skills and knowledge.
It's best to start off with some 'open' questions that allow candidates an opportunity to demonstrate their interests and experience. Examples of 'open' questions would be 'That must have involved some tricky algorithm development?', 'Do you enjoy doing that kind of thing?', or 'What was your part in the project team?'. This sort of question gives candidates a chance to express themselves and tell you about things they are proud of. When you ask an open question, give the candidate lots of time to answer and avoid interrupting; the more the candidate talks the better, within reason.
Then from these open questions you can ask a few 'closed' questions on specific skills and experiences that are relevant. Examples of 'closed' questions might be 'Can you remember what tool you used for that?', 'Did you create the user interface yourself?', or 'Are you familiar with the TIFF file format?'. Closed questions are the sort with a short answer that delivers specific information. Don't use too many of these sorts of questions as they are very specific and don't tell you much about the person's motivation and personality. It's best to reserve them for probing into specialist skills, or to detect whether candidates really know what they are talking about.
You need to control the flow of the interview. If you want to hear more, it's often enough just to nod and make eye contact and perhaps make some encouraging remark. If you've heard enough then you can also convey this by your body language if you reduce eye contact and give little encouragement, most people will realize that they have said enough. If this doesn't work and you feel that the candidate has answered the question, then you can simply interrupt, thank the candidate and move on to another question.
You should find yourself talking for much less of the time than the candidate; you can't learn anything if you do all the talking.
Having gone through the CV, you should set the candidate some tests. It's a good idea to write out a set of tests that you can give to every candidate, to help you compare one candidate with another.
Each interviewer should use the same set of test questions on each candidate they see. They may not set every test to every candidate. It's not so important for all interviewers to work from the same set of questions, people should be able to use their own sets that work for them, although building up a standard set of questions for interviewers to choose from can be useful in improving interview practice.
It is vitally important to set tests that are as similar as possible to the work that you want the person to do. If you are trying to find someone that can design, then don't just ask them coding questions, get them to do some design for goodness' sake! Be clear about what each test is testing. If you want to find someone who can design then make sure the test determines whether they can design, and does not simply test their skill with a given methodology or tool. You can write other tests for those things if they are important. If you want to find someone who can write code then get them to write some code, not just to read some code and talk about it.
Personally I never get people to look through code on paper, trying to spot syntax errors. This is not a realistic test because in real life they have compilers and debuggers to help them.
Tests don't have to involve written or spoken answers. A very good test for programmers is to sit them in front of a computer and make them write a program. You can watch how they use the tools, how well they can use the help systems, how much commenting they do, how much error checking they put in, how they test their own work and so on. If you are interviewing people who may not have used a given tool before, then you could write the shell of the problem for them, so that they only have to complete a small part.
Start off with simple tests and work up to harder ones. This helps to let people relax and it also saves you time as you can stop when you reach the candidate's level of knowledge. Sort the tests into areas, for instance start with an easy coding question and move on to harder coding questions, and then start again at the easy end of the scale for design questions (or whatever categories of question make sense to you).
Don't be scared to ask questions that are hard. Better people like being asked harder questions, because it gives them a chance to stand out from the crowd.
Never over-sell the job. The single most common reason given by technical people for leaving their job is that it did not live up to the expectations they had following the interview. Be honest. You can talk up the positive points of the job, but don't hide the negative side. Don't pretend it's more exciting or more senior than it really is. If everyone works 10 hours a week overtime then say so. It's better to talk about this with a job candidate, than find yourself talking about it to a very upset employee a week after he or she arrives.
Towards the end of the interview, make it clear that you're finished, invite candidates to ask any questions they may have, and allow plenty of time for answering them. Also make sure that candidates know what will happen next when and how your decision will reach them, and whether they might have to come back for another interview.
You may also like to show candidates around the place where they would be working this makes it much easier for them to imagine themselves doing the job, which improves the chance of them accepting. It also gives another more informal situation, where questions can be asked with less pressure. It is a good time to talk about the person's life outside work, such as their hobbies, to try to get a more rounded picture of the candidate as a human being.
With many candidates, there comes a point during the interview where you are certain that you would not want to offer them a job. A common reason is that you realize the candidate has over-stated their knowledge to a huge extent, claiming years of experience when they have merely read a book such people must not be hired. There is little point continuing after this point, you might as well draw the interview to a close, as you are wasting each other's time. In particular I would only give tours of the facilities to those candidates that you are really impressed by these tours take time and often cause distraction to other people.
Following the interview, make sure your impressions are given as soon as possible to whoever will make the decision. The three questions you should ask yourself are:
Can they do the job?
Have they got the skills, knowledge and experience that it requires?
Will they do the job?
Are they interested in this type of work? Are they enthusiastic? Would they work hard and work smart or do they just want an easy ride?
Would they fit in?Do you think you would enjoy working with the person? Were they easy to talk to, easy to communicate with? Would they be accepted into the organization?
The answer to all three questions has to be 'definitely yes' for you to consider hiring someone. It is no good, for instance, taking someone who knows their stuff and is enthusiastic, but whom you can't work with.
The question that often causes the most soul-searching on the part of the interviewer is the last one. You must not reject competent people merely because they are 'not like one of us', but you cannot accept someone who is technically skilled but will be unable to work with other people.
It's very healthy to bring in people who have different outlooks and experiences. People with interests outside software, or who came to software through a roundabout route, often have the broadest interests and can apply ideas from other areas.
An expert on image processing who I once knew was previously a bricklayer. I often wondered if this experience of making a big object from thousands of tiny ones helped him in his image processing!
The fundamental question is, 'is this person a team player?' You can take someone with just a little arrogance (only a little), a little timidity, a reasonable amount of ambition, or quite strong personal or political opinions, as long as you believe that the person will not let these things get in the way of working with others.
It is good practice to write notes immediately after an interview, while it is fresh in your mind, as things can get muddled later.
Some organizations routinely photograph all candidates it helps people remember them later.
Never see more than three or four candidates in a day, otherwise you will be very tired and confused by the end of it.
It used to be standard practice to ask candidates back for a second interview, although this is becoming less common. If you do this, it is worth considering how you could ensure that you cover as much new ground as possible, perhaps by involving new people, setting different tests, or making the second interview a more informal affair.
I would like to encourage the recruitment method usually found in France, where the candidate is taken out for a really good meal if they get through the first round!
It should go without saying that you should avoid discriminating against candidates on the basis of factors that have no bearing on their work, such as gender, race or religion. Finding good people is hard enough without rejecting people for no good reason. This is another good reason to keep notes about candidates, in case a rejected candidate complains of discrimination.
In the case of disabled candidates, don't assume that their disabilities will make it impossible for them to do the job, or that they will require expensive equipment. Find out the facts. Find out how competent disabled candidates are and how productive they can be by testing them, as you would anyone else. Note specifically that typing speed actually makes very little difference to a software engineer's productivity; competence is much more important than speed.
Remember that while recruitment is expensive and time-consuming, BAD recruitment is VERY expensive and VERY time-consuming. Bringing someone in who does poor work or who disrupts the rest of the team can have a lasting negative effect on the organization.
The importance of hiring good people applies as much to contract staff as to permanent staff it is a mistake to think that contractors can be hired with a less thorough interview process. Although contractors can be got rid of quickly, it is a mistake to reduce the selection process with this in mind. Poor people make a mess of your project very quickly, and a succession of poor people is a disaster. Be as choosy with contractors as you would be with permanent staff.
If you've been recruiting for some time, and getting desperate to find someone, you may start to doubt that you will find the right person. You might worry that you are setting the standard too high. You will be tempted to bring in someone who is not really all you wanted. DON'T DO IT. Never accept a mediocre candidate because you have not yet seen anyone good enough; keep looking. Having a vacancy is better than having it filled by someone who is a waste of space.
Eventually, if the job is not filled the organization may have to go back and reconsider why it is recruiting for this position, and might have to split the job into two roles, arrange for existing staff to be retrained, reorganize departments or take other larger decisions. It is not your job to make these kinds of decisions; you should just try to recruit a good person to the job as currently described.
When someone has accepted a job offer, it's still not the end of the process. Eventually that person will arrive for their first day of work. If they work on your team, then you should be prepared to spend a great deal of time with them to start with. Write off all your time on their first day at least. The way people are treated on their first day has a lasting effect on them. Spend time introducing them to the team and to other people in the organization, telling them about the project and what they will be working on, explaining the company's procedures and its IT set-up and so on. Recruiting someone is not just about getting someone in, it's about getting someone who will do a good job and stay for some time, and the first day is an important part of that process.
People rarely write comments if you ask them to write code on paper but you would expect to see some if you ask them to write it for real.