The art of interviewing engineers

These past few weeks I’ve been interviewing with a few companies, as I’m actively on the lookout for a new challenge, and the number of flaws I have encountered in some hiring processes has disturbed me.

Interviewing is hard; interviewing Software Engineers is a work of art.

interview

Let’s be honest. Software Engineers, especially in the functional programming space, are a scarce resource. So the better the interview process, the bigger the chances you have of hiring great engineers.

During my career, I’ve been part of the hiring process from day one, and I have learned a few lessons I would like to share with you all, given my recent frustration with some companies.

1. Two or more engineers

Most interviewing processes have a pair-programming session, which is probably the most delicate part. You will not only assess a candidate’s coding skills but also their ability to work in a team.

It was at this stage where I’ve seen many companies fail. They commit the most terrible mistake: having a single engineer on the company’s side.

This is sort of a monarchy where you, the candidate, are judged by an individual who might not be as competent as two or more persons in doing so.

I cannot enumerate the number of times I have disagreed with my colleagues while interviewing a candidate. We all have different points of view, so having at least one more brain in the room will open up the chance for debate and avoid ending up in a biased decision.

Having two or more engineers applies to conducting any other interview, such as system design, code review, or behavioral assessment.

2. Give feedback

The sooner you get back to your candidate with feedback, the better. Whether you decide to move forward or not.

I would argue it is even more important to give feedback when you don’t want to proceed with the candidate. Let them know about the reasons why you think they will not be considered for the current position.

It is a professional courtesy that will make your company respectable.

3. Ask for feedback

Giving feedback shows professionalism; asking for feedback shows humility.

Your interview process might be utterly broken and far from perfect. So take this chance to get an outsider’s opinion to improve it.

A good convo is to ask for feedback in the same email where you are giving it. For example:

Dear candidate,

We have decided not to move forward given the following reasons:

  • first point
  • second point
  • etc

If you have some time, we kindly request your feedback about our hiring process. What did you think about it?

Kind regards,

The interviewer.

Being humble is one underrated skill.

4. Coding challenge

If, as part of the process, you decide to go with a take-home coding challenge, be flexible when it comes to third-party libraries usage or different approaches.

Remember that you are asking engineers to free some of their time to get an unpaid task done. So at least let them choose the tech stack.

Most engineers take this task as a chance to explore some libraries they love or would love to use. Other engineers wouldn’t even bother going through all of this, so be considerable.

What is more important is to evaluate their thinking-and-solving-problems ability. As long as they can defend their solution in the code review stage, the techniques or third-party libraries they might use will remain secondary. Defending a solution is something we, engineers, need to do quite often. So you will be assessing another critical engineering skill.

In the meantime, you - the interviewer - might learn a few things as well; it is a back-and-forth learning process.

5. Cut the bullshit

Let the formalities be handled by those who enjoy living in a world of bureaucracy.

If you know you have the chance to hire a great engineer, cut the bullshit and offer an alternative and quicker hiring process. Engineers hate beadledom.

If you succeed, you will more likely secure a bunch of great engineers who would be happy to work in a relaxed environment, free of that they spite the most.

Additionally, the happiness of your employees comes with other benefits; they will promote your company and recommend it to other engineers. It is a win-win strategy.

Ultimately, be clear about what you are looking for, but also be honest about the current situation of the company. Nobody wants to jump on a sinking ship. Don’t oversell it.

Summary

This is my top five. However, I believe a great hiring process should always be in constant improvement. Question your techniques and results at all times, and aim for a top-notch hiring process.

How about you, Software Engineer? What other pain points have you stumbled upon while taking interviews?

At last, I’ll leave you with another great resource on how to conduct a good programming interview.