Introduction
Having experience of being an interviewer and an interviewee means I get to see
both sides of the equation. As an interviewer I find nothing more tedious than
a techie spouting on about how wonderful the new technologies are and how they
are the answer to all our problems. The majority of all software projects that
fail have nothing to do with the technology and more to do with failures in
project management than anything else. Failure to extract the correct
requirements and manage them is in my opinion the biggest reason for failure.
No ‘cool’ technology is going to solve that problem.
The strongest piece of advice I can give any developer prior to an interview is
to demonstrate to the interviewer they are focused on building the simplest
thing that will work in order to solve the business problem.
Here are my other tips for successful interview technique:
-
Firstly, no advice about firm hand shakes, and looking people in the eye. If
you are confident and know your subject, the interviewer won’t care if you
don’t crush their hand or look at them lovingly!
-
Look smart. It's irrelevant of course in terms of your ability, but alas, smart
clothes create a good first impression. You also might be client facing. So,
it’s worth proving that you shower every now and then and know how to put a tie
on!
-
The main purpose of the interview is to hire the 'best fit'. The 'best fit'
could be a back room technical geeky genius or someone less technical and more
business aware. You'll need to gauge this at the interview. Then you can focus
your questions to show that you fit the role they have described.
-
Never focus on why the role would be good for you and what you would get out of
it. The client does not care. They are solely interested in whether they can
trust you to do the job on time and to budget.
-
Never try to pretend that you know something that you don't. You will be caught
out. No one hires a blagger. They are far too risky. The boss wants to know
that at the end of the day they can trust you to either get something done, or
put your hand up and ask for help. Honesty goes a long way. If you have to take
a guess, then explain that it is a guess beforehand. If you do not know how to
solve something, admit you don't, but suggest how and where you could find the
solution. It shows you are resourceful.
-
Just answer the question. It is easy for techies to 'go off on one' and get
carried away by drilling down into some detailed technical area when it is not
required. Provide the information necessary and ask the interviewer if that
covers what they wanted to know.
-
Don't interrupt. Remember your manners and wait for the other person to finish
speaking. Make notes whilst they are speaking if you are worried you'll forget
your points by the time they have finished. Watch out for your eagerness being
mistaken for simply being rude.
-
Try to ensure the conversation is evenly balanced. If they speak for 90% of the
time you won't get your points across and be able to impress them. If you speak
90% of the time they will think you talk too much and are a poor listener.
-
Prepare your questions. Create a set of open questions that provoke
conversations about topics which you know a lot about. No one else in that room
is going to blow your trumpet. You've got to blow it yourself. Filter your
prepared questions that are relevant to the position they have explained to you
during the interview.
-
Unless the position is highly technical then avoid getting bogged down in deep
technical discussions that do not give you the opportunity to demonstrate your
skills in other areas like software process and lifecycle.
-
Align your responses based on the interviewer. If they are non technical then
don't bore them with deep technical information they know nothing about. They
won't be impressed. Use the buzzwords and describe the benefits in terms of how
it can help improve the business and hit deadlines. If they are very technical
then you might want to get heavily technical to show them you know what you are
talking about.
-
Ask them about the business problem. You are potentially going to be hired as
an IT doctor to diagnose and solve their business problems with technology.
Your not being hired to use the latest Whizz-bang CV compliant technology, but
are there to help their business. Demonstrate that you are focused on providing
business value, rather than just using the latest technology to build 'cool
stuff'. This is key.
-
Treat the exercise as a skill matching exercise. You are trying to evaluate if
it is a good fit. Be yourself and find out as much as you need to about the
role. Don't wait until day 1 to realise that it is 9 months analysis when you
would prefer to start designing from already documented requirements.
-
Show that you know and understand the commercial realities of software
development. For example, when suggesting solutions and discussing approaches
you should be aware of the difference between tactical and strategic solutions.
You should understand why they just want to knock up a quick fix solution,
rather than turn a requirement into a software science project. Being aware of
the balance between cost of solution and the practicalities is very important.
-
Show that you have an understanding of where technology is heading. Assuming
you read web sites, and journals regularly, ensure you get that across to the
interviewer. It is a big bonus if you can show you understand what is coming
up, rather than still sticking to old versions of software.
-
Demonstrate that you understand the project life cycle, together with some
formal iterative methodologies. However, don't give the impression that
everything must be done formally. Show that you understand the balance between
'over doing it' from and 'getting the job done'.
-
Never discuss rates and hours with the interviewer unless you have personal
commitments that they need to be aware of. If you are worried about 'number of
hours' on a daily rate, then get it put into the contract that a day consists
of 8 hours of your services. Anything more is chargeable pro rata.
-
Don't give the impression you know everything. You actually know very little,
except a lot about one very small subject. No one likes an ego - they wreck
teams and cause mayhem.
-
Sum up at the end and summarise how you think you can help, and also the areas
that you cannot help. For example, you may be great at VBScript, but a novice
at JavaScript. Make sure you mention this. If you don't want the job then say
so there and then. The interviewer will respect you for saying so.
-
Do some homework about the company before the interview. A quick hour search on
internet will be okay. Get some facts and shoe horn a couple of quotes into the
interview to show them that you have found out about the company. It's the fact
that you made the effort to find out that is important.
-
And lastly, show that you are human. Use your sense of humour.
Published: Monday, October 02, 2006
© 2012 All rights reserved. Reproduction in whole or in part without permission is prohibited.
Please see our copyright notice.
If you want to use any content you have seen on this site then
please request our media pack and
ask for details of our Content Licencing Service.