How To Interview a Programmer (Dos and Don'ts)
I've been on both the giving and the receiving end of interviews in my long career as a software engineer, and I've been privvy to a great many styles of interviews. There are interview questions that completely turn me off as a potential candidate and there are interview styles that make me want to jump at the chance to work for a company. In any event, interviewing programmers can be a tricky process, and I wanted to lay out some of the "dos" and "don'ts" that companies and human resource departments should follow to make their job easier.
1.) Throw education out the window. When's the last time you actually called a school to verify that a person attended or graduated? For foreign applicants, have you ever called over to that Indian or Russian university to verify their masters degree in engineering? No. Why put stock in what's listed on a resume for education in the first place then? This might matter if you're looking for a junior level developer, but if the person has experience, education is secondary.
2.) Be careful with what your headhunters list and say. It's bad enough when a job requirement lists "n" number of years experience in a certain technology that has been out for less than "n" number of years; but then to have a headhunter begin asking technology questions when they don't understand the answers is demoralizing to potential candidates. The headhunter ends up listening for what sounds most impressive, rather than what really qualifies the person.
3.) Don't quiz the candidate. Asking a question like "what are generics?" is basically like saying "I don't trust you, so I'm going to throw random terms out and see if you can answer them to my satisfaction." Technical knowledge means nothing compared to problem solving skills. The best programmers excel when they've reached a problem where they don't know the answer. Nobody knows everything, but the better employees are the ones that, despite not knowing, can easily learn and adapt to new technologies and obstacles.
Instead of quizzing the candidate, ask about their experience. Ask what they've done. Based on their answers, dig deeper into the areas that are important to your company and ask for more specific details of the operation in that area. This shows the candidate interest rather than trust issues, and it gives you a more accurate idea of what the programmer has worked on and how they worked in that environment.
4.) Take hunger over book smarts. At a previous company I worked for, we had interviewed a programmer with an excellent resume and excellent technical knowledge. He was hired, given a larger salary than many already working at the company, and was entrusted with an important project. Despite his education, credentials and technical knowledge, he was a complete bust. He didn't work well in a fast paced environment, nor did he work well with a team. He missed deadlines, spent more time on Trillian than on work, and was ultimately let go. His replacement? A graphic designer hungry to learn programming, who was enthusiastic to join the team and worked diligently to prove himself.
Now this doesn't mean that the graphic designer was better than the seasoned programmer (although in this instance - for what we needed - he was). This shows that the importance in the hiring had less to do with the person's experience and more to do with their character. A person with a good character and a solid skill set will trump a superstar engineer with a poor work ethic any day of the week.
This is why the style of the interview is so important. It is impossible to tell a person's character by their resume, or by quizzing them with definitions. You need to get them in story mode by asking them about their work environment and experience. Your questions should nudge them in the direction you want them to go, but at the same time, let them tell their own story. This way, you're guaranteed to get a better understanding of their goals and candidacy, and your new knowledge of their character will help you decide what kind of employee they will be.
