Discussion :

[Stéphane le calme]

Des développeurs avouent leurs « péchés » de programmation,
pour s'ériger contre un processus d'entretien technique qu'ils estiment brisé

Un certain nombre de développeurs ont pris Twitter d’assaut pour attirer l’attention des professionnels, en particulier des recruteurs, sur le processus d’entrevue qui peut s’avérer éreintant dans leur domaine et repose fortement sur des questions techniques.

David Heinemeier Hansson, un développeur danois père du framework web Ruby on Rails et du wiki Instiki, avait fait allusion à cette pratique des recruteurs dans ce qu’il a appelé « l’algorithme de bizutage du tableau blanc », étape de l’entretien d’embauche où les candidats sont mis à rude épreuve avec des questions techniques.

Ce style d'entrevue, largement utilisé par les grandes entreprises technologiques, notamment Google et Amazon, consiste généralement à mettre les candidats face à un tableau blanc sans qu’ils n’aient accès à un matériel de référence, scénario de travail que des développeurs ont qualifié de démoralisant, mais aussi de test irréaliste de la capacité réelle.

C’est David Heinemeier Hansson qui a ouvert le bal en déclarant : « bonjour, je m’appelle David. Je ne parviendrais pas à écrire un tri à bulles [ou tri par propagation : un algorithme de tri qui consiste à comparer répétitivement les éléments consécutifs d'un tableau, et à les permuter lorsqu'ils sont mal triés]sur un tableau blanc. Je cherche du code sur Internet tout le temps. Je ne fais pas d'énigmes ».

En guise de réponse à son Tweet, certains développeurs ont suivi le ton de cet « aveu ». Comme l’ingénieur Tim Dierks qui a déclaré « bonjour, je m'appelle Tim. Je suis un responsable d’équipe chez Google avec plus de 30 ans d'expérience en développement, pourtant j'ai besoin de chercher comment obtenir la longueur d'une chaîne Python ».

Ou encore le développeur Lukas Kollmer qui a déclaré « bonjour, je m’appelle Lukas. J’écris du code Objective-C depuis près de 8 ans, mais pourtant j’ai toujours besoin de chercher la syntaxe objc block sur Google ».

Même son de cloche chez un autre développeur qui a déclaré « bonjour, mon nom est Bruce. Je développe en Clojure depuis 7 ans déjà et j’ai toujours copié et collé les déclarations des espaces de noms, puis je les ai changées ».

« Le seul monde où vous auriez besoin de pouvoir vous souvenir d'un algorithme serait un monde post-apocalyptique, où les disques durs de tous les ordinateurs connectés à Internet seraient grillés et toutes les copies de documents universitaires fondamentaux et de manuels d'informatique auraient été réduits en cendres », a estimé le professeur Quincy Larson dans un billet de blog intitulé « l’entretien au tableau blanc est une compétence discrète, tout comme être capable de se rappeler Pi à un millier de décimales ».

Et d’expliquer que ce processus « refroidit de nombreuses personnes qui sont sous-représentées dans le domaine du développement de logiciels ». « Si vous êtes occupés à travailler et à élever des enfants, vous voulez passer autant de temps que possible à apprendre à coder et non effectuer des mémorisations par coeur qui n'auront aucune importance une fois que vous aurez commencé votre travail ».

Il arrive que les développeurs passent des jours, voire des semaines entières à se préparer à cette épreuve, motivés en partie par la peur d’être interrogés sur un algorithme qu’ils n’ont pas étudié ou qu’ils ne maîtrisent pas. « Une petite industrie a émergé qui nous rappelle le mal-être de la préparation au SAT », a expliqué Karla Monterroso, vice-président des programmes pour Code2040, une organisation pour les techniciens noirs et latinos, dans une critique de l'entrevue du tableau blanc. « Un individu peut dépenser des milliers de dollars à apprendre les normes culturelles nécessaires pour se mettre dans un bureau d'une entreprise de technologie ».

