The science of hiring

A couple of weeks ago I had a conversation with a friend of mine about how working in the States alters your perception of work – particularly if you’re working on a management level and need to pick your own team. Picking the right people, who get the job done on time and on budget is no easy task. Not just because it might be a rather unjust thing to judge people by one, two, three or X interviews lasting Y minutes over the course of Z days, but also because it’s very much about the environment, a team member’s personal life, the project schedule and so many other factors if someone performs well beyond expectations, just so so or doesn’t seem to get anything done at all. Of course, what matters most is if the chosen ones are performing well on average over the given work; after all, it’s no good to work on a project 150% for 3 weeks and then quit for 6 months because of a burn-out.

I’ve seen a good number of different interviewing styles and ways over the years; I’ve applied my fair share myself. So when I happened to read Joel Spolsky’s “Guerilla Guide to Inverviewing”, which is now in its third version, I had to smile. I know, it’s a long but really worthwhile read. There’s a couple of really interesting points he makes – some I’ve seen applied in the wild myself. The way I cited it, the title might be a little misleading though – the outlined techniques are limited to IT and are probably most applicable to hiring people in software development – after all, there’s certainly a reason why Joel’s blog is called “Joel on Software”.

I remember having a discussion once with a friend of mine, if quizzing someone in an interview about technical stuff and letting the interviewed person program something on paper is detrimental to the interview process. The point my friend tried to make was that the interviewer would not learn anything from him as a person by letting him write a “stupid” little program. However, this particular conversation focused on the comparison of technical versus soft skills. While I’ve got to agree that writing program code will not tell me very much about a person’s social competence, there’s a valid point in the necessity of checking one’s technical skills – especially if you plan to hire that person for programming and extending your team. Still, there are concepts and techniques in computer science that require a very special skill set. One of those may very well be C pointers, like mentioned in Joel’s article, others might be social skills in defusing tough meetings. Depending on the job profile, they might be both worth checking out, but that takes time – particularly if you want to check the technical and social competence of someone.

The aforementioned article outlines three concepts, which can probably gap social and technical:

  • Take a point where the interviewed person is right and pretend you think she is wrong. Argue and see if the person is capable of convincing you in a polite manner that I am in the wrong.
  • Let the interviewed person design something and see if she just starts painting some UML or diagrams or if the person is actually querying for more information before jumping into the unknown.
  • Drag some point along; just sit on it and act as if you cannot decide and see if the interviewed person is willing to pick up the ball and go along the line “you know what? Lets just take A now, we can still come back later, reconsider and take route B if we realize later that it’s the better option”

I imagine that these might create some very awkward situations if applied a little too forcefully – so keep in mind: you’re the interviewer – if you push too much you might intimidate and get a skewed view of a candidate.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.