Comments on: Code Critique as an Interview Tool http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/ The blog of Adam Hupp Sat, 06 Sep 2008 02:29:05 +0000 http://wordpress.org/?v=2.6 By: » links for 2007-07-18 | Paul Cowles http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-49 » links for 2007-07-18 | Paul Cowles Tue, 28 Aug 2007 21:59:22 +0000 http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-49 <p>[...] rococo - then rubble » Blog Archive » Code Critique as an Interview Tool i like this approach over asking someone to write a simplistic application from scratch (tags: programming interview) [...]</p> [...] rococo - then rubble » Blog Archive » Code Critique as an Interview Tool i like this approach over asking someone to write a simplistic application from scratch (tags: programming interview) [...]

]]> By: wolfdancer http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-28 wolfdancer Mon, 30 Jul 2007 18:37:34 +0000 http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-28 <p>What I did before, which I hope to install at my current workplace, is to do what you have described (not as many items to check off though, not that it is not a good idea), then give the candidate a new requirement for the existing code to implement. I will pair with him (we required TDD and pairing) and look at his coding behavior.</p> What I did before, which I hope to install at my current workplace, is to do what you have described (not as many items to check off though, not that it is not a good idea), then give the candidate a new requirement for the existing code to implement. I will pair with him (we required TDD and pairing) and look at his coding behavior.

]]> By: Matt Cox http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-26 Matt Cox Mon, 30 Jul 2007 12:31:24 +0000 http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-26 <p>When I interviewed for my current job my boss gave me a question like this. He gave the source to some home brewed string replace function. The function was omitted and the code was atrocious. All he was looking for was if the candidate could read the code and discern what the function should be named.</p> <p>Ever since that I've used that same method on candidates but I would often ask them to critique the code as well. Works great as it is, but it really shines when you ask them to take you through the code and explain what's happening. This is where you really get to see how they think and communicate.</p> When I interviewed for my current job my boss gave me a question like this. He gave the source to some home brewed string replace function. The function was omitted and the code was atrocious. All he was looking for was if the candidate could read the code and discern what the function should be named.

Ever since that I’ve used that same method on candidates but I would often ask them to critique the code as well. Works great as it is, but it really shines when you ask them to take you through the code and explain what’s happening. This is where you really get to see how they think and communicate.

]]> By: jvvw http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-12 jvvw Thu, 19 Jul 2007 22:18:55 +0000 http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-12 <p>I've used code reviews as an interview tool and I'm a fan of them. They definitely give you a lot of information relative to the amount of time that they take compared to other technical tasks/questions I've tried. Deliberately doctoring some of your code is quite fun too. I did once have one good candidate ask very worried if it was real code from our codebase though!</p> I’ve used code reviews as an interview tool and I’m a fan of them. They definitely give you a lot of information relative to the amount of time that they take compared to other technical tasks/questions I’ve tried. Deliberately doctoring some of your code is quite fun too. I did once have one good candidate ask very worried if it was real code from our codebase though!

]]> By: greg_____macquarie http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-8 greg_____macquarie Mon, 16 Jul 2007 07:57:55 +0000 http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/#comment-8 <p>We currently use this technique to screen all our development hires. This has been an invaluable tool in sorting out the guy rating himself 9/10, but just read the J2SE 1.5 certification book, and the guy who rates himself 7/10 but has indepth knowledge of production quality code.</p> <p>Our test has about 30 issues on it. Its reasonably difficult, so if someone gets 8-10 of them; we're happy. For a senior developer or architect; they should be getting between 10 and 20 issues. If I learn something from them doing the review; they're definitely hired!</p> <p>We've found code reviews don't work on grad's. They don't have the real world experience to see code in that light.</p> <p>If you're new to this, start by taking some code that you've found in your codebase that you're not happy with. It has to be genuinely a diversion from best practice (not a personal style difference). Find a couple of those, refine them to make them generic/abstract/non-proprietary, and make a couple up. We found http://www.javapractices.com/index.cjp to be a good source of potential inclusions (or a good place to cross-check).</p> <p>Best of luck in your hiring!</p> We currently use this technique to screen all our development hires. This has been an invaluable tool in sorting out the guy rating himself 9/10, but just read the J2SE 1.5 certification book, and the guy who rates himself 7/10 but has indepth knowledge of production quality code.

Our test has about 30 issues on it. Its reasonably difficult, so if someone gets 8-10 of them; we’re happy. For a senior developer or architect; they should be getting between 10 and 20 issues. If I learn something from them doing the review; they’re definitely hired!

We’ve found code reviews don’t work on grad’s. They don’t have the real world experience to see code in that light.

If you’re new to this, start by taking some code that you’ve found in your codebase that you’re not happy with. It has to be genuinely a diversion from best practice (not a personal style difference). Find a couple of those, refine them to make them generic/abstract/non-proprietary, and make a couple up. We found http://www.javapractices.com/index.cjp to be a good source of potential inclusions (or a good place to cross-check).

Best of luck in your hiring!

]]>