En décembre, Aline Lerner, l'un des fondateurs de Interviewing.io, un service qui permet aux développeurs de se préparer par la pratique pour des entretiens techniques et effectue même des entretiens anonymement pour certaines entreprises, a écrit un billet de blog intitulé « vous ne pouvez pas améliorer la diversité dans la technologie sans corriger l’entretien technique ».

« Après avoir tiré des données de milliers d'entretiens techniques, il est devenu clair pour nous que l'entretien technique est un processus dont les résultats sont non déterministes et souvent arbitraires », a-t-elle écrit. « Nous croyons que l'entretien technique est un processus brisé pour tout le monde, mais que les défauts dans le système ont encore plus de répercussions sur les groupes sous-représentés ».

Certaines entreprises, comme Foursquare, ont déjà abandonné l'entretien sur le tableau blanc.

Source : l'entretien technique est brisé, billet David Hansson, tweet David Hansson, billet Quincy Larson, tweet Tim Dierks, billet Aline Lerner, Foursquare

Et vous ?

Quels sont vos « péchés » de programmation ?
Partagez-vous cet avis sur le tableau blanc en entretien technique ou pensez-vous qu'il est nécessaire ? Pourquoi ?

[Jarodd]

J'ai trouvé cette initiative de "coding out" très rafraîchissante et marrante. Ca met bien en exergue le défaut du recrutement par des gens qui ne connaissent pas notre métier ni notre façon de travailler.

Et ça permet de lutter contre le syndrôme de l'imposteur qu'on peut ressentir à force d'être piégé dans les entretiens par ces questions sans sens

Sinon, qu'est-ce que le SAT ? Et par "techniciens (noirs et) latins", vous voulez dire latinos ?

[ilatech]

Quels sont vos « péchés » de programmation ?

Je regarde souvent sur Internet pour trouver des exemples de codes, même pour des choses très simples. Ça me donne souvent des idées.
J'aime bien aussi le papier et le crayon.

Partagez-vous cet avis sur le tableau blanc en entretien technique ou pensez-vous qu'il est nécessaire ? Pourquoi ?

C'est n'importe quoi car tout le monde fait des recherches sur Internet, dans des livres, des notes, l'appel à un ami, etc. Ce n'est pas aberrant, bien au contraire car quand on travaille dans une entreprise le but est de "produire" du code, mais pas forcément de le faire tout seul dans son coin en parfait autarcie.

Je préfère des questions du genre "Est-ce que vous avez un projet perso à me présenter ?", "Participez-vous à un projet open-source ?" ou "Faites-vous des contribution sur github ?". Là on peut beaucoup mieux juger un candidat.

[Traroth2]

Personnellement, j'ai utilisé une méthode que je trouve assez efficace : annoncer un sujet de discussion technique à l'avance, dans le mail de confirmation de rendez-vous, pour l'entretien.

Fondamentalement, l'effet de surprise est toujours au détriment du candidat. Mais aussi du recruteur, puisqu'il va avoir du mal à déceler les bons candidats. En tant que recruteur, je ne veux pas savoir ce que le candidat va pouvoir imaginer en 5 minutes, mais ce qu'il peut produire en réfléchissant à tête reposée. Et si on prend un sujet un peu pointu, c'est facile de détecter ceux qui ne comprennent rien à ce qu'ils racontent. L'inconvénient, c'est que le recruteur doit être compétent aussi, mais est-ce un inconvénient ?

On peut même aller plus loin et annoncer le plan complet de l'entretien dans le mail. Moins le candidat est stressé, plus on peut voir ce qu'il vaut dans une situation proche du réel. Personnellement, je vais jusqu'à demander aux candidats de me raconter une blague, en début d'entretien (ça, ce n'est pas moi qui l'ai inventé).

[leroivi]

Perso, j'ai TOUJOURS les docs de référence de ce avec quoi je travaille ouvert, prêt à vérifier le moindre détail, que ce soit -dans mon cas- la documentation Qt, la documentation du projet courant (fait par les collègues, voire moi-même), ou même la documentation de la STD avec cppreference.

