Take the 2-minute tour ×

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!

share|improve this question

closed as off-topic by gnat, Bart van Ingen Schenau, Kilian Foth, MichaelT, Dan Pichelman Aug 20 at 19:01



personally I think focusing on reuse at all is a poor idea, especially in an interview. Code reuse should be more of a happy accident than a design goal. Generally what happens when reuse is a goal is the original code is far more complex than necessary to solve the problem, and when its reused its not that useful in the new problem. So now too solutions took more work than necessary. –  Ryathal Feb 8 '12 at 22:05
Really? I would argue the exact opposite. Maybe we're not talking about the same level of reuse, but on the small scale I think dividing code into reusable pieces promotes separation of concerns, easier to understand code (e.g., one large method broken out into pieces that can be reused and each describe exactly what they do, etc.), and makes it easily tested. Maybe I described it wrong. I'm not looking for someone who will apply a design pattern to "Hello World", more-so I want someone who can at least recognize a good opportunity for using one when it's beneficial to the solution. –  Ocelot20 Feb 9 '12 at 14:13
@Ocelot20 - Couldn't agree with you more. Code that can be re-used is code that is structured properly to separation of concerns. This type of code should be more intuitive and easier to maintain. –  Chris Dutrow Apr 15 '13 at 17:46

2 Answers 2

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.

share|improve this answer
+1, slightly contrived and constrained but real problem is the way to go. –  Wyatt Barnett Feb 13 '12 at 19:03

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.

share|improve this answer
Do you have any suggestions for those easier ways to weed out bad candidates? I hate a lot of the typical data structure and algorithm tests because they don't really apply to our project which is a web app with pretty high-level concerns. One could argue they are still good candidate filters, but I want to test their design abilities as well (it's something we've found to be lacking in a lot of developers and seems harder to test for). –  Ocelot20 Feb 9 '12 at 14:30
