sure you make notes and keep score of the candidate’s answers. Single
words to jog our memory often suffice.
Ø Feedback from Written One (10 mins)
start by going through the answers for the Written One. This only takes
five of ten minutes and provides an opportunity to assess whether the
interview should proceed as well as allowing the candidate to firm up
answers that may be unclear. This is a great opportunity to probe areas
in which the candidate appears wooly. For example many candidates fail
to test the null case in a unit test. This would flag that they may not
be that familiar with the process and thus would warrant further
phase can have the drawback that it applies excessive pressure to the
candidate early in the interview, particularly if you are not happy
with some of their answers. It is worth iterating that care should be
taken not to make questions too accusatory or condescending in this (or
any other) section of the interview.
Ø The Open Question (5 mins)
always open the main phase of the interview with the same question:
What makes you a good developer?
When you start to write a piece of code what are you aiming to do
other than fulfil the functional specification?
candidates will jump on this opportunity to demonstrate what they are
interested in and how they like to improve the environment in which
they work. Developers that just churn out code are likely to give
flatter, more instrumental answers (but this may be what you are
candidates don’t jump on this one immediately, relate it back to their
last project: “In you last few projects what have you been really
pleased with and why?”
questions are aimed to probe the candidates approach directly and have no
right or wrong answer. Specifically they look at areas such as “would
you make a change in this situation or would you leave it?” and “is
large scale copy and paste ever an acceptable development strategy?”.
questions are subjective and it is up to you to assess the candidate’s
answers. Most importantly the answers must fit in with the development
strategy of your team and business environment. I have seen highly able
candidates perform badly in our environment simply because they cannot
fit in with the process and approach that it requires.
always throw in a question about how they deal with confrontation.
do you do if you boss insists on you doing something you feel to be
fundamentally wrong. Have you been in this kind of situation before?”
questions often reveal interesting aspects of how the candidate has
dealt with confrontation before.
standard interview practice it is very useful to spend time probing
what the candidate did in their last position. In particular:
- Try and
understand their last project. This gives you an opportunity to
probe them on their home turf about subjects they should know inside
- If a good
topic isn’t immediately forthcoming ask some direct questions.
Asking them to describe the workflow model in their last system or
give them some paper and ask them to draw the system outline often
works well (you can start the candidate off on this one when
marking the Written One).
- Do they seem
passionate about what they did? Getting enthralled in describing
some aspect is a sign of a good candidate.
- Do they
explain their project in a eloquent and comprehensible way?
- Make sure you
ascertain that they have thought about the big picture, questions
such as “how could that have been improved”, or “had you team
considered taking that in this direction? What might be the
advantages and pit falls of this if you did?”
questions that have not been addressed so far from a list of technical
questions <technical questions>. These include topics such as
threading, swing and OO design.
Ø The CV (5 mins)
their CV for past experiences, technical specifics etc
Ø About the Position (5 mins)
opportunity for you to really sell the position you are recruiting for.
Technologists tend to be attracted by good technology and the
opportunity to learn on the job so always play that card first if you