Hiring process: should I review some candidate's code looking for errors or potential for being better?

My experience is that it is much more common to look for errors when reviewing code submited by a candidate during the hiring process, things like:

• this class has too much responsibility
• that class does too little
• pattern X is not implemented correctly
• etc...

My current company is like this, and after reviewing their code we invite the candidate to discuss it: we read/explain our comments and they defend their decisions. After the discussion I'm feeling really tired (the mood is more confrontation than collaboration,) and I'm not sure what kind of person does well in this kind of process.

So I thought about it and realized that instead of looking for errors I could look for potential for making that code better, just like normal code review:

• this class has too much responsibility, what about extract this and that into another class?
• this class does too little, what about moving it into that other class?
• if you change this and that the code will implement pattern X

On one hand this leads the candidate to an easy answer but on the other hand we know how they respond the a code review.

Any thoughts/experience on reviewing code for hiring?

Comments

[Dian Fay]

You didn't mention what benefits led your organization to adopt an interview "code review" process so different from your day-to-day process, what it demonstrates about the candidates, or what insights it offers you into how they think and model and decide. Can you come up with any?

I can't.

[Daniel Tamai]

I don't think we had this conversation about the why. I talked to some colleagues about this and I realized that I learn more about ourselves than about the candidates, how we think. Not the point of the interview...

Yeah, I also can't come up with anything this process offers us.

Thanks for the reflection!