
How to Hire Great Devs: Interview Pairing with OO Design and TDD - savagebits
https://medium.com/@SavageBits/how-to-hire-great-devs-interview-pairing-with-oo-design-and-tdd-d7967583393f#.53f86mw5l
======
r2dnb
Interesting, I used to give the same kind of coding exercise to candidates but
was leaving them alone in the room for 60 minutes and popped-in every 20min to
ask them if everything was fine.

I also kindly insisted on the fact that they should feel free to come see me
if they had any question. The reason is part of the exercise was to assess
their ability to avoid wasting their time by being blocked on something and
ask for clarification.

On the one hand I like this pair interview approach because it allows you to
check the communication and social skills of a candidate. On the other hand I
don't like it because you lose tons of valuable information.

You lose information on the autonomy of the candidate, on his creativity, on
his coding habits, and more. You create a group effect (we're not the same in
groups that when we are alone). And to me, while team work is important, the
interview is about gauging the individual contribution that the candidate will
make to the team and in an artificial environment it is done more accurately
by allowing time to assess his individual work skills.

I also knew that in the particular company I worked for, we didn't do pair
programming and we most of the time had to work alone on several mini-
projects. So it made even more sense to assess how they would perform under
their future work conditions.

I prefer my approach because you can get the same insight into their thinking
patterns by reviewing their solution with them point by point afterwards, but
you also get plenty of other information by doing so. I never focus on the
syntax but ask questions on the strategy and the choices made. The code could
even not compile I wouldn't care, the only point of the exercise is to have
material for a discussion.

The one important thing to hire good developers is to always have a coding
project of 1 hour or so relevant to the role in the interview process. This
revealed the bad developers instantly, and the frightening thing is that all
of them had otherwise performed very well during interviews.

Thanks for sharing though, I didn't know about this practice and it is always
refreshing to know what other people do. While I don't think I will implement
this approach for the reasons mentioned above, having a broader perspective
can only benefit the mind.

