How I conduct job interviews based on trust, transparency and honesty
I read Ibrahim Diallo’s post about job interviews in the IT-sector and was again reminded how awfully dumb and pointless it apparently is in many places. All my career I have only been working for smaller companies in Denmark, and have thankfully avoided most of the silliness I can read about. I am sure there is a massive difference between the world’s leading tech companies in Silicon Valley and small- to midsized companies in Denmark, but now that I am in a position to conduct job interviews myself, I want to share what I personally think is a much better approach that is built on honesty and trust.
The main priority of the first interview is to establish a mutual understanding. Of course I want to get an idea if the candidate could be a right fit for the job, but they also need to know if the job and company is actually good for them. I can only get so much from a CV and they can only get a limited idea from the job posting and what is on the website. I will try to establish a foundation of trust and honesty in the conversation, by being as open as possible about the team’s internal values and culture, what trajectory the company is currently on, why we are looking for more people (it is better to tell people we are hiring because of growth and not just because someone quit and a replacement is needed) and what form of technical difficulties we are facing.
I don’t work through a set of questions, but I would usually start with something along the lines of getting them to tell why they found this particular job interesting. While technical skills is important, I am usually more interested in how people work. Do they value test and observability, how do they deal with code reviews and generally what motivates them in day to day work.
If I call in the applicant for a second interview, this will usually be a bit more structured. It will include other people from the team and in some ways we will cover the same area of questions, just with more people present. I don’t really believe in coding tests or trying to assess people with very specific technical trick questions. Instead, I will encourage the applicant to present a project of their own. Either from their current job if possible or some hobby project. Just let them go through their architectural design and their code structure. Doing this usually shows where their passion in their profession lies. If time allows, I will try and pull up a piece of our code and have an improvised little talk about that. I think it is good to be transparent and show them what kind of code they are expected to be working with and it also indirectly gives a pretty good idea of their general skill level with what kind of comments they have based on what they see.
All this has pretty much the single goal of building mutual understanding between the candidate, the company and the team. No one benefits from making the wrong choice. I have been at the same company for over 8 years now, and we value high retention. People generally stay many years, so we really try to hire the right people. I think that is best achieved through transparency and honesty from the beginning, so when new people start, the job itself and culture should be as close to what they have expected as possible, with no unpleasant surprises.
I also have the belief that if I am able to convey honesty and transparency about my team's current strengths and challenges, the applicant will feel more comfortable to do the same. I know for many people that a job interview is a bizarre theatre, where it is just a matter of pretending to say the right things and “playing the game”, but that approach doesn’t serve anybody. Because if someone gets hired on false pretences, then it doesn’t work anyways and everyone will have to start over after 2 months. I strive to get it right the first time.