I’ve been thinking a lot about hiring practices. How do you evaluate a potential employee’s programming skills? One popular yet (sometimes) controversial method is the use of coding quizzes. While I like this idea in principle, these quizzes can range from the absurd to the superfluous to the fascinating-yet-bizarre to the absolutely brilliant.
This suggestion is going to be very specific to my own milieu, but I think it can be abstracted easily.
One of my favorite learning experiences ever has to be Ruby Koans. It’s a set of failing unit tests that you have to figure out how to make pass. It’s fantastic, challenging (for the neophyte Rubyist), and enlightening.
I think this paradigm would be applicable to any TDD-oriented (and if you’re not, you should be) shop, because it tests both coding skill and testing proficiency. These aren’t the same thing, but both should be important to any hiring manager.
The other thing that comes to mind is Star Trek. Specifically, the Kobayashi Maru scenario (side note – it’s awesome that my browser and/or WordPress didn’t mark “Kobayashi Maru” as a misspelling).
For those who don’t know, the Kobayashi Maru was a no-win scenario, which Kirk managed to beat (the only time it was ever “won”) by reprogramming the computer. So you can test creative thinking, grace under fire, etc. by making some of the tests bad. If you’re into torturing applicants. It’s just an idea, not necessarily a good one, but if you’re a high-pressure shop, you might want to gauge that sort of thing.
This could happen on-site, or be sent to the applicant with a 24-hour window to submit the results.
Here’s how I think the protocol for this kind of test should go though:
- Timeboxed – You have a finite amount of time to complete this. It doesn’t have to be perfect, you don’t necessarily have to pass every test, we want to see how you think, how you prioritize problems to get the best results in the time allotted.
- Real-world – You’re not restricted as to resources. You can use Google, Stack Overflow, GitHub, whatever you want. In the real world, we try to see if we’re working on a solved problem before reinventing the wheel. I’m less interested in what you know than in whether you know how to find the answers to new problems efficiently.
- Honest – Be up-front about the problem. If the tests should be regarded as the source of all truth, say so. If the tests might be flawed, tell them. If you’re trying to test their ability to make that distinction, be honest. Tell them you’ll answer any questions they have unless you think it will bias the results. You want your programmers to have as much information as possible about the project you’ve just handed them, and you want them to be able to ask you the right questions about it. If they can do a better job by gathering information from the project manager, that’s a good thing.