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.
