What are some good small-scale refactoring tests?

Question

I'm looking to test potential candidates on their ability to develop concise, reusable code. I feel like a good test of that skill would be to give them a very small scale application or class hierarchy with problems ranging from obvious to complex, and have them take a shot at re-factoring it (or at least verbally explaining some things they would change).

I would be looking for things like application of object-oriented design principles, use of design patterns, re-usability, showing clear intent, etc.

Before I try making this myself, I'm wondering if anyone could suggest some existing template programs that people have created for the same purpose. I don't care too much about the language, but C# or Java would be preferred because of their wide use. Thanks in advance!

Answer 1

Part of what makes a test good is how well does it measure what you exercise. A generic problem isn't really what you are interested in seeing from candidates.

Use a real problem your team has faced instead of taking a seemingly generic problem and presenting it to the candidate; perhaps simplified or slimmed down to be managable within a reasonable confines of an interview.

Before handing out the exercise to candidates, have the current team 'solve' it under similar conditions that you would give the candidate. In this way, you will have a better gauge of where the candidates will fit relative to the rest of the team, and might give some indication of their basic awareness and ability to mentally grasp the domain and evidence of stylistic tendancies beyond just applying text-book design principles.

Answer 2

I really prefer the rule of sevens - no more than seven properties of an object, no more than seven dependencies in an object, no methods with more than seven parameters, and no methods (or very few methods) with a McCabe Complexity above seven.

It's not a hard and fast rule (nothing in software engineering is), but it works well for determining if something needs to be refactored or not.

Also, I'll note that what Ryathal said about reuse is absolutely true - good code gets reused because it's good code, you don't write good code because you to be reusable. If you write tightly coupled code unless you want something to be reusable you're doing something wrong.

Finally, if you have an interview or pre-interview task that is programming related that takes more than two minutes to talk or work through, you're wasting people's time. There are easier ways to weed out the bad candidates and the good candidates will realize that you don't have the skill to determine whether they are apt programmers or not - they'll go work somewhere that has smarter management.