The end of the year is an especially intensive recruitment season for many IT companies & software houses. This does not mean that only HR departments have their hands (and calendars) full. As one of the last steps before offering (or not) a job, a technical interview has to take place. Selected engineers, previously busy with technical stuff, have to now become recruiters, verifying people's skills and experience. And that's quite of a challenge!
For the past few years, I've led tens of technical interviews, for various different positions. I was also an observer or a candidate in many of the others. If I'd have to pick one key thing that I learned during this time, I'd choose to treat the technical interview as a mutual time investment. In short, our candidate invests her/his time in order to speak with us, so we should also invest our time & experience in return, by providing proper feedback, sharing the knowledge, etc. Partnership, not a giver and a taker.
In this post, I'd like to share a few tips, that are helped me to value a candidate's time more.
Answer your own questions
Remember the Duck Hunt game? This is exactly how some poor technical interviews look like. The interviewer is constantly shooting with questions and doesn't care that there is no answer from the candidate, or that the provided answer is wrong. She/he just keeps reloading.
As already written, we should invest our time during a technical interview in the same way as our candidate does. If there was no answer, just provide one. If the candidate was wrong, simply point out the issue. This should not turn into a lecture, but rather into something closer to the short discussion in the office's coffee point. Tell and listen. You may be surprised, how much you can learn about the person just by discussing the particular problem.
One day, a candidate may ask you a question that you won't know the answer to. This attitude could help you to realize, that it's a great opportunity to learn, no matter how experienced you are. A technical interview could be like a box of chocolates too!
Turn code challenge into a collaborative code review
Coding tasks (live ones or not) as a part of technical assessment could be considered a bit controversial in general. For sure, they require significantly more time and preparation, but in some scenarios, they could provide a lot of information about what kind of programmer our candidate is. However, whether or not to require those coding challenges within the assessment pipeline, is a huge topic of its own.
Whenever asking a candidate for implementing something, there is one point that must not be missed - the feedback (again!). Simple good or not good is not even close to being enough in this case. When evaluating somebody's work, take advantage of the skills you already have - code review. Treat this piece of work as any other pull request you see at work. Make your comments constructive & kind, and keep in mind that the candidate is not your old friend with a specific sense of humor. Last but not least, remember to leave some space for discussion!
Always provide direct feedback
Somebody will call you is not the right way of ending a technical interview. After spending an hour or so, candidates deserve immediate feedback. Put yourself in their place, and imagine what you'd like to hear.
Think about what was impressive or interesting to you and which of the discussed areas could require more experience or knowledge. Then, compare all of these with the requirements for the job your candidate applied for, try to answer yourself if it's a good fit or not. This could be your simple recipe for feedback message content.
Just remember to be honest, precise, and kind. In general, a message like:
I'd recommend you to read a bit about Java generic types
is much better than:
Your programming skills are not high enough.
There are tons of excellent articles about giving feedback (including the negative ones), so just give them a try.
Book just enough time for the interview
One could say, that all the tips I provided so far are just too time-consuming. How are we supposed to fit all of this feedback stuff and "sharing the experience" into 30 or 45 minutes of the interview? The answer is pretty straightforward - we don't.
If there would be something like RecruITment Craftsmanship, it would probably advise to do it properly or don't do it at all. If you (or your company) don't have enough time for your candidates, why should they have some for you?
It is the assessing person's responsibility, to build awareness within the organization of how much time is needed to make a proper interview. In the end, building the candidate's experience from the technical part is mostly on the interviewer's side. That's why we shouldn't rush (too much) - the other side would instantly feel it otherwise.
To me, a technical interview should be a mutual time investment. Both sides have so much to give to each other, that it would be a pity not to take advantage of this opportunity.
The technical interviewer should not only ask questions but also share the knowledge & experience, as a part of a partnership-based discussion. The key thing here is to never forget about giving feedback - both for questions and coding tasks - and being open to the feedback from the other side. Since all those activities require some time, the interviewer has to make sure, that there is just enough time booked, in order to ensure a proper candidate experience.
Do you have your own tips or a different opinion on that topic? Feel free to leave a comment or discuss it with me on Twitter!