The Value of a Safe and Open Interview Process

I’ve recently been interviewing for a new role. During this time I went through the interview process with three different companies. Two of these I already had in progress before finding the third role (which was the one I really wanted). Each offered a very different approach to the way they structured and conducted their interviews.

At the end of these processes I had very different emotional feelings about each of the three companies and roles. This got me thinking about what factors resulted in these different emotional responses.

Company A - Traditional Interview Process

This company had a fairly traditional interview process divided into four stages:

• An initial short chat with a member of the Talent Team to make sure that the role was a good fit. There’s no point in pursuing an expensive and time consuming series of interviews if the role is not a good fit for the candidate or visa-versa.
• A technical interview with two Engineering Team members talking through experience, knowledge and approach, with a few technical and design questions along the way. This also acted as a chance to discuss and ask about engineering culture.
• A problem interview, which for this company was conducting a code review on an example pull request. This was carried out in a low-pressure way where I was given time to do the review without the interviewers being present, followed by a short discussion of the points I had identified at the end. (Kudos to the person who wrote the code to review, it was a masterpiece of how to cram as much bad coding and design practice as possible onto a single page!).
• A final chat with the Engineering Manager (which I didn’t complete as I had already accepted one of the other roles by this time).

Overall I came away from this interview process feeling fairly neutral about both the company and the role. There was nothing that made me feel uncomfortable or unsettled, but at the same time I didn’t come away from any of the interviews feeling super excited or energised by the process.

They created an environment where I was able to feel fairly open to answering their questions, but still feeling that there were certain questions that they wanted to hear me give model answers to and others where the answers had to be correct.

I expect that this is the default experience for many people as they go through the process of finding their next role, but is this really the best we can do?

Company B - Toxic Interview Process

The second company I interviewed with had an interview process that I can only describe as toxic. I made it to almost the final stage of these interviews, but after my experience, there was no way I would have wanted to go and work for them anyway (even though they were the most high profile and highest paying of the three roles).

First off, before you could even enter their interview process you had to complete an online, timed, coding exercise. This involved two tasks where you are presented with a short problem statement, an empty code template and a set of unit tests (most of which you can’t see the inputs or expected outputs for). You then have to code up a solution that solves the problem and makes all the unit tests pass. All this takes place in an environment with a big countdown clock in the corner that ticks away your remaining time.

In my experience, there are very few people who can just sit down and pick up coding kata problems like these and produce great results. In order to be successful you have to have practised many times on similar tasks before actually taking the test. These practices also get you familiar with how the site doing the testing works, how it describes its problems, what sort of things it tests for and so forth. The net result is that to be able to pass the 90 minute test you also have to additionally invest a number of hours of practice time as well, and this is before you even know if the company or role is a good fit or not.

I also have some very specific complaints about these sort of logic/coding puzzle timed tests:

• All they prove is that you are good at logic/coding puzzles - they bear little resemblance to most of the engineering you will actually be doing in your job.
• A lot of them require you to just ‘see’ the solution, and, if for that particular problem, you don’t have that immediate insight, then it’s almost impossible to complete a solution, as you just don’t have enough time to work through it and create working quality code.
• Some people who are great engineers just don’t thrive in situations where there’s a countdown timer or someone watching their every keystroke.
• These tests may also exclude people who feel less confident or a bit anxious from even being able to access the interview process at all.
• They can create stress and discomfort, especially if the candidate is struggling with the particular problem they have been presented with and the clock is draining away.
• Unit tests where you cannot see the input or the expected output, only that they are failing provide minimal value or oppertunity to improve your solution and just add additional stress and pressure.

So, I did manage to pass this initial screening test. Even though my first impressions weren’t great, I decided to continue with the process just to find out more about the role, team and company - you never know, it may just have been some poorly considered HR requirement.

The next steps were multiple technical interviews with various Engineering Team members that all followed a similar pattern:

• A brief discussion about the role or some aspects of the project or engineering culture.
• A bunch of fairly detailed technical questions covering skills and previous experience.
• Yet more logic/coding exercises carried out live with the interviewer(s) watching and commenting on every line you wrote and expecting you to both code and narrate your thought processes as you did so.

There were a number of aspects to these interviews that turned them into a hostile and stressful environment:

• When discussing projects or processes the interviewing engineers came across as acting in an incredibly superior way, sometimes sneering if your answer wasn’t perfect or you previously haven’t been working to the specific ‘variation’ of scrum that their teams have adopted.
• They presented a demeanour of making you feel small or unworthy if you didn’t immediately know the Big O notation for a specific sort algorithm or couldn’t immediately code out a fully working, super efficient implementation of their chosen logic/coding problem.
• I got the feeling that often they were trying to catch me out and just waiting for the moment to pounce: especially if I gave a slightly wrong or incomplete answer to one of their questions.

The result of this sort of interview approach is that I started to feel stressed and pressured. Every question became a panic decision between do I give the answer I thought was right vs the risk that the answer might be wrong vs admitting that was something that I didn’t fully know. Rather than opening up to them I was being forced to close down. Ultimately I just didn’t feel safe or supported in that interview environment, started to doubt my own abilities and began to become flustered and unable to answer or write code any more.

At the end of each interview, the overwhelming emotion that I experienced was one of relief that the ordeal was over. No excitement about the role or the company was generated: just relief. After the final interview with them I was left visibly shaking from the release of stress tension built up over the duration of the interview.

Edit: Having thought about this more, I'm sure that this company didn't set out to create an interview process that created these emotions. I believe they probably have the goal of selecting only the very best technical candidates. Their selected solution for doing this was to focus heavily on processes that test primarily for technical skills. The unintended side-effect of this being that they have less time to focus on cultural fit and empathy for the candidates. /end

