|
I came across seemikecode.com and it got me thinking how this could be used for live coding sessions when screening applicants for a job. For example:
What are your thoughts on this? Are tools like this helpful or do they get in the way of evaluating a candidate? |
||||
|
|
|
There's a fine line between trying to suss out whether or not a programmer can actually program (the point of Atwood's article) and setting up what would quite possibly be an uncomfortable situation for the candidate regardless of their programming prowess, thus making their results not match their actual skills. More to the point, people tend to freak out when they're being watched (if you've ever been in a meeting with people all collaboratively editing a Google doc you might have heard someone say "stop watching how I type!"). Even in pair programming situations, they tend to succeed when there's trust between the two people and the context is thoroughly understood. There's also the question of what is it that you'd be evaluating in that live code session: whether or not someone can sit down and code without mistakes right out of the gate? How they start, edit, and iterate through code (the composition process, basically) to make it perfect? How much code -- good or bad -- they can produce in a given time? Despite my own discomfort at being watched when I compose something , I can still see the benefit of a sit-down test like this if it is given to everyone at a certain stage in the process and you have given the applicant a heads-up including clear criteria for evaluation (e.g. what you're looking for: volume, "the right answer", how you work through a process, etc). There's been a discussion recently in some circles of programmers/managers/hiring folks about giving candidates puzzles to work out during the interview, and whether or not that is/is not a good idea. I'm really against the puzzle idea (for all of the reasons David Heinemeier Hansson outlines), but what you're talking about is -- or can be -- different enough. |
|||
|
|
I personally think, that web-based interviews aren't the solution if you want to get a good employee. At my company while face2face interviewing he has to explain some source code examples we provide. As we're always two or more, one of us only observes the candidates behavior... We also ask more or less hypothetical questions, e.g., what would you do if you have to add new features to untested legacy code. IMHO complex coding tests do not focus on the human behind the applicant. |
|||||||
|
|
Definitely maybe. My thought is that you're going to have to see how your candidates wrangle code (as well as many other things) at some point in the interview process. Almost all of these things you want to check are best done in a face-to-face interview, but there's only so much time; you can't give everyone who applies a several-hour in-person interview, especially if it's clear they aren't suitable for the job after the first five minutes. Thus, you have several screening stages to select the people you will offer interviews to. Perhaps you start by getting a recruiter to look for buzzwords in their CVs, then do a phone interview and finally haul them in for a face-to-face. At each stage, you have an opportunity to weed out candidates who are not up to scratch, and you save yourself the time you would spend dealing with them in future stages. Should an online coding task be one of your screening stages? Possibly. If you thing the time and effort spent on it will save you more time and effort at later stages (by allowing you to progress fewer candidates to them), then yes, go for it. Otherwise, no. For example, if you notice lots of candidates are getting rejected at (for instance) an in-person interview because they can't whiteboard-code for toffee, then you could consider using this to weed out the real incompetents, so you can spend more time in person on bigger problems with those who do show the ability to do the basics. |
|||
|
