The Technical Interview - Go hard or go home?

The technical interview… Some see its importance, some say it doesn’t represent what actually needs to be done at the job. And still, it is a big piece of the recruitment process when considering a job in software engineering. A technical interview is conducted to have a grasp on the skill level of the candidate, but not all interviews are built the same. Every company has the freedom to evaluate the areas of interest for the job they are recruiting in a way that reflects best their approach to software engineering, the dynamics and structure of their team, and the abilities they value most in a colleague. Software engineers can expect a large range of questions, from straightforward technical ones such as “What is CQRS and how can it help in practice?” to questions designed to get a hint of your creative thinking, like “When have you used an inventive method to stretch company resources beyond the normal level?”.

There are some common technical interviewing methods that most companies used and that you, as a software engineer, probably have also encountered in your career.

• Question-based interviews: that review your technical knowledge, your approach in scenarios from your previous experiences or future scenarios, soft skills, and the culture fit

• Live coding exercises: they asses the capacity of candidates to answer data structure questions and offer a fairly consistent measurement and evaluation

• Digital prompt: engineers code a UI using an online editor while sharing their screen with the evaluator

• Take-home project:... self-explanatory :)

All of these methods have their advantages and disadvantages and play their role in finding a good fit for a role. However, companies are constantly trying to fine-tune their technical interview in such as way that it represents both an engaging experience for the candidates and an optimal opportunity for the employer to assess them. For example, at GitLab, they implemented an entirely new way of interviewing frontend engineers using a GitLab Bot that assigns a merge request to troubleshoot on a test project. As stated in their article, they aim for conducting technical interviews for engineers that 1) represent realistic scenarios based on the role’s responsibilities, 2) are “open-book” and thus showcase how the candidate applies their knowledge, 3) have a standardized, objective rubric, 4) represent an inclusive process.

Now that we shortly went over the specificities of a technical interview, another question rises: how difficult is it ought to be? Many professionals complain that technical interviews are either too hard or too time-consuming. But from an employer’s perspective, a thorough evaluation is needed to ensure that the candidate is going to perform well in their future role and team. One of our clients has implemented an uncommon type of technical interview, that consists of a discussion based on only open questions, addressing general software engineering topics and technology-specific ones, that refer to real-life situations that come up in their daily work. Future candidates can find all the possible questions on their website and prepare accordingly. Since they are open questions, they don’t require a specific answer that needs to be memorized in order to pass, but more so aim to highlight the thought process of the candidate. The interview is long, and according to them, pretty hard, but they restructured the dilemma of whether a rigorous evaluation is indeed needed as follows: “A harder interview is going to elicit a stronger commitment to the process”. This statement has the psychological concept of cognitive dissonance as a starting point and our client implied that the candidate will follow a line of thought similar to the following one: “If I put so much effort into this interview it means I must really want the job”.

Cognitive Dissonance and Hard Technical Interviews

“Cognitive dissonance is a mental conflict that occurs when your beliefs don't line up with your actions. It's an uncomfortable state of mind when someone has contradictory values, attitudes, or perspectives about the same thing.” (Read more at Psycom). So does it apply to the above-presented case of our client? There are several possible scenarios that we see here.

1. Candidates put in hard work and it makes them think they must really want the job to be this involved.

2. The interview acts as a filter for attracting the right candidates and only those who truly want the job end up getting involved in such a difficult interviewing process.

3. A person who is not 100% sure about the job, but who already invested time and effort to prepare for the interview tries to reduce the conflict of the cognitive dissonance and reach a point of cognitive coherence, by justifying their effort and changing their belief: “For sure I want the job, otherwise I wouldn’t be this involved.”

The third scenario is similar to the first, but with a negative twist, supposed the candidates in 1) are just using the extra work required by the interview as a source of motivation, not to justify their intentions. But 3) is obviously not an ideal scenario for employers, because it means they could end up hiring professionals who are not truly dedicated to the role and who have great chances of ending up unsatisfied.

We are all hoping for the 1) and 2) scenarios to be the ones that apply, both for the benefit of our candidates and for the sake of our clients.

Concepts that might come in handy in conceiving and evaluating technical interviews

But since we tackled this area of psychology, it is worth mentioning the Yerkes-Dodson law. Eustress is the low to moderate amount of stress that leads to arousal, a sort of internal drive that propels us to rise to a challenge. As seen in the graph, arousal and performance are highly correlated. They rise in tandem to the point of optimal performance, where eustress describes the state of the person, but beyond that point, additional stress leads to impaired performance.

At the same time, the shape of the curve can vary depending on different factors, such as the difficulty of the task or the skill level. A simpler task can be accomplished even in moments of distress.

Another interesting psychological concept to keep in mind, not only in the context of technical interviews but in the concept of daily work as well, is the concept of flow. Mihaly Csikszentmihalyi describes in his book Flow, this optimal state for creating, innovating, working, and living. The state of flow appears when the task is difficult enough to keep one engaged and they are confident enough that they can accomplish it. A balance between one’s ability levels and the difficulty of the task is needed, or else the situation can lead to either apathy or stress.

Maybe experimenting with different ratios of arousal, task difficulty, and required ability levels is going to manifest into a fantastic technical interview for your future colleagues. And remember, these concepts can have a great impact on the daily work environment as well.

Ultimately, keep in mind there is no universal recipe for the perfect interview, only the most suitable approach for your company’s needs and the specifically targeted role. However, there are some key aspects that, if taken into consideration, could deliver a better evaluation and experience both for you and the candidates:

• Keep it practical and relevant - What are the actual responsibilities that need to be evaluated for this role?
• Keep it standardized - Make sure you know exactly what represents a satisfying answer and, according to a former Amazon VP, “don’t try out new questions on candidates”.
• Keep it human - Connect with the candidates and try to see them beyond any bias that you might encounter

Good luck with your next hires and may the best of software engineers join your team!