Recruter dans la Tech, dur dur

En 2021, le recrutement de talents dans la tech, en particulier des profils que l’on appelle communément des “devs” - peu importe leur niveau d’expertise -, est toujours aussi difficile dans un contexte où l’économie du digital fonctionne à plein régime, où trop peu de femmes choisissent ces métiers - divisant de fait par deux le vivier de talents disponibles - et où le nombre total d’ingénieurs formés dans les technologies du digital est trop faible pour satisfaire la demande.

Une pénurie systémique.

Il est important de rappeler un fait à propos des femmes dans l’informatique : elles étaient majoritaires jusqu’au début des années 1980 ; et depuis la proportion de femmes n'a fait que diminuer.

D’après National Science Foundation

Un article de fond très complet permet de comprendre ce qu’il s’est passé pendant cette période : à lire sur Ritimo.org

Pourtant, elles ont été à l'origine de nombreuses révolutions dans le domaine du digital. Par exemple Grace Hopper a inventé un des langages qui a été à la base de quasiment toutes les applications métier, le Cobol et Annie Easley dont la contribution aux programmes spatiaux de la NASA en tant que mathématicienne et informaticienne a été déterminante.

Les solutions pour améliorer la proportion de femmes dans la Tech se mettent petit à petit en place, que ce soit au travers de politiques globales inclues dans les RSE des entreprises pour favoriser l'égalité de traitement, de changements culturels, d'une ouverture et d'une communication des filières de formation de la Tech à destination des femmes...

Ces changements prennent malheureusement du temps, et pendant cette période, la sous-représentation des femmes dans les métiers de la Tech continuera d'amplifier la pénurie existante. Elle devient de ce fait systémique.

Une pénurie qui n'est pas exceptionnelle.

Dans les années 1990, une situation de pénurie identique avait conduit à ce que de nombreux salariés changent de carrière : chimistes et biologistes pour ne citer qu’eux avaient massivement migré vers les technologies de l’information ; et le développement en Cobol notamment.
A l’époque, cette bascule était simplifiée par le fait que le périmètre technologique était encore petit, et que chaque collaborateur avait encore des tâches très spécialisées.
Il était possible d’être “expert (comprendre développeur) cobol” en ne connaissant réellement que le Français, Merise, le Cobol, SQL et un environnement de développement comme TSO.

La promesse était simple : une formation aux concepts de Merise, essentiellement pour savoir comprendre un modèle de données physique - sans s’embêter avec la compréhension d’un MCD la plupart du temps -, une formation à Cobol et SQL et une intégration dans une équipe projet.
Les cycles longs de développement permettaient à chacun de trouver sa place, et les collaborateurs les plus enclins à comprendre les concepts et l'algorithmie prenaient en charge les parties les plus complexes.
Évidemment, il existait d’autres domaines proches de ce qui existe maintenant, par exemple des environnements 100% unix, avec des langages comme le C/C++, des bases de données objet, des traitements distribués.
La grosse différence à l’époque, c’est que de nombreux projets stratégiques nécessitant de gros moyens se faisaient à l’aide de technologies et langages dont l’approche était relativement simple comme le Cobol dans des environnements gros systèmes de type OS390.

On ne devient pas un bon développeur en quelques semaines.

Maintenant, l’histoire est différente : bien loin de la promesse initiale de simplifier le développement informatique, les évolutions technologiques ont apporté de nombreuses possibilités… et une complexité accrue.
Un développeur quelque soit son niveau dès lors qu’il doit intervenir sur des projets ambitieux, doit maîtriser de nombreux outils et langages : pour le front, pour le back, pour l’accès aux données, pour l’indexation, pour l’approche Devops, pour l’accès distant aux services etc.

Ce qui était possible en 1990 et avant ne l’est plus : être capable d’intervenir dans des projets informatiques requiert un niveau de compétences fort sur un périmètre large.
N’importe qui de motivé ne fera malheureusement pas l’affaire, il est donc illusoire de penser qu’en abaissant les critères de sélection technique, il sera possible de trouver les moyens de recruter des personnes rapidement efficaces en mode projet.
Il est tout autant déraisonnable de penser qu’une formation rapide peut permettre de mettre à niveau un candidat trop faible.

