Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Quelle est la pertinence de sélectionner en entretien d'embauche sur de l'algorithmique,
alors que ce ne sera probablement pas le cœur de ton job au quotidien ?
Alors attention, j'aimerais mettre un petit avertissement.
J'aime l'algorithmique, je m'éclate là-dessus, en ce moment, j'apprend le Swift
et je joue beaucoup sur Coding Game et ça m'amuse énormément.
Mais la question, c'est dans un contexte professionnel,
à quel point est-ce que tu vas réellement utiliser cette compétence d'algorithmique ?
Et pourtant, j'ai l'impression que c'est un critère hyper répandu dans les boîtes
de sélectionner et de recruter sur cette capacité à faire des algorithmes.
Et en fait, moi je connais très peu de jobs dans lesquels l'algorithme est vraiment importante.
Alors je ne dis pas, bien sûr il y a des jobs dans lesquels c'est important ou tu vas bouffer de l'algorithme,
et ok pour ces jobs là, c'est évident qu'il faut trier et sélectionner sur cette capacité
parce que écrire des algos et des bons algos, c'est une vraie compétence à part entière.
Mais pour le commun des mortels, quelle est réellement la proportion de ces jobs là ?
Je crois que c'est vraiment un film, c'est 1%, 2% peut-être des jobs qui sont concernés.
Mais ça c'est vraiment une croyance, je ne sais pas, je suis très curieux de ton avis.
Parce que même, je me dis même si un jour tu as un bout d'algos à écrire et que tu es moyen sur le sujet,
tu t'en sortiras a priori, tu vas trouver une manière de faire, ça ne sera peut-être pas optimisé,
ça ne se supportera peut-être pas des charges énormes, et là effectivement si tu as un algos à
faire qui est sous charge, tu auras encore plus de travail à faire, il faudra que tu creuses.
Mais j'ai l'impression que quand même globalement on s'en sortira.
Même j'ai envie de te dire si on va un petit peu plus loin comme ça,
je questionne la pertinence de recruter sur la connaissance pure d'un framework.
Ok, tu vas me dire c'est déjà plus pertinent, je suis d'accord,
parce que ton framework a priori tu l'utilises au quotidien.
Mais quelle est réellement la pertinence de recruter sur Angular v2 ?
Tu sais comme moi que ces choses là elles bougent énormément.
Tu as tous les ans le nouveau framework à la mode, tu as des vagues successives,
là ces dernières années c'était la vague du JS, en ce moment j'ai l'impression que c'est la
vague du Python qui est en train de monter. Est-ce que c'est vraiment pertinent de sélectionner
quelqu'un qui va probablement t'accompagner sur plusieurs années quand on sait que les
modes des frameworks vont et viennent, se font et se défoncent ? On ferait peut-être mieux de
recruter sur la capacité à apprendre un framework, la capacité à s'approprier ses outils,
l'autonomie de chaque développeur pour gérer sa propre autofarmation.
Parce que au fond est-ce que coder un framework, coder dans un framework ou faire l'algo,
est-ce que c'est vraiment ça l'essence du métier ? Et pour moi la réponse est clairement non.
L'essence du métier n'est pas de coder un framework ou de coder avec un framework,
l'essence du métier n'est pas d'écrire de l'algorithmique et de faire des trucs
finalement hyper pointus, hyper techniques. Pour moi ce qui fait l'essence du métier
de développeur, c'est d'abord ta capacité à comprendre le besoin réel de l'utilisateur.
Donc je vais la redire doucement cette phrase. Comprendre le besoin réel de l'utilisateur.
Et là tu vois bien que tout de suite on a un énorme problème parce que je parle bien du besoin
réel de l'utilisateur et pas du besoin fantasmé du client. Le client est rarement ton
utilisateur. Le client c'est vraiment celui qui, c'est soit celui qui te paye, qui te nourrit,
soit celui qui te dit quoi faire, le donner en ordre. Parfois c'est les deux. Et c'est rarement
le client lui-même, ça peut arriver mais c'est rarement, enfin le client est rarement
l'utilisateur lui-même. Et dans le meilleur des cas, le client croit qu'il sait ce qu'il veut,
qu'il sait que voudra son utilisateur. Mais dans la réalité c'est rarement le cas. Dans la réalité
dès qu'on met quelque chose dans les mains de l'utilisateur, alors tu en as toute une partie
qui va l'utiliser tel qu'il a été pensé, si ça a été bien pensé. Et tu en as toute une
partie qui vont l'utiliser autrement. Alors soit en innovant et en créant de nouveaux usages
qui n'étaient pas du tout prévus à la base, soit en répondant et en montrant que ça répond pas
complètement à son besoin réel. Et donc là déjà tu vois qu'on a un boulot énorme rien que là.
Ensuite pour moi l'essence du métier c'est échanger et se coordonner, c'est-à-dire de parler
entre humains parce que l'époque où une personne seule pouvait faire un programme complet et quand
même un peu derrière nous, tu peux toujours, si tu es free, si tu es ou même développeur isolé dans
une boîte faire beaucoup de choses, ça peut marcher. Mais globalement aujourd'hui les équipes
que je vois elles sont quand même pluridisciplinaires parce que chaque technologie demande aujourd'hui
un niveau de compétence qui est tellement pointu que c'est difficile à une personne de
toutes les maîtriser correctement. Et du coup aujourd'hui on a vraiment besoin de bosser en
équipe et donc cette nécessité d'échanger et de coordonner me paraît largement plus critique
dans un projet pour la réussite d'un projet que ta capacité à coder un algo. Et puis il y a aussi
cette, pour moi ce qui fait l'essence du métier et les points sur lesquels je bute au quotidien,
c'est vraiment nommer les choses correctement. Pour moi c'est une des activités les plus
difficiles à faire. Alors parfois j'ai l'inspiration, ça vient vite, parfois c'est plus compliqué que
ce que je pensais, parfois il faut que je m'y reprenne à une, deux, trois, quatre fois pour trouver
le bon concept, donner le bon nom et comment je sais que je n'ai pas donné un bon nom,
quand je relis mon code quelques temps après si ce n'est pas évident, ce que fait tel méthode
ou tel objet, c'est qu'il y a un problème. Et la petite page d'autopromotion, tout ça c'est
l'objet du module 2, apprendre à ranger son code, apprendre à ranger chaque classe à sa place,
si tu es intéressé c'est dans la maison des compagnons maison.artisan-developer.fr module 2
du cursus. Autre point qui me semble faire l'essence du métier, c'est ta capacité à écrire du code
propre et durable et ça tu sais que c'est tout le sens de mon engagement avec artisan-developer.
Tout l'enjeu c'est prévoir l'avenir en répondant aux besoins d'aujourd'hui. Attention,
prévoir l'avenir, prévoir ce n'est pas anticiper l'avenir. Anticiper l'avenir c'est ce qui t'amène
au big up plan design, c'est-à-dire passer beaucoup de temps à tout anticiper, tout l'écart, tu te
retrouves avec un over design monstrueux qui va éclater en vol dès le premier changement,
dès le premier change request, dès le premier changement de spec, dès le premier usage de
l'utilisateur va te dire, ah oui ça c'est presque ça mais il y a ce petit détail et
puis baf, cathatrafe, là il y a tout qui peut être quoi. Prévoir, donc prévoir ce n'est pas
anticiper, prévoir c'est s'occuper de l'instant présent, c'est écrire du code souple aujourd'hui
et laisser les choses émerger dans ton code, faire un code émergent ou les concepts émergent
petit à petit et pas en anticipation de tes besoins futurs parce qu'on se trompe souvent
quand on essaie d'anticiper. Et ça c'est vrai que c'est difficile à sentir dans un entretien,
il faut passer du temps pour comprendre comment le développeur réfléchit et c'est pas un QCM
ni un test d'algaux qui va t'amener ça et du coup je comprends que ce soit de plus difficile à
faire surtout dans une époque où les développeurs n'ont pas spécialement envie de passer une
demi journée sur un recrutement, ils ont tellement d'offres que c'est difficile pour eux de passer
ce temps là mais pourtant ça me paraît essentiel et en tout cas aujourd'hui je questionne vachement
ces approches où on teste sur un QCM ou on va te tester sur un truc hyper pointu d'un
langage d'un cas particulier du langage, ça me paraît juste un non sens. Mais je suis qui
retourne, est-ce que ça te semble pertinent de sélectionner sur de l'algorithmique voire même
sur la connaissance d'un framework ? Est-ce que tu fais souvent d'algorithmique dans ton quotidien ?
Tiens, est-ce que ça c'est vraiment un sujet pour toi ? Est-ce que tu en fais beaucoup ? Est-ce
que tu fais pas ? Je suis Benoit Arrobaz, artisan-developer.fr et je te dis à demain.