Richard Bucker

Better Interviewing Tactics

Posted at — Feb 27, 2015

Job interviews start with the Posting.Some years ago when I was starting to get into erlang (for the second time; the first time was a failure) I recall reading an article that suggested [prarphrazed] It is better to post a job for an erlang programmer instead of a java as you are (a) going to get fewer respondents (b) of higher quality and aptitude. I cannot find fault with this approach except that posting for an erlang position and then using C#, java or perl and you might actually keep the candidate if you manage to win the day.In the past I had interview questions which I would say have their origin in the Silicon Valley way of thinking. Of which the author of this article [Phone Interviews] would have you believe is bad; and today I agree as my initial opinion has changed. In the end I realized that I have a good intuition when it came to interviewing. I think I ask questions that cover various median knowledge and aptitude; and some that are meant to gauge the interpersonal stuff… it is intuition after all.The Phone Interview also links to two other interview articles that I think I might find interestingThe GitHub Hiring Experience (link)The post makes an interesting point that other techniques might not. First Contact seems to be “brick and mortar” meaning that it’s not your typical internal or 3rd party recruiters that busy “dressing flesh” in order to get candidates through the pipeline. It’s an easy way to pre-screen potential candidates.As for the interview process. That’s a bit much too. In this case the candidate indicated that s/he met with 10-12 interviewers. If this is a typical 10a-4p interview day with an hour for lunch that’s 10 people over 6 hours if everyone manages to show up on time and is prepared. That’s going to work out to an average of 2 interviewers per meeting and a group or just the manager at lunch.One thing that was not mentioned was “who” were the interviewers? Were they managers, architects, peers in the same or different departments, were any of the interviewers interns, or just learning to give interviews. I’m not sure that any of this works. At some point you have to savvy enough to:stop doing the “ice cream man” dancestart selling the company, manager and job And that is simply impossible in an hour when there are so many departments, teams, and personalities involved.Project Based Interviews Instead of GitHub (link)“No one should ever require a Github profile in favor of a resume”Resig makes a number of assumptions about “custom projects” for the specific interview. This is something I did when I presented candidates with “the impossible quiz”. I suppose if you’re interviewing at Google and you want to show your chops then doing a special project might have some value. It’s also possible that recording a live pair programming session might have the same outcome. But these are exceptional cases and not the norm and it’s not going to demonstrate the candidates interest in you market or stack. There are simply way too many variables for a project to be valuable.However.I have been known to provide a few programming assignments, both in advance or at the time of the interview. And from that POV I’ve asked decision questions. “why a hash instead of a list” etc… That usually leads to a better outcome.Resig goes on to challenge the pressure of an individual interview. (I blew a few of those with the like of Google and Amazon). Frankly, unless you are simply desperate for a job (been there too) nervousness or lack of confidence can be an indicator for that candidate’s abilities. And sadly with a little too much confidence the candidate might not have enough practical experience to know the difference. But a nice balance is good.