Founder’s Guide to Interviewing Engineers

When you’re interviewing for a software engineering position, you must know how to code. There’s no way around this. The current job market with its never-ending demand for developers has spawned a billion dollar recruiting industry built around finding and placing engineers into jobs. Finding suitable applicants is hard enough, a fact evidenced by the huge payments organizations make to headhunters, but vetting developers for compatibility and competency, even for bigger organizations who have years of experience in hiring, proves more of a challenge. In principle, it seems simple. You’re looking for people who are competent and can get the job done.

Making the wrong technical hire, especially for an early startup, can prove to be more than just a costly mistake. Founders, even the technical ones, depend on early hires to build out keystone features, help steer the company, and make critical decisions about how the product will evolve. So, of course, we spend a considerable amount of time poring over resumes, looking for the perfect mix of skills, pedigree, and experience. From timed programming tests to twisted computer science questions, from take-home work to putting them through pair programming on-site, we like to talk to interviewees about their past projects, looking for parallels to our company’s current or future work.

• The most crucial thing is running a repeatable and consistent process. It’s tough to get meaningful results if you do not maintain consistency. Often companies display a considerable disorder in how they interview candidates. It sometimes depends on how busy it is, what projects are currently a focus for the team, who is in the office, and by whom the candidate engineer may have been referred. Start by laying out a consistent scoring system which runs across both cultural compatibility and skill competency.
• Secondly, the candidate should interview with at least two to three different people at the company, which will average out a fluke terrible or great experience. Plan for what each person will interview the candidate about. There’s no point covering the same ground over and over again. The plan should be to paint a larger picture of the candidate, every time somebody from your organization interviews him or her. This way the candidate won’t have to repeat herself over and over again, either.
• Most of us gravitate towards beginning the interview by asking the candidate about his or her involvement in past projects and have them walk us through how they did something or how they solved a particular problem, to get the conversation started and glean an understanding of the candidate’s personality. This strategy seems sound, and it is an overused one because it’s comfortable and far less stressful than asking and answering quiz-like questions or going through whiteboard exercises. However, talking to people about past programming won’t tell you much because you don’t know how much of the described solution the candidate was indeed responsible for, and these conversations tend not to get into the kind of gritty details that make them truly useful. And these conversations could bias the process toward the more articulate and puts the less talkative, but competent programmers at a disadvantage. Too many of good programmers undersell themselves, so trying to prompt them with these kinds of free-flowing conversations might not always work.
• Degrees from reputed institutes does indicate a particular caliber, but by making it a criteria, you will miss out on too many good candidates who may not have these credentials. Use a blind process that judges an engineer on nothing but his or her skills and readiness to contribute. Meaning, you don’t look at a candidate’s resume before interviewing him or her. Ask your technical questions and dive into the code, but you won’t know whether the candidate you’re interviewing has majored in computer science, civil engineering, or arts. Or if they even graduated. This will allow you to judge them without any preconceived notions coloring your opinion.
• Make take-home projects an option for candidates, not a requirement. Most experienced developers with impressive resumes won’t participate in a take-home engineering test. They don’t have to. So by making this a rule, you quickly eliminate many qualified applicants. The ones that don’t work well under pressure might prefer to do one of these as they might want to work without somebody standing right next to them. But one can’t argue that going over the code the interviewee wrote for your project is a clear way to understand how he or she approaches problems and pieces together solutions.
• Don’t ask complex programming questions in the interview. The way a candidate solves a question offers a better, more dependable sign of aptitude than asking all a complex question, which most might not solve at all. Some engineers who answer the problem quickly, without a struggle, might just be more practiced than developers who need a little time to think about the problem and scrape their way to the correct answer. However, both engineers could have been stumped by a difficult question, which won’t offer the same quality of feedback for interviewers.
• Don’t read too much into past hires. Too many startups that may have made ten to twenty engineering hires will use their experience as a guide to future hires. Ten or so hires is nowhere close to enough data. You cannot count that as a noteworthy sample size. So even if you have found three decent engineers from a certain institute, it isn’t enough to look at degrees from that institute as a sign, just as a bad experience with one developer from an institute also doesn’t indicate anything significant.
• Engineers, like the rest of us, tend to favor people who come from the same technical backgrounds, experiences, and skill-sets like their own. Whether a company realizes it or not, this bias will make its way into evaluations. So it’s something that has to be controlled for, or else much of the meaning in an evaluation has been compromised.

• We are all bad at something. Interviewers need to acknowledge this. Questioning an engineer to gauge his or her average aptitude across various subjects sets the candidate up for failure, and doesn’t do much good for your company either. The whole point is to hire people who are good at something your company requires. Hone in on the skills that are extremely crucial to your company. A candidate’s high rating in that area is a better overall indicator of their worth as an engineer to you than their average overall score. If you ask somebody a question on their strong suit, perhaps front-end architecture, they should rock it. They might do quite poorly on a question about back-end python frameworks, but that’s okay, and it shouldn’t place them behind a candidate with average scores on both questions.
• Use pair-programming exercises throughout most of the interview process. While the code quality a candidate displays during these exercises is vital, it’s important to observe how the candidate works with other engineers. You’re looking for team players who enjoy collaborating with other developers to solve problems, not a lone ranger with a freelancer mentality. Can they incorporate feedback as they progress? Are they open to varying opinions? Do they ask for clarification or help quickly? What they do when they get stuck? You don’t want people wasting their time trying to figure things out themselves when a quick call for help on Slack would remove a blocker. Candidates who impress your team are those who buy into a supportive and collaborative environment. Other than through reference checks that don’t always tell the whole story, the only way to figure that out is by working on a problem side by side.
• Question the candidates about engineering projects they’ve done outside of work if any. Good developers are often passionate about their work and often have stuff they’ve been working on in their spare time. Their self projects are generally hosted on repositories like Github where you can go through their work without violating policies regarding other organizations code and IP. It’s a good trade-off for ones who would like to dig into the candidate’s previous projects without making the error of not probing far enough into it.
• The first sign of a good interview and a smart candidate is when you don’t have to explain things over and over again. The conversation just flows. Often, the candidate says something that shows real insight or mental acuity. So an important part of the interview is creating a situation where someone can show you how smart they are. The worst kind of interviewer is one where the interviewer does all the talking, barely leaving the candidate much to say.
• Another horrible way of taking an interview is conducting a trivia contest. Smart does not equate to knows a lot of facts. So asking a bunch of trivia questions about programming for which you can find answers online in about twenty seconds doesn’t prove anything. You want to hire people with aptitude, not a particular skill set. Most skill sets people come with, soon become obsolete technologically in a few years anyway, so it’s wiser to hire folks that are fast learners than fact hoarders.

In general, to learn enough about anybody, you need to allow them do much of the talking. Give them open-ended problems and questions. Vetting candidates from an applicant pool demands time and diligence. It’s a job. And remember, good engineers, come from all kinds of backgrounds, with just as many learning and work experiences. Happy hunting.

Follow us on Product Insights Blog from CognitiveClouds: Top Ruby on Rails Development Company