Guest Opinion

The Art of the Interview

Now is definitely not the time to let your interview skills get rusty. Here are some tips to help you stand out from the crowd of job-hunters (and potential employers, too).

• By Billy Hollis
• 03/01/2009

Here are a few tips for people on both sides of the interviewing table.

For Interviewees

• The most underused answer in technical interviews is, "I don't know." No one knows all the details on today's platforms. Feeling around for the correct answer to a technical question makes you look bad.
  
  
• Don't pad your resume with long lists of technologies that you supposedly know. Just because a technology was used at your company and you got within 10 feet of it doesn't mean you know it or should tout it on your resume.
  
  
• Bring some sample code, even if the interviewer doesn't ask for it. About five or six printed pages will do, and it need not be a complete program or module. This will impress the people you most want to impress. If the interviewer doesn't want to see it, that tells you something, too.
  
  
• Stress the business value of your past contributions to a company. Most interviewers are a hybrid of business-oriented and technically-oriented. If you have that same balance, it will make you stand out. If you can't articulate the business value of your contributions, you need to take stock of yourself. There are two main possibilities: you simply don't care about the business side, or your contributions aren't really very valuable.

For Interviewers

• Don't wing it. If you're doing any significant amount of interviewing, you owe it to your company to have a list of questions you can ask, so that you don't have to think them up on the fly. I have a list of about 40 questions that I mix and match, depending on how the interview goes. (No, you can't have it.)
  
  
• Ask a combination of technical and "soft skill" questions. You need to gauge technical competence, but non-technical skills such as teamwork, attitude, process knowledge and so forth are at least as important. For example: Suppose a project sponsor lays out a project to you, and you have loosely estimated that it will take at least six months to do it. Then the sponsor says, "And we've promised it to the customer in two months." What do you do? As Captain Kirk says about the Kobayashi Maru test, there's no ideal answer. It's a test of character.
  
  
• Ask for sample code. Stress that it need not be a complete project, and that you only need to see a few pages. I believe that reading that code will tell you more about a candidate than any resume they can write. Occasionally, someone will reply that all of their code is proprietary and they can't give you any. You can decide if that's a dodge, but it's a clear signal that the candidate doesn't do any serious professional development outside of work.
  
  
• Don't give the candidate a lot of feedback while they're answering questions, especially soft-skill questions. Some candidates will attempt to feel their way into the answer that you want. Keep your body language neutral while candidates answer soft-skill questions. If they start going back and forth between possible answers, floundering for a response I find acceptable, I scratch them from the list.
  
  
• You'll have many candidates who will be washouts in the first five minutes. Don't become abrupt or careless about your treatment of those candidates. It can hurt your organization's reputation among other developers.
  
  
• When you're finished asking questions, give the candidate a chance to ask any questions of you. That includes asking you why you asked about certain things. They may have been coached to ask generic questions about the company, but what you're hoping for are deeper questions that reveal general inquisitiveness.

Again, these tips focus on technical interviews. You can find lists of generic interview tips at sites such as interviewtips.org, and I recommend that you also check those out.