Don’t forget soft skills when interviewing engineers

This is based entirely on personal experience, but I thought it might be useful to others. Tech companies tends to do highly technical interviews in engineering and overlook the soft skills. Over the years, when I’ve been given the freedom to do so, I tend to focus more on soft skills. Here are some things I often ask. There really aren’t right and wrong answers, but it’s more about how they handle what is thrown at them.

How do you think code should be tested?

Here I’m generally looking for a few things:

• Recognition that having only engineers testing their own code is not adequate. If they think it is, I will usually point out that if you know how your code works, it might be hard to stumble upon bugs. Then I see how they respond.
• Familiarity with the different types of testing and their strengths and weaknesses. For example, engineer testing, unit tests, manual testing, and automated testing.
• Understanding that all testing cannot be entirely automated. If they think it is, I will point out cases where it’s problematic. For example, new features in flux and UI-centric features.

Communicating technical to the non-technical

It’s important for engineers to be able to explain highly technical things to non-technical people. Perhaps internal users that file bugs that aren’t engineers or EPMs that might be less technical or even technical people that aren’t familiar with the area you’re working in. One thing I’ve done here is that I look at their resume beforehand and find some buzzword I don’t understand or maybe just pretend I don’t. I ask them to explain it to me and try to put myself in the shoes of somebody that doesn’t understand the topic area at all.

Arrogance

Arrogance is a trait I feel we don’t want where I work and I’ve helped reject candidates that had stellar resumes because of their arrogance. It can lead to tunnel vision or difficulty working with other people, especially if other people think you are wrong. One thing I’ve done here is to take something on their resume and cut it down, maybe say that I don’t understand why what they did was important or why they did it the way they did. If they respond in a more self-deprecating way, that’s great, but if they get upset or agitated, that’s a warning sign.

Finding defects

I feel like even someone who doesn’t do QA should be skilled at finding defects. Sometimes what I ask is for people to list some really irritating bugs they found on one of our platforms. If they can’t think of a single thing, that’s a big red flag in my mind. Or I’ll ask them what they feel is the worst product the company makes. Are they OK with criticising the company that they may work for.

Communication style

One of my red flags is people that talk too much, talk over me, or don’t let me end the current question and go on to the next. Now, this one is difficult because people are going to be nervous and people tend to talk more when they are nervous. I usually start the interview by explaining that I have X topics to cover and I’ll be checking my watch frequently to make sure that we are on schedule.

Affecting change

Large companies in particular are slower and more difficult to change. So I ask people what major thing would they change about the company if they could. Then I challenge them and tell them that what they brought up might be very, very difficult to change, even if it’s not necessarily true. Then I gauge their reaction to it. Candidates need to know how to pick their battles and be prepared for the difficulties of working with large numbers of people. 

Indecisiveness

Regardless of the size of the company, individual contributors have to make a lot of quick decisions on their own and not wait for their boss to tell them what to do. I like to see candidates that can be decisive. One exercise I’ve used is a prioritization exercise. Whether it’s a hardware or software company, tough decisions must be made of what to fix now versus later (or never). I give them a list of either made-up or real defects in a product and have them put them in order of importance. It’s just the title of the problem so they can ask any question they like. I look for smart and quick decision making and good questions.

Why here?

This is a very cliché question, but I think every candidate should be asked. I strongly feel that if a candidate is interviewing at multiple companies that this company must be their first choice out of their available options. And the answer to why they want to work here is critical. We don’t want people where the decision between this and another company is a difficult one. We want people that are very passionate about our products and want to make a real difference in the world.

What have you done on your own?

For an engineer, a huge flag for me is someone that has done NO side projects outside of school or other jobs. I expect people to have some sort of passion that they met by creating a product. Or wrote an interesting tool that helped them in their personal life. That shows true passion when it’s something you’ll willingly do when a boss or a teacher isn’t telling you to do it. This is a huge red flag for me and shows lack of intellectual curiosity and lack of interest in solving problems.

In this article, I wrote about a specific case of this being employed.