Comment Repérer Un Bon Développeur En Moins De 15 minutes

UPDATE: cet article a été rédigé en 2017 (ca date). En 2022 les choses ont un peu évoluées chez KNR, je t’invite à écouter ce podcast où je parle en détail de nos nouveaux process de recrutement. Allez, bisous.

Hello toi,

Que tu sois CTO, porteur de projet ou juste en charge du recrutement des développeurs de ton équipe tech, tu es souvent confronté à cette question :

Comment déterminer rapidement si un développeur est un bon fit pour ton équipe ?

Après avoir été formateur pour la SSII Octo Technology, CTO pour la startup Modalova et enfin CEO de ma propre agence KNR Paris; j’ai eu l’occasion de faire passer un grand nombre d’entretiens à des développeurs venant de tout background. Certains sortant de grandes écoles, certains autodidactes ; certains étaient jeunes, d’autres plus âgés ; des hommes et des femmes.

Au fil de ces entretiens, j’ai pu me rendre compte que certains candidats au CV « parfait » ne savait en réalité par vraiment coder ; ils avaient quelques connaissances en la matière, mais n’étaient pas pour moi de vrais développeurs. J’ai donc mis en place une « roadmap » pour mener mes entretiens techniques, une liste à cocher de choses qu’il me fallait vérifier durant l’entretien avant d’envisager d’intégrer un profil à mon équipe.

Cette roadmap me permet d’éliminer en moyenne 80% des candidats, qui malgré un très bon CV sur papier, n’ont pas les compétences nécessaires pour rejoindre mes équipes.

« Mais Gabriel, me diras-tu, en quoi ta roadmap va-t-elle m’aider à mener MES entretiens à moi ? Je n’ai peut-être pas les même attentes que toi concernant mes développeurs ! »

Et bien, lecteur, je te répondrai que tu as tout à fait raison. C’est pourquoi dans cet article je ne parlerai que des aspects techniques qui me permettent de séparer les bons développeurs des moins bons ( pour ne pas dire mauvais ). Des développeurs, qui pour moi n’en sont pas encore. Des développeurs qui ne seront, à mon sens, pas capable de produire un code de qualité, pouvant être utilisé en production sans la supervision d’un autre développeur plus expérimenté. Disons que les développeurs, que je considère comme « moins bons », auront des difficultés à être autonome, force de propositions et à produire un code sans bug.

Ok, let’s get into in !

Le fameux test Fizzbuzz

Le test Fizzbuzz est un test relativement connu par les développeurs. La simple connaissance de l’existence de ce test témoigne d’une certaine culture en informatique ; mais le fait de ne pas le connaitre n’est pas forcément rédhibitoire. Par exemple: je ne le connaissais pas lorsque j’ai intégré Octo Technology.

L’énoncé du test Fizzbuzz est assez simple : il est demandé au développeur d’écrire un code ( je laisse en général le choix du language au candidat ) pour résoudre le problème suivant :

Soit une liste de nombres ; restons simples, prenons des nombres entiers, positifs, compris entre 1 et 1000 (ici on reste simple pour pas que le candidat perde son temps à réfléchir au type de variable à utiliser s’il décide de passer le test avec un language fortement typé, style C).
Pour chaque nombre n de liste, on veut effectuer les opérations suivantes:

• si le nombre est divisible par 3 : on affiche Fizz
• si le nombre est divisible par 5 : on affiche Buzz
• si le nombre est divisible par 3 et par 5 : on affiche Fizzbuzz ( d’où le nom du test )
• sinon : on affiche le nombre n

Et voila, c’est tout ; le test à l’air simple comme ça, et d’ailleurs il l’est. Mais j’ai constaté ( avec un certain effroi ) qu’environ 70% des candidats que je recevais en entretien n’étaient pas capables de passer ce simple test. Certains étaient même en école d’ingénieur, pratiquement diplômés, avec 5 années de « développement web » sur leur CV ; mais ne pouvaient pas passer ce simple test. On en arrive à se demander ce qu’ils apprennent à l’école…

La première étape est de voir s’ils arrivent à passer le test, un bon développeur devrait vous sortir un code potable en 5, voire 10 minutes, pourrait rencontrer un bug en testant son code avec le nombre 15 ( divisible par 3 et par 5 ) ; mais devrait trouver la solution en moins de 5 minutes.

