What are Interviews for?
I’ve been talking to a lot of people lately about the interview process, particularly when it comes to Software Development companies. There is a lot to say about how to do it properly or successfully but today I would like to focus on a single question: why do we do it? What’s the goal behind interviewing someone that’s willing to join our company?
Hopefully, by being conscious about the reasons behind the process we can more effectively tune it to get the best possible results out of it.
TL;DR
The short version of this article would be: Some colleagues tend to use interviews as a way to spot liars. I tend to use interviews to get to know each other (the interviewee and the company) better, decide if we really fit together and come up with a plan to properly integrate ourselves.
I’m still learning how to be a good Tech Lead, so I would like to know your opinions about this subject :)
A Bit of Context
At InakaESI we have our guidelines for display on GitHub and among other things, we describe the process we use for interviews there.
Following a great piece of advice by Oren Ellenbogen, we send an email to each candidate before their first interview including a link to our guidelines. That way candidates have the chance to know beforehand what we’ll ask them on the interviews with a high level of detail.
The interviews may then develop different paths depending on the candidate and almost certainly include a coding exercise that’s not described there but, in general, if you want to work at InakaESI you know what we’ll be asking you. Even for the coding parts, you can check our open-source repos at GitHub and you’ll even find previous solutions, too.
But how does that even work?
Some of my colleagues questioned our decision to be so open regarding the process and the questions used for interviews, mostly because of a somewhat widespread view of interviews as a way to spot cheating candidates (at least around here, in Buenos Aires). In other words, in many people’s minds, the interviews are a way to detect whether or not the candidate lied on their application.
Under that light, the interview is used to determine if the interviewee who claimed to be a senior Android developer is not actually just someone who built an Android app on his spare time.
I personally dislike that approach. I’m a naïve person, in many aspects, by choice. I generally prefer to trust candidates upfront and be disappointed later over being skeptical right away and miss the opportunity to work with a great colleague.
The Reasons for Interviews
But if that’s so, you might wonder, why do we still conduct interviews? If we’re going to trust people anyway, why don’t we just hire them and see. In Argentina at least, everybody is in a trial period for the first three months of engagement by law, anyway.
Well, in my view, there are other reasons for conducting interviews and, in general, getting to know people before hiring them. Such as…
Match-Making
One of the main outputs we try to get from the interviews is a perspective of how comfortably the candidate will fit within our company culture. That’s why we always try to choose an interviewer that’s currently in a position similar to the one the interviewee is applying for. After the interview we ask the interviewer how would you like to work with them in your team? Do you think they will like to work with you?
When I’m the interviewer I also take the time to let the interviewee know how we work at the company, how I work as a CTO and how their relationship with me will be within the company should they get hired. That way they can make a more informed decision on wether they do like to work with us/me or not.
I also spend a significant portion of the interview talking about how they like to work, what projects do they prefer, how they think they work best, etc. Again, that’s for me to figure out if I would like to work with them and also for them to push their ideals on what they want upfront so they can contrast those with what I present as the realities of our company.
Planning
The other really important thing we try to get out of the interviews is an idea of how long the adaptation periods of the candidates will be if they get hired.
On the brightest days of our company, we tend to conduct two kinds of searches: We either try to hire people to augment one of our teams for a particular project or we try to hire people just to augment our team as whole.
When we know exactly what we need a developer for, out of the interview we get a sense of how hard it will be for the interviewee to join the project. How much time will they need to adjust to the new role and catch up with the team and all until they start being actually productive.
When we’re just looking to hire someone, on the interview we talk with the interviewees about the languages/technologies they’re familiar with and which ones they want to learn more about. Then we may end up deciding to spend some time training them on those new languages. This is particularly true when it comes to Erlang. You can learn more about that on one of my all-time favorite Erlang Factory talks by Iñaki Garay:
What about You?
I’m still learning, I wrote this blog post because I’m not 100% convinced about the way I think. I would love to read what others had thought about this subject.
So… what about you? Do you interview people? Were you interviewed lately? Let me know in the comments what you think should be the goal of the interview process and how that should (or should not) affect it. :)
