Introduction
I have been in the software development business now for twelve years. I have worked as a contractor, consultant and an in-house developer and thus have been on many an interview along the way. First, it should be understood that companies generally do not know how to interview as noted in the book "What color is your parachute?" by Richard Halls, but worse than that most companies put other developers in the room to interview the job candidate as they wish. These are people who have their own agendas and often expect more in the interview than they would expect from an interview. I want to outline several problems I have seen over the years in the IT interview process so that perhaps someone might read this blog and find a better solution to this dilemma. I don't expect you to agree with everything here but please read it with an open mind and try to make real changes in your interview process.
The Standard IT Interview Process
Interviews usually go through the following workflow. First, the resume is received by a human resources team or a recruiter who specializes in finding IT talent. On their desks it is scrutinized for spelling mistakes, overselling and the ability of the job candidate to articulate his skill set. I really do not see a problem here as this is what one would expect from a good HR employee.
Next, the handful of candidates who were chosen based on their resume are often scheduled for a phone interview. The phone interview varies but is often peppered with questions about who you are and where you have been and in many cases a series of basic programming syntax questions are asked.
Finally, one or two candidates are chosen from phone interview for a face to face interview. A candidate coming in for a face to face interview could be subjected to several interviews with various levels of management and development staff. In some cases these combined interviews can last several hours and produce very little toward the goal of hiring a candidate. The last step is often repeated one or two more times until the company in question is sure they have the right employee. Below I have outlined several interview types which I have identified over the years and why they are effective or in most cases not effective.
The Test Driven Interview
Nothing is more daunting to both the developer and the interviewer than the test driven interview. In this interview scenario, there is often a verbal and/or written examination which can vary from simple syntax questions on a particular language to full blown project related questions where a developer codes a business scenario under a given time window.
Testing has a purpose in an interview, but testing is often not realistic and not focused. First, asking a seasoned developer syntax questions is often just an exercise in futility. Veteran developers have authored projects in languages ranging from Java to T-SQL to Objective C and realize that syntax is pretty much the same across all OO languages. A good handle on Google is about the only tool a long term developer needs. So if you are interviewing a senior or lead developer keep the syntax questions to a very minimum. It is better for the interviewer to tailor their questions toward the subject of architecture and problem solving. In other words, a for loop is a for loop so who cares how it is executed.
The Good Ol' Boy Interview
In this type of interview, general questions are often asked which probe the developer to see what kind of a fit he would be in a particular team. I have been asked questions such as "Do you drink beer?" or "Do you play World of Warcraft?" or "What is your political affiliation?" These types of questions do have a place in the interview but one needs to be careful that the entire interview isn't questions about hobbies and life stories. Personally I would stay away from questions regarding alcohol and political preference. The interviewer should be able to get a good feeling about the candidate without asking personal questions. Just as a note, I usually excel at the Good ol' Boy interviews because, well, I am a good ol' boy.
The Bad Cop, Bad Cop Interview
Did I mean "Good Cop, Bad Cop?" No, I meant bad cop, bad cop. In this type of interview the interviewers make every attempt to intimidate the developer and make him crack. I think somehow they think if the ask every question like a police office trying to get someone to confess to murder they will weed out the weak. In this particular case they often project themselves with a solemn face and ask questions in monotone. My personal feeling is that they really don't want to be there and they really don't want another developer on the team so they try to run the poor guy off. Usually they ask very difficult questions in an effort to completely fluster the candidate. In one bad cop interview I was asked "How many parameters can be passed into a stored procedure in SQL Server 2005?" Really, is anyone passing 1024 parameters into a stored procedure? Think about the questions you ask. Are they practical and meaningful or just trivia? In one instance I became so angered by the silly questions they were asking, I just started asking them difficult questions. Of course they didn't know the answers either. Interviewing is not a game of Jeopardy, it is a way to find out if a candidate will be a good fit and be productive in an organization.
The Senate Hearing Interview
Similar to the Test Driven Interview, in this scenario, the candidate is faced with a panel of perhaps 6 to 10 developers firing away question after question ranging from simple to the absurd. These interviews can often last over an hour.
In our world, there is a concept called fight or flight. When a person is put into a pressure cooker situation such as a panel of interviewers the fight or flight mode is activated. I have reacted in this situation in one of two ways. Either I become angry that they are asking so many questions from so many directions and I begin to get defensive or I just give up. Remember that you are hiring a developer not an attorney. A software developer does not need to be able to stand up to a barrage of questions coming from 10 different directions. Most developers are involved in very small groups and do a large amount of head down development with small meetings scattered in. By the end of this interview the developer is tired and generally turned off about your organization.
Conclusion
An interview should be composed of between 1 to 3 people and be structured as follows.
The interview lasts no longer than 40 to 45 minutes! Note that in the end no interview process is going to giv e you the perfect candidate but it can make the choice a little easier. Culture and fit probably play the biggest role of all in finding the perfect developer. Technology can be learned but communication skills cannot. Finally, don't forget about the technical references. Usually they are coworkers or a manager and can offer good insight into what technologies he knows and what he has done.
I have been in the software development business now for twelve years. I have worked as a contractor, consultant and an in-house developer and thus have been on many an interview along the way. First, it should be understood that companies generally do not know how to interview as noted in the book "What color is your parachute?" by Richard Halls, but worse than that most companies put other developers in the room to interview the job candidate as they wish. These are people who have their own agendas and often expect more in the interview than they would expect from an interview. I want to outline several problems I have seen over the years in the IT interview process so that perhaps someone might read this blog and find a better solution to this dilemma. I don't expect you to agree with everything here but please read it with an open mind and try to make real changes in your interview process.
The Standard IT Interview Process
Interviews usually go through the following workflow. First, the resume is received by a human resources team or a recruiter who specializes in finding IT talent. On their desks it is scrutinized for spelling mistakes, overselling and the ability of the job candidate to articulate his skill set. I really do not see a problem here as this is what one would expect from a good HR employee.
Next, the handful of candidates who were chosen based on their resume are often scheduled for a phone interview. The phone interview varies but is often peppered with questions about who you are and where you have been and in many cases a series of basic programming syntax questions are asked.
Finally, one or two candidates are chosen from phone interview for a face to face interview. A candidate coming in for a face to face interview could be subjected to several interviews with various levels of management and development staff. In some cases these combined interviews can last several hours and produce very little toward the goal of hiring a candidate. The last step is often repeated one or two more times until the company in question is sure they have the right employee. Below I have outlined several interview types which I have identified over the years and why they are effective or in most cases not effective.
The Test Driven Interview
Nothing is more daunting to both the developer and the interviewer than the test driven interview. In this interview scenario, there is often a verbal and/or written examination which can vary from simple syntax questions on a particular language to full blown project related questions where a developer codes a business scenario under a given time window.
Testing has a purpose in an interview, but testing is often not realistic and not focused. First, asking a seasoned developer syntax questions is often just an exercise in futility. Veteran developers have authored projects in languages ranging from Java to T-SQL to Objective C and realize that syntax is pretty much the same across all OO languages. A good handle on Google is about the only tool a long term developer needs. So if you are interviewing a senior or lead developer keep the syntax questions to a very minimum. It is better for the interviewer to tailor their questions toward the subject of architecture and problem solving. In other words, a for loop is a for loop so who cares how it is executed.
The Good Ol' Boy Interview
In this type of interview, general questions are often asked which probe the developer to see what kind of a fit he would be in a particular team. I have been asked questions such as "Do you drink beer?" or "Do you play World of Warcraft?" or "What is your political affiliation?" These types of questions do have a place in the interview but one needs to be careful that the entire interview isn't questions about hobbies and life stories. Personally I would stay away from questions regarding alcohol and political preference. The interviewer should be able to get a good feeling about the candidate without asking personal questions. Just as a note, I usually excel at the Good ol' Boy interviews because, well, I am a good ol' boy.
The Bad Cop, Bad Cop Interview
Did I mean "Good Cop, Bad Cop?" No, I meant bad cop, bad cop. In this type of interview the interviewers make every attempt to intimidate the developer and make him crack. I think somehow they think if the ask every question like a police office trying to get someone to confess to murder they will weed out the weak. In this particular case they often project themselves with a solemn face and ask questions in monotone. My personal feeling is that they really don't want to be there and they really don't want another developer on the team so they try to run the poor guy off. Usually they ask very difficult questions in an effort to completely fluster the candidate. In one bad cop interview I was asked "How many parameters can be passed into a stored procedure in SQL Server 2005?" Really, is anyone passing 1024 parameters into a stored procedure? Think about the questions you ask. Are they practical and meaningful or just trivia? In one instance I became so angered by the silly questions they were asking, I just started asking them difficult questions. Of course they didn't know the answers either. Interviewing is not a game of Jeopardy, it is a way to find out if a candidate will be a good fit and be productive in an organization.
The Senate Hearing Interview
Similar to the Test Driven Interview, in this scenario, the candidate is faced with a panel of perhaps 6 to 10 developers firing away question after question ranging from simple to the absurd. These interviews can often last over an hour.
In our world, there is a concept called fight or flight. When a person is put into a pressure cooker situation such as a panel of interviewers the fight or flight mode is activated. I have reacted in this situation in one of two ways. Either I become angry that they are asking so many questions from so many directions and I begin to get defensive or I just give up. Remember that you are hiring a developer not an attorney. A software developer does not need to be able to stand up to a barrage of questions coming from 10 different directions. Most developers are involved in very small groups and do a large amount of head down development with small meetings scattered in. By the end of this interview the developer is tired and generally turned off about your organization.
Conclusion
An interview should be composed of between 1 to 3 people and be structured as follows.
- Get to know the developer time (10 minutes) - question to ask might include topics about where he is from where he went to school and what type of hobbies he participates in. Do not ask him where he sees himself in 10 years. This can be a huge turnoff for me anyway.
- Project Related Questions (10 minutes) - questions might include topics about the business problems solved and how architecturally they were solved. Also ask questions about technologies used to solve the problem.
- How To Questions (10 minutes) - questions might include topics about how would I connect to a database and what types of objects are involved. Be creative here but not ridiculous. Don't ask questions about the value of "x". This is a waste of time!
- Questions from the Candidate (10 minutes) - this is the time for the candidate to ask you questions.
The interview lasts no longer than 40 to 45 minutes! Note that in the end no interview process is going to giv e you the perfect candidate but it can make the choice a little easier. Culture and fit probably play the biggest role of all in finding the perfect developer. Technology can be learned but communication skills cannot. Finally, don't forget about the technical references. Usually they are coworkers or a manager and can offer good insight into what technologies he knows and what he has done.
0 comments:
Post a Comment