The rough world of interviewing

This week’s briefer:

• Explicit vs Implicit Strategy

• Game development with a remote team: It Takes an Abbey

• Kent Beck on experts

Interviewing is in itself a job. Every day I set a slot in my calendar to review jobs, apply, fill in the multitude of questions about why I should be the best candidate… One application can take at least half an hour if the goal is to answer the questions in the best way possible.

This is only the beginning. 15 minute interviews with HR, take-home or live interviews, system design sessions, meetings with everyone, including the grandma and their pets. All of these multiple times a week or even multiple times a day. At one point, my mouth opens automatically, with no conscious thought, and repeats mechanically and methodically the same answers. They’re good answers, forged in battle.

It’s nothing new, but it’s a tiring and performative act. I’m not fully me, with all my skills, experiences, and view of product and software craftsmanship, but the filtered version that aligns with or contorts to the role. The same could be said in the other direction, as I’m also looking to understand if the role and the company aligns with my vision. This is understandable, both parties don’t know each other and there’s limited time to gauge the qualities of the person or the company. There’s risk in the process, what if the person does not work out, what if the company has a bad culture, etc.? In the end, even if things seem okay from both sides, the only definitive way to confirm the bet is to work together. Before that, each step is there to try to reduce risk as much as possible, even if it means losing great candidates on the way. The outcome of not recognizing a person that would’ve been great tends not to be as negative as getting a bad hire, which could wreak havoc on a team.

Even though the rationale of the hiring process is understandable, and I’ve been on both sides, interviewer and interviewee, I feel it’s often broken, and dehumanizing. Not only that, the typical process tends to perpetuate exclusionary environments, with their usual lack of diversity.

To me, the hiring process should be one of the most important areas of the business, specially for small companies. In a startup, we’re not only creating a product or a piece of software, we’re co-creating the foundations, the values, habits, and culture as we go. Every person who joins is critical and impactful and adds their experiences to the mix. Picking random people, without deep thought, and putting them together doesn’t cut it. That’s why I believe strongly that thinking about DEI from the beginning is paramount. Unfortunately, when companies start to care—or appear like they care—they already have a homogeneous environment that will be biased—consciously or unconsciously— to only hire people that fit that environment.

The technical steps

Going back to the hiring process, we normally see for the technical parts a live tech interview or take home task, followed by a system design interview in senior roles. Both the live interview (including the system design one) and take home task can have problems and biases.

Live interview

In the live interview, which in my experience, it can take an hour or two, the candidate’s expected to show they can solve a problem and potentially apply good coding practices, tests, patterns… All of these in a timely manner, while also showing good communication. This type of interview tends to favour people who perform well under pressure and stress.

In my case, I feel the stress, the anxiety and in some situations I can’t even think straight. When I finish the interview and can relax is when everything comes to the brain, all the failures and the potential solutions or improvements. It's a performative act, it can show what you know, or it can diminish it significantly if you can’t show it properly. Interestingly, in most companies, the work won’t be done under stressful, judgmental conditions.

When I do live interviews, I try to apply techniques to reduce my anxiety, to “slow down” my brain. Mediation and Stoic approaches work well. What would be the repercussions of failing this interview tomorrow, in five months, and in ten or in a hundred years? Probably it won’t mean much in the big scheme of things. I remember as well the metaphor of the archer:

All I can do is to be ready, be prepared and know my stuff as much as I can (which includes reducing my stress and anxiety), but everything that happens after is not up to me and doesn’t reflect on my value as a person or a developer. In fact, failing an interview is an opportunity to get feedback, learn, practice, and improve for the next one.

On top of all these, bringing mindfulness to the interview, by being aware of the breathing and how the body feels, helps me to slow down and get mental clarity. Here’s another tip, I don’t drink anything stimulating before an interview, the last thing I need is to accelerate even more my brain.

As an interviewer, it’s critical to build rapport, and make the interviewee comfortable, without jumping to the exercise first as if it were a routine (it is for you but not for them). I also think it’s good to share the format and requirements of the interview beforehand and, if there’s real coding that’s not a super easy exercise, to share an overview of what the it entails. The idea is to reduce uncertainty and stress levels.

Take home task

If we have on one hand the live interview, on the other hand there’s the take home task. A candidate can do really well here, but it can be really time-consuming. Many tasks could take an average of four hours or more, and consider that they might have other interviews or tasks at the same time. These tasks can ask for a lot of time, and the trade-offs you make to save time (while knowing it wouldn’t be ideal) can be used against you. What’s the minimum time and effort I can put in while still producing a decent solution to not fail?

I’ve also seen the argument that take-home tasks that are longer than 1–2 hours should be paid, which I don’t find unreasonable. What about people that don’t have spare time to spend many hours on tasks, but could do great in the team?

If we’re trying to ask: can this person code or are they faking it?, the task could be a simple exercise without complexity, bonus steps, etc. Creating an API or a simple UI and doing some basic processing might be enough.

AI and the irony of it all

Now, let’s add a twist to the whole thing: ChatGPT. What prevents me to using AI tools to solve the exercise without wasting lots of time, would that be fair game? Maybe it means that, moving forward, on top of the task, there’s a small live interview to “prove” you can code. Do we have an arms race?

The irony of it all is that a developer with some years of experience that has been involved in a few products or projects, will most likely be able to code just fine, barring outliers. So, why are we testing if they can code (no matter if it’s a live interview or take home task) when they’ve actually been coding for years? We don’t ask a surgeon to do a surgery to prove they can do their job, or a civil engineer to design a bridge or a building with great quality and all standards. What’s so different in the software industry, what are we really testing for?

What if we assumed that most people know how to code already, given they have experience? The focus changes to other areas: are they good at working with people, collaborating and communicating, do they have a mentality we appreciate or that can gel with our culture, do they have some skill we’d like or a set of expertise or experience we want to get, do they have density of experiences…?

If the candidate doesn’t have a lot of experience, we might focus on the potential, growth mindset, soft skills, etc.

The more I think about it, the more I am against the usual hiring process. I feel we should put conscious effort into it (specially in small companies), to make it more humane, inclusive and overall a better experience for all. It’s a hard problem, though not one we should ignore by going with what everyone does.