Ce style d'entretien n'est pas si délirant je pense, ce qui l'est c'est les conclusions qu'on en tire. Il faut juste pouvoir juger ce qu'on a pu observer à sa juste valeur, et ce n'est donc pas à considérer comme représentatif du travail qui pourra être effectué ensuite.

Je préfère des questions du genre "Est-ce que vous avez un projet perso à me présenter ?", "Participez-vous à un projet open-source ?" ou "Faites-vous des contribution sur github ?". Là on peut beaucoup mieux juger un candidat.

Contre. On demande à un commercial ses ventes sur leboncoin ? Je suis d'accord qu'on puisse mettre ses réalisations perso en avant, mais il ne faut pas que ça en soit une norme/une obligation. Le gars qui n'a pas eu le temps, qui a dû consacrer sa vie perso à autre chose que l'info ne doit pas être pénalisé, il faut bien différencier la vie perso et professionnelle tout de même !

[Metalman]

Enfin les langues se délient...
Ouf...
Oui il y a des algos faciles à retenir, mais il y en a d'autres... zut quoi.
Même celui qui fait passer l'entretien ne serait pas toujours capable de s'en souvenir... (voire le meilleur : selon le contexte on peut avoir plusieurs algos, et le recruteur n'y pensait même pas/plus)

Merci à eux d'avoir le courage de nous l'avouer

Sinon, qu'est-ce que le SAT ?

Le SAT, c'est un examen : Studyrama : tout-savoir-sur-le-sat-scholastic-assessment-test

[bihetq]

Hello,

Perso, j'ai TOUJOURS les docs de référence de ce avec quoi je travaille ouvert, prêt à vérifier le moindre détail, que ce soit -dans mon cas- la documentation Qt, la documentation du projet courant (fait par les collègues, voire moi-même), ou même la documentation de la STD avec cppreference.

Contre. On demande à un commercial ses ventes sur leboncoin ? Je suis d'accord qu'on puisse mettre ses réalisations perso en avant, mais il ne faut pas que ça en soit une norme/une obligation. Le gars qui n'a pas eu le temps, qui a dû consacrer sa vie perso à autre chose que l'info ne doit pas être pénalisé, il faut bien différencier la vie perso et professionnelle tout de même !

Pour la première partie, j'ai l'habitude de fonctionner de la même façon, et je trouve cela beaucoup plus intelligent de fonctionner comme cela. Nous ne sommes pas des robots nous ne pouvons pas penser à tout.

Pour la deuxième partie, je partage aussi ton point de vus. On m'a demandé lors de tous mes entretiens les différents projets personnels et autre que j'avais pu faire. A croire que pour les recruteurs nous ne sommes bon qu'à faire du code et que nous n'avons pas de vie perso... Quand je sors du boulot je n'ai pas forcément envie de me remettre dans le code en rentrant chez moi... Je préfère faire passer ma vie de famille et personnelle avant tout, et faire des projets perso, ou contribuer à des projets libre quand j'en ai le temps et l'envie.

Malgré tout, je suis aussi contre le "tableau blanc" lors des entretiens, cela peut provoquer du stress et faire perdre ses moyens à un candidat. Il vaut mieux mettre à profit la période d'essai pour voir les capacités réelle d'un développeur plutôt que de faire un choix semi arbitraire avec l'examen du "tableau blanc".

[ultimatemanu]

Pour ma part j'ai vécu un recrutement de rêve il y a qqs années: les mecs m'ont donné une clef USB avec tout l'environment de dev + la doc dessus et m'ont dit: vas-y, tu prends une semaine pour développer un truc, ce que tu veux, et tu nous le présente.
Bilan: cela va faire 10 ans que je travaille avec eux. D'abord en tant que salarié, et depuis quelques années comme un de leur prestataire. Que du bonheur!

[NoPr0n]

Pour ma part j'ai vécu un recrutement de rêve il y a qqs années: les mecs m'ont donné une clef USB avec tout l'environment de dev + la doc dessus et m'ont dit: vas-y, tu prends une semaine pour développer un truc, ce que tu veux, et tu nous le présente.
Bilan: cela va faire 10 ans que je travaille avec eux. D'abord en tant que salarié, et depuis quelques années comme un de leur prestataire. Que du bonheur!

Ce type de test pose aussi quelques problèmes selon moi. Quand tu recherches activement un poste et que tu est en contact avec 5 à 10 boites qui te font passer ce genre de test technique qui peu durer plusieurs heure, tu fais comment pour tout faire ? Tu abandonne ta vie ? Tu mise tout sur uniquement 1 ou 2 de ces boites en espérant que le projet soit sympa et que la boite t'accepte bien au final ?
Surtout que généralement les consignes sont flou et le résultat peu énormément varier entre celui qui ne fait rien de sa vie et celui qui participe à 3 assoc et 2 meetup par semaine.
Ce genre de test ne vaut pas mieux que demander un projet perso au final.

[Florent.Lebail]

Le tableau blanc haha... un développeur qui n'as pas pas internet a portée de main ou de docs etc... sa veux dire un développeur qui ne fait pas de veille techno. Est ce qu'on peux appeler ça un développeur ? (Sauf technologie qui n'évolue plus et dont on maîtrise absolument tout mais j'ai pas de langage en tête la ><!)

[Omote]

Il m'arrive très souvent de recherché la solution à un problème sur internet. Avec le temps je mémorise les façons de faire et pourtant je retourne encore régulièrement pour voir si il n'y en a pas de meilleurs. StackOverflow est très pertinent sur ce point. Quelqu'un qui réutilise tout le temps la même solution peut se priver des avancés des languages.

[ultimatemanu]

Ce type de test pose aussi quelques problèmes selon moi. Quand tu recherches activement un poste et que tu est en contact avec 5 à 10 boites qui te font passer ce genre de test technique qui peu durer plusieurs heure, tu fais comment pour tout faire ? Tu abandonne ta vie ? Tu mise tout sur uniquement 1 ou 2 de ces boites en espérant que le projet soit sympa et que la boite t'accepte bien au final ?
Surtout que généralement les consignes sont flou et le résultat peu énormément varier entre celui qui ne fait rien de sa vie et celui qui participe à 3 assoc et 2 meetup par semaine.
Ce genre de test ne vaut pas mieux que demander un projet perso au final.

C'est vrai que je n'ai jamais été en contact avec plus de 2 boîtes en même temps ... Concernant ce test, ce fut le seul du type mais c'est celui qui m'a laissé le meilleur souvenir... J'ai effectivement investi quelques soirées et une partie d'un weekend, mais ça a été payant... Cela peut valoir le coup parfois de zapper un ou deux Meetups ... Surtout que niveau Meetups il ya plutôt inflation ces temps-ci, du moins sur Paris... Mais c'est un autre sujet

[grunk]

Même celui qui fait passer l'entretien ne serait pas toujours capable de s'en souvenir...

Souvent il ne sait même pas de quoi il retourne puisque l'entretien technique est rarement réalisé par une personne technique mais plus souvent par quelqu'un des RH.
Il à la solution à la question et si ta réponse ne rentre pas dans la boite c'est pas bon , même si techniquement elle est valable.

[Matthieu Vergne]

Quels sont vos « péchés » de programmation ?

J'avoue, j'utilise l'auto-complétion de mon IDE. Si je me sens coupable ? Pas le moins du monde !
J'avoue, je copie et m'inspire de codes sur le net. Les problèmes de licences ? Aucun, vu que j'en tiens compte quand il y en a une et je cite mes sources sinon !

Partagez-vous cet avis sur le tableau blanc en entretien technique ou pensez-vous qu'il est nécessaire ? Pourquoi ?

Tout dépend de ce qu'on entend par cet entretien technique sur tableau blanc. Je n'ai rien contre tant que l'interviewer ne cherche pas les broutilles, mais cherche à comprendre le cheminement du raisonnement, et pose des questions sur comment j'aurais fait évoluer le code au tableau dans telle ou telle condition. S'il commence à me demander si je suis sûr que c'est bien "getSize()" et non "getLength()", ou si il me fait la remarque sur une erreur d'étourderie, je lui ferai remarquer que, heureusement pour moi, je ne postule pas pour un poste de compilateur. Après tout, chacun son boulot.

[bihetq]

Le tableau blanc haha... un développeur qui n'as pas pas internet a portée de main ou de docs etc... sa veux dire un développeur qui ne fait pas de veille techno. Est ce qu'on peux appeler ça un développeur ? (Sauf technologie qui n'évolue plus et dont on maîtrise absolument tout mais j'ai pas de langage en tête la ><!)

On peut faire de la veille techno et utiliser internet ou de la doc quand on dev, je ne vois pas le rapport... Je suis développeur et je fait énormément de veille techno, et pourtant pour certaines choses je préfère garder la doc ouverte à côté de moi...

Pourrais-tu expliquer plus précisément le lien entre les 2 points car je t'avoue que je ne le vois absolument pas....

[ilatech]

Contre. On demande à un commercial ses ventes sur leboncoin ? Je suis d'accord qu'on puisse mettre ses réalisations perso en avant, mais il ne faut pas que ça en soit une norme/une obligation. Le gars qui n'a pas eu le temps, qui a dû consacrer sa vie perso à autre chose que l'info ne doit pas être pénalisé, il faut bien différencier la vie perso et professionnelle tout de même !

Le boulot d'un commercial est de vendre, il sait donc se vendre. Après je n'ai pas parlé d'obligation, car comme tu dis on ne pas forcément consacrer notre temps à faire du développement. Le tableau blanc est une idée comme les autres, mais c'est pour moi une moins bonne idée que les projets persos ou un github actif.

Après il faut que le recruteur sache de quoi il parle aussi.
Je repense à une petite anecdote, lors d'un de mes entretiens: Petits tests très simple pour un dev SQL Server. Je suis embauché et mes deux premières tâches confiées par mon supérieur direct (administrateur BdD à peine plus âgé que moi) consistes à optimiser 2 traitements assez longs et qui n'avait pas réussi à résoudre. La première se fait en modifiant une requête (max 2h de travail, en comptant le temps d'explication de mon chef), et la seconde j'ai juste ajouter des index. Quand tu expliques ça à ton n+2, autant dire que mon chef avait peur que je lui pique ça place.

Le but d'un recruteur de mettre la bonne personne au bon endroit (ça c'est la théorie). Et c'est justement en lui montrant le plus d'éléments positifs, et de préférence en phase avec l'entreprise, que l'on a le plus de chance de se faire recruter (de mauvaises langues disent que les prétentions salariales sont un facteur déterminant).

Pour ma part, je ne participe n'y à des projets open source, et je n'ai pas de projets perso à mettre en avant. Par contre j'ai mon expérience et d'autres activités annexes qui peuvent intéresser un recruteur, ou au moins me démarquer.

[Glutinus]

Je suis vraiment surpris. Pour moi l'algo se fait en pseudo-code ; bien sûr, on sait que sous matlab ou python y a une fonction qui fait une moyenne mais surement pas en C (de memoire).

Faire un algo de tri à bulles reste theorique avec des pseudos fonctions. Et c'est different que de connaitre la syntaxe exacte d'une instruction.

[coolspot]

C'est vrai que je n'ai jamais été en contact avec plus de 2 boîtes en même temps ... Concernant ce test, ce fut le seul du type mais c'est celui qui m'a laissé le meilleur souvenir... J'ai effectivement investi quelques soirées et une partie d'un weekend, mais ça a été payant... Cela peut valoir le coup parfois de zapper un ou deux Meetups ... Surtout que niveau Meetups il ya plutôt inflation ces temps-ci, du moins sur Paris... Mais c'est un autre sujet

Moi je suis contre ce genre de test. Tout simplement parce que c'est du travail gratuit. A titre de comparaison pour engager un maçon pour faire ta maison tu va pas lui demander de construire un garage pour prouver qu'il connaît son métier.

Et pis comme rappeler on a pas que ca a foutre de coder en dehors des 7-8h de taf requis. Il y a des gens comme moi ou c'est un travail alimentaire et j'ai pas que ca à foutre de coder chez moi surtout si c'est en plus juste pour un entretien d'embauche. J'ai autre chose à foutre de mes journée que perdre du temps avec ca.

[23JFK]

Surtout que tous les algorithmes fondamentaux sont systématiquement portés dans les API des langages de programmation ; ils ont donc été testé, vérifié et revérifié voire optimisé via des rapports de bugs par les millions de personnes les ayant intégrés dans leurs codes. Niveau fiabilité, c'est sans égal par rapport au type à qui l'on demande de réinventer l'eau chaude. Savoir comment ça tourne en dedans, c'est exactement la contrainte qu'est censé éviter la POO aux développeurs.

[tchize_]

Je préfère des questions du genre "Est-ce que vous avez un projet perso à me présenter ?", "Participez-vous à un projet open-source ?" ou "Faites-vous des contribution sur github ?". Là on peut beaucoup mieux juger un candidat.

En quoi ça permettrait de le juger? Certes , tu peux charger le projet et regarder comment il l'a codé. Mais si tu y réfléchis un peu: la qualité de ses commits dépendra fortement de l'organisation du projet auquel il contribue. Plus le projet est propre au départ et bien encadré, plus les commits suivant seront propres et structuré au final, tu va juger le projet et non le candidat, et ce n'est pas forcément lié. Je peux comprendre qu'un candidat amène ça en avant si il a contribué, mais je ne vois pas l'intérêt de la question posée directement.


J'aime l'open source et j'aime pouvoir aider si c'est possible dans le cadre de mon travail. C'est toujours plus pratique d'avoir un fix importé dans le projet de base que d'avoir ton build parallèle résolvant un problème que tu rencontre dans ton boulot. Je ne pense pas être incompétent, ni un génie d'ailleurs, mais j'ai acquis pas mal d'expérience et je suis capable de la mettre au service de mon employeur. En tout cas mon boss continue de le voir comme ça après 2 ans :p. Mais si tu me demande mes contributions opensource: j'ignore où elle sont, j'ai soumis quelques patchs dans ma carrière, quelque part. Mes projets contributeur opensource? J'ai arrêté de contribuer activement sur l'open source quand j'ai commencé ma carrière. C'est ok quand on est étudiant ou quand c'est le core business de votre boite, ça l'est moins quand il faut aller chercher sur les heures de sommeil ou la vie de famille pour le faire. Mon temps libre je le consacre à d'autres choses, ce qui permet de revenir le matin avec un esprit dégagé qui me permet de sortir la tête du guidon et de revoir un problème dans sa globalité et non plus sur juste son aspect technique.


Ce genre de philosophie de recrutement, a mon avis, aboutit à ce que l'on vois souvent sur github: une chiée de micro projets à l'utilité suspecte, non suivis et qui ont pour objectif principal d'améliorer le ranking de l'utilisateur (hé, regardez, j'ai 20 projets sur github!). Et ça finis presque toujours de la même manière. Tu tombe sur le projet en essayant de trouver un plugin pour XYZ, tu l'active, tu te rends compte qu'il a des problèmes, tu va voir le code, et tu rends compte que le type a rien compris à l'outil derrière, fait n'importe quoi et t'a fait perdre 2 heures de boulot en présentant l'outil comme robuste et efficace alors que c'est une bouse sans nom. Ca ne sert plus le but de base qui était de fournis de outils open source de qualité par un travail collaboratoratif, ces projets n'ont que tu des contributeurs uniques et ne sont pas utilisé au delà d'un microcosme dont le contributeur est l'usager principal.

Bon, ça reste plus propre et moins violent que le test technique qui nécessite un investissement de 40h du candidat et s'apparente plus à de l'esclavagisme.