Thread by @jbuget

À la grande question : "comment bien évaluer techniquement un professionnel du code (dev, ops, autre)?" ma conclusion définitive du moment, après des années d'expérience et d'expérimentations en tout genre est…

(roulements de 🥁)

à la fin de ce 🧵

Ça fait près de 10 ans que je participe à du recrutement tech, en tant qu'équipier, puis tech lead, manager et aujourd'hui CTO.

Dans le même temps, j'ai aussi été amené à être moi-même évalué techniquement lors de changements de boîtes, comme dev ou lead.

J'en ai vu des façons de faire : tests techniques façon QCM, strict ou pas, sur papier ou sur le Web,des cas d'études plus ou moins larges et précis, des exos d'algo,sur whiteboard, en pseudo-langage ou dans une techno imposée, des échanges ouvertes,des grilles de questions, etc.

Des sessions de pair-programming, des demi-journée au sein de l'équipe, voire carrément 3 jours d'intégration ; des projets de 40h à coder chez soi ; des hackatons ; des plates-formes style codingame, etc. (bis)

J'ai connu des échecs personnels :
- je ne suis pas un compilateur ms je sais utiliser mon IDE
- je n'ai pas 3XP en <techno> ms je maîtrise <concept_sous_jacent> et X technos identiques
- je n'ai pas 45h à consacrer à une énième TodoListApp ms je fais bien la marionnette-renard

J'ai connu des succès personnels. Merci de m'avoir fait confiance :
- feu-People in action Cc. @mathieuisaia et @LV_Emmanuel
- feu-Object Direct
- @OCTOTechnology — pr le coup, j'ai passé 45h à potasser ts les soirs pendant 1 semaine ms le sujet et la boite en valaient la peine

J'ai connu des échecs collectifs :
- (p-ê) trop
- + ou - graves et douloureux
- qui se sont révélés + ou - tôt
- évitables (ou pas)
- chaque fois différents
- des gens qu'on a acceptés alors qu'on n'aurait pas dû
- d'autres qu'on a refusés et qui font des choses dingues ailleurs

J'ai connu des succès collectifs :
- la très grande majorité (GG les gens & équipes)
- certains comme des évidences
- d'autres sous forme de "paris" (incroyablement) réussis
- d'autres encore, juste inimaginables ("il a accepté ???" 🍾 🕺 🚀)

Et donc, ce que je retire de tout ça ?

1/ Personnellement, je suis d'une nullité crasse sur les exercices de code pur, en live / binome / via plateforme de code.

Malgré 15XP et des dizaines (centaines) d'heures de code par semaine depuis tout ce temps.

Pcq je n'aime pas coder sans délivrer de valeur utilisateur ou communautaire #OSS ; à défaut ce doit être pour apprendre & progresser

Pcq je n'aime pas coder sous contrainte(s) artificielle(s). J'accepte la pression d'une vraie Prod. Mais pas celle générée et imposée *pour voir*

Pcq je n'aime pas coder un truc qui apporte de la valeur à une entreprise si je ne suis pas rémunéré

Pcq recoder pour la millième fois un FizzBuzz et autre QuickMerge n'est franchement pas marrant, ni même intéressant

Et surtout, pcq ça me stresse de ouf, jusqu'à m'en bloquer.

J'ai pourtant l'habitude d'animer régulièrement des sessions de live-coding ou mob-programming. Mais dans ce cas, je suis dans un contexte de confiance, dont l'assistance (connue ou pas) souhaite ma / notre réussite.

Par le passé, j'ai tenté et utilisé cette approche quelques fois. Mais je n'ai jamais trouvé le résultat à la hauteur de mes/nos attentes & investissements.

Je conçois que cette méthode puisse paraître juste, équitable, objective. Mais mon expérience personnelle, me pousse plutôt à croire que ce n'est qu'une illusion.

Il y a tellement de façons de coder un algorithme. Il existe tellement de solutions à un problèmes.

Le meilleur code est celui qu'on évite (en posant les bonnes questions, en concevant la bonne UX, en trouvant le bon logiciel ou partenaire).

Je considère que le code de production représente moins de 10% du travail et des responsabilités d'un développeur.

Les 90% restants consistent à poser des questions, poser des tests, améliorer les outils / process / culture / ambiance, monitorer, faire du support, se former (veille active / passive), être curieux, se mêler aux autres métiers de l'entreprise.

Je suis déjà tombé sur des exercices de code bien faits et intéressants. Mais derrière, il y avait un véritable investissement conséquent. En termes de réflexion et de code. Mais aussi de maintenance ou de formation des *interviewers*. Ce qui me fait franchement douter du ROI.

2/ Les séances de pair-mob programming, c'est intéressant, mais ça a aussi de grosses limites.

Pour commencer, ça crée un trop grand déséquilibre entre le candidat et le ou les évaluateur(s), qui maîtrise(nt) le sujet, le contexte et surtout l'attendu.

On demande rarement à une personne d'être autonome et pertinente avant plusieurs semaines. Ce type d'approche oblige le candidat à être percutant et à l'aise de suite.

Ça peut bien fonctionner avec certaines personnes, mais pour la majorité des gens, l'effort est immense.

Par ailleurs, ce type de pratique représente aussi un effort important pour l'équipe / les gens côté entreprise.

Il faut s'organiser. Trouver le bon sujet, chose pas toujours aisée ni possible.

Les compétences pour mener correctement ce type d'entretien, ultra dynamiques et très "dans l'impro", ne sont pas forcément communes. Tout le monde n'est pas à l'aise ou doué avec l'exercice.

Enfin, pour les équipes / boîtes qui demandent des demi-journées ou plus, là aussi il faut se mettre à la place du candidat.

