Pourquoi on fait des challenges de programmation?

Depuis le tout début, chez Ezo, nous faisons passer un challenge de programmation à tous les candidats qui se présentent à nous. Nous nous sommes lancés dans cette merveilleuse entreprise en pleine crise de l’emploi où les programmeurs sont devenus l’or moderne, ce qui fait qu’on nous a souvent demandé :

Mais… pourquoi vous faites des challenges de code?

Qui va vouloir investir du temps la dedans ne sachant pas s’il va avoir la job?

T’as pas peur qu’un candidat qui a le choix entre vous et un compétiteur choisisse le compétiteur parce qu’ils ne font pas faire de challenge?

T’imagines comment ça deviendrait compliqué de se trouver une job s’il fallait faire des challenges à chaque endroit?

Pourquoi les tests de compétences classiques ne sont pas bons?

Bon… j’y vais fort. Quand je parle de tests de compétences classiques, je parle notamment de tests sur papier ou ordinateur où le candidat se fait poser des questions auxquelles il doit répondre par choix de réponses. On a deux problèmes ici.

Similitude des tests classiques

Dans un premier temps, on peut se dire que l’évaluateur technique va avoir googlé « C# interview questions » pour construire son test, alors ça devient assez facile pour un candidat d’apprendre les réponses aux questions les plus populaires et s’en sortir avec un bon score sans qu’on ait pu vraiment en apprendre sur ses connaissances techniques.

Deviner la réponse

Deuxième problème, on a la théorie des jeux… On peut voir le processus de recrutement comme un jeux opposant deux adversaires : le candidat et l’entité morale qui fait l’évaluation, que ce soit une ou plusieurs personnes. L’objectif du joueur 1, le candidat, c’est de convaincre l’évaluateur qu’il est le meilleur candidat pour le poste. L’objectif du joueur 2, l’évaluateur, c’est de déterminer lequel parmi tous les candidats est le meilleurs pour le poste.

L’évaluateur, au moment de créer le test, va nécessairement choisir lui-même lequel des choix de réponse est la bonne réponse. Est-ce qu’il va choisir la réponse 1 à toutes les questions? J’en doute… mais si on pousse plus loin, imaginons que vous ayez les choix suivants, sans consulter la question :

1. 10
2. 504
3. 3,564
4. -20

Si on s’y attarde en se mettant à la place de la personne qui a fait le test, on peut se dire qu’il a pour objectif de vous rendre la vie difficile pour ne pas que la réponse soit trop évidente. Donc, on peut penser que les réponse 3 et 4 ne sont pas les bonnes puisqu’elles ont chacune leur particularité. 3 est le seul choix avec un nombre qui n’est pas entier et 4 est le seul choix négatif. Si vous aviez fait une erreur quelque part dans votre raisonnement, vous pourriez quand même avoir la bonne réponse puisqu’il n’y a qu’un nombre négatif par exemple. Tout à coup, il ne reste que 2 choix…

Comment un challenge résout ces problèmes?

Le challenge est un cadre précis. Le candidat a une durée définie pour faire le challenge, tous les candidats font le même exercice et tout le monde présente son code dans un environnement semblable. Donc, comme le test classique, il est possible de comparer les candidats selon leurs résultats de façon juste.

Similitude des tests classiques

En ce qui a trait au problème de similitude entre les questions d’un test, on assure par le challenge que ceci arrive à chaque fois. Oui, oui! Chaque fois, le candidat doit répondre à exactement la même question, et une seule, celle du challenge. Le candidat pourra se préparer à l’avance à sa discrétion pour se documenter sur les solutions possibles au problème, mais il devra l’implémenter lui-même pour être en mesure de l’expliquer correctement. Certains candidats plus méthodiques vont cherche la solution et l’implémenter, certains plus créatifs vont inventer une solution au problème. Dans tous les cas, on a une bonne image de sa personnalité.

Deviner la réponse

En 3 ans et demi, jamais nous avons vu deux tests identiques. Et chaque fois qu’on rencontre un candidat, on est surpris par la créativité des développeurs. En quelque sorte, ça démontre pourquoi il est impossible d’estimer le temps de développement d’un logiciel.  Au mieux, on peut faire un guesstimate .

Bref, pour prouver ce point, je ferai une analogie : Quelles sont les chances que vous demandiez à deux peintres différents de vous faire exactement la même toile et qu’elles soient exactement identiques, sans qu’ils ne se parlent?

Bonus : Le filtre naturel

Ce dernier point est à part parce qu’il est propre à Ezo. En tant qu’entreprise en démarrage et en forte croissance, on a besoin des bons joueurs dans l’équipe. On peut difficilement se permettre un taux de rotation élevé puisque le recrutement et le développement des affaires sont le cœur de l’entreprise. Il y a un avantage certain à trouver des candidats qui vont rester avec nous pour plusieurs années plutôt que de prendre des candidats ne seront pas dans l’équipe à long terme.

Je le répète. Je ne dis pas que les candidats ne sont pas bons pour nous, simplement que la réalité d’une startup comme la nôtre est bien différente des géants des TI. Il y a des pours et des contres et il faut s’assurer que tout le monde soit heureux.

Donc… la question qu’on pose avec le challenge, c’est : Es-tu assez motivé à joindre nos rangs et créer un empire des TI pour faire cet exercice?

Conclusion

Aujourd’hui, vous avez appris pourquoi les tests techniques classiques sont ordinaires comme outils d’évaluation. J’espère aussi que cette explication pourrait avoir donné envie à un d’entre vous de nous contacter pour faire partie de l’équipe! Ezo est basé sur la passion du développement logiciel et de l’entrepreneuriat. On prend une bière?

Partager sur Facebook

Partager sur Twitter