Highlighting strengths makes interviewing more enjoyable

By, Adam Dangoor

As a candidate, some of the least enjoyable interview experiences I have had are those after which I felt that I did not get across what I could bring to the team. The interviewer didn’t walk away knowing what I could do, only what I could not do. Software engineering is such a broad field that you could spend a lifetime writing up what I cannot do. Knowing what I could bring to the team is much more useful. I won’t re-apply to those companies and I won’t suggest that my friends do.

This post presents a few techniques that leave candidates with positive feelings about the interview experience. That’s great if you want them to accept an offer, and it is good even if their skills and approach don’t quite match what is needed for the job right now. I like to frame this as an attempt to highlight the candidate’s strengths.

Multiple question options add flexibility

Say I’m hiring for a DevOps role at a Python shop, I have a bunch of technical skillsets that I would like to know about:

• Tying together tools
• Using legacy tools
• Using cutting edge tools
• Managing cloud infrastructure
• Continuous integration strategy

. . .

The most insightful job interview is working with someone for a decade. This is hardly realistic for every candidate. An interview is therefore necessarily a time-limited process. We only have a few hours, at best.

We don’t have time to go in-depth about all of the skillsets for all candidates. Strong candidates will have experience with some subset of what we’ll want them to work on, and anyone we hire will have to learn the rest on the job.

What does it tell us, therefore, if we ask about managing cloud infrastructure, and the candidate demonstrates a poor understanding of this domain? Very little. Much more useful is to give the candidate a chance to demonstrate their strengths. If we instead tell the candidate the five most important technical competencies we are looking for, we can let them choose which one they are strongest in and therefore which one we will talk about.

If this candidate does not demonstrate strong skills, we can fairly safely assume that they do not have strong skills in the other topics. This might be a good time to end or adjust the interview process, depending on the requirements of the job.

In either case, the candidate will feel that they had an opportunity to show off their best selves in this domain, and that may or may not have been good enough.

If a particular skill really is the most important, we can phrase our prompt like this:

I have a bunch of questions about continuous integration strategy. Is that a topic you’re happy to dive into? Don’t worry if not – I have some other topics we can dive into instead.

We then have both the data that they do not know about a particular topic enough to want to talk about it in detail, and the data that they do know about another topic.

This technique lowers the stress level in an interview. Most programming job environments are not similar to a stressful interview situation. Removing the fear factor of being caught out by a question that you know nothing about can help to put a candidate at ease and allow them to show off what they can do. That has the effect of reducing a natural bias towards people who are confident in interview situations, which benefits candidates with more experience, or who come from backgrounds that provide opportunities for practice.

Ask questions anyone can answer

Another way to avoid putting someone on the spot is by asking questions that anyone can answer, where possible. If I’m asking someone about a programming project, I might ask “what kind of tests did you write?”. This puts some people on the spot: people who are not familiar with software testing and people who did not write any tests for the project they are discussing. They might feel embarrassed as they sheepishly answer “I didn’t”.

Instead, I prefer to ask “how did you know that your code was working?”. Everyone has an answer for this. And I don’t lose any useful indicators. Weaker candidates might talk about how they clicked around a few times and everything seemed to work. Stronger candidates might talk about the trade-offs they made for unit vs end-to-end tests, test coverage, manual testing, user testing, or any other techniques.

Redos reduce pressure and make for a more enjoyable interview

Offering a redo opportunity puts people at ease. They’re less likely to worry about having a bad day – the pressure is off a little. It doesn’t cost that much – redo opportunities aren’t taken very often. Candidates can often tell after a thorough interview process when their skills don’t match what you are looking for – why bother with another round?

And if a candidate does take a redo opportunity and pass – great! You potentially have a new hire without the extra sourcing cost. Offering a redo shows an understanding which is attractive and it might set you apart.

Let the candidates know what you are looking for

Engineering teams that I want to work with communicate clearly and often. Mind-reading isn’t such a useful skill that it needs to be tested in a technical interview. When I’m giving someone a coding challenge and time is a factor, I don’t make them guess what I’m looking for.

I might tell them that in this interview, completeness is the most important thing. Or I might say that I’d like to see what the code they ship to production looks like, and I don’t mind so much if we don’t quite complete the challenge.

If I’m looking for a colleague who writes really well-documented code, what use is it interviewing someone who thinks that I want to see how many coding challenges they can do in fifteen minutes?

Give only as much guidance as is necessary

If I’m given a coding or design exercise in an interview, I might get stuck. Usually, the interviewer will step in to help me. And sometimes, either inadvertently, or out of frustration, they might give me some advice that I don’t really need.

Say I am given a coding challenge to return a sorted list of prime numbers from an unsorted list of integers. Partway through my code has a couple of bugs – it counts some negative numbers as prime and it gives a division error if zero is in the list. While I get stuck trying to fix the division error, the interviewer steps in to help me. They suggest that I simply “ignore a number if it is less than or equal to zero”. If I could have figured out the negative number issue myself, albeit, in a different way, I have lost the opportunity to demonstrate my strengths.

As an interviewer, I try to be conservative. Once someone has clearly shown that they cannot do something, there is no point in watching them struggle. But until that point, I give them the benefit of the doubt. And when they do get stuck, I consider what the minimum help I can give is to potentially unstick them. I can always give more help.

Avoid questions which are aimed at putting people under pressure

How someone acts under work pressure may or may not be something that you want to know about. In my experience, this is not something that you can effectively assess by putting someone under pressure in an interview situation. Someone who is calm when you put them on the spot might be so because they have another job offer already. Someone who is nervous might be behind on their rent and desperate for the job.

Real work pressure is often about managing time and expectations over weeks and months, not answering hard or impossible questions on the spot. Possibly the worst interview question I have ever been asked is to draw a sheep. The stated aim after I was finished was to see how I dealt with unusual demands under pressure. So far in the decade since that interview, I have not had to face a similar challenge in my career.

I am yet to hear a convincing argument for asking trick questions. They make people feel bad. Is life at your company really about tricking people and figuring out how people are trying to play you? If so, then you should probably consider leaving.

Summary

To conduct enjoyable interviews, there are many techniques that you can use to give a useful interview which highlights a candidate’s strengths and lets them come away feeling that they were fairly assessed.

• Keep in mind that one of your goals is to give an enjoyable candidate experience
• Focus on finding out what the candidate can do, not what they cannot do
• Hold back from giving guidance for something that the candidate may know how to do
• Consider offering a redo opportunity
• Do not add artificial pressure to the situation

Good luck hiring great engineers!