Morceau de code avant l'entretien

Lorsque je recherche des prestataires in­dépen­dants ou des développeurs pour moi ou mes clients, un point paraît pri­mor­dial : s'as­sur­er que le can­di­dat sait écrire du code. Dès les tous pre­miers en­tre­tiens, je de­mandais sys­té­ma­tique­ment aux can­di­dats de fournir un morceau de code qu'ils ont écrit, pour le com­menter en­suite. Ceci per­me­t­tait de savoir que la per­son­ne est très prob­a­ble­ment l'au­teur du code ou du moins qu'elle est ca­pa­ble de com­pren­dre par­faite­ment le code soumis.

Au fil du temps, la ques­tion a évolué vers une for­mu­la­tion plus pré­cise. Sa ver­sion actuelle est :

Pou­vez-vous, s'il vous plaît, fournir un morceau de code que vous avez écrit pour vos pro­jets pro­fes­sion­nels ou per­son­nels et que vous trou­vez par­ti­c­ulière­ment in­téres­sante ou de bonne qual­ité ?

Mal­heureuse­ment, alors-même que la ques­tion est posée bien avant l'en­tre­tien, lais­sant ain­si le temps à la per­son­ne de choisir, pré­par­er et revoir le code, peu de can­di­dats ar­rivent à répon­dre cor­recte­ment à cette ques­tion. Qu'est-ce qu'on at­tend d'eux ?

Leur code à eux

Tout d'abord, on s'at­tend à ce que les can­di­dats en­voient le code qu'ils ont écrit, eux.

Par­mi les cas anec­do­tiques, un sta­giaire a soumis un gros morceau de code as­sez in­téres­sant à lire ; lorsque, quelques jours plus tard, on lui a de­mandé d'ex­pli­quer cer­taines par­ties du code, il n'a pas été ca­pa­ble de le faire. Force­ment, pas facile de com­menter le code copié et qu'on ne com­prend guère.

Un code in­téres­sant ou de bonne qual­ité

Qui a vu le « ou » ? Ef­fec­tive­ment, au­par­a­vant, la ques­tion se ter­mi­nait par « in­téres­sant et bien écrit ». Ceci avait deux in­con­vénients.

Le pre­mier, c'est que « bien écrit » ren­voie in­con­testable­ment une im­age sub­jec­tive. Est-ce qu'un tel ou tel code est bien écrit ? Com­ment le juger ? L'ex­pres­sion « de bonne qual­ité » paraît alors légère­ment moins sub­jec­tive, même si la nu­ance n'est pas facile à cern­er. Lorsqu'on par­le du code C# de bonne qual­ité, ça fait aus­sitôt penser non seule­ment à Style­Cop et Code analy­sis, mais aus­si à Code met­rics, ou en­core à l'util­i­sa­tion co­hérente des ex­cep­tions. Un code bien écrit, c'est quand quelqu'un qui le lit ap­pré­cie la fa­cil­ité de la lec­ture. Un code de bonne qual­ité, en plus d'être lu facile­ment, peut être util­isé à des fins pro­fes­sion­nelles.

Le deux­ième in­con­vénient, c'est qu'il n'y a pas énor­mé­ment d'oc­ca­sions d'écrire un code qui soit à la fois in­téres­sant et de bonne qual­ité. Si je me réfère à Or­seis, par ex­em­ple, le code est man­i­feste­ment de bonne qual­ité, mais il n'y a rien de par­ti­c­ulière­ment in­téres­sant en soi : au­cun prob­lème com­pliqué à ré­soudre. En re­vanche, lorsqu'on a l'oc­ca­sion de ré­soudre un prob­lème très in­téres­sant, le plus sou­vent les con­traintes ex­térieures font qu'il n'est pas pos­si­ble de soign­er da­van­tage le code.

Un code issu d'un pro­jet pro­fes­sion­nel ou per­son­nel

Recher­chant récem­ment un développeur pour un client, j'ai eu un autre cas anec­do­tique. Le can­di­dat me répondait qu'il ne peut pas me fournir de code in­téres­sant car ce code est écrit unique­ment dans un cadre pro­fes­sion­nel et ne lui ap­par­tient pas. Sérieuse­ment ? Un free­lance avec dix ans d'ex­péri­ence en développe­ment n'a ja­mais fait au­cun pro­jet per­son­nel où il y au­rait une par­tie du code quelque peu présentable ?

C'est juste­ment l'ob­jet de la ques­tion ini­tiale. Une per­son­ne qui a passé des an­nées à écrire du code doit force­ment avoir quelque chose à mon­tr­er. Ce n'est pas pos­si­ble autrement.

Un code court ou un code long ?

La ques­tion ne pré­cise rien sur la longueur. C'est fait pour. C'est juste­ment au can­di­dat de choisir s'il veut présen­ter quelque chose de long ou quelque chose de très court. Le code peut être ter­ri­ble­ment court. Si par ex­em­ple la per­son­ne a trou­vé une al­ter­na­tive à un prob­lème qui se présente couram­ment aux développeurs, et que sa ré­so­lu­tion est meilleure que celle com­muné­ment ad­mise, que de­man­der de plus ?

De la même façon, la per­son­ne peut très bien soumet­tre un pro­jet en­tier. Si j'avais été can­di­dat, j'au­rais don­né le lien vers Or­seis. Ce n'est pas sans pos­er de risques en re­vanche. Il ne faut pas ou­bli­er que le can­di­dat va de­voir com­menter les par­ties du code et répon­dre à des ques­tions liées au code ; j'ai telle­ment tra­vail­lé sur Or­seis que je le con­nais qua­si­ment par cœur, mais la per­son­ne va avoir tort de soumet­tre un code trop long qu'elle ne maîtrise pas du début à la fin. Si on lui pose plusieurs ques­tions tech­niques sur une par­tie qu'elle a écrite il y a six mois et n'a ja­mais revu depuis, il risque d'y avoir des soucis.

En don­nant Or­seis, je sais qu'il y a un cer­tain nom­bre de points faibles que je suis prêt à as­sumer lors de l'en­tre­tien, en ex­pli­quant pourquoi ils n'ont pas été cor­rigés et quelle serait la cor­rec­tion en­vis­age­able. À moins d'être to­tale­ment sûr du pro­jet tout en­tier, vaut mieux soumet­tre un morceau de code plus pe­tit alors. Dans les deux cas, on prend des risques : le code court par ex­em­ple peut paraître in­suff­isant, no­tam­ment lorsqu'il sera de­mandé au can­di­dat de le com­menter.