How to Interview Engineers


Interviewing engineers can be a complicated process. Several mistakes could leave you without the best talent that you need to build your team. Here are some common mistakes – and steps to deal with them.

The Traditional Method

Most engineering interviews happen in two steps – screening and then a final in-person interview.


This process is to cut interview time and involves an extremely short glance over a resume and a phone interview of at most an hour. Some companies, though not many, also use take-home challenges to test programming skills.

Of all applicants, around half are rejected in that initial short resume scan, while the second part of the screening loses another 30%. Decisions happen quickly, and there is no time to consider hidden talents or benefits.

Engineers usually get technical interviews of around an hour, followed by another focusing on their soft skills. Every interviewer gives their opinion, and the hiring manager makes a decision based on this.

Of all applicants in the second stage, just over 20% get a job offer, around 65% of whom accept the offer. After a year, only about 5% of these new hires get let go.

The problem with the status quo

While it looks solid on paper, the main issue with the current trend in interviewing and hiring is noise. False positives lead to a lousy engineer being hired and later fired. A false negative prevents an extremely skilled person from taking the role.

Bad hires cause expense, financially and morally, to a business – so companies lean more towards rejecting than hiring during an interview. Unfortunately, this loses out on much talent!

The “noise” includes the fact that an hour is not much time to judge technical skills. It’s also tough to get to know a person on a phone call or in a 45-minute chat! This noise leads to a situation where expertise gets ignored in favour of educational credentials, which is hardly fair for those who may have real talent and no official qualification. It’s damaging both to the company, who loses out on talent, and the candidates, rejected seemingly off-hand.

How to reduce noise to find the best candidates

1. Know your skillset

Programmers all have different sets of skills, and before your interview, you must know which collection of skills you need. Someone quick or someone rigorous at coding? Do you need someone interested in problem-solving or someone product-focused? What language do they need, and do their current qualifications matter for this role? Ask yourselves these questions, so you know what you’re looking for going ahead.

2. Keep it relevant

Professional engineers will work on extremely long projects, but an interview is a very compressed environment. To solve this, focus on small problems to be resolved quickly, and make sure the chosen tasks are related to what the engineer will be doing in the workplace. If it’s a take-home exam, make sure not to waste their time with external programs they need to download, install, and learn.

3. Don’t ask questions that everyone knows already.

Just avoid brain teasers and insight questions altogether. They’re all online, and they don’t prove anything! Items should be step-by-step and build on one another, making a cohesive experience. Presenting multi-part questions also lets you help out if candidates get stuck – a positive to their interview experience, and to you, who may have missed out on extreme talent due to one tiny gap in knowledge that may simply be nerves.

4. Don’t make it too hard

Yes, you want the best skill, but a too-intimidating set of questions is just going to make people nervous and scare them off. As well, a correct answer is hardly ever as important as the process they took getting there! As a rule, don’t set a problem that you can’t solve in a quarter of the time the interview might take. Their processes, rather than the answer, will provide you with the most useful information in the long run.

5. Keep questions the same…

It might sound simple, but if you’re interviewing candidates, you need to ask them all the same problems. It’s the only way to ensure consistent, fair, and accurate comparison of all interviewees.

6. …or make them completely different

While ad hoc questions are never a good idea, you might want to hire a lot of different kinds of engineers with different skill sets. If this is the case, make the interview tracks completely different to focus on the different areas. However, still, keep them consistent!

7. Avoid over-reliance on credentials

Most engineers are not MIT graduates who have worked for Apple. Relying too heavily on these things leaves much talented, experienced talent out in the dark! Yes, you can consider these things, but you should never let them be the final deciding factor between two candidates. Before giving the resumes to your interviewers, it might be a good idea to take company names and school names off!

8. Don’t haze!

Don’t be short-tempered or frustrated with a candidate who is struggling, and don’t make it into a painful rite of passage. You are a company and a job for them, not a fraternity! If a candidate is struggling, let your interviewers teach them how to solve the problem and find the answer. Switching between evaluation and teaching can mentally prevent the negativity of the hazing mindset.

9. Final decisions should focus on their maximum skill level, not the minimum or even average they can do.

One of the problems is that when there are many potential candidates with several interviews, fluffing one part can lead to a strong ‘no’ from that interviewer. The solution is to make sure you’re asking the right questions that check if their main strengths match those that you need for the role, and their weaknesses don’t line up with your requirements. You shouldn’t let one mistake in an interview write off a candidate completely.


Interviews are stressful, but a necessary way to evaluate skill. You cannot expect any kind of process to work all of the time correctly! However, bear in mind the humanity of both you and your candidates, and you’ll be one step closer to a better team.