Interviewing engineers when you aren't one is a regular human resources task that tends to give non technical folk fits and for good reasons.

1. Focus on What You Can Interview them About

To the non engineer, our job is all about coding but that's actually only a part of what an engineer does. Engineers exist in the same ecosystem as any employee and there are all kinds of questions about work practices that need to be asked. For example if remote work is a part of your work environment then dig down into how that person might function in a remote context.

2. Communications Ability Is Always Key

Engineers do not work in a vacuum and the ability to communicate is a key ability that improves the quality of their work. Ask questions and see how the engineer communicates.

3. Look for Attitude

A lot of engineers love to drown non technical people in what amounts to techno babel – it is a way for us (yes I am an engineer myself) to feel superior. Look for hints of that attitude during the interview and if you find it before they are an employee then you should expect it to be even worse once they are an employee.

4. Look for Values Alignment / Culture Fit

When I'm an interviewer, I care most about whether or not the candidate can do the technical work because, honestly, I can work with anyone – in the end all I care about (mostly) is whether or not the code works. Now if you are non technical then you don't care about that but you likely care a lot about value alignment and culture fit so dig in there.

5. Look at Work Practices

Even if you aren't technical, you likely have some idea around work practices in development from either past experience or media. It is ok to ask a general question like "I have a bug in what you are working on - how do you handle it?". And then what you are looking for is some kind of logical approach.

Note: My first two answers on this one are:

  • They either log the bug formally in the bug tracker / ticket system
  • They try and reproduce it

6. Salary / Benefits / Company Details

If you are a non technical interviewer then there is a good chance that you get the (oh joy) role of tackling salary / benefits / company stuff. This is something that has to be dealt with.

I'm a firm believer in NOT doing coding tests particularly for senior engineering roles. There are all kinds of reasons for this that should likely be the topic of another blog post. I tend to take people's word that if they tell me they can do X competently then that's true. And the reason for this is that if they misrepresent themselves, well, that's a fireable thing. And I lost my fear of firing people before I turned 20 years old.

If you feel like you have to prove coding quality upfront then I recommend:

  • White boarding exercises
  • Rigorous reference checks
  • Code samples
  • Published Github code
  • Contributions to open source projects