On compassionate technical interviews

Until very recently I was still holding on to a folder full of over 200 rejection letters I received from roles I applied for between the ages of 18 and 19, I would like to say getting rid of them was a moment of catharsis, releasing toxic emotions and associations that were holding me back personally and professionally, but the truth is they were just water damaged — however they did get me thinking about how those experiences have helped shaped how I hire people.

In recent years I have been responsible for hiring engineers with varying levels of experience. I have also been through many technical interviews at dozens of companies, and I can say hand on heart that there was not one that I found enjoyable.

For many of the interviews I conducted, the format of the interview was set by the business, I just followed the playbook:

• Bombard the candidate with questions about facets of different languages, the more experience they have the more specific/obscure the question.
• Expecting them to write an optimised algorithm with zero preparation while I looked on silently. Spoiler Alert: We're almost always looking for a hash map and a loop in O(n) time, or a recursive function.

My main problem with these technical interviews is that they both ignore and exacerbate important aspects of a candidate's personality at the same time. As someone who has suffered from anxiety, I have always empathised with candidates who capitulate under the strain technical interviews impose.

Often I would put a note on their file if I felt their emotional state did not accurately reflect their abilities. I don't know if it ever helped, but I felt it was always important to note and validate a candidate's humanity, not just reduce them to a rating or a yes/no.

Many years ago, I went for an interview at a Melbourne-based fintech start up. After I crashed and burned on the coding test (it was a hash map and a loop in O(n) time they were looking for by the way), we progressed to a role-playing scenario where the interviewer posed as a client wanting to purchase a custom designed car, and I was posing as the car designer.

It quickly descended into a farce, his requirements for the car were starting to become criminal, or at least criminal-adjacent. I tried to end the mock conversation on "moral grounds", but he kept redirecting and restarting the conversation, but my anxiety was already off tap after the whiteboard exercise, and I felt so unsure of myself, and confused about where the conversation was going that I started to sweat profusely, making my discomfort and embarrassment even worse. My confidence took such a knock that I didn't apply for another role for nearly 6 months.

Last year, a recruiter wanted to put me forward for a role with a graphic design startup that now has a higher valuation than Telstra. She informed me that because it was a senior role there would likely be 3-4 rounds of interviews with one or two 3 hour technical tests. I politely (or at least politely-adjacent) declined.

My main issue with many technical interviews is they only consistently surface one metric: How well a candidate might perform on a game show.

The day-to-day life of a software engineer does not involve having to recite SOLID principles, or writing code on a whiteboard with no reference material, and it certainly doesn't resemble the "dance monkey dance" routine often found in technical interviews.

A technical interview should feel like an average day in a candidate's professional life, not their worst day.

I have found that pair programming is a great way to not only discover where a candidate is at in their technical development, but it's a great way to tease out other soft skills that make a well-rounded software engineer and teammate: Critical thinking, listening, cooperation, verbal and non-verbal communication, respectfulness, curiosity, ability to take direction, tenacity, etc.

When I run interviews now, I am always up front and say: "I'm not going to ask you to implement an algorithm you would only implement once or twice in your career, and I'm not going to sit there and silently judge you while you try and figure out why a recursive function keeps crashing, we're going to work on this solution together"

I may not walk away knowing that they can bang out an implementation of Dijkstra's algorithm in under 30 minutes, but I will have a good idea of whether or not we can have a great working relationship and Get Shit Done.

It's still early days for me, and I am keen to improve my technique and interview structure, so what has your experience been with technical interviews? What techniques have you found most valuable when hiring software engineering candidates? Let me know in the comments!