Use code interviews to assess soft skills and personality

Coding interviews are quite infamous, especially with more senior developers. The main arguments against them are that they don’t properly assess skills, are not matching any reality of the job, and are time-consuming for both the hiring team and the candidates.

Whether they are “whiteboard” coding, live coding, or coding home-works, they seem to all have the same flaws.

I agree mostly with those flaws but think code interviews can still be useful. I found that there are 3 criteria that are often not properly cared for, and interviews should be designed for each of those criteria:

1. Who do you interview? (seniors, juniors, remote coders, consultants, etc…).
2. When — in the recruitment process — do you want to assess technical coding skills?
3. How are you going to “grade” or what do you want to assess exactly?

Who do you interview?

Are you looking for juniors or seniors? The main difference between the 2 ends of the seniority scale could be summarized like this:

• Juniors tend to be very good at “academic” tasks. They are closer in time from all their tutoring, where they learned about algorithms, and the foundation of software engineering: concurrency, sorting and data structure algorithms, complexity, etc…
• Seniors have more real-life experience. That doesn’t mean they don’t know how to sort a binary tree anymore, they know where to find that information rapidly when needed, and what to look for. But from the top of their head, they would not be able to rewrite those algorithms.
• Juniors tend to be very focused on the languages, frameworks, and tools, as they are still learning a lot, every day, and are not already used to work in teams.
• Seniors will have team collaboration, debugging, and production experience. They know what to do when the theory can’t help you anymore. They also know that the success of a project does not depend only on code and frameworks, but also on communication, automation, simplicity, delivery, marketing, adoption, user experience, etc…
• Seniors have used many tools, frameworks, and languages. They know the pros and cons and are less likely to have religious software opinions. They are also more likely to learn something new faster.

Also, depending on the level of expertise on a particular technology you need, the interview needs to be adapted: are you seeking a particular skill in a particular technology? Then assess that skill in depth.
Are you looking for a versatile, great software engineer? Then a deep technical assessment of a particular framework or product is not going to yield good results. I believe that a great Java developer will make a great Scala developer in a few months, given they have the right mindset and the right environment to support them.

When to use coding interviews in the process?

Coding interviews can be very expensive in terms of time and energy. For the candidate, and the team.

Beginning of the process: use existing tools or platforms, with standardized coding interviews for everyone. Those should help you sort a large number of applicants rather than tell you if someone is really a good coder. They should be short, enjoyable, with a standardized grading scale.

• Pros: sort out any “unmotivated” individual, or people with a big gap in skills
• Cons: they will most likely repel more senior developers or good developers with very little available free time.

End of the process: prefer in-person pair-programming or homework. They are more difficult to design, should match more closely what your company is doing. They take also more time for candidates, so doing them at the end “optimizes” the time lost over the pool of candidates and the hiring team.

• Pros: can be closer to your business and tech stack, more challenging, and assess particular hard skills that are important to your team.
• Cons: you need to design them well, or you will just lose a huge amount of time and gain no insight (or worse: wrong insights).

What to assess with coding interviews?

Technical interviews help you sort through very bad apples and get a first insight if the candidate’s tech skills. However, it’s rare to find someone who’s an expert at all the tech you’re already using internally, and for the reasons above, it’s also hard to craft a good technical interview.

Following the common wisdom that you should hire for soft skills, train for hard skills, I found that tech interviews are actually very valuable to assess soft skills too!

After a few dozens of interviews, I liked to use pair-programming, home-works, or other tech interviews to assess the following skills:

• Collaboration and interactions with peers/managers
• Communication
• Precision and attention to details
• Capacity to read instructions!
• Cleanliness (not only of the code but of everything around)
• Understanding of the big picture, capacity to take a step back
• Creativity
• Stress management

A few examples

Ask the candidate to provide the Git history with the homework. (or ask them to use Git also during a live interview)

• Did they actually provide it? (or were they actually only focused on code?)
  Assesses attention to details in the instructions, but also to the big picture. A project is never only code, and rarely a one-person project.
• Is everything into one big commit called “WIP”? Or did they use a few commits to actually make their code clean and shareable? Team collaboration and product maintenance rely heavily on Git. This is as important as a good working code.
• Have the commits meaningful names? Again, collaboration and maintenance. Signs of seniority

Look at tests, or ask them to write tests.

• Seniors who have maintained projects over time will write better tests (or just write tests at all). Juniors will tend to write meaningless tests just for the sake of it and focus on functional code only.

Try hard to give some feedback regarding things they could have done better or differently. See how the candidate responds to that.

• Feedback that goes against one’s ideas is always difficult to hear. Justified or not. Reaction to this feedback (including body language) tells a lot about team skills, communication, empathy, capacity to take a step back, and ego. Code is never the property of one person in a team. It’s the whole team’s code.
• Look for someone who accepts feedback, and reflects on it first. Try to avoid people who are unable to take a step back, try to justify all their choices without even first trying to understand a different point-of-view. If they are unable to accept feedback in an interview process, they are most likely unable to accept it in a normal team configuration.

Ask them for improvement feedback about the assessment.

• Are they able to see the big picture, what did they think of the assessment beyond “It’s nice”, “It took me longer than expected”, or “I don’t like assessments”…
• Are they able to formulate this feedback with more than a statement, communicate their ideas with a manager or teammate?

Pair-programming

Pair-programming refers to the practice of having 2 engineers tackling the same piece of feature or bug. While it may sounds “inefficient” for non-tech people, this is a practice that is actually good for the following reasons:

• Less or no review is needed, as the code written is “4-eyes-checked” continuously. Hence quality is improved.
• Live collaboration fosters creativity and simplicity while reducing bugs and misunderstandings

The great advantages of running “pair-programming” interviews are many:

• Involve future teammates, get to see the real team, in its natural habitat
• Work on something “real”, get to see the actual code and product
• Includes all aspects of the technical interview at once: tech knowledge, coding ability, testing, cleanliness, review, interactions, creativity, communication, etc…

The main disadvantage is organization and the time it takes to run it. You also need teammates that are willing to welcome an “intern” for a few hours of their daily routine.

Closing thought

Assessing the hard skills of Software Engineers is important of course. And while coding interviews are still a debatable practice, they are full of information regarding soft skills too. I would go as far as saying that I learned more about candidates’ personalities, indirectly through technical and coding interviews than I did through “calculated” behavioral or generic interview sessions.