Maintenant, si la personne ne réussit pas le test ; elle est disqualifiée pour moi. Je pense que ce genre de problème devrait être un jeu d’enfant pour un développeur qui se propose de développer pour vous, de réaliser votre projet ou d’intégrer votre équipe tech. On admettra que le stress de l’entretien peut également jouer en sa défaveur et faire perdre au candidat ses moyens: c’est pourquoi il est important de bien le rassurer : ce test est simple, il n’y a pas de piège, le but du jeu est d’aller au plus simple. Dans ces conditions, si votre candidat a besoin de 30 minutes pour sortir un code potable, c’est NOGO pour moi.

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 ! Félicitations, votre dev a réussi le test Fizzbuzz ; il sait donc programmer.

L’idée maintenant est d’essayer d’estimer sa sensibilité à la beauté d’un code clean, épuré et respectant les règles de single-responsability.
Pour faire simple, dans l’exemple de code proposé plus haut, la totalité de la logique de notre code se trouvait dans la fonction fizzbuzz. Or en informatique, on aime bien découper un programme, de manière à ce que chaque bout de code ait un rôle unique ( principe de single-responsability ). En expliquant ce principe à votre développeur, demandez-lui s’il voit un moyen d’améliorer son code pour le rendre plus lisible, en respectant ce principe.

Ici, on essaie de voir comment le développeur répond quand on lui demande « d’améliorer » son code.
Beaucoup de développeurs vont confondre améliorer et optimiser le code. Quand on parle d’optimisation, on parle d’augmenter les performances d’un code ; par exemple le rendre plus rapide, moins gourmand en ressource. C’est très bien de savoir optimiser un code, mais je pense qu’avec les machines que nous avons aujourd’hui ; gagner quelques millisecondes sur l’execution d’un simple programme a moins d’importance qu’auparavant.

Mais je m’égare ! Donc on demande à notre développeur d’améliorer son code. Par améliorer, j’entends le rendre plus beau, plus lisible, plus Charlie, plus apte à être repris par un autre développeur sans qu’ils se disent WTF en lisant les lignes de code, plus faciles à débugger et surtout plus facile à modifier. C’est que j’appelle un bon code, un beau code.

Demandez donc à votre développeur d’améliorer son code ; s’il commence à vous parler d’optimisation pour rendre l’algorithme plus rapide, dites lui simplement que ce n’est pas ce qui lui est demandé ; on cherche seulement à rendre le code plus beau.

Ici, je m’attends en général à ce que le candidat, sorte la partie logique du code qui sert à déterminer si un nombre X est divisible par un nombre Y. Cela permettrait de rendre le code plus DRY ( Don’t Repeat Yourself ) ; et également d’améliorer sa lisibilité. On fera également attention à la façon dont il nomme ses variables et ses fonctions. Un code avec des variables nommées a, b, c, x, y est synonyme d’un développeur qui n’a jamais vraiment travaillé en équipe.

function est_divisible($nombre, $diviseur) {
  return (0 === $nombre % $diviseur);
}

Read between the lines (of code)

Et voilà, on a donc les quelques lignes de codes qui permettent à un développeur de me prouver qu’il sait effectivement coder. Mais est-ce que cela suffit pour se démarquer des autres candidats ? Well, no…

Un bon développeur : c’est aussi (et surtout) un développeur qui maitrise son outil.

En général je demande aux candidats d’amener leur ordinateur en entretien ; ainsi ils peuvent utiliser l’outil sur lequel ils devraient en principe être à l’aise. Durant le test fizzbuzz ; je vais observer la manière dont ils se servent dudit outil ; utilisation d’un IDE, utilisation de raccourci clavier ; est-ce qu’ils utilisent trop souvent leur souris/touchpad ( spoiler alert : c’est mauvais signe ) ; est-ce qu’ils tapent vite au clavier, à deux mains ; en utilisant plusieurs doigts. Ça me donne en principe une idée assez globale de la facilité qu’a le candidat à utiliser son outil ; cela va souvent de pair avec son niveau de compétence.

So that’s it ; am I hired?

Not yet, young padawan. Cette article ne traite que de la partie technique des entretiens. J’ai déjà refusé des candidats qui avaient pourtant passé haut-la-main le test Fizzbuzz. Je te donne rendez-vous dans un prochain article où j’explique comment nous recrutons chez KNR et pourquoi des compétences techniques on point ne suffisent pas à faire un bon candidat.

N’oublie pas de t’abonner à la newsletter pour être mis au courant lors de la sortie de l’article !

Es-tu un CTO, porteur de projet, ou même développeur à la recherche d’un poste ? Dis-moi ce que tu as pensé de ma roadmap dans les commentaires ci-dessous !