Interview Questions (was: Brainbench)

Daniel Perrett perrettdl at googlemail.com
Wed Sep 5 22:15:49 BST 2012


"Given that fib(n) is equal to fib(n-1) + fib(n-2) write a fib
function in any language"

The fib(n) task as stated tests three things of the candidate:

- Are you confident enough to consider that the interviewer might be
presenting a problem as complete which in fact requires some more
info? (And to risk asking?)
- Can you spot the trick in the question?
- Can you perform the fully specified programming tasks, once you've
spotted the trick?

While I wouldn't say those are invalid, the question for you, the
interviewer, is "do they tell you what you need to know?"; the answer
may depend a lot on whether you're after someone you are expecting to
train up or someone you expect to be refactoring your legacy code in
their first week. I'm going to assume something closer to the former.

The confidence issue is a big question and I'd argue you need to
mitigate it. It's going to depend on all sorts of factors including
how stressed they are (if it's their ideal job, the answer is *very*),
how many people you've interviewed (i.e. how impatient you seem), and
whether it's before or after lunch. Whatever problem you set, you
should do make it clear you expect people to ask questions (even dumb
ones). Sure, hubris is a Programmers' Virtue and a good employee will
be confidently asking tricky questions and poking holes in the spec,
but compared to the interview room that's a very different social
relationship. Confidence (natural, socialised, or situational) gives
you an advantage in interviews anyway, and I think it's important to
avoid increasing that advantage.

"Spot the trick" can be a useful skill, in fact, you can argue it's
similar to the skills we use for debugging, but it's impossible to
gauge reliably based on one problem (especially when the problem is
equivalent to a well-known one which people might know by chance
rather than because they figured out you need the additional info).
And because the problem is mathematical, people with academic
mathematics-like backgrounds will see that quicker, and I suspect
that's going to end up selecting for a less diverse range of
experiences/ideas/approaches/demographics than you'd like (but hey,
maybe you feel strongly linguists will mess up your Perl code, I
dunno). If you want to do "Spot the trick", avoid known sequences. But
because you don't want people to focus on trying to guess if it's ok
to question the question in an interview, I would simply recommend
saying 'Here is a function to do X, it doesn't work: why not/what does
it do instead?'.

Performing defined programming tasks is something you might want to
test, but you could do a selection of simple and clear tasks in a
pre-interview question without the trick, It's a filtering question.
If you're doing this, I would recommend something which people can
picture rather than just "numbers", e.g. triangle numbers, as this
minimises the chances that you're explaining things less than clearly
or in a way inaccessible to the candidate, or in a way which makes
them pore over the wording looking for tricks. (I know I just said
avoid defined sequences but that was if you were testing something
else; I am suggesting you choose one or the other).

Things it doesn't necessarily test for, but which you might be interested in:

- Is the candidate able to grasp and apply the principles of
recursion, even if they've not used it before in a language?
- Can the candidate turn an iterative function into a recursive one?
- Does the candidate know (or can they meaningfully discuss) when it
is best to use recursion?

I'm writing this not because I think it's heresy to use this task, but
to use it as an example to think through why we do tasks in
recruitment. We need to think hard about and talk a lot about these
questions, because we are Perl devs and not HR experts.

So I guess as a positive recommendation: rather than a simple "is
problem X good or bad?", the question we should be asking ourselves is
"I want someone who is capable of doing A/B/C, and I am also
interested about what they know about X/Y/Z. How do I design and
present my problems so that as far as possible they identify all those
and only those who can do A/B/C and give them the opportunity to
demonstrate their knowledge of X/Y/Z?"

Daniel


More information about the london.pm mailing list