Les sociétés de la Tech digitale qui n’ont pas de moyens de faire des formations intenses techniques de mise à niveau l’ont bien compris puisqu’elles formalisent leurs propositions de postes peu ou prou de la façon suivante :

Je veux un dev de 3 à 5 ans d'expérience et passionné sur les technos que j’utilise.
(et si en plus il est disponible de suite, sympa, rompu aux approches Devops et Agile et que c’est une femme, c’est encore mieux)

Dans le marché actuel de la recherche de talent dans la Tech, il est probable que les résultats de la campagne de recrutement ne soient pas ceux espérés.

Pour autant, quand on Aime la Tech, on ne peut pas non plus recruter avec l’idée suivante :

“Je prends n’importe qui qui dit maîtriser les techno que j’utilise ; et je verrai bien comment je m’y prends pour les mettre au niveau”.

Quelles solutions pour recruter des bons développeurs ?

Dès lors, il n’y a pas beaucoup de solutions pour recruter du personnel compétent. Une première solution consisterait à équiper son entreprise d’un processus de remédiation technique ambitieux ; ce qui est à la fois coûteux et pour la plupart des entreprises trop éloigné de leur cœur business.

Une seconde solution pourrait être de sélectionner autrement pour être en mesure d’identifier des talents que les autres recruteurs ne savent pas repérer.
En couplant cette approche à une possibilité de remédiation technique forte en interne, il est ainsi possible de retenir des talents latents - c’est-à-dire sous exploités ou abîmés par leurs précédentes expériences - et les remettre dans une trajectoire gagnante.

Sélectionner autrement, sans aucun doute, mais sans oublier la grande responsabilité vis-à-vis du recrutement, de la sélection et de l’onboarding pour une entreprise qui vise la performance et la compétence.
Il faut identifier et intéresser des femmes et des hommes qui se passionnent pour la Tech ; et qui veulent être parmi celles et ceux qui maîtrisent le mieux l’écosystème ciblé par la société.

Il faut aussi respecter les équipes en place qui souhaitent des nouveaux talents qui leur ressemblent et qui les complètent pour que l’équipe soit encore plus performante. Les équipes en place sont en général prêtes à accepter un temps d’adaptation, mais il doit être contenu.
Quant aux nouveaux talents, ils souhaitent pendant la phase de recrutement valider à 100% que leur potentielle nouvelle société sera bien le terrain de jeu qu’ils attendent pour valoriser et développer leur expertise.

Cette sélection, ou plutôt cette rencontre entre les nouveaux talents et la société qui recrute repose sur de nombreux critères humains ; mais aussi sur des critères techniques : il s’agit tout autant de mesurer le niveau technique, que d’évaluer la capacité à encore progresser ou encore de vérifier l’appétence pour la Tech.

François-Pierre, un des associés fondateurs que chaque nouveau talent rencontrera forcément lors de son processus de recrutement chez Takima, aime rappeler que :

“Le but des tests techniques n’est pas de trouver des arguments de ne pas retenir un(e) candidat(e), mais de déceler les vraies raisons de lui faire intégrer notre équipe”

Concrètement, cela implique qu’il serait erroné de mesurer le niveau technique avec des systèmes conventionnels de type QCM ou coding games automatiques.
Ces pratiques ne sont pas dénuées d’intérêt : elles permettent de vérifier un certain nombre de savoirs et d’automatismes en centrant l’évaluation sur la réussite ou non à répondre à des questions ou à résoudre un problème dans un contexte donné et fermé.
Autrement dit, ce type d’évaluation automatique va permettre de valider une base de savoirs, voire de savoirs-faires (si le coding game est bien conçu).
Ce système conduira ainsi à créer deux groupes : ceux qui n’ont pas atteint la note minimale et ceux qui l'ont atteint.

Le premier groupe va être exclu, et le second va être retenu… pour passer d’autres tests ; car chacun sait qu’il ne suffit pas d’avoir des bases théoriques pour être un bon développeur.