Celui ou celle-ci est très certainement encore en poste. Elle n'a p-ê pas moyen ou même envie de poser des congés pour un résultat incertain.

REX : nous avons tenté une fois une immersion de 3 jours avec un candidat. A la fin, nous l'avons embauché, plutôt convaincus par ce que nous avions.

Finalement, nous avons mis fin à son contrat plusieurs mois plus tard.

3/ Finalement, la forme d'entretien que je privilégie aujourd'hui - et dont je ressens tirer les meilleurs résultats - est la "simple" discussion technique, à partir d'un bout de code apporté par le candidat.

Ca peut être du code à elle, ou pas (mais c'est mieux si ça l'est) ; dont il est fier ou qu'il aimerait améliorer.

Le code est un prétexte, un point de départ concret dont le but est de permettre l'émergence d'un véritable échange enrichissant / épanouissant pour les 2 parties.

Tel que j'aime pratiquer mon métier ou le voir pratiquer, les softs skills importent bien + que les hards skills.

Un esprit bien fait vaut mieux qu'une tête bien remplie.
Je ne cherche pas un compilateur humain.

Je cherche un futur coéquipier capable de gérer le facteur humain.

Par ailleurs, je place la maîtrise des concepts + standards + bonnes pratiques largement au-dessus de la maîtrise de telle ou telle autre techno.

Impossible de saisir autant de richesse dans un exercice de code, quelqu'il soit.

De même qu'il n'est pas possible de couvrir l'ensemble des savoirs, savoir-faire et savoir-être réels ou potentiels d'un candidat juste par la discussion.

Mais il est plus facile d'adapter une discussion qu'un énoncé de code ou un use case.

Si je devais résumer un entretien (opérationnel, managérial, autre) à une question, ce serait :

"Est-ce que je me projette, moi, sa futur équipe & coéquipiers, l'organisation dans son ensemble, avec cette personne ?"

Je suis déjà tombé sur des candidats qui cochaient toutes les cases techniques ou opérationnelles et même plus. Et pourtant, je ressentais "un truc" (trop sérieux, trop volubile, trop engagé, pas assez autre chose) qui m'a fait dire no-go.

Au passage, les derniers échecs que je / nous avons connus me font désormais appliquer la technique du :

"dans le doute, pas de doute"

Mettre fin à une période d'essai est un acte traumatisant. Pour le futur-ex-employé, mais aussi pour l'équipe,l'organisation et le manager/RH.

REX : je dis ça, mais j'ai échoué récemment à appliquer stricto-sensu cette règle.

Pcq dire "non" ce n'est pas si simple.

Pcq sur le moment, après 90mn d'échange, on a la tête trop pleine.

Pcq qu'on s'en rend compte qu'au débrieffing avec le reste de l'équipe.

Pcq les bons profils sont rares et qu'on a toujours peur de passer à côté de la perle rare pour un détail.

"Ce sont les détails qui font les grandes histoires".

Pour en revenir à l'entretien en mode discussion, et au côté adaptatif, je le mène de façon à creuser plus ou moins loin différents sujets de sorte à repérer et évaluer avant tout les points forts du candidat.

Ce que je cherche, c'est à détecter dans quelle mesure la personne :
- peut apporter un truc en plus dont l'organisation a vraiment besoin
- est complémentaire ou supplémentaire au reste de l'équipe

Concrètement, on part du code, je pose des questions sur le contexte du projet, du problème ou de l'intention qui a donné vie au code.

Ça me permet d'évaluer le degré d'implication métier/utilisateur de la personne.

Puis, en fonction de la personne (et de mes envies), je vais orienter l'échange sur de l'archi, les concepts / patterns, les choix technologiques, les pratiques individuelles et collectives, Git, le découpage/organisation du code, l'outillage, les opseries, etc.

Dès que je sens que j'ai atteint une profondeur suffisante ou que j'ai touché un point faible, je change de sujet.

Mon but est de révéler le meilleur de mon interlocuteur. Jamais de le descendre. Encore moins de le piéger.

"On ne se grandit pas à rabaisser les autres."

Il ne faut pas oublier qu'un entretien professionnel est un moment de séduction bi-directionnel.D'autant plus dans le domaine de l'informatique.

Il ne faut pas non plus oublier que le temps est notre bien le plus précieux à tous.

"Respecter l'autre, c'est respecter son temps"

REX : le risques avec ce genre d'entretien, c'est que la discussion s'avère un peu trop passionnante et de déborder un peu trop allègrement 😅

Bref, pour conclure (il est plus que temps, "Harry Potter et la Chambre des Secrets" se termine), il n'existe pas de recette magique ou de parfait exercice pour bien évaluer les compétences techniques et opérationnelles d'un inconnu.

Quelle que soit la méthode employée, au final, qu'on le veuille ou non,qu'on se l'avoue ou pas,c'est le facteur humain qui fera la différence. Et c'est tant mieux.Jusqu'à preuve du contraire,le métier de professionnel du code,est "avant tout et malgré tout centré sur l'humain" 😊

Épilogue (1/3) : l'un des meilleurs recrutements auxquels j'ai participé, qui a donné l'un des meilleurs résultats, c'était avec un type qui postulait comme consultant/développeur avec la gueule en vrac car complètement malade, mais avec qui y a eu cette fameuse étincelle.

Épilogue (2/3) : ce jour-là, je lui aurais demandé de coder, il tenait pas 10mn. Je lui aurais foutu un QCM, je pense qu'il aurait répondu à l'envers. Mais notre échange m'a fait ressentir un truc, qui m'ont fait dire GO (ce qui n'est pas si courant).

Épilogue (3/3) : quand on se voit, on en rigole encore ensemble. Il est devenu l'un des meilleurs DSI dont j'ai croisé la route. Des bisous mon @pierre_nicoli 😘