Home Home

Morceau de code avant l'entretien

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
129
articles
July 11, 2012

Lorsque je recherche des prestataires indépendants ou des développeurs pour moi ou mes clients, un point paraît primordial : s'assurer que le candidat sait écrire du code. Dès les tous premiers entretiens, je demandais systématiquement aux candidats de fournir un morceau de code qu'ils ont écrit, pour le commenter ensuite. Ceci permettait de savoir que la personne est très probablement l'auteur du code ou du moins qu'elle est capable de comprendre parfaitement le code soumis.

Au fil du temps, la question a évolué vers une formulation plus précise. Sa version actuelle est :

Pouvez-vous, s'il vous plaît, fournir un morceau de code que vous avez écrit pour vos projets professionnels ou personnels et que vous trouvez particulièrement intéressante ou de bonne qualité ?

Malheureusement, alors-même que la question est posée bien avant l'entretien, laissant ainsi le temps à la personne de choisir, préparer et revoir le code, peu de candidats arrivent à répondre correctement à cette question. Qu'est-ce qu'on attend d'eux ?

Leur code à eux

Tout d'abord, on s'attend à ce que les candidats envoient le code qu'ils ont écrit, eux.

Parmi les cas anecdotiques, un stagiaire a soumis un gros morceau de code assez intéressant à lire ; lorsque, quelques jours plus tard, on lui a demandé d'expliquer certaines parties du code, il n'a pas été capable de le faire. Forcement, pas facile de commenter le code copié et qu'on ne comprend guère.

Un code intéressant ou de bonne qualité

Qui a vu le « ou » ? Effectivement, auparavant, la question se terminait par « intéressant et bien écrit ». Ceci avait deux inconvénients.

Le premier, c'est que « bien écrit » renvoie incontestablement une image subjective. Est-ce qu'un tel ou tel code est bien écrit ? Comment le juger ? L'expression « de bonne qualité » paraît alors légèrement moins subjective, même si la nuance n'est pas facile à cerner. Lorsqu'on parle du code C# de bonne qualité, ça fait aussitôt penser non seulement à StyleCop et Code analysis, mais aussi à Code metrics, ou encore à l'utilisation cohérente des exceptions. Un code bien écrit, c'est quand quelqu'un qui le lit apprécie la facilité de la lecture. Un code de bonne qualité, en plus d'être lu facilement, peut être utilisé à des fins professionnelles.

Le deuxième inconvénient, c'est qu'il n'y a pas énormément d'occasions d'écrire un code qui soit à la fois intéressant et de bonne qualité. Si je me réfère à Orseis, par exemple, le code est manifestement de bonne qualité, mais il n'y a rien de particulièrement intéressant en soi : aucun problème compliqué à résoudre. En revanche, lorsqu'on a l'occasion de résoudre un problème très intéressant, le plus souvent les contraintes extérieures font qu'il n'est pas possible de soigner davantage le code.

Un code issu d'un projet professionnel ou personnel

Recherchant récemment un développeur pour un client, j'ai eu un autre cas anecdotique. Le candidat me répondait qu'il ne peut pas me fournir de code intéressant car ce code est écrit uniquement dans un cadre professionnel et ne lui appartient pas. Sérieusement ? Un freelance avec dix ans d'expérience en développement n'a jamais fait aucun projet personnel où il y aurait une partie du code quelque peu présentable ?

C'est justement l'objet de la question initiale. Une personne qui a passé des années à écrire du code doit forcement avoir quelque chose à montrer. Ce n'est pas possible autrement.

Un code court ou un code long ?

La question ne précise rien sur la longueur. C'est fait pour. C'est justement au candidat de choisir s'il veut présenter quelque chose de long ou quelque chose de très court. Le code peut être terriblement court. Si par exemple la personne a trouvé une alternative à un problème qui se présente couramment aux développeurs, et que sa résolution est meilleure que celle communément admise, que demander de plus ?

De la même façon, la personne peut très bien soumettre un projet entier. Si j'avais été candidat, j'aurais donné le lien vers Orseis. Ce n'est pas sans poser de risques en revanche. Il ne faut pas oublier que le candidat va devoir commenter les parties du code et répondre à des questions liées au code ; j'ai tellement travaillé sur Orseis que je le connais quasiment par cœur, mais la personne va avoir tort de soumettre un code trop long qu'elle ne maîtrise pas du début à la fin. Si on lui pose plusieurs questions techniques sur une partie qu'elle a écrite il y a six mois et n'a jamais revu depuis, il risque d'y avoir des soucis.

En donnant Orseis, je sais qu'il y a un certain nombre de points faibles que je suis prêt à assumer lors de l'entretien, en expliquant pourquoi ils n'ont pas été corrigés et quelle serait la correction envisageable. À moins d'être totalement sûr du projet tout entier, vaut mieux soumettre un morceau de code plus petit alors. Dans les deux cas, on prend des risques : le code court par exemple peut paraître insuffisant, notamment lorsqu'il sera demandé au candidat de le commenter.