The ideal interview
Over the last three years, my role has included taking part in the hiring of Software Engineers from all levels of experience. An educated guess would place the number of completed in-person interviews at well over 50. During this time, my suggested process and key attributes that I look for in Engineers has morphed as I understood more about how to find the best candidates.
Traditional interviews
Traditional interviews for Engineering roles are seen as difficult, technical discussions. They involve what are now rather frowned upon practices such as “whiteboard sessions”, wherein the candidate is posed a problem that they are required to solve. For remote jobs, there is often a live coding session, in which a screen is shared and the candidate expected to write quality code on “common” software problems.
The issue with these interviews, as many others have pointed out before, is that they do not truly place the candidate into a position where they can show what they are capable of. It places candidates with technical accumen ahead of those with strong communication and capacity to learn. Furthermore, the questions that are often asked are not problems that are required to be solved in most engineering roles. For instance I have yet to write my own implementation of an Array container, find every second letter in a sentence and capitalise it, or write a custom depth-first search algorithm. What is more important than knowing how to solve these obtuse problems, is knowing when to use them.
Modern interviews
In comparison to the above examples, an ideal interview would focus on the following key aspects of the candidate:
- Capacity to learn
- Focus on finding examples of how they have learnt new things, work related or not
- Communication
- Ask a question such as “What is a complex problem you have solved?”
- Probe them on the more complex areas of their answer, forcing them to explain it in a simpler manner
- Relative experience
- Rather than technical experience, focus on relative industry experience and if they have solved similar problems to yours
Don’t forget, this interview is just as much a chance for the candidate to review yourself and the company you work for. Allow them many opportunities to ask questions, and be transparent about the problems you face.
Although technical accumen is of course important, with a high capacity to learn it can always be moulded and improved upon in the right environment. To measure this, create an appropriate technical problem that is relevant to the work you do. For instance, if you are a company that manages a payment gateway, have candidates complete a test to validate credit cards. If you are a form based busines, a test that measures their ability to create a simple form wizard would be appropriate. Send this too the candidate to complete in their own time, and setup a follow-up call once reviewed. This allows you the chance to ask details around the implementation and verify their communication skills.
This approach has worked well for my hiring so far. I have managed to build multiple teams that are not only quality engineers, but also communicate well with stakeholders and each other.