in reply to Re^3: Rosetta Dispatch Table
in thread Rosetta Dispatch Table (Interview Question)
These days, I no longer attempt to do interviews where I ask a candidate to write source-code “on the spot.” Because, well, “we all have our good days and our bad days,” and a candidate who really wants the job is pretty stressed-out already.
Yes, I certainly don't want someone to fail due to nerves or stress. To put the candidate at ease, and so eliminate stress/nerves as a major factor, I think you need to tell them up front that they have at least two hours to prove themselves ... which can admittedly prove awkward if you decide after thirty minutes that the candidate is not nervous, just a complete lemon, and now you can't easily cut the interview short. :)
One thing I haven't tried yet, but might, is to leave them alone in a room for two hours, with a terminal and access to doco and probably the internet too. Give them some crusty old legacy code with unit tests and ask them to refactor it, improve it -- while making sure the unit tests keep passing. Followed by a debrief session where they can discuss what they did and why. Knowing up front they'll be alone in a room for two hours may help them relax and focus on the code with less stress. Hopefully, the debrief session will be enough to assess their communication and teamwork skills.
as well as teamwork and a disposition to work as part of a team rather than as a “self-important lone wolf,”Yes, teamwork and interpersonal skills are so important that lately we've been sitting down with the candidate in a room for a cooperative two hour pair programming session, the idea being to try to figure out whether you would actually enjoy working with the candidate or not.