While thinking about better ways to design technical interviews (meaning not based on social skills but purely technical ones) I started to think about this possible way of doing (without having the possibility to test it):
- Determine the kind of problems, high or low level of abstraction, from architecture to bitwise manipulations if that's your shop's business, that you are solving every day in the applications you work for. For this example I'll suppose we are in a PC game development company that produce a game based on extensions via modules.
- Write a simple application that solve those problems. Lets say a simple game that have not the same scale than the one we're working on but that would be
- Add bugs. Architecture bugs and more language-knowledge related bugs if it's critical (for example it's important to know about virtual destructors in C++). Make it obviously buggy, maybe make it crash first and buggy after that. Make sure it works with the tools that most people use in the domain (like cross-platform C++ for a simple game, providing the libraries code with the rest).
Provide the full source code of the application to the candidate and tell him to a) fix the code, b) add a functionality (related to the position if necessary). The candidate would have a limited time to send something back. For example, one week or two. That time would be several times the time needed to do the work in full time, it have to be fair.
4'. Maybe a different way to do that would be to provide the application source code publicly online and start to meet only the candidates who sent you the working application with the additional feature...but that would work very differently so I'm not sure if it's really interesting too.
For 4.b., I'm assuming that the functionality to add is simple but requires basic understanding of the overall organisation of the code. That would not be adding content.
5) Make the candidate explain what he did.
All that process would be a kind of interview screening, there would be a meeting after that if the candidate did provide something. It feels like parallel screening : you screen several people at the same time without spending time sequentially on each. A meeting with discussions about the code is obviously really necessary.
The questions :
a) Do you think that it would be pertinent? What do you think? (I'm not very experienced in interviewing so I'm relying on your experiences)
b) Would it be considered as paid work? Even if it's not work done on your product but just a interview-specific application?
c) I'm assuming that the candidate will use whatever he have available to solve the problems, even friends helping because I think that reflect better an real development environmental. Is there something wrong with assuming that? (Yes I'm questioning my own way of thinking, they say that's sane. Are they wrong?)
d) Is there a variant that would be more interesting?