Comment repérer un mauvais développeur en quelques minutes

Plus de 13 ans que je suis dans le développement avec Aventique et que je recrute des développeurs, des centaines de développeurs recrutés, mais surtout des milliers de développeurs rencontrés. Le recrutement n’est pas une science exacte mais réduire le risque d’un mauvais recrutement reste l’objectif de tout recrutement.

Parfois, il n’y a pas si longtemps, j’ai dû en rencontrer une quarantaine de profils pour en pré-sélectionner 3 seulement.

Qu’on parle de développeurs backend, frontend, web, mobile, java, C#, javascript, on peut réussir à filtrer les développeurs moyens ou ceux qui n’ont pas le niveau sur un échange de quelques minutes.

Le process de recrutement que nous avons chez Aventique : 

• 1. Un 1er échange de 15 minutes environ pour filtrer.
  2. Un 2ème entretien plus avancé (live coding …).
  3. Entretien final.

C’est lors du 1er échange et au bout de quelques minutes que je sais que je ne recruterai pas le développeur que je rencontre.

Un bon développeur est quelqu’un qui maitrise les fondamentaux

Le métier de développeur est un métier intellectuel où l’abstraction joue un rôle important, les connaissances théoriques sont donc importantes.

Le 1er mauvais signal c’est quand le développeur me dit “je ne suis pas fort en théorie” mais que “tu peux compter sur moi lorsqu’il faudra coder”. Je suis convaincu qu’un bon développeur doit être à l’aise dans les 2 aspects et je n’ai pas envie de voir le code source de ce développeur qui ne maîtrise pas ou qui ne sait pas expliquer des points théoriques de base, surtout quand la complexité du projet s’accroît et que la dette technique devienne quasiment irrattrapable.

Je vais faire une analogie avec le médecin, quand il s’agit de t’expliquer le problème de santé pour lequel tu es venu le consulter et qu’il te dise : ”Je ne saurai pas t’expliquer ce que tu as exactement mais prend ce médicament, il va te guérir”. Et bien moi, ce médecin là, je ne lui ferai pas confiance et je consulterai un autre.

Le 2ème mauvais signal est lorsque j’entend, souvent de la part de profils ayant pas mal d’années d’expérience, “j’ai oublié ce point, avec l’expérience que j’ai, j’ai dépassé ce genre de questions et je suis focus aujourd’hui sur des sujets beaucoup plus complexes”.

Un médecin, pour reprendre son exemple et après 15 ans d’expérience saura toujours expliquer la différence entre un virus et une bactérie.

Pour vérifier les compétences théoriques de mon développeur, voici des questions, très basiques que je pose souvent et pour lesquels, de junior à sénior, j’ai encore des réponses approximatives qui démontrent l’incapacité du développeur à aller au fond des choses :

Git

Git, c’est l’outil de partage de code entre développeurs, c’est aussi l’outil qui permet d’historiser ses modifications de code source, notamment.

Différence entre un commit vs un push

Commit, action locale : ça enregistre tes modifications dans l’historique de ton dépôt en local (sur ton PC).
Push, action distante : ça envoie les commits locaux vers le dépôt distant (par ex. GitHub, GitLab).
Le but : partager ton travail avec les autres ou sauvegarder sur un serveur.

Et bien sur une question simple, j’ai souvent des réponses confuses, encore aujourd’hui ! Pour plus de détails sur Git.

Orienté objet

La majorité des développeurs ont fait de l’orienté objet durant leurs études ou maîtrisent au moins un langage orienté objet : Java, C#, Python, PHP…

L’orienté objet est un modèle de programmation où l’entité de base est un objet. Vous voulez développer une application pour la location des voitures, nous aurons besoin de créer des objets voitures, clients par exemple.

Qu’est-ce qu’un variable statique

Je vais prendre un objet que tout le monde connaît, l’humain et qui a des attributs propres à chaque instance (à chaque humain) comme la taille, le poids, la couleur de peau…

Et bien un attribut static est un attribut commun à tous les humains, l’attribut espèce dont la valeur est “homo sapiens” par exemple mais qui peut changer (par exemple, évolution en une autre espèce ou reclassification scientifique).

Beaucoup de développeurs répondent que static veut dire que la valeur ne change pas, que si on désignait le poids comme static, ça ne changerait pas et ne disent pas l’essentiel, un attribut static est un attribut qui peut changer, mais que, s’il changeait, il changerait pour toutes les instances d’humains (en gros pour tous les humains).

En gros, qu’il est un attribut de classe (type humain) et non un attribut d’instance (lié à un humain en particulier : Julien, Antoine…)

Javascript

Javascript est aujourd’hui le langage le plus utilisé. On l’utilise pour faire du backend avec Node ou Nest JS, du frontend avec React, Angular ou Vue.JS mais aussi du mobile iOS et Android avec React Native.

Qu’est-ce qu’un callback

Un callback (ou fonction de rappel) est simplement une fonction passée en argument à une autre fonction, et qui sera appelée plus tard, souvent quand une tâche est terminée ou qu’un événement se produit. C’est une fonction définie quelque part et appelée ailleurs, elle permet de rendre le code plus flexible et de découpler les traitements.
La notion de callback est très utilisée en programmation asynchrone (JavaScript, Python, etc.) pour gérer les opérations qui prennent du temps (lecture d’un fichier, appel réseau, clic utilisateur…).
Si ce n’est pas expliqué aussi clairement que ça. Il y a alerte car cette notion fait partie des bases.

