Take the 2-minute tour ×

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:

  • Email telling the interviewee what to expect
  • Problems attributes of coding problems that are suited for this setup
  • How to responded to the code presented
  • Recording the session

What are your thoughts on this? Are tools like this helpful or do they get in the way of evaluating a candidate?

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
+1 @jcmeloni: Thanks for the input, guess my experience is different than most it that I've been virtual for a long-time and guess in part expect people I'm working with to be okay with it. Pairing wise, I've paired in person and virtually, and pretty good at breaking the ice, and rolling the session forward. Your answer made me realize that guess I'm testing coders in part to see if they're able to excel in a virtual setting. Again, thanks for your input! Cheers! –  blunders Jan 9 '12 at 17:35
add comment

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.

share|improve this answer
+1 @Scott: Thanks for the input, guess my experience has been talking about coding, and coding are different skills. Also, I've meet lots of people that had nice sample code, but when we started coding real-time had issues logical stepping through a problem and coding it. At the same rate, I've run across people that had poor resumes, code samples, etc., but could code; i.e. they weren't putting effort/thought into marketing themselves. –  blunders Jan 9 '12 at 17:41
add comment

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.

share|improve this answer
Clearly your company is not interviewing face-to-face every person that submits a resume, right? How do they screen people to get to the in person interview? Also, in case you missed it on the webpage I referenced, here's the background on this approach: codinghorror.com/blog/2010/02/… –  blunders Dec 10 '11 at 12:18
We screen by references and skills that the applicant "actively used" in the last 2-3 years. Do these main skills match with our needs. In some cases we make an interview on the telephone in advance. –  tuergeist Dec 12 '11 at 22:12
add comment

Your Answer


