This is my personal story on how I went from having zero interviewer experience to having a strong opinion on what a good software engineering interview is and how it should be conducted.
Just to give you a small introduction, I’ve been a software engineer for about 5 years now, and actually switched company about 6 months ago (to xgeeks 🎉), but from the time prior to this change, I was never involved in the interview process, nor did I felt prepared to work on it!
I joined xgeeks at a really early stage, so I had to enter this interview process whether I liked it or not. My first thought was:
How can I do a good interview? Something that the candidate won’t think that it was a waste of time. Something where I can connect with the candidate somehow. A real technical conversation instead of an inquiry.
Of course every company has its own needs, and each one looks for different profiles to match their business needs. In our case we are a newly founded company created in the context of a larger group. Our needs are varied, but they all focus on a few base points: An engineer that has critical thinking on tasks, able to break down larger problems into smaller ones, proactive, team-player and with a great will to grow and learn more and more and overall improve as an engineer.
As it’s to be expected, my first couple of interviews were a failure (at least from my point of view), I was only being able to do a style of “question-answer” model and that didn’t feel right at all, since it didn’t approach the candidate’s full knowledge (or at least, more knowledge than plain questions).
So I started thinking how could I improve this. After some experimentation and trial and error I approached the interviews in different ways until I came up with something that I believe is a satisfying result. Actually there was one interview in particular where it went so well that I was super happy in the end, something that I did not expect at all.
Our current model is based on the candidate’s background experience entirely (or almost).
Analyse the candidate’s experience. Is he working? For how long? Where has he been working? What has he been doing? What technologies is he familiar with? Does he have side projects? Does he write articles or have some blog?
Try to be critical in your thinking, but without judging, you should go to every interview with an open mind.
With this analysis done, I try to prepare a few topics from his main background experience. If you see that he has more experience, prepare more difficult topics / questions, if you see he is not very experienced, then prepare easier topics.
It’s very important to note one thing:
You are doing the interview but at the same time you are being evaluated. Every candidate will try to figure out if you are “worthy” of them. Do you have the knowledge to be able to ask the difficult questions? You got to have it, or else more experienced candidates may trample you or catch you off guard. Having said this, I’m not trying to tell you that you need to know everything. No one knows everything. Especially in this business. But you should be trying to do better at a daily basis if you want to be a good interviewer.
You go to the interview with some knowledge of what he does, what he has worked with. You go prepared with material to be able to approach some interesting topics regarding his background experience. What you don’t know is who the candidate is.
Regarding this topic it’s important for you to evaluate more than technical skill. It’s especially important for you to evaluate the candidate’s soft skills. How does he behave under pressure? Does he try to answer questions that he has no clue what the answer is? Is he honest? Is he comfortable admitting mistakes?
Have all this in mind when conducting the interview, because these kind of topics will tell you a lot about how the candidate will work on a team, and especially if he is humble enough to learn every day with the rest of the team.
For us in xgeeks team work is essential, so we always look for team players.
Given this, I always like to make it clear to the candidate that we are going to have a conversation. I believe this is important for my approach since it will leave the candidate a bit more at ease and a bit more comfortable for him to be able to elaborate on answers more than what usually occurs from simple questions.
I start the interview by asking the candidate what he found interesting from the work he has done previously. I ask not only what he found interesting but also what made him proud or challenges/problems he faced that marked him in any way.
These questions are the base of the interview. This will make the candidate expose real problems he had to solve, how he did solve them if he did, what blocked him, etc. This is really useful knowledge and is a perfect base for an engineering interview in my opinion.
When the candidate exposes his past projects and his role in them, there will be topics that arise that you can pick up as an interviewer and ask a bit more about them (the topics you prepared previously or others!). Remember that with this approach you have to go with the flow. It’s not a script, so you have to be able to adapt to the conversation constantly.
Another thing that is interesting to do in the interview is to listen to a problem presented by the candidate and based on that, ask the candidate how would he solve the problem if something (changed by you at the moment) was different? This is really powerful since it enables the candidate to show critical thinking under pressure and problem-solving skills.
One remark that I would also like to make is that for me, the most important thing is not for the candidate to know how to do super specific things in one programming language, but instead to know how to abstract from a problem and from a high level perspective be able to draw out a solution (independent of language, technology, etc).
In this model you are able to evaluate not only questions/topics prepared by you but also real world problems, real solutions that the candidate performed, his opinions on them, if he would do things differently or not, based on what he learned after.
What if things are going bad this way? What if the candidate doesn’t have enough background experience to apply this strategy? What if the candidate is not flexible enough to be able to think of solutions on the spot?
In these situations this model is not applicable. What I do here is to fall back to the “question < - > answer” model like it was an inquiry. I really don’t like it, but it’s a completely valid way to do the interview if the previous way is failing you.
Pay attention that if the candidate isn’t able of thinking of solutions on the spot this may reveal that he is lacking critical thinking agility and this, in my opinion, is a particular important trait in an engineer.
The path to this model was paved by consecutive failures and learnings from those failures, so what I hope to achieve with this post is to expose my learnings and the model that I reached at the end of these trials.
It’s not perfect, it has flaws, but at least it’s something that I am comfortable saying that is a good interview approach for engineering.
It has room for much improvement, so please comment with any opinions, improvements and critics to it, so we can improve it together 😉.
Would love your feedback 🙂 If you find it interesting please share it because you know — Sharing is caring!
Let me keep you posted on new projects, articles or talks that I do!