Asynchrone ou synchrone

Synchrone : Les instructions s’exécutent une par une, dans l’ordre. Tant qu’une opération n’est pas terminée, la suivante attend. C’est comme faire la queue à la boulangerie : le client suivant attend que le précédent ait fini.
Asynchrone : Certaines instructions peuvent être mises en attente et s’exécuter plus tard, pendant que le programme continue. C’est très utile pour les opérations lentes : requêtes réseau, accès disque, temporisation… C’est comme commander une pizza : tu commandes (la requête part), tu fais autre chose, et quand c’est prêt, on t’appelle ce qu’on a expliqué juste avant, le callback/promise.

== vs ===

En javascript c’est simple, 1 “1” va donner VRAI alors que le 1er est un nombre et le 2ème est un texte bien que la valeur soit la même.
, ça compare donc uniquement la valeur et pas le type (ici entier vs chaine de caractères).

1 === “1” va donner en revanche FAUX puisque, même si les valeurs sont OK, les types ne sont pas les mêmes === compare donc la valeur + le type.

Qu’est-ce qu’une closure

Pas mal vont lacher ici et ne sauront pas expliquer ce concept.
Une closure (ou fermeture en français) est une fonction qui “se souvient” de l’environnement dans lequel elle a été créée, même quand elle est utilisée en dehors de cet environnement.

De façon plus détaillée, une closure est formée quand une fonction interne accède aux variables de la fonction externe qui l’a engendrée. Ces variables restent en mémoire tant que la closure existe. C’est très utile pour encapsuler des données, créer des fonctions personnalisées ou simuler des variables privées.

Design patterns

Le design pattern est une notion commune à tous les langages de programmation, un bon programmeur doit savoir ce que c’est et en connaître quelques uns.

Qu’est-ce qu’un design pattern et cite moi quelques uns

Un design pattern existe pour apporter la meilleure solution à un problème récurrent. Ce n’est pas du code prêt à l’emploi, mais une structure ou une approche qui aide à résoudre un problème de conception rencontré dans le développement de logiciels de manière élégante et éprouvée. Cette définition “meilleure solution à un problème récurrent”, beaucoup ne sauront pas y répondre.

Quand un développeur n’est capable d’en citer aucun, il n’est tout simplement pas prêt. Le design pattern révèle une appétence du développeur pour les abstractions nécessaires qui feront qu’il produira un code de qualité plus tard.
Parmi les plus connus, je vais citer Observer, Stratégie, Singleton…
La liste exaustive et dans la bonne catégorie sur ce lien

Un bon développeur est quelqu’un qui a les soft skills obligatoires

Les soft skills, on en entend souvent parler, je vais citer des exemples concrets de développeurs que j’ai rencontré ou recruté et où l’absence de soft skills rend l’expérience de collaboration très difficile.

Les soft skills sont importants parce que pour se projetter et me dire : “OK, je me vois travailler avec lui de façon fluide”, j’ai besoin de voir un certain nombre de qualités :

L’écoute active

Dans une époque ou le remote s’est généralisé, une personne qui sait écouter, en étant bien présent fera toute la différence avec une personne qui donne l’impression de ne pas être là, ou de ne pas avoir compris alors que tout est clair pour lui. La bonne collaboration entre collègues en dépend fortement.

Rassurer et envoyer le signal qu’on peut compter sur soi

a capacité de rassurer, de sortir de soi et d’être focus sur les besoins de la personne en face, c’est indéniablement une qualité très importante.

L’exigeance

Un développeur à qui on doit tout dire va vite épuiser l’équipe. Être capable de savoir ce qu’est réellement important et avoir un niveau d’exigeance élevé va soulager l’équipe dans la résolution des problèmes rencontrés lors de son recrutement.

Savoir se situer

Que le développeur ne soit pas parfait, nul n’est parfait. Un signe d’intelligence est de savoir se situer. Le pire serait d’avoir des réponses fausses à des questions techniques et de croire qu’on est bon. Et je le vois fréquement.

L’énergie

L’énergie que dégage un développeur est un critère essentiel, c’est avec cette énergie qu’il peut rassurer sur sa productivité, qui fera qu’il communiquera sur un blocage qu’il rencontre, qu’il fera tous les efforts pour résoudre un bug difficile, qu’il donnera le complément d’information sur un sujet technique difficile. Bref, c’est cette energie qui fera qu’il prendra bien sa place et que personne d’autre ne sera obligé de compenser.

Comprendre le business

Cette faculté est réservée aux meilleurs et ceux qui ont un peu de séniorité mais une personne qui s’intéresse au besoin réel des utilisateurs, au problème que l’application doit résoudre sera capable de challenger les besoins et de proposer les meilleurs solutions en prenant en compte les bons paramètres, de ne pas y aller tête baissée et de ne pas perdre de temps sur des problématiques qui n’ont aucune importance au final.

Conclusion

Vous avez des exemples de questions pour échanger avec un développeur et savoir évaluer le niveau de la personne que vous rencontrez.
A la fin, si vous n’êtes pas outilés pour le management d’un développeur, collaborer avec une agence web ou une agence mobile peut être pertinent surtout si vous disposez d’un cahier des charges. Voir comment rédiger un cahier des charges.
Le modèle d’externaliser le recrutement et de disposer de la compétence en fonction de ses besoins (full time ou part time) est aussi une très bonne option selon vos besoins.
En complément, pour vos recrutements, voici également quelques informations utiles sur les coûts des développeurs.