Ce type de test ne sert donc qu’à réaliser un filtre rapide ; pour ne conserver qu’un nombre limité de candidats à qui on pourra faire passer de vrais tests, plus solides, et surtout qui veulent dire quelque chose ; qui permettent de se décider s’il faut oui ou non faire une proposition au candidat.

Le problème de ce filtre rapide est double :

• Il conduit à rejeter des candidats en utilisant un filtre conçu pour exclure : il est très probable que des candidats de qualité soient exclus à tort. Qu’il aurait suffit que leur chance leur soit donnée, avec une remise à niveau adaptée, pour qu’ils deviennent de supers développeurs.
• Il pré-sélectionne des candidats sur des critères qui ne sont pas ceux qui permettront de les retenir in fine ; puisque d’autres tests techniques seront réalisés. Du temps est perdu, dans un processus qui doit pourtant être le plus rôdé et efficace possible.

Un peu à la manière des Shadoks qui pompent sans fin, un recruteur qui fonctionne de cette façon sélectionne sans fin. On parle couramment de “funnel” de recrutement, qui expose, par exemple, que sur 100 candidats en entrée, il n’en reste plus que 1,6 sélectionnés ; personne n’ayant envie d’être le 0,6 qui plus est.

Evaluer la compétence de manière efficace.

L’idée est de mettre en œuvre un seul test qui permet à la fois de voir quelles bases techniques sont comprises, que le candidat a une approche de la résolution de problème logique et maîtrisée et qu’il est en mesure d’apprendre et de progresser.

Un candidat peut “échouer” au test suivant des critères classiques ; et pour autant avoir prouvé qu’il avait sa place sur les critères techniques dans l’équipe de la société.
Le candidat retenu peut ne pas être au niveau de ce qui est attendu, mais dans le même temps ce test pourrait valider qu’il est possible de mettre en place une stratégie ciblée de remédiation technique lors de l’onboarding.

Ce test technique doit donc aussi permettre de définir le besoin en formation des candidats retenus : d’une simple mise à niveau sur les dernières versions de la stack, à un ajout d’expertise sur un sujet donné en passant par une remise à niveau complète Dev/Devops ; les stratégies de remédiation sont infinies… et sur mesure.

Certaines sociétés ont mis en œuvre des processus d’évaluation techniques de ce type ; avec principalement deux approches qui sont parfois utilisées en complément l’une de l’autre : des coding games d’une part et d’autre part la réalisation d’un projet en temps limité.

De nombreuses plates-formes de coding games ont fleuri ces dernières années ; certaines proposent des QCM améliorés sur des sujets techniques, d’autres proposent des exercices complets à réaliser dans un environnement de développement en ligne.
Les secondes sont les plus intéressantes dans la mesure où elles se rapprochent de ce que doit faire un développeur au quotidien ; mais avec des limites qu’il convient de comprendre.

Prenons un exemple concret pour illustrer ces limites : des tests de mise en situation face à un feu.

1. Théorie : un ensemble de QCM permettant de vérifier que chacun sait distinguer les types de feu - électriques ou non - et choisir le bon extincteur en fonction.
2. Pratique 1 : manipulation des extincteurs réels, mais sans les utiliser.
3. Pratique 2 : manipulation d’extincteurs réels, mais de petite taille, sur des feux contrôlés en labo.
4. Pratique 3 : mise en situation réelle dans un bâtiment en feu.

Les coding games visent à une mise en situation réelle ; un peu comme un pompier face à un vrai feu ; mais proposent une expérience de mise en situation simplifiée, cadrée, qui se rapproche plus de la pratique 1 et 2.
Dans ces coding games, chaque étape propose un canevas établi, une architecture définie et souvent simple et un objectif quant au résultat à obtenir ciblé sur un objectif d’évaluation.
Le développeur peut coder, compiler et exécuter son code ; mais s’il souhaite faire des choses non prévues, le système l’en empêchera par construction.
Il y a peu de chance que l’aspirant pompier fasse une chute de tension en pratique 1 et 2 ; et il est probable que la fuite soit une option qui lui passe par la tête en pratique 3. Et c’est précisément là que le cœur de l’évaluation se pose : l’apprenti pompier sera t’il capable d’intervenir avec sérénité en situation ?

