The Killer Interview Question You Need to Answer Well

Wednesday, July 11, 2007

by Gerry McLaughlin

In a job interview, the best way to separate the men from the boys, the sheep from the goats, is to ask a candidate what could go wrong with a project. If they had only done a course on the subject, they wouldn't be able to answer. If they had only used it very sparingly then their replies would be very limited.

However, if they had extensive experience of a technical area, then they could probably go on at length about the possible problems and their solutions. Experience in troubleshooting past technical problems can vastly expedite your interview process.

As an interviewer I have found greater value in asking the candidate what problems they have had when using the particular skill instead of giving them a technical test. Too few interviewers actually do this.

Turn the Interview Around

Why not turn the interview around so that you are able to bring out your knowledge of a particular technical area or skill?

Before you go to the interview, think of all the things that can go wrong when using the particular skill - and what you have done in the past to make them right.

Go to the interview determined to get this across - that you know what can go wrong and you can sort it out. It should be pretty easy at the interview to be able to bring up the topic, one way or another, of the problems that you have had and your solutions.

You might want to ask them about the main problems that they have had at their site, and then discuss the solutions with them. You can then go on to state other problems that you have had and what you did to correct them. If they haven't come across some of those problems yet, they might be very keen to have you for when they do.

Even if they have come across the problems, by bringing them up you will show that you have a broad based knowledge of the subject and can sort out problems in it.

Bad Previous Experience

I once did a series of interviews to find a couple of project managers. I interviewed quite a few people.

They all did well at the first part of the interview, and their resumes seemed great, this is until I started asking them what could go wrong with a project at the various stages of development, i.e. from scoping and estimating through analysis, programming and testing, to production.

I was surprised how few problems that they had actually come up against. Even when I came up with a problem myself, and asked how they would sort it out, they just looked at me blankly most of the time.

As there were no other candidates, I took three of them on, but my initial feelings about them were accurate - they didn't know how to run projects, although one managed to do very well in other areas. The other two were a dead loss.

Therefore, if you are an interviewer, the best way to find out who will be able to do a job for you (rather than run a course) is to find out from the candidates which problems they have had in the past, and how they sorted them out. If they don't know this at the interview, then they won't be able to solve problems for you when they arise.

If you are an interview candidate, make sure that you have prepared a list of what can go wrong and how you would put it right, and go to the interview determined that you are going to get it across.

Interviews Can Become Quite Pleasant

They say that companies only take on people that they like. If you are able to talk to them as an equal (or superior) in a subject that they know and like talking about, often the interview becomes quite natural after a while as you talk about common problems met and solved. The interview can even become quite enjoyable.

Often you'll know that you've got the job as you warm up to each other. You'll leave knowing the job is in your pocket.

Set the Agenda

Interviews are about setting the agenda and showcasing what you know, and hiding what you don't. They usually also have set times, e.g. one hour.

If you are able to turn the agenda to what you know, then you'll often find that they either don't have the time, or have satisfied themselves that you know what you are talking about, and won't bother asking those searching, testing questions that you would rather avoid.

It's happened to me before. They reached the point of the interview where they were to ask technical questions. They said to me in an embarrassed way, "You obviously know what you are talking about, so there's no need to ask you these", and then closed the folder of questions.

I was very thankful for that. I started the following Monday.

About the Author
Gerry McLaughlin has fulfilled every role in Software Development from Trainee Programmer through Systems and Business Analysis, Project Leader and Manager, Systems Manager and Chief Information Officer with a department of 80 people. Tens of thousands of IT Contractors visit www.ITContractor.com each month to keep themselves in touch with the market.

Source: www.goarticles.com