Interview Preparation

The Interviewing Skills program in the Sensible Computers’ Soft Skills Training helps participants to improve their interview skills through interviewing tips and interviewing techniques. Today's job market has become very competitive. As a representative of the organization, how do HR professionals portray and choose the most suitable candidate for a job? We understand that this is not an easy task. A couple of years ago we had excessive demand but low supply of qualified man power; today the situation is reversed. Because the supply is excessive, professionals involved in recruiting for a company should not be lax about the process of choosing the best candidate as attrition should be avoided at all costs.

HR Professionals who are conducting interviews should have 2 critical understandings:

• The core competencies needed for the particular position
• The ability to identify these core competencies in the interviewee

While interviewing an eligible candidate, it is necessary for HR professionals to be well acquainted with appropriate interviewing questions. Sensible Computers trains participants on the vital aspects that make up a successful interview. We take the participants through the process of identifying the core competencies to conducting the interview. Participants conduct mock interviews which are videotaped; each participant is given feedback by the trainer and the participants on his/her performance in this HR training.

The key focus areas that are covered in the Interviewing Skills Program conducted by Sensible Computers are:

• Developing interviewing skills
• Structure and Methodology of an Interview
• Ways to conduct an interview with 2 interviewers
• Key Areas of Interviewing
• 10 key areas to capture before closing an interview
• Managing your bias in handling interviews
• Methods to upgrade one's interviewing skill on a continuous basis

How to Interview a Programmer

Finding good programmers is hard because good programming is dependent on much more than just knowledge of programming language syntax. You need someone who, despite wearing striped pants with a polka dot shirt, has a good sense of taste in OO design. You need someone who is creative enough to find innovative solutions to problems, yet anal retentive enough to always line up their curly braces. You need someone who is humble enough to be open to suggestions for improvement, but arrogant enough to stand firm and provide leadership when they are the best person to provide it. How can you tell all this about a stranger by spending 30 minutes with them in a conference room?

Explore an Area of Expertise

Although various interview methods were tossed about that morning, a few fundamental techniques emerged from the discussion. For example, rather than simply look for expertise and experience in the exact area in which the candidate will work, you should look for general programming talent and ability. One way to explore and judge a candidate's talents is to explore an area of their expertise:

Dave Thomas:

Hire for talent. One of the biggest mistakes companies make is to recruit from a shopping list: I need a programmer with six years Java, three years Oracle, and two years EJBs. The world changes, so you need to hire folks who change with it. Look for people who know computing, not necessarily particular narrow niches. Not only will they adapt better in the future, they're also more likely to be innovative in the present.

Chris Sells:

To identify how good the candidates are technically, I let them choose an area in which they feel they have expertise. I need them to know something well, and I ask them about that. I ask them why. I want them to know why something in their area of expertise works the way it does. I'm not necessarily after an expert in the area I need. If they learned why in the past, I have confidence they'll learn why in the future.

Have Them Critique Something

Another technique involves the importance of creating a dialog with the candidate. To get to know the candidate's talents and personality, you can't merely ask questions that have short factual answers. You have to find a way to engage a conversation. To stimulate dialog, you can ask the candidate to critique some technology:

Josh Bloch:

I ask candidates to critique a system or platform that we both have in common, preferably something they will use on the job. For example, I might ask, "What parts of Java don't you like and why?"

Pete McBreen:

I give candidates samples of our current code and ask them to explain and critique it. This gives me a sense of their skills, but also lets them know what they can expect.

Ask Them to Solve a Problem

FAnother way to foster an open-ended dialog is to ask the candidate to perform a task: to solve a problem or create a design. Although everyone at the meeting seemed to agree that this was important and useful technique, it also generated a lot of concern. People felt that asking the candidate to solve puzzles and problems needed to be done with care:

Josh Bloch:

I like to ask a candidate to solve a small-scale design problem, finger exercises, to see how they think and what their process is: "How would you write a function that tells me if its argument is a power of 2?" I'm not looking for the optimal bit-twiddling solution ((n & -n) == n). I'm looking to see if they get the method signature right, if they think about boundary cases, if their algorithm is reasonable and they can explain its workings, and if they can improve on their first attempt.

Bruce Eckel:

I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain, because everyone knows what a chicken is. I think it also jars people away from the technical details of a computer. It tests to see if they are capable of thinking about the big picture.

Scott Meyers:

I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate.

Matt Gerrans:

I don't like when I'm asked to write a program that does X on a piece of paper. Don't ask the candidate to write a program on paper. That is a waste of time and sweat. People don't write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person's work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person's work and style.

Kevlin Henney:

I like design dialog questions that don't have a single fixed answer. That way they have to ask me questions, and this sparks a discussion. It's good to have a whiteboard available in the room. A dialog lets the interviewer see how the interviewee works, whereas a question of fact is just that: it is great for TV quiz shows, but doesn't tell you how someone will work and approach things over time. A puzzle question requires knowing a trick, which is in essence something that is either known or unknown. I dislike puzzle questions, because they don't require dialog.

Look at Their Code

Josh Bloch suggested one technique we all seemed to like: Have the candidate bring a code portfolio to the interview. Look at the candidate's code and talk to them about it. Although we were concerned that some candidates may not have code they could legally bring to the interview, we figured most candidates could probably come up with something. It can't hurt at least to ask a candidate to bring to the interview a sample of code they had written in the past.

Find Out What Books They Read

Several people indicated that they ask candidates about the programming books they read to see if a programmer is self-motivated or concerned about improving their own programming skills:

Matt Gerrans:

I ask candidates, "What books have you read about programming?" If the book is beyond syntax, that's important.

Randy Stafford:

I find out what books they read because it's important to me that they educate themselves of their own volition.

Conclusion

To sum up the overlying themes from our hour-long discussion in Portland: You should look for talent and fit more than specific skill sets. Ask open-ended questions to initiate revealing dialog. Ask candidates to critique something. Ask them to design something. Investigate their past experience. Review their code. And through conversation and, if possible, a trial period, you should try to become familiar with the candidate's technical abilities, talents, and personality.