Pour notre développeur, les enjeux sans être aussi importants - il ne risque tout de même pas sa vie pour sauver celle des autres -, nécessitent tout de même d’évaluer son approche dans un écosystème informatique ouvert où tout est possible ; le pire comme le meilleur : va t’il chercher à s’inspirer d’un existant valide ou réinventer la roue, va t’il reprendre du code qui n’est pas de qualité, va t’il améliorer l’existant ?

Le coding game tel qu’il est imaginé dans la plupart des plates-formes ne suffit pas à réaliser une mise en situation poussée.

L’approche qui consiste à demander la réalisation d’un projet en temps limité au candidat et à ensuite analyser le résultat permet quant à lui une mise en situation réelle, au niveau de complexité souhaité… en théorie.
En pratique, c’est plus complexe car pour proposer un test en situation réelle, il faut mettre à disposition un environnement de développement et d’exécution complet, ce que peu choisissent de faire. Il s’agit d’un vrai investissement.
Ces exercices sont donc le plus souvent des exercices de création “from scratch” dans lesquels le candidat doit définir une architecture, choisir des composants, intégrer ceux qui sont imposés et réaliser la fonctionnalité demandée.
La seconde limite est l’approche “asynchrone” qui ne permet pas - à la différence des coding games - de juger l’approche, les différentes itérations, erreurs et compilation qui ont permis d’arriver au résultat final.
De fait, si le candidat prend une mauvaise approche au départ, rien ne permet de le remettre sur la bonne voie et son test peut ne pas être discriminant.

Outiller spécifiquement la mesure de la compétence.

Takima a choisi, pour tenter de trouver une solution à cette problématique, de développer une plateforme ad-hoc qui reprend les codes du coding game et du projet ouvert en temps limité :

• Les exercices sont totalement ouverts : le candidat peut décider de coder ce que bon lui semble, d’utiliser ou non des frameworks tiers, d’agir au niveau de la configuration du système ou de la JVM par exemple.
• L’environnement de travail et d’exécution est totalement industrialisé : comme dans un coding game habituel, tout l’environnement pour coder et tester est lancé automatiquement. Il peut être simple, ou complexe avec plusieurs instances serveurs mobilisées des logiques de répartition de charge, du multi cloud.
• Tout ce qui est fait est enregistré et restituable sur une timeline pour permettre une analyse à posteriori, revenir sur chaque étape suivie par l’apprenant.
• Il est possible d’agir en temps réel avec l’apprenant, par exemple pour le remettre sur la voie.

Cette plateforme permet de sélectionner les meilleurs candidats, en s’appuyant sur une analyse différente de ce que font d’autres sociétés ; pour ne surtout pas laisser passer un potentiel talent.

Nous sommes particulièrement fiers de cette approche, car il s’agit d’une approche qui recherche et favorise la compétence tout en étant ouvertement inclusive : takima fait tout pour identifier ce qu’il y a derrière le CV, derrière les expériences réussies et celles qui le sont moins ; c’est à dire se donner une chance de travailler ensemble pour faire avancer nos valeurs.
Et lorsque la rencontre ne peut pas se faire tout de suite, le candidat dispose de conseils pour avancer de lui-même sur la voie de l’amélioration de sa compétence.

Évidemment, il existe aussi dans notre processus de recrutement des critères obligatoires. Par exemple, Takima ne fera pas de proposition à un candidat ne maîtrisant pas les concepts objets ou n’ayant jamais pratiqué Java parce qu’une remise à niveau sur ces éléments représenterait un investissement en temps trop long à l’échelle d’une entreprise. Le candidat sera invité à se lancer personnellement dans cette approche, pour pouvoir se représenter plus tard quand il sera prêt.

Le recrutement technique, c'est aussi cela chez Takima : contribuer à ce que chacun soit en mesure de dépasser sa maîtrise technique actuelle.

Sources :
Image écran 3270 : Virtel https://virtel.readthedocs.io/
Image désert : Olivier Duvoid, 2015
image shadoks : https://shadoks.fandom.com/fr/wiki/Wiki_Shadoks