Blake Callens is CEO and co-founder of PencilBlue, and co-founder of the Raleigh Entrepreneurial Acceleration Lab. He’s a regular contributor to ExitEvent.
Every software engineer has experienced a job interview in which he or she was forced to act more like a dictionary than a human being. There’s a prevalent misconception that, in order to properly develop software, one must know all the minute details of any programming language listed in the job requirements. It’s a remnant of the days when developers received their knowledge from physical manuals.
It’s common for today’s experienced developers to disqualify a company the second they’re treated this way, and a ton of companies lose out on great prospects when creativity is taken out of the interview process.
I once sat on the phone with someone for the better part of an hour as they proceeded to ask me what different variables and functions in JavaScript and jQuery were named and what they did. Not one question had to do with my actual experience working with web technologies to meet business goals, even though this was for a leadership position at a multinational corporation.
I’ve many times had to listen to non-technical human resource managers stumble through “pre-qualifying” questions handed to them by a technical lead. It’s obvious the interviewers could have been speaking in Star Trek technobabble, for all they knew.
These questions often reek of bias from the person that wrote them; more “here’s how I do things” instead of “how does this work?” The interviewer doesn’t know this, of course. The person just marks the interviewee as having failed the question when the response doesn’t match the single possible answer given.
I once was given an on-the-spot code test, where I was asked to write a JavaScript application in a browser window (without monospace type and where hitting tab would exit the text field – but I was judged on formatting, of course). I had no ability to test my code before submitting it, because the interviewer was watching me write it live and would copy and paste it into a browser console.
In a feat I’m still proud of, the whole application somehow worked perfectly on the first run. The interviewer then proceeded to bluntly and rudely walk me through his personal way of solving the problem. It was a solution that he had obviously spent significant time thinking about and retooling, not on-the-spot like I was asked to do, and it included far more preference than improvement anyway.
As bad as all those experiences were, they all pale in comparison to the interviewer who asked for my SAT math score. I was 34 at the time.
These situations are utterly ridiculous, not just in themselves, but also because of an unspoken truth about developing modern software: three quarters of it is knowing the general philosophy of programming and how to communicate that knowledge. The rest you can find through a Google search.
Don’t believe me? Here are some some real technical interview questions you can find in “best of” lists:
How does jQuery bind a click event to a DOM object?
What are the Data Types supported by Java?
Two things, more than anything else, will keep you from finding and hiring the best software engineer for a position:
1. Focusing on pure technical knowledge over actual business experience.
2. Looking for conformity of opinion instead of diversity.
Ask business questions to software engineer candidates since those are the kind of problems you’ll bring after hiring someone. Make them relevant to real world challenges you face:
*Our client wants to integrate a re-marketing vendor with our POS system. Do you have experience working with email marketing and/or REST APIs?
*Here are the photoshop mockups of an application. How would you go about building the front end? What technologies would you want to use?
*What’s your opinion on [technology in use at the company]? What do you think are its strengths and weaknesses?
All three of these questions open up the conversation to deeper technical questions that cover the type of knowledge software engineers need to properly do their job. None of them will cause the interviewee to have to prove his or her rote memorization of terminology. You’ll also get a better sense of how this person will communicate and work with a team. After all, it’s far easier to teach someone technical skills than how to interact with coworkers.
Instruct your technical leads that, when the interviewee answers these questions, he or she is free to challenge the candidate’s assertions, but only if it furthers the conversation. Under no circumstances should the candidate be told that the personal programming preferences of the technical interviewers are better than his or her own.
This is a very common, destructive mistake made by technical leadership at companies that can permeate every part of the process, not just interviews. It is usually solved only when the leader forcing people to tow his or her line is sacked. Software is healthy only when a variety of ideas are present in its construction and maintenance.
When programmers aren’t allowed to inject their visions into the team effort of an application, many opportunities for improved software are missed. Great developers who can better your product by adding their unique experience will turn and run at the sight of an overbearing technical lead.
Overall, the best thing to keep in mind when hiring a software engineer is that it’s no different than hiring any other skilled tradesperson. You wouldn’t ask a marketing candidate to recite the phases of Gartner’s hype cycle, so why would you do that to a software engineer?