If that’s their process for finding the ‘right’ people, what would they be like to work for? A culture that encourages that sort of pressure on interview candidates surely isn’t an enjoyable, safe and supportive place to work? Would the type of people who were actually able to make it through the recruitment process be the kind of people I would want as my future colleagues?

In the end they decided not to continue with the final stages of the interview process with me. I wouldn’t have gone for another interview with them anyway. I’ve never been happier to drop out of the running for a new job!

Company C - Safe and Open Interview Process

The final company I interviewed with followed a process that was a world apart from my other two experiences. This process was probably the most detailed and time consuming of the three, but every aspect of it was thoroughly enjoyable, engaging and enlightening.

First off was a chat with the Engineering Manager who I would be working with. This was about as far away from a technical interview as you can get. We just chatted. He spent a lot of time telling me about the company, the product and the culture. Then I was asked a simple question (I can’t remember the exact words, but it was something along the lines of): “What’s your first impression, what excites you about this role?”. What a great way to assess a candidate. If they aren’t excited by what they’ve heard then why would you want them in your team? As a candidate, if the role and culture aren’t exciting then would you really enjoy working there? Would you grow? After that we just chatted generally about experiences, background and so on.

Particularly interesting was that the chat was conducted in a way that felt safe. It was easy to open up, admit answers I didn’t know; ask questions that might seem strange; talk about times when things I did went wrong. The overall feeling was that the interview was about getting to know each other rather than trying to judge. I finished this step excited and already knowing that I really wanted this job.

The next stage of their process was a take-home exercise. I know some people aren’t a fan of these, but I’ve always found them to be quite an enjoyable way to demonstrate my abilities. If they are structured right then they allow you to show problem solving, technical approach and code that is realistic to what you would typically produce (as opposed to trivial/funky/clever code that solves a specific logic problem).

In this particular case the exercise was closely related to their product, so it almost felt like you were already working on something related to the job. The exercise was timeboxed to three hours (which is often a criticism of take home exercises that are open ended and thus candidates feel they have to dedicate a huge chunk of their life to completing them). I spent a day mulling over the problem in my head then sat down over a couple of sessions and produced my submission. I was really enjoying the problem so I even carried on for a few more hours after submission to improve my solution and solve a couple of little areas that I hadn’t quite got right.

My submission was reviewed and I was invited back to the next stage of the interview, which was to talk about what I had done. This was carried out with two members of the Engineering Team that I would be working with if successful. Again this was conducted in a way that was structured to be entirely safe and open. They seemed really interested in what I had done and how I had done it - not some kind of faked interest, but genuinely interested. At no point was there ever any judgement on the approach taken, it was always a discussion on the reasons and the thinking behind a particular approach or technique.

Feeling comfortable and secure, I found it easy to be open and honest about where I had made good or bad decisions and how I would do things differently as I iterated over the solution. This enabled much more discussion rather than it being a question/answer driven session. I was not only able to get a sense of how they worked as a team and how strong their engineering practices were, but also who they were as people - something that’s generally really hard to get during a typical interview.

Next up was another session, this time on talking through how I would go about solving a particular engineering problem. Again this was a problem relevant to their domain and product so it felt like I was actually working with the team rather than being assessed. This was also another great example of creating a safe interview space where it was easy to be open and explore different avenues. No suggestion was wrong or dismissed, I was free to explore avenues that didn’t go anywhere or solutions that might be a bit unusual. It was easy to ask questions about what might or might not be possible. The discussions were all about the directions taken to solve the problem, why they might work or not and how my thinking process worked to get there. Again this was very much a two-way process of how I would fit in with the team but also how the team would work with me.

I left both of the above sessions feeling even more excited about the role, excited about the people I would be working with and with a sense of comfort that I would be able to bring skills and ideas that would enrich the team and that I would get the same in return. That’s a really positive feeling to leave a technical interview with!

The final interview stage was back with the Engineering Manager again, this time with the Product Owner involved as well. Again this worked as much more of a discussion process rather than an interview. The PO was able to enthusiastically talk about the product and the vision for the future. There were ample opportunities to ask detailed questions and discuss thoughts. Finally there were questions around how I think about products, user experiences, technology and so forth. Again this was all conducted in a safe space where I felt at ease opening up with my thoughts and where I felt comfortable giving detailed answers and my reasoning behind them.

Overall this interview process was amazing. At every point in the process I felt able to give open and truly honest answers. After each interview I felt energised and excited. Suffice to say, when they offered me the position I jumped at the opportunity and I can’t wait until I join the team. In fact, I already feel part of the team just from the interview process and that’s a great feeling.

Conclusions

Thinking over my interview experiences there’s a few good takeaways that should be part of every organisations’ interview process:

• If an organisation can’t excite a candidate or the candidate can’t excite the team then the two may not be a good fit.
• Creating a safe interview space will encourage candidates to be more open and honest with their answers, offer up more details and be more likely to ask deeper questions. Both parties learn so much more about each other.
• Conversely, creating an interview environment that is hostile and stressful will discourage candidates sharing honest answers, will limit how much you can learn about them and ultimately will prevent them wanting to join your organisation
• Some exploration of technical skills and experience is always relevant but ensuring the candidate is a great fit to the team culture personality wise is far more important,
• During the interview, make the candidate part of the team and work with them as such. You will learn much more about who they are, how they work and whether they are a great fit than if you treat them as an outsider to interrogate.
• Empathy with the candidate shows that the team they will be joining cares, and for great people that’s often a far bigger selling point than financial rewards or interesting technologies.