The technical interview is all about getting real and finding out if the candidate does really know the stuff relevant to the job. Secondly, it is also a means to understand if the guy really cares about his craft and uses the right tool that makes him efficient. Thirdly, one learns if he has the passion to learn new technologies.
These three points might sound basic, and you may wonder why people end up hiring bad candidates and eventually having to let them go. Well, there could be various reasons, but the one we hear often is: the candidate was not capable enough to deliver on the job. So, we actually failed in the beginning itself - false positives. Didn't we? So, the big question is how do we go ahead and address these points before we get our next hire on board.
Let's take this up one by one:
Does the candidate know and have the right set of skills needed for the job?
The fundamental thing which we need to verify is if the candidate has actually worked on the relevant languages, frameworks, servers etc., which are needed for the job. To start with, we need to ask some very deep questions on the topic he has worked with or is getting hired for. Not just some straight questions on this but various follow-up questions around it. We need to get ourselves 99.99 per cent sure that the candidate has the technical ability needed for the job. Anything average could only create problems later down the line.
Does the candidate care about his craft and uses the right tools?
Asking the candidate a few questions related to best practices on the languages he uses is important. On why he likes one particular framework over the other. Does he write tests for his code? Does he follow the best possible deployment strategy? Does he care about a single line code he writes? Asking questions on the tools and how it translates into his daily work setup, what IDE, operation systems he uses, is all crucial. Has he ever got a chance to read books like SICP, Code Complete et al; if yes, then a few more follow-up questions on that will be useful. These are some areas a recruiter can touch upon to get some insight on how much the candidate cares about his craft and tools.
Does the candidate have the passion to learn new things on his own?
Now, this is very important. This is very painful but a lot of people I meet consider programming as a job which is no different than any job, which I believe to be completely insane.
Frankly, after working so many years in programming, I can safely say that it is a serious job and it takes deep passion and care to produce a great piece of software. It is also fun and perhaps the most interesting job in the history of mankind (sorry, if I am exaggerating!). The way to quickly get a sense on this would be to look at their Github/Bitbucket/StackOverflow accounts and perhaps Twitter timeline as well. If the candidate has got a decent amount of code of his own and some good karma on these sites then it partially explains that the candidate has the passion for it. Asking relevant questions like, 'who do you consider your inspiration', 'what sorts of books have you read' (and some follow-up question on this topic would only help), 'what sort of technology-related news sites you follow on a daily basis' are good. By the way, if you only heard the candidate saying 'Techcrunch/TheNextweb' for the last question, then that's not a great sign. Honestly, I had been in this situation before. You can also ask questions on where he thinks this web/mobile technology is moving, although that will be too much for an entry-level hire. You can also quiz him on whether he has ever tried any functional programming like Erlang, Haskell and Common Lisp, and any fun projects he has done as part of his midnight hacking exercise etc. I can only imagine many more follow-up questions on this.
I strongly believe that these are some key questions which a recruiter needs to know really well before they say 'yes' to a candidate.
Do let me know your questions/comments. Would love to hear them.
- Data collection
- Human communication
- Job interview
- Common Lisp
- functional programming