I think I did my first technical interview about ten years ago and in the last two years I’ve had the chance to do even more. As a result I’ve improved my approach.
Today I find that the technical interviews with our candidates are rather well structured and efficient, for us as well as for the candidate.
Here is a non-exhaustive description of how our technical interviews go.
The technical test
First, our tech manager sends the technical test to the candidate. This is an exercise that requires the candidate to code a small project based on a description that is very far from our daily business problems. The candidate has about 3 hours to complete the test using the development environment with which they feel most comfortable.
Using this test, we have a grading scale that includes 38 evaluation criteria according to rather simple rules: Point mastered, point partially mastered and point not mastered.
Despite this, the scoring can be rather subjective and that is why we prefer to have several developers evaluating the candidate’s test separately. However, using the same scale is a great advantage when comparing the performance of candidates with each other or with developers already in the company.
After this test, we systematically schedule a technical interview between the candidate and the developer(s) who evaluated the candidate.
The technical interview:
Whether it is a on site or in a zoom meeting, we always start by indicating how the interview will take place: “Quick roundtable introduction, our questions about the code delivered and then the candidate’s questions”.
Indeed, we often have particularly stressed candidates who may dread this type of interview, and to calm and relax the candidate as quickly as possible, we must avoid surprises and therefore indicate the purpose of this meeting.
So we quickly move on to a round table discussion where we “employers” briefly introduce ourselves with a similar model: “Our first and last name, our current position and in which team we work and for how long we are part of the company. Our family situation and hobbies”. All of this with a smile, humor and a relaxed attitude to reassure the candidate. The goal is that the candidates introduce themselves in the same way without repeating their entire professional background. Not that we are not interested at all, but we have access to their CV and the goal is to talk about their technical test without going into a formal professional interview.
To reassure the candidate, right after the presentation, I point out to them:
That all of us here are developers and that we don’t have any managerial roles;
That we are here to discuss the solution implemented for the technical test and that we do not hold the truth or the perfect solution;
That this is an open discussion for which there is no wrong answer or trap.
Here the goal is to invite the candidates to really deliver their thoughts, without apprehension on their technical choices.
And I start with the same series of question to finally launch the candidate:
How did the test go? What did you think of it?
These questions indicate the candidate’s state of mind regarding the test. Some of them admit that they didn’t like to start the exercise from a blank sheet of paper because they are not used to this, some found the exercise pleasant. But all of them talk about their feelings about their performance and often admit to being disappointed with their performance, not having finished in time, wanting to do more, thinking they were not on the right track, not having enough time, etc…
Roughly, how much time did you spend on it?
Even if the exercise is given for 3 hours, it is necessary to make sure that the candidate was not forced to do the exercise in less time or that they had been able to free up enough time to do it.
Do you think you were in optimal condition to do this test?
Friday night, after a week of work, with the cumulative fatigue and starting at 9pm and with regular interruptions because the little one is teething … we can imagine that it is not optimal and that the candidate may have missed some points because of these conditions. Here we leave room for the candidate to testify personally on how they carried out the technical test.
Are you overall satisfied with what you have delivered? What would you have liked to have done differently if you had more time, or that you could do again if you could come back to it?
To be honest, it is rare for candidates to admit to being satisfied with their deliverables. Usually the candidate mentions what they would have liked to have finished, to have done some things differently, to have a better test coverage, and this is very useful to identify if they also perceived the points that were lacking in the grading scale before mentioning it.
I then try to orient the candidate towards the technical concepts, DDD, Solid, CQRS, hexagonal architecture, the best being that they naturally approach them by themselves at the correct moment. It’s not about being already an expert but having already heard about the concept, having understood the main lines AND having perceived the benefits is already a serious plus for the application. The hard skills can be learned… however, we quickly know if the candidate is curious, does their research and challenges their practices. This is also where you can spot juniors who are eager to just piss code and senior profiles who code as they always have. After 20 minutes, we have generally covered the technical part and we can reverse the questions, always in a relationship of dev to dev.
The candidate’s questions
It is up to the candidate to ask the questions and this is where you have to stay focused and pay attention to your answers. Because it is your answers that will largely motivate the candidate to leave their current position, perhaps move, disrupt their routine. In short, to join you, but not only… they must also feel good, challenged and want to go on for a long time in the company. This means that you must not oversell the position. Otherwise it is the best way to disappoint the candidate and also the main source of employee departures in the tech industry.
The two questions that come up most often are:
What is your technical stack?
I then present the technical stack with the greatest honesty, mentioning the versions of the frameworks we use even if they are not really up to date. I remain critical of our stack, if we use a trendy thing but want to get rid of it because we’re doing it wrong, I don’t hesitate to say so. The same goes if we have really cool tools but I know that the candidate, if recruited, will not use them. Don’t sell the dream at all costs. I then talk about the rest of the technical stack: devops, data, machine learning and this time it allows me to see what the candidate’s tech culture and curiosity is.
What is your typical day/week like?
This kind of question, which is not purely technical, allows me to detect a natural curiosity about the company’s processes in the candidate. Usually it reflects a previous experience where the processes were not optimal or a well-oiled organization. This makes me think that the developer will not consider the rituals and alignment meetings as “noise” but as an entire part of their job. So in the interest of transparency, I share my screen directly to show the agenda of my current week, explaining quickly what is usual or not in terms of meetings. Our way of being agile is there in front of their eyes, we can hardly cheat with our rituals. I also warn them that each team is autonomous and free to define its way of doing agile.
Our recruitment process is not perfect and this technical interview is only one step in of the whole process. I had the opportunity to meet a candidate at a meetup event and even though we took different ways, he told me that he particularly appreciated the clarity of our process and the clear and technical feedback that allowed him to identify areas for his career development. Finally, formalizing this interview was a necessary action for several reasons but the main one was to establish equality between the different candidates by evaluating them rigorously in the same way.
Curious about our vacancies?
🇩🇪 Berlin: https://careers.instapro.group/
🇳🇱 Amsterdam: https://www.careersatwerkspot.com/vacancies/
🇫🇷 Aix-en-Provence: https://careers.instapro.group/
French version here | Follow me on twitter @scullwm
