This is Bob's Typepad Profile.
Join Typepad and start following Bob's activity
Join Now!
Already a member? Sign In
Recent Activity
Great post! I like the idea of an audition project, but have some concerns. Many companies have substantial code libraries and frameworks. If the goal is to produce code that you would want to see integrated and used in your production environment, then that code will probably need to use your code libraries, frameworks, and databases. So, the first problem is providing access to that code base and sample data. Are you really prepared to do that for a potential new hire without actually hiring them? Think about all the issues involved there - legal, potential competitor stealing / copying functionality, obtaining the code, providing a test environment, providing enough good data to test on, etc.. It could take a few days to a week just to set up the environment - depending on the company. The second problem is that getting up to speed on some projects is much, much tougher than others. C++ programming jobs in general take a longer time to come up to speed on than say Java or C#. I had a tough time coming up to speed in one of my C++ jobs in the past. Fortunately, the managers knew it was a difficult environment to learn so they did not expect very much from any of their developers for the first month or 2. I thought Roloc (who I have never met by the way) made a good comment and from his blog post: "1. A night or two before the interview give the person a problem. Something like, parse this file of words and print out on the screen the count of all the words that start with each letter, and end with each letter. Now it doesn’t have to be this specific problem, that is just one I came up with as I was typing it. Realistically, pick a problem that your company has recently had to solve, and won’t take hours to complete. Something simple yet forces them to cover the concepts that are important to you. For instance the above example is obviously going to need some loops and show file reading, inspection of strings etc etc. 2. Ask the person to bring the solution to the interview on a thumb drive or email it to you earlier. 3. Sit down with a projector or just around a monitor and do a code review! Let them describe what in detail the code is doing and why they chose to solve it that way. Ask them clarifying questions just like you would if you were helping out a peer." I would add if algorithms are important, then ask the candidate to find all the possible combinations that 8 queens can be placed on a chessboard without attacking any other queen. Mix it up for different candidates. Change it to 8 rooks, 8 nights, or a mixture of pieces that don't attach each other. I would also add a debugging problem or 2 as well as a few simple object oriented programming tasks that shows the candidate understands how to take a non-oo solution and turn it into a well designed oo solution. Whatever tests you come up with, also give them to your best developers to see how long it takes them. Don't be surprised if it takes most candidates anywhere from 3 to 5 times longer. But, I would not be discoraged by how long it takes them, especially if they completed most tasks and they were for the most part correct. Speed comes with experience. During the interview, I also would not ask the developer to write any code on a whiteboard or a piece of paper. Again, Roloc's blog explains the reasons for this quite well.
Toggle Commented Jun 24, 2012 on How to Hire a Programmer at Coding Horror
Bob is now following The Typepad Team
Jun 23, 2012