Kotlin chez Mediatech-cx ?
Quel rapport peut-il y avoir entre le QCM Kotlin de WeLoveDevs, la société Mediatech-cx et le langage de Jetbrains ?
Le rapport c’est la collaboration entre 2 sociétés qui aiment les développeurs.
Le recrutement de profils techniques est vraiment une tâche compliquée. Personnellement je trouve que cela prend énormément de temps. La selection est ardue même sur mon coeur de métier : le code.
Si WeLoveDevs existe à mon avis, je ne suis pas le seul à trouver le recrutement de développeurs difficile. Il y a environ 2 ans nous avons naturellement exploré l’approche proposée par WeLoveDevs pour nous aider à mieux recruter.
Fort de cette relation, Vincent Cotro me contacte en Septembre dernier pour tester en avant première les QCMs qu’ils intègrent à leur plateforme. J’accepte d’emblée parce que cela touche une problématique importante de mon métier de CTO. Vincent ne me demande pas trop de temps. Aussi, j’apprécie cette démarche de co-construction avec les clients et les gens de chez WeLoveDevs sont sympas 🙂
Pourtant je ne suis pas un grand fan de QCMs. Et je n’écris pas cela parce que j’ai fais un score moyen au test Java. Je me focalise pourtant sur la promesse de gain de temps dans le process de recrutement. C’est un enjeu fort pour recruter des devs. La réactivité, c’est un critère de sélection des candidats qui ont plusieurs propositions (c’est même un KPI chez Indeed par exemple). Cela nous permet d’évaluer plus de candidats. Mais aussi d’éviter de passer à côté de la perle rare à cause d’un process trop long ou trop compliqué. C’est une démarche gagnant-gagnant.
Mediatech-cx vous faîtes quoi ?
Chez Mediatech-cx nous développons une plateforme Saas de mesure et suivi de la satisfaction client, lancée en 2010 et développée en Java/Java EE.
Pour autant, j’essaye d’encourager mes collègues à s’intéresser aux autres langages, aux autres écosystèmes.
Quand nous avons débuté le développement de notre plateforme Saas, on ne parlait pas encore de Node, React/Angular/VueJS n’existaient pas, Spring n’avait pas de « boot », pas de Rust, Go était encore marginal…
Le paysage du dev informatique a bien changé en 10 ans ! Et il est impossible de suivre toutes les actualités.
Pourtant, aller voir ce qui se passe à côté permet de challenger nos connaissances et de remettre en cause nos pratiques.
Pour moi par exemple :
– le serveur Node me démontre qu’il n’y a pas que le multi-thread pour faire un serveur qui peut traiter des requêtes en concurrence. L' »event-driven programming » et l’Actor Model ont des cas d’utilisation bien identifiés aujourd’hui. Quelque soit votre langage de prédilection vous trouverez votre librairie « event machine » à la Node.
– La montée en popularité de la programmation fonctionnelle ces dernières années (grâce au javascript à mon avis) me pose des questions intéressantes sur les principes de conception d’un programme : est-ce que la mutabilité est une bonne chose ? Est-ce que je gère au mieux les effets de bord dans mes fonctions ? … Encore une fois, quelque soit le langage du quotidien, vous devriez vous poser ce genre de questions et regarder comment sont adressés ces concepts ailleurs.
– Le langage Rust n’a pas de notion de NULL !? Le langage ne plante t-il donc jamais sur des pointeurs qui ne pointent pas sur une zone mémoire ? Pour un développeur Java je peux vous dire que c’est révolutionnaire. Comment sont donc gérés les traitement qui renvoient parfois une valeur et parfois rien ? Rust n’a pas inventé les valeurs optionnelles mais si vous jouez avec ce langage vous êtes obligés de les appréhender et les manipuler. Et cela impactera nécessairement votre façon de coder en Java/C#/…
– ES6 introduit les Promises en Javascript !? Vous ne serez pas perdus si vous manipulez des Future<T> et CompletableFuture<T> en Java.
J’arrête ici les exemples, car il y en aurait des centaines.
Retenez simplement que la profession aime bien recycler ou réintroduire des concepts parfois vieux comme l’histoire de l’informatique. Ne vous intéressez donc pas à un langage, un framework ou une API… Ce savoir sera obsolète dans 2 ans. Intéressez vous aux concepts de la programmation et renforcez sans cesse vos connaissances de ces concepts.
Autre certitude, je ne vais pas changer la stack technique de notre plateforme à chaque fois qu’une technologie émerge. Nous passerions notre temps à refaire ce que nous avons déjà fait !
C’est le paradoxe du CTO : rester pragmatique et gérer la frustration des collègues passionné.e.s. Et oui, le Java (dans notre cas) est une grosse machine avec un historique et une communauté énorme (pour ne pas dire inégalée). Par conséquent, le langage ne se bouge pas comme ça. Rester en veille sur tous les concepts informatiques permet avant tout de rester à l’aise lorsqu’ils sont finalement introduit en Java. Et si son évolution est jugée trop lente par le marché ? Comment intéresser les candidat.e.s qui sont tenté.e.s de tourner le dos à Java ?
Parce que Java n’est pas encore mort chez Mediatech-cx.
Pourquoi Kotlin ?
Sous le capot de Java en revanche, la JVM (le runtime qui fait tourner Java) est loin d’être figée. Des langages comme Groovy ou Scala démontrent que l’on peut mettre en oeuvre une foultitude de concepts de la théorie des langages dans un compilateur qui produit du bytecode. Il y a donc une richesse incroyable à aller piocher dans les « JVM players ». Mais surtout aussi l’espoir d’une compatibilité avec notre bon vieux « legacy code ».
La concurrence entre les langages de la JVM est féroce avec ses initiatives aux destins tragiques, ceux qui s’accrochent … et ceux qui trouvent la bonne recette. Je pense donc qu’il faut piocher chez les autres mais dans un seul but : améliorer la qualité du code et l’architecture de notre plateforme. « L’éclate » et le « dogme », il vaut mieux les réserver pour les « side projects ».
Dans cette quête de qualité, il nous est apparu que le langage Kotlin validait pas mal de cases a priori :
– très bonne compatibilité avec du code Java existant,
– très bon support dans IntelliJ IDEA, notre IDE de prédilection. En même temps il y a le même éditeur derrière,
– apporte des concepts de programmation absents du Java avec un accessibilité correcte pour le développeur moyen.
L’an dernier nous démarrions le développement d’un nouveau service pour notre plateforme et avions besoin d’une API Rest. C’était le moment de tester Kotlin sur un projet de la vraie vie. Une équipe de développeur Java, une stack Payara 5/ PostgreSQL, une intégration continue Maven/Jenkins/Sonar, un process de livraison de code en place depuis plusieurs années.
Le résultat est au rendez-vous : nous avons donc du Kotlin dans notre base de code. Et nous le maintenons avec nos outils traditionnels. Un projet Maven qui tire des dépendances internes (écrites en Java) ou de l’ecosysteme, un déploiement sur notre serveur d’application préféré. Cette Mediatech-compatibilité fait que l’introduction de Kotlin a induit peu de changements dans le quotidien de notre équipe qui n’a pas été trop perturbée à mon avis.
Je dirais donc que le Kotlin s’adapte au sein d’une équipe de développeurs Java EE avec un niveau de stress minimal.
Kotlin Champions ?
Si vous m’avez bien lu jusqu’ici, vous pourriez vous demander : où est la cohérence de prôner la veille sur les concepts généraux de la programmation et un QCM ultra-spécifique au Kotlin ? Vous auriez raison.
Demain, je pourrai très bien préférer embaucher le/la « PHP Champion » au « Kotlin Champion » même si la personne n’a fait que peu de Java et jamais compilé de Kotlin.
Lorsque Vincent m’a contacté pour me parler des QCMs WeLoveDevs, j’ai néanmoins pensé au Kotlin.
Et j’y ai vu 2 intérêts à court terme :
– une occasion de proposer un exercice qui sort de la routine à Fred, notre Lead Dev en pointe sur Kotlin.
– remettre un focus sur un autre langage que le Java dans mon équipe. Elle a en effet été la première à découvrir le QCM et à faire les feedbacks dessus.
Aujourd’hui je ne suis pas encore convaincu par les tests techniques en QCMs. 20 minutes pour évaluer si un.e candidat.e maîtrise un langage aussi riche que Kotlin me semble absurde, dans un process de recrutement. En tout cas cela ne doit pas être un critère fort de sélection.
Je vois plus l’utilisation de ces QCMs sur des outils qui ont un spectre fonctionnel plus limité (Git par exemple) ou pour tester les connaissances dans une démarche de formation d’une équipe en place (sans le couperet de la proposition d’embauche).
Peut-être y a t-il ici un deuxième marché pour les QCMs WeLoveDevs ?
Dans tous les cas, comme pour la veille techno qui remet constamment en cause mes pratiques de développeur, cette expérience avec WeLoveDevs remet en cause mes pratiques de recruteur. Et c’est forcément une bonne chose !
