I’ve wanted to touch on this topic for a long time. Mainly because it aligns with a value I respect a lot.
Interviews. Specifically, technical coding interviews.
Let’s put on our engineering hats and think of an interview as a solution to a problem. The problem is a lack of the right person in a team. The solution is to hire that person through a series of tests. We know that solutions should be tested, but how do we test our approach to technical interviews? One cruel way is to use candidates to validate the interview strategy. A better way is to put yourself in the candidate’s shoes.
One of the principles at Atlassian is “Don’t f@ck the customer”. Although it says “customer”, this principle can be applied to many situations, including interviews. This principle is about sharing context and establishing an even playing field.
Let’s face it: interviews are difficult for everyone. Time is limited, a candidate is trying to guess what the interviewer is looking for and what signals to send while the interviewer is trying to keep track of what the candidate is trying to convey and gather data for the decision. Without clear objectives and proper preparation on both sides, it’s a waste of time for everyone.
Most of the time, candidates are not in a strong position. Those who design the interview process need to remember that for a candidate, an interview is a stressful test because they are the ones being judged. For people who are actively looking for a new job, the pressure is even greater because they have much more at stake. Especially if there are external factors such as finances or visa issues. That’s why people who aren’t actively looking tend to do better in interviews, because they don’t feel the pressure to impress anyone and stress less. It is also why companies miss out on some great talent and waste a lot of valuable time.
That’s why, unfortunately, interviews rarely give a full picture of a candidate’s true work ethic, attitude and often even skills that people can otherwise demonstrate under normal conditions. Here’s another point. It’s really hard for the candidate to strike a balance between how they normally work and how they want to impress the interviewer. Time is limited and the candidate wants to put their best foot forward. Without clear objectives, people often tend to fall back on what they see as the main reason for that meeting - coding a solution. But we all know what our days look like in reality and in different circumstances the candidate may work through the problem differently. Then the interviewer has to stop and correct the course, which may reduce the candidate’s confidence even further driving that person to a failure. But it doesn’t have to be this way.
To reduce this burden, both sides should know what the test is about, what is being measured. Interviewers need to have clear criteria for what they are testing and looking for. The candidate should know what the interviewer is looking for. In other words, the interview must be very focused. Otherwise, it becomes a guessing game for both sides - instead of showing how their skills match the company’s needs, candidates are frantically trying to score some points. As a result the interviewer does not get enough (or worse, the right) signals to assess a candidate thoroughly. All because the objectives of a test have not been clearly formulated.
When interviewing with the big tech companies, (at least from my experience) candidates are usually given a lot of context about what is expected of them. Some call it “setting the candidate up for success”. Of course there will be a task relevant to the role, but people also know what the objectives are for that hour-long meeting, whether it is communication and explaining their thought process, maybe showing the depth and breadth of their technical background, maybe completing the whole task is not a priority as the task is more of a discussion point, or the other way around, writing and explaining the complete solution is a must. Knowing this beforehand changes the dynamic of the conversation and helps to know what to emphasise.
This is not to say that we should give candidates clues or answers in advance or make it easier. The point is to have a task that is appropriate to the expectations of the role and questions about that task that allow the interviewer to assess whatever they deem appropriate to asses. For example, it is perfectly fine to hand a candidate for a front-end engineer position a task that involves browser APIs, best practices for a chosen framework, an approach to handling a complex layout and error handling. If all goes well, you can talk about algorithms and the runtime internals. This list is not an exhaustive, of course, but there is so much to explore and challenge in each of these areas.
In conclusion, interviewing is about empathy (suggested research: empathy vs sympathy). As with avoiding crewing the customers, there’s nothing wrong with understanding the candidate and taking a step to balance the scales of the interview. It can be a rewarding experience for both parties. After all, if you find a strong candidate, chances are you will be working with that person. So, why not try to create an atmosphere of support and understanding from the day 0?