Today in my interview I didn’t even bother with the usual process of asking technical questions. All I did was say “Build the game” and after that was done “Implement this task” Building the game took an average amount of time, but the task was a 10-15 minute task he took an hour to do, and did wrong, so I ended the interview and there were no doubts from either of us that I made the right decision.
Total time taken away from me was probably 15-20 minutes, and I got a perfect measure of the candidates suitability.
When I think back on my previous bad hires, this approach would have screened out all but one of them, and it would have even worked there if I had given a more complex task.
It seems obvious now, but I can see how my past approach of asking lots of technical questions wasn’t sufficient in itself. All that did was keep away guys that didn’t know the performance differences between a linked list and a binary search tree. Since most candidates do, this didn’t help me that much.
The best approach I have right now is:
1. Prescreen with technical questions that require good fundamentals (use of data structures and 3D math). This should only take the minute or so to send an email, and another 5 minutes to scan over the reply. Also require salary requirements and start availability in the reply.
2. Give a short but real task, that involves working with other code, that is typical of the kind of tasks you might actually give. This will tell you if the candidate looks at what he is doing carefully, can read and work with existing code, can follow and understand instructions, and how fast he works. I think speed is a good measure of ability.
3. Hire on an hourly basis at first, with a clear understanding that the first few months are probation. This will save you from guys that are lazy, or who got past step 2 and shouldn’t have.
I’m happy that I saved a lot of time and money today with this new technique. Too bad I didn’t know it months ago 🙁