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 as

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.