Were you ever in a situation whereby you wonder how did a co-worker managed to get pass the hiring manager’s interview? Or were you part of an interview that you weren’t quite sure how to access the candidate’s technical competency? Or were you the candidate, wondering why was the interviewer so focused on testing your ability to memorize the APIs or making you give a standard textbook-style answer, word-for-word?
Let’s take a step back and think, why is an interview required? One reasonable response would be it’s one of the easiest way to assess a candidate’s capability. It is usually the first time both the interviewers and candidate meet, so without any past collaboration experiences to draw from, an interview is usually the best way to find out more about a candidate. There’re a few kinds of interviews: a normal chit-chat to find out more about the candidate’s characters, expectations and past experience; or a technical interview, consisting of either written test or verbal Q&As to find that competent new team member; or likely a combination of both.
But does it work? I suppose it depends on a combination of factors: the experience of the interviewers and the right questions asked. It is important for both parties to assess if there’s a fit, be it culturally or technically. If there’s no good fit, logically, the deal should be off. But many times we’d seen compromise due to factors such as costs and time. A misfit hurts both parties. The hirer risks rocking the boat while the new hire suffer from agony in his job.
In a casual chit-chat, one can establish the culture of the organization and the candidate. Is the organization a sweat-shop, aim at squeezing every bit out of its staff? Is the candidate someone who sticks to a no overtime policy strictly? There’re traits that each organization or team cherishes and this should be the time, the interviewer tries to find out if the candidate has them. Likewise, the candidate should use this opportunity to find out if he’s getting into a career or a role of a fire-fighter.
For a technical interview, what kind of questions should the hirer ask? While it is tempting to have a organization-wide standard set of questions, I would believe that a tailored set meant for the team or the hiring department would be better. If my department engages in interfacing with other teams, it is naturally more important for me to find out if the candidate has such experiences and can answer questions on them. But where do I find such questions? Not the Internet for sure. I would propose two excellent sources: your bugs and your requirements. Ask not a lot of questions but sufficient to see if the candidate can identify bugs that your team made or better still offer solutions or processes to avoid them. See if he could offer ways to meet your developed requirements and see if his are similar or in fact better options.
An interview should be engaging and bi-directional. Having the right person and tool would help both parties in the interview.