UPDATE: this article was written in 2017 (ca date). In 2022, things have changed a bit at KNR. I invite you to listen to this podcast where I talk in detail about our new recruitment processes. Come on, kisses.
Hello you,
Whether you’re a CTO, a project manager or just in charge of recruiting developers for your tech team, you’re often faced with this question:
How can you quickly determine whether a developer is a good fit for your team?
After working as a trainer for Octo Technology, CTO for the startup Modalova and finally CEO of my own agency KNR Paris, I’ve had the opportunity to interview a large number of developers from all backgrounds. Some were graduates of prestigious schools, others self-taught; some were young, others older; men and women.
Over the course of these interviews, I came to realize that some candidates with “perfect” CVs didn’t actually know how to code; they had some knowledge of the subject, but I didn’t see them as real developers. So I set up a “roadmap” for conducting my technical interviews, a checklist of things I needed to check during the interview before considering integrating a profile into my team.
This roadmap enables me to eliminate on average 80% of candidates who, despite having a very good CV on paper, don’t have the necessary skills to join my teams.
But Gabriel,” you might ask, “how is your roadmap going to help me conduct MY own interviews? Maybe I don’t have the same expectations of my developers as you do!”
Well, reader, you’re absolutely right. That’s why in this article I’m only going to talk about the technical aspects that enable me to separate the good developers from the not-so-good (not to say bad) ones. Developers, who for me are not yet developers. Developers who, in my opinion, won’t be able to produce quality code that can be used in production without the supervision of another, more experienced developer. Let’s just say that developers, whom I consider to be “less good”, will find it difficult to be autonomous, to make proposals and to produce bug-free code.
Ok, let’s get into it!
The famous Fizzbuzz test
The Fizzbuzz test is a relatively well-known test for developers. Simply knowing that this test exists is proof of a certain level of computer literacy; but not knowing about it isn’t necessarily prohibitive. For example: I didn’t know him when I joined Octo Technology.
The statement of the Fizzbuzz test is quite simple: the developer is asked to write a code (I usually leave the choice of language to the candidate) to solve the following problem:
Let’s take a list of numbers; let’s keep it simple, let’s take positive integers between 1 and 1000 (here we’ll keep it simple so that the candidate doesn’t waste time thinking about the type of variable to use if he decides to take the test with a strongly typed language, such as C).
For each number n in the list, we want to perform the following operations:
- if the number is divisible by 3: Fizz is displayed
- if the number is divisible by 5: Buzz is displayed
- if the number is divisible by 3 and 5: Fizzbuzz is displayed (hence the name of the test)
- otherwise: the number
n
And that’s all there is to it; the test looks simple enough, and indeed it is. But I found (to my horror) that around 70% of the candidates I interviewed were unable to pass this simple test. Some were even in engineering school, practically graduated, with 5 years of “web development” on their CVs; but couldn’t pass this simple test. It makes you wonder what they learn at school…
The first step is to see if they can pass the test. A good developer should be able to produce drinkable code in 5 or even 10 minutes, may encounter a bug when testing his code with the number 15 (divisible by 3 and 5), but should find the solution in less than 5 minutes.
Now, if the person doesn’t pass the test, they’re disqualified as far as I’m concerned. I think this kind of problem should be child’s play for a developer who offers to develop for you, carry out your project or join your tech team. Admittedly, the stress of the interview can also work to the candidate’s disadvantage, causing them to lose their nerve: that’s why it’s important to reassure them: this test is simple, there are no traps, the aim of the game is to keep things as simple as possible. Under these conditions, if your candidate needs 30 minutes to come up with an acceptable code, it’s NOGO for me.
function fizzbuzz($liste) {
foreach($liste as $n) {
if($n%3 == 0 && $n%5 == 0) echo 'fizzbuzz';
elseif($n%3 == 0) echo 'fizz';
elseif($n%5 == 0) echo 'buzz';
else echo $n;
echo "\n";
}
}
fizzbuzz([1, 2, 3, 4, 5, 7, 15, 20]);Now you have my attention
OK! Congratulations, your dev has passed the Fizzbuzz test, so he knows how to program.
The idea now is to try and estimate its sensitivity to the beauty of clean, uncluttered code that respects the rules of single-responsibility.
To put it simply, in the code example proposed above, all the logic in our code was in the fizzbuzz function. Now, in computing, we like to cut up a program so that each piece of code has a unique role (the principle of single-responsibility). As you explain this principle to your developer, ask him if he can see a way to improve his code to make it more readable, while respecting this principle.
Here, we try to see how the developer responds when asked to “improve” his code.
Many developers will confuse code improvement with code optimization. When we talk about optimization, we’re talking about increasing the performance of a code; for example, making it faster and less resource-hungry. It’s all very well knowing how to optimize code, but I think that with the machines we have today, saving a few milliseconds on the execution of a simple program is less important than it used to be.
But I digress! So we ask our developer to improve his code. By improve, I mean make it more beautiful, more readable, more Charlie-able, more likely to be taken over by another developer without them thinking WTF when they read the lines of code, easier to debug and above all easier to modify. That’s what I call good code, beautiful code.
So ask your developer to improve his code; if he starts talking about optimization to make the algorithm faster, just tell him that’s not what he’s being asked to do; we’re just looking to make the code more beautiful.
Here, I generally expect the candidate to output the logical part of the code used to determine whether a number X is divisible by a number Y. This would make the code more DRY ( Don’t Repeat Yourself ) ; and also improve its readability. We’ll also pay attention to how it names its variables and functions. Code with variables named a, b, c, x, y is synonymous with a developer who has never really worked in a team.
function est_divisible($nombre, $diviseur) {
return (0 === $nombre % $diviseur);
}Read between the lines (of code)
And there you have it, the few lines of code that allow a developer to prove to me that he can actually code. But is that enough to set them apart from the other candidates? Well, no…
A good developer is also (and above all) a developer who masters his tool.
I usually ask candidates to bring their computer to the interview, so that they can use the tool they should be comfortable with. During the fizzbuzz test, I’m going to observe how they use the said tool; use of an IDE, use of keyboard shortcuts; do they use their mouse/touchpad too often ( spoiler alert: this is a bad sign ); do they type quickly on the keyboard, with two hands; using several fingers. In principle, this gives me a fairly general idea of the candidate’s ease of use of the tool, which often goes hand in hand with his or her skill level.
So that’s it; am I hired?
Not yet, young padawan. This article deals only with the technical side of interviewing. I’ve already turned down candidates who had passed the Fizzbuzz test with flying colors. See you in a future article where I’ll explain how we recruit at KNR and why technical skills alone are not enough to make a good candidate.
Don’t forget to subscribe to our newsletter to be notified when the article is released!
Are you a CTO, project manager or even a developer looking for a job? Tell me what you thought of my roadmap in the comments below!
