I’ve been hiring software engineers for over 20 years now. In that time I’ve interviewed literally hundreds of people. Here are some of the lesson’s I’ve learned along the way…

Fit over skills

I’ll take attitude, willingness to learn and enthusiasm over skills every time. It’s nice if the person has the skills but, given that the gap is not unassailable, we can generally teach any missing skills. I cannot teach empathy, intuition or curiosity however.

Flexibility

I always ask some questions about favorite tools or approaches. Then I challenge these to see the reaction. A ‘red flag’ for me is someone who is inflexible about their technology choices. In my view it’s equivalent to having a favorite hammer that you will always use - even when what you actually need is a scalpel.

What I am looking for flexibility. If presented with a viable alternative would the person still stick to their firmly held belief? If working in a team that used a different tech stack how would they react?

Learning

Learning is a lifelong commitment in Software Engineering. Some of the skills & technologies we have today will change over time. This is one of the reasons that hiring solely for skills is problematic. It’s critical for me to asses the person’s ability to learn and how they learn. If the person is unable or unwilling to learn it’s better to know up-front. If the person’s learning style is at odds with how your organisation trains this could also be a problem.

I normally ask these question:

• “How do you go about learning something new?”
• “What was the last thing your learnt?”
• “What is the thing you are most proud of having mastered?”

Tactical vs Strategic skills. I classify skills as Tactical or Strategic. Tactical Skills are the things we use every day. Think your IDE, Javascript Framework or Build System. Strategic skills are things like Enterprise Integration Patterns, SOLID, OOP, Functional Programming. What I’ve found is that Tactical Skills change at a different rate than Strategic. Some of the Strategic ideas have been around, largely unchanged, for decades.

What I test for

I use our engineering ladder as a basis for the interview. Our ladder is based on the framework proposed by Engineering Ladders. It looks at individuals in terms of a number of dimensions:

• System - level of ownership of the system(s).
• People - relationship with the team(s).
• Tech - knowledge of the tech stack and tools.
• Influence - scope of influence of the position.
• Process - level of engagement with the development process.

Each role is plotted against this model to determine the minimum level of capability for that role. For example we would expect a Tech Lead to score above an ‘Enforces’ on the Process dimension as we expect our Tech Leads to be a driving force in process improvement.

During the interview I try to assess where I think the person is on the ladder and compare that to where they would need to be for the role. You can then ask question to get a feel for where the person might be. For example:

• System: Tell us about a time you tried to improved a system you were working on? How did it go? How would you as a new team member suggest and implement such a change?
• Team: Tell us about your previous teams. What worked well? What role - did you fulfill? Tell us about a time you helped the team or team members.
• Process: Tell us about a time you tried to improve a team process?
• Tech: See ‘Testing for Skills’ below.
• Impact: What other teams do you work with frequently? How do you interact with those teams?

Testing for Skills

In the past I relied heavily on whiteboard interviews and supervised coding tests. I have come to learn that these approaches are fundamentally flawed at best and inhumane at worst.

Software Engineers are not expected to work with someone looming over their shoulder watching their every keystroke. Neither are they expected to be shown an esoteric piece of code and instantly spot the errors and propose a fix within a 20m conversation. Many people simply cannot handle this type of pressure - the fight or flight reflex kicks in and they literally lose the ability to reason. I’ve seen talented engineers completely flunk questions that, if asked in a different environment, they would have been more than capable of answering.

My approach these days is to ask the person to share some code they have written. If they don’t have something I propose a small problem - something that can be accomplished in a couple of hours. The person can tackle this on their own time, using their own tools, in the language of their choice and send it to us. We then can have a conversation about what they wrote.

I frequently hear the concern ‘what if the person has help’ or ‘what if they Google the answer’. This is obviously a factor, even more so in the age of ChatGPT. Let’s say that happens though. When we do have the conversation would they be able to explain ‘Why’ certain things were done? Would they be able to explain ‘how’ they arrived at the solution? Even if someone had help with the solution but can eloquently explain the ‘why’ and the ‘how’ of what is there and extrapolate beyond the scope of the initial question I’m OK with this. After all - collaborating, asking questions, Stack Overflow and now ChatGPT are all valid tools in the Engineer’s Toolbox. Why should we expect people to fly solo for the sake of the interview?

Hire a contractor if you are only looking for specific skills. In some cases you simply need to have access to a specific skill-set. In these cases I would try to find a contractor or company to work with. Compromising on ‘fit’ because of short-term skills can be risky if the person does not work out. A short-term contract with the option to convert to full-time is a safer bet.

Be careful of group-think

Keep a careful eye on your successful candidates and those you filter out. This is especially important when you scale and start to devolve the hiring process to individual teams. There is a tendency for people to hire those who look, act and think like them. If this happens it’s to the detriment of the organisation as a whole. There are numerous studies to support this position. In addition bias in the hiring process artificially reduces an already limited pool of options. If you find yourself saying ‘We can’t find anyone’ go back and check who you filtered out and why.

CV Scanning

When looking for an engineer it’s not uncommon to be presented with a list of 40 plus candidates. Here’s how I whittle them down…

• Do a quick screen to remove obvious non-starters. I’ll frequently get people who are below our ability to train or simply have the wrong background. For example, someone wanting to move from the Accounting Team to Engineering with zero programming knowledge. This is not something that we are geared for.
• Scan through the remaining CV’s and and select the ones that ‘stand-out’. For me these typically have one or more of the following characteristics:
  – Some details on what the person has done above just a simple chronology and list of technologies. For example: “Performed a complete rewrite of the mobile application using Redux for state management, rebuilt the storage system which now runs on Watermelon and RxJS.”. This tell me much more than ‘PHP Development’ or ‘Android Development’.
  – Range of technologies. This shows that the person is capable of learning new things and has done so.
  – Links to Open Source projects, Blogs etc. These are interview gold. If the person has a GitHub I can quickly take a look and see what level they are at. Blogs and community contributions also give good insight into the person’s communications skills.
• If at this stage I have enough candidates I’ll stop there. If not I’ll repeat until I do. The number of candidates is based on the Interview to Hire ratio. For example if you typically take 7 interviews to select on developer then you would need at least 7 candidates.