Recrutement de codeur, une solution à toute épreuve.

Ce post fait référence à la difficulté d’évaluer les compétences d’un candidat dans le monde de la technologie et propose, avec la traduction d’un article publié sur Medium par Amir Yasin, une solution afin d’améliorer le processus de recrutement.

Soyons réalistes, dans le monde de la technologie, un simple entretien est souvent insuffisant pour engager des candidats adéquats. Non seulement n’obtient-on pas toujours une première impression correcte du candidat mais surtout, on risque d’éliminer les bons candidats en faveur des mauvais.

Dans cet autre article, apparu également sur Medium, Eric Elliott parle des techniques qui fonctionnent ainsi que celles qui ne fonctionnent pas pour mener des entretiens d’embauche avec des ingénieurs. En considérant ce qui marche le mieux, nous avons réalisé que la combinaison de ces deux idées donne les meilleurs résultats.

Rémunérer la réalisation d’un projet-type (penser à payer équitablement – prendre $100+/ heure de temps estimé pour la complétion- si le problème devait prendre 2 heures pour être réalisé, offrir 200$)
Convoquer le candidat et discuter de la solution. Laisser le candidat expliquer son raisonnement et parler de ses décisions de conception en le contestant, comme vous le feriez avec tout membre de votre équipe

Payer des candidats pour travailler sur de simples projets et ensuite en discuter avec notre équipe a presque entièrement éliminé les mauvaises décisions de recrutement.
Par ailleurs, la rémunération du candidat qui vous donne une mauvaise solution (ou pas de solution) vous coûtera au final beaucoup moins cher que d’engager la mauvaise personne et de devoir mettre en place un programme d’amélioration des performances et potentiellement se retrouver à licencier le candidat.
En utilisant cette technique, nous nous sommes retrouvés dans des situations où notre avis a changé de « ce candidat correspond exactement à ce dont nous avons besoin » à « j’ai de sérieux doutes à travailler avec ce candidat sur le long terme». A contrario, certains candidats sont parvenus à changer notre première impression négative. En effet, alors qu’il est aisé d’embellir un CV et de mémoriser les bases d’algorithmique et de programmation, les compétences réelles sont en revanche difficile à falsifier.

hire tech guy

Pourquoi le système du défi/exercice dans le cadre de recrutement IT fonctionne-t-il ?

Pour l’employeur

Étant donné que le candidat est payé, il traite la tâche comme étant un travail légitime et par conséquent il donne le meilleur de lui-même afin de résoudre le problème.
Cela permet de simuler une interaction de travail avec le candidat à un faible risque pour vous. Une fois le projet terminé, vous pouvez convoquer le candidat et lui poser des questions au sujet de ses décisions de design/de codage. Cela vous permet d’avoir une idée de la façon dont il communique, comment il supporte la critique, les questionnements et aussi de voir s’il est en mesure de fournir un raisonnement solide supportant ses choix.

Pour le candidat

Cela lui donne une expérience réelle de la façon dont vous interagissez avec les membres de l’équipe.
Cela lui permet de mettre en valeur certaines des compétences qui sont sur son curriculum vitae, mais qui n’apparaissent pas lors d’une simple lecture.
Cela lui permet de vous donner une idée de ce qu’il pense est important, sans s’exposer à un jugement de valeurs. Par exemple, la personne a-t-elle écrit un test pour chaque ligne de code ? Non ? Peut-être n’est-ce pas primordial pour elle et peut-être que ce raisonnement est tout à fait valable. Jamais vous ne recevrez ce genre d’informations simplement en leur demandant: as-tu de l’expérience en Test Driven Developement ? Tout le monde dira que les tests sont importants … et ils le sont. Cependant cela n’empêche pas les gens d’être en désaccord quant au degré d’importance. Ceci aura l’avantage de vous montrer cela.

Nous avons 6 règles lorsque nous utilisons cette méthode d’entretien.

REGLE#1 – Donnez-leur le week-end afin de résoudre la tâche.

Voilà un point où nous sommes en léger désaccord avec Eric. A notre avis, 2 heures n’est simplement pas suffisant pour voir si une personne est capable de trouver une solution appropriée.
Ce que nous faisons, c’est inviter les candidats le vendredi au bureau afin de discuter du problème en question et de comment nous voudrions qu’il soit résolu. Ensuite nous leur transmettons le problème et fixons un rendez-vous le lundi afin de réviser leur solution.
Nous fournissons certaines technologies qui devraient être utilisées pour parvenir à la solution. Mais évidemment que les candidats restent libres d’utiliser d’autres outils et technologies. Par exemple, nous pouvons demander d’utiliser JavaScript en programmation réactive (Reactive Programming) afin de résoudre ce problème, mais la décision d’utiliser Kefir, Bacon ou RX appartient au candidat –

REGLE #2 – N’utilisez pas un problème réel qui doit être résolu au sein de votre entreprise. Pas de cas client!

Cela va de paire avec la Règle #1, mais excepté si vous recherchez un représentant du service à la clientèle, il est inadéquat de par exemple demander de réparer un problème spécifique à votre CMS propriétaire. Soumettez un problème qui est clairement défini et accessible pour le candidat.

REGLE #3 – La solution que vous attendez doit être claire mais susceptible d’être améliorée.

Par exemple, si nous interrogeons un développeur web, nous lui donnerions une tâche précise, par exemple: » créez une appli sur une page qui permet de saisir des films et de les entrer dans sa collection personnelle, de les stocker hors-ligne et de pouvoir faire des recherches à travers sa collection. Je veux pouvoir faire des recherches en fonction du genre du film, du titre et des acteurs. » Nous ne leur donnons pas plus d’indications comme par exemple ; utilisez le stockage web vs cookies, rendez le projet adapté à plusieurs plateformes ou utilisez une feuille de style personnalisée. Nous leur laissons une certaine liberté dans leurs décisions.
Certains choisissent de faire exactement ce que nous avions demandé et d’autres en font nettement plus. Au final, ce qui compte c’est que nous apprécions le résultat du projet.
Nous ne leur disons pas : « Nous aimons les films, créez-nous une page web sympa au sujet de films» ou « Comment architectureriez-vous IMDB si vous deviez le créer en partant de rien ? ».
Nous préférons que la tâche soit suffisamment simple afin que l’ingénieur puisse fournir une solution mais en même temps assez complexe pour qu’il puisse utiliser ses compétences pour créer quelque chose de spécial.

REGLE #4 – Laissez le candidat présenter sa solution devant un groupe.

Le plus grand problème que nous avons rencontré avec des nouveaux employés dans le monde de la technologie c’est qu’ils peuvent devenir très défensifs à l’égard de leur travail. Nous allons consciemment questionner, contester leur solution afin de voir comment ils réagissent. S’ils réagissent d’une manière défensive c’est immédiatement un no-go. Il s’agit d’être conscient de la différence qu’il y a entre défendre qui est vu comme étant positif et être défensif, qui est considéré comme étant négatif. La différence étant que le premier est basé sur des faits rationnels tandis que le second est basé sur les émotions. Un aspect essentiel pour ceci est que chacun dans le groupe soit venu préparé, en ayant considéré la solution proposée par le candidat.

REGLE #5 –Mettez le problème sur papier pour que le candidat puisse le prendre avec.

Soyez clair concernant les technologies, les outils, le look que vous recherchez ainsi que les standards selon lesquels l’évaluation est conduite. En même temps, laissez la solution finale suffisamment ouverte afin que les candidats puissent intégrer leur propre touche. Laissez les candidats vous poser des questions le vendredi et assurez-vous d’être disponible, par email, pour les questions supplémentaires pendant le week-end. Le but étant de créer un environnement favorisant le succès du projet (comme vous le feriez avec un employé).

REGLE #6 – Réglez le paiement le jour de la présentation.

Que vous les employiez ou non, rémunérer les candidats après qu’ils aient présenté leur solution est la meilleure manière de débuter ou de terminer une relation.
Une autre option est de faire appel à une tierce personne de l’entreprise pour faciliter l’entretien et le paiement.

Engager ou ne pas engager, telle est la question.

Indicateurs positifs à l’égard du candidat :

Durant l’entretien du vendredi, le candidat a posé de nombreuses questions pertinentes
La solution proposée résout le problème en utilisant les technologies et techniques prescrites
Le candidat a lu le problème en entier et suivi correctement les instructions données (par ex. si le problème disait d’utiliser PostgreSQL, il n’aura pas écrit des requêtes qui fonctionnent sur Oracle)

Indicateurs négatifs à l’égard du candidat :

Il refuse de faire le projet avec l’argument suivant : « quelqu’un m’emploiera sans que je n’aie à faire un projet préalable»
Il n’a pas rempli la tâche correctement
Il n’arrive pas à argumenter ses décisions de design/de codage
Il se met sur la défensive lorsqu’il présente sa solution

Conclusion

Votre expérience dans le recrutement peut varier, mais nous pensons que cette technique fait des merveilles pour embaucher de nouveaux employés talentueux dans le monde de la technologie. Même si notre échantillon n’est pas immense, cette technique ne nous a pas encore mené à une mauvaise embauche.

Sources: