Introduction

Ces derniers temps, j'ai passé plusieurs entretiens, et pour plusieurs d'entre eux, j'ai eu des tests de programmation à la fin de l'entretien. Je n'ai pas forcément trouvé ça génial.

Les tests

Pour l'un d'entre eux j'ai trouvé ça plutôt amusant, car j'ai eu des tests du project euler, ça montre que c'est une boite avec une orientation plutôt geek. Cependant, je trouve ça assez délicat en entretien d'avoir ce genre de tests, pour la simple et bonne raison, que c'est malgré tout plutôt orienté mathématique, et pas très proche de ce qu'on fait en tous les jours dans notre travail de développeur. Le premier était assez simple et je l'ai réussi facilement, le deuxième était déjà beaucoup plus difficile et demandait une vrai réfléxion. De plus après une longue journée de travail et après un entretien, je ne trouve pas forcément ça très marrant, de devoir prendre encore du temps à réfléchir sur un problème. Sans compter qu'écrire du code sur papier, c'est vraiment difficile, car aucun moyen de tester. Le deuxième entretien que j'ai eu avec un test était sur ordinateur, mais pas le droit à la documentation du langage et aux pages de man qui n'était pas installé sur la machine. Le problème était simple, mais il existe une fonction très connu pour faire ce qui était demandé, du coup je voyais pas l'intérêt d'écrire l'algo, en pratique on va pas réinventer la roue, j'admets que pour le coup, c'est de ma faute, je me suis complétement planté.

Ma méthode

Je pense que j'ai une approche assez basique qui est la même que la plupart des gens. En général, je pose sur papiers quelques points important, avec la problèmatique, les contraites, les différentes possibité qui s'offre à moi pour la résoudre. Ensuite, j'écrits du code, je test des choses, je m'y reprends à plusieurs fois, j'essaie de faire propre dès le début et lisible, mais pas forcément très optimisé. Je passe ensuite généralement par beaucoup de phase de refactoring, j'accepte de faire des erreurs dans mon code et de ne pas penser à tout des le début, et j'apprends de mes erreurs. Pendant ces phases même pour un problème simple, j'apprécie d'être tranquille pour réfléchir, ne pas être limité sur le temps, car il peut m'arriver de prendre du temps, des fois on sait pas pour quel raison le cerveau bloque un peu, il m'arrive aussi d'essayer des choses complétement idiotes ou de me parler à haute voix et de dire des bêtises, mais ça m'aide à avancer, ça libère mon esprit. J'y vais vraiment étape par étape petit bout par petit bout, quelque soit la complexité du problème, bien-sur certaines étapes seront plus ou moins rapide. Pour déboguer, j'ai un défaut je n'utilise que très rarement les débogueur c'est pourtant très bien, je vais y travailler. En général, j'essaye grossièrement de trouver la méthode qui pose problème, si il y a des tests unitaires c'est très facile, et ensuite je mets pleins de print, les argument que la méthode reçoit en entrée et ce genre de choses.

Je pense que ma méthode, ne se prête pas trop aux tests très académique, et mon côté émotif et peur de l'échec ne m'aide pas forcément. Il serait peut-être plus intéressant comme l'a déjà suggéré Jeff Atwood sur son blog coding horror si il est vraiment nécessaire de faire passer un test, de demander si éventuellement le candidat pourrait se libérer une après-midi et le faire travailler avec un développeur de la boite. Ce serait plus bénéfique pour les deux parties, si c'est bien fait un développeur de l'entreprise aura passer du temps avec le candidat suffisament pour se faire une idée des capacités du candidats à s'adapter même si il n'a pas tous réussi durant cette après-midi ou qu'il a dit des bêtises, pour le candidat je pense que ça sera moins stressant et qu'il y aura vraiment un véritable échange entre les deux personnes donc il se sentira plus en confiance, de plus il sera certainement plus intéressé et motivé de travailler sur des problèmes plus concrets.

Conclusion

Je comprends qu'on puisse faire passer des tests, mais je ne pense pas que ce soit forcément toujours nécessaire selon le profil de la personne, surtout si il contribue à des projets open-source par exemple, et que pendant l'entretien il su démontrer ses connaissances techniques, quoiqu'il en soit je pense pas qu'il faut se baser uniquement sur ce point. Je pense que ce genre de tests ne va pas dire grand chose, une personne qui sort tout juste de l'école, ou qui est à l'aise avec ce genre d'exercices peut très bien s'en sortir certes, mais je ne suis pas certain que ça signifie qu'elle produira correctement sur le terrain, et une personne peut complétement se louper à ce genre d'exercice, car des tests plutôt académique ne se prête pas à tout le monde, c'est possible qu'elle soit plus rétissante et moins intéressé par ce genre d'exercice par conséquent ne fait pas d'effort, et ça ne signifie pas pour autant qu'elle est mauvaise ou incapable d'écrire du code et c'est dommage de passer à côté de profil à cause de ça. J'ai l'impression que les boites essaie de se calquer un peu au modèle de Google ou d'autres grosses boites et ne le font pas forcément correctement. Par ailleurs, je pense que je vais m'amuser à faire plus de petit exercices de ce genre, nottament via project euleur, je pense que ça peut malgré tout être très bénéfique pour le travail au quotidien.

Project euleur Coding horror

Original post of Hobbestigrou.Votez pour ce billet sur Planet Libre.