Here's an idea for how to actually do a technical test (if you do want to do one). 1. You bring the candidate in to your office. You have their future desk alr

Here's an idea for how to actually do a technical test (if you do want to do one). 1. You bring the candidate in to your office. You have their future desk already available with computer and development environment already functional. Pick a somewhat standard environment configuration. 2. Have an exercise already prepared. Best option is not a "build this from scratch" but have something that already works and needs some additional feature. Something small that could be done in, at most, an hour. Another option is two or three smaller tasks that together would take as long. 3. You give the candidate incomplete information. You describe the task clearly and in a mostly complete way, but leave out a number of details. 4. Very clearly explain these things. One: You won't be on them; this is not pair programming and they should feel at ease and free to do however they want. But you will be sitting in the next desk and you will be doing something unimportant so they can -and should- ask you anything and all they want. They can also use S.O. or whatever search service they want but you'd prefer that they asked you first. Two: You won't be looking at their code unless they want to show you. Three: they have around one hour, but time doesn't matter that much. If giving out more than a single task, indicate that they won't be judged by how many they manage to finish. 5. During that time, you focus on the questions they ask you. What they ask, how they ask them, which problems they face, what things they do or don't understand. This is the key. This is what will tell you about how they think, what things they know and which ones they don't. Keep an eye on them, if they seem too quiet you can interrupt them with simple "how's it going?" or "something wrong?", but don't push it too much so that you don't stress them. You may even suggest a 5 minute break for a coffee/water half-way through if you feel they might need it. 6. The whole idea is to get them to do some task but more importantly to get them to talk about it. When they are done, or when enough time has gone by, don't go over their code. Instead, ask them how it went, what they managed to do, if they got stuck. If they got it running, they can run it. If they want, they can show you the code or part of it. but you don't need to focus on that. Focus on their talk. 7. Finally, do offer them the option of showing the code. But then, get them to show it and explain it. Don't just go over it yourself. 8. The task(s) should be adequate and reasonable for the role, of course. But try to lean on the easier side more than on the harder one. And remember: do leave some information out. The task should be clearly understood but not finely detailed so that they will need to ask and maybe even make some decisions. (You can make them have to decide something by giving them more than one option as answer to some question.)