http://fr.fotolia.com/id/22301074 Fotolia.com
Etes-vous un expert ou un développeur sénior ? Quelle définition donnez-vous au mot « consultant sénior » ? La définition et la qualification d’un profil représente un gros travail. C’est un sujet tellement vaste, que je me suis dis : il faut que j’en parle avec eux. Bref me voilà de retour pour bloguer sur ce sujet…
Pour améliorer la mise en relation entre les candidats et les recruteurs, l’eXpress-board doit proposer de nouveaux outils pour les recruteurs. En discutant avec les équipes RH ou les experts du recrutement, il manque encore des outils pour faire gagner du temps. Avant de lancer ce chantier, voici où j’en suis : j’ai un modèle assez simple, j’ai travaillé avec la base actuelle des profils qui représente environ 440 candidats, et j’en ai parlé un peu autour de moi.
Mais le plus gros du travail est à faire là, maintenant. Cette article vous intéressera si vous cherchez à comprendre ce que l’on appelle un « bon développeur ». Côté RH vous découvrirez de nouveaux outils, pourquoi pas une vision du recrutement différente et complémentaire de votre approche actuelle.
Un « bon » développeur ?
Un développeur avant tout, c’est un bon technicien. Capable de mettre en œuvre des techniques de programmation, il sait comprendre un problème et implémenter une solution. Il a donc un capital de connaissances techniques acquis lors de ses études puis au fil des années. Si la formation de base est importante, il s’avère que la veille technologique l’est tout autant. L’effort ne doit pas venir que de l’employeur, il est aussi important que le développeur continue à se former sur ses heures de travail.
La majorité des projets informatique sont développés en équipe. Être un bon développeur, c’est aussi être une personne avec laquelle nous aurons envie de travailler 8h par jour. Discipline, capacité à communiquer ou à écouter l’autre, tout devient important lorsqu’il s’agit de travailler à plusieurs. Si en plus, vous êtes un chic type qui sait rigoler, bienvenue dans l’équipe.
Un autre facteur important : la motivation/l’énergie. Il y a celui qui attend à peine la fin de la réunion pour commencer à coder. Et il y a l’autre qui ne sera pas très proactif, qui demandera plus d’aide et d’accompagnement en tant que manager. Tout est affaire de motivation, d’envie et d’intérêt. Le cadre dans lequel se déroule le projet a une influence assez forte sur notre énergie. C’est donc un critère environnemental en quelques sortes.
Il y a aussi des moments magiques. Un matin, vous pouvez coder en 15 minutes ce que vous n’avez pas réussi à faire en une journée la veille. Un développeur motivé peut être 10 fois plus productif que lui-même. Il y a clairement aucun rapport entre le salaire payé chaque mois à un développeur et sa productivité/motivation.
A salaire égal, certains développeurs sont simplement 5 à 20 fois meilleur que d’autres :
A poor programmer in a company could consume 5 to 20 times more in time, effort and equipment resources than a good one [3]
En tant que recruteur, c’est là que vous devez identifier la bonne personne. C’est cette personne là que vous devez recruter et motiver. Pas son voisin, qui à formation équivalente, n’a pas ce petit plus, qui va radicalement changer votre projet.
Bref un développeur n’est pas une simple fonction, ni un rôle. C’est plutôt une composition de plusieurs facteurs. Il a une part d’inné et une part d’acquis. Il faut d’abord comprendre le profil de la personne, puis ensuite comprendre ce qu’elle a acquis.
Or le recrutement aujourd’hui ne sait travailler que sur un catalogue produit. Chaque développeur est étiqueté « Ingénieur(h/f) Java J2EE » pour être placé dans le rayon charcuterie, à côté de la barquette de viande certifiée Bio.
Je crois sincèrement qu’il faut proposer de nouveaux outils et un modèle complémentaire à l’approche classique pour trouver les candidats. Les mauvais ne passeront pas les mailles du filet. Les bons seront enfin reconnus et payés à un niveau normal. Les recruteurs arrêteront de nous traiter comme de la viande lorsque nous serons en mesure de montrer notre motivation, notre savoir-être et notre niveau technique avec des critères facilement mesurables (nous verrons cela dans « la reconnaissance des pairs » plus loin).
Les différentes caractéristiques d’un bon développeur
Un bon nombre d’articles ont été publié depuis le début des années 80. La recherche de bons développeurs n’est pas un sujet si récent. Les Universitaires y travaillent depuis un certain nombre d’années. Que ce soit en psychologie du travail ou dans la médecine du travail, il y a des travaux sur ce sujet.
Les bases du modèle
A partir du modèle des frères Dreyfus, essayons d’expliquer la différence entre un Novice et un Expert. Je n’ai pas inventé ce qui suit ci-dessous, je l’adapte d’un article publié en Anglais [1] ainsi que du modèle d’acquisition des compétences de Hubert L. Dreyfus ([2]). Emmanuel Hugonnet (de l’Alpes JUG) a aussi publié un très bon papier sur le modèle d’acquisition des compétences de Dreyfus.
Commençons par expliquer le modèle de H. et S.Dreyfus.
Evaluer votre niveau par compétence
En 1986, Hubert L.Dreyfus et son frère Stuart, proposent un modèle d’acquisition de compétences techniques en s’inspirant de l’enseignement du pilotage dans l’armée de l’air (voir aussi [3]).
Ce modèle est intéressant car il permet de se situer dans notre courbe d’apprentissage d’une compétence. D’autre part, elle permet de comprendre pourquoi dans certaines situations, un expert va refuser de faire ce que vous lui demandez. L’acquisition d’une compétence s’effectue tout d’abord par la mise en place de règles. Lorsque le niveau technique d’une équipe est globalement « Novice », il faut définir des règles très précises, voire même des socles techniques, afin de s’assurer que la base de départ est saine. Si l’équipe est plus « Expert », elle sera alors autonome et à même de prendre des décisions techniques, sans risque pour votre projet. Comprendre la composition d’une équipe est donc vital pour un manager. Quand on parle de « chef de projet » au lieu de parler de « chef d’équipe« , on mesure déjà à quel point nous en sommes loin… bref passons. Je garde cela pour plus tard.
Le modèle décrit 5 niveaux d’acquisition d’une compétence. Prenez l’apprentissage de la conduite, de la guitare ou du dernier framework Java à la mode et voyons votre niveau :
1. Je suis Novice
– je suis strictement les règles et le plan
– je n’ai pas de jugement critique
– je ne connais rien à la technique étudiée, j’apprends par des jeux d’essai et d’erreur
– j’apprends par recopie d’un modèle ou d’exemples
– je peux effectuer des tâches simples
2. Je suis Junior
– je ne comprends pas encore tout le cadre dans lequel je développe
– j’applique les règles que l’on m’a montré, si cela ne marche pas c’est la règle qui n’est pas bonne
– je sais trouver de l’aide et de la documentation
– je ne distingue pas encore l’importance et j’ai du mal à gérer les priorités
– je commence à apprendre tout seul une technologie
3. Compétent
– je connais maintenant plusieurs solutions à un problème et je sais faire un choix
– je comprends les règles
– je prends des initiatives et j’essaye de nouvelles pistes, je suis conscient de mes choix
– je suis autonome pour trouver de l’aide, même si je ne suis pas encore très efficace
– je dois être concentré sur chacune de mes tâches
– face à une situation inattendue, j’essaye d’appliquer les règles enseignées
4. L’Efficace
– je deviens intuitif, je n’ai pas besoin de réfléchir pour gérer une situation banale (créer une Classe, passer une vitesse en conduisant, lancer mon serveur Tomcat)
– j’analyse une situation rapidement mais j’ai conscience de ma prise de décision
– je sais faire la distinction entre une règle (« je dois tout tester ») et le contexte de son application (« … mais les getters/setters, non ») car j’ai maintenant assez d’expérience
5. L’Expert
– je suis complètement intuitif
– je ne pense pas à une solution, elle vient naturellement
– je peux « sentir » une situation et reconnaître des choses déjà vues, pour m’adapter
– je gère les cas exceptionnels très rapidement et très efficacement, car c’est ce que je recherche
– je ne suis pas toujours en mesure d’expliquer ce que je fais, même si je sais « que c’est bien »
– je pense au but et à ce que je dois faire, j’envisage plusieurs solutions, je peux me lancer et changer d’avis, mais je réussirai au final.
– j’ai une vision globale sur un nouveau problème, je suis capable d’expliquer et de justifier mes choix
Voici donc un premier outil : une échelle qui permet de mesurer soit une compétence particulière, soit votre niveau actuel d’expérience.
Le modèle D.Girard du développeur
Rendons à César ce qui est à César, Didier Girard (CTO de SFEIR) extrapole ce modèle et le projette sur le parcours professionnel type d’un informaticien. Il inclus dans sa vision une composante « consultant » et « directeur », je vais donc l’adapter un peu et simplement parler du niveau d’acquisition des connaissances d’un développeur lambda, avec quelques courbes d’expérience pour illustrer l’idée.
Premier message pour les étudiants en informatique : une fois diplômé, vous êtes Novices. Lorsqu’ensuite on parle d’apprentissage et de compagnonnage dans l’informatique, ce qui va suivre prend tout son sens.
Si nous définissons tout d’abord 5 niveaux, avec en abscisse le nombre d’années d’expérience, voici une première courbe.
- Le novice : débutant par excellence qui a besoin d’être encadré.
- Le junior : correspond au modèle de Dreyfus
- Le sénior : correspond au niveau Compétent
- L’expert : correspond à l’Efficace, la personne autonome à même de prendre des décisions
- L’influenceur : Expert, qui a par ailleurs une influence au delà de son équipe, sur la communauté ou au sein de son entreprise. Pour moi, c’est un Antonio Goncalves, un David Gageot ou un Guillaume Bort.
Tout d’abord, je pense plutôt que la grande majorité d’entre nous a un parcours classique, où nous devenons Sénior ou Expert. La différence entre un Sénior et un Expert ? Le deuxième a dépassé ce qu’on lui demande de faire, et il devient référent sur une ou plusieurs techniques. Il fait la différence avec un Sénior en étant à même de présenter une technologie ou une pratique (Scrum) devant les autres. C’est celui que l’on vient voir pour demander de l’aide.
La majorité d’entre nous est Sénior, ce qui est très bien :
Il y a aussi l’exemple de la personne qui est « Expert » pendant un certain temps, le temps que la technologie soit à la mode. Ensuite il redevient « Senior »
L’influenceur est un cas à part. C’est un développeur qui a dépassé le niveau actuel des connaissances et qui propose de nouvelles approches techniques. Par exemple Guillaume Bort l’auteur de Play! Framework, Emmanuel Bernard avec Hibernate ou David Gageot avec son expérience des tests. Ce sont les « marketmakers« , les personnes qui créent les technologies ou les pratiques que nous utiliserons demain :
En conclusion, nous avons défini les mots « Novice/Junior/Sénior/Expert/Influenceur ». Voyons maintenant comment nous en servir.
Une fiche personnage
Vous voyez les fiches personnages dans les jeux de rôle ? Il suffit de voir comment les jeux finalement vous classent et vous permettent ensuite d’évoluer dans un monde virtuel. Pourquoi ne pas imaginer des « classes » de développeurs ? Puis ensuite, selon l’expérience, des fiches types ? Pourquoi ne pas imaginer la fiche de Matt Raible ou de Guillaume Laforge ?
Au lieu de penser notre CV par titre, nous pouvons penser par domaine fonctionnel. Il existe tout d’abord différentes catégories de développeur. Pour nous aider à s’identifier, l’idée est de prendre aussi des personnes de la communauté Java et de vous montrer où elles se situent. Si je peux faire par exemple la fiche eXpress-Board d’Antonio, cela vous donnera une idée de son profil et de ses compétences.
Les différents profils
Essayons d’abord de créer quelques profils types. Pour cela, je me base sur les profils actuellement enregistrés sur l’eXpress-Board.
Voici ce que j’ai trouvé :
– Développeur
– Testeurs
– Exploitant système et production
– Responsable Outils de développement, gestionnaire de configuration et de builds
– Support technique
– Avant-vente/Evangélisation
– Chef d’équipe technique
– Formateur
– Architecte
Ensuite, sur l’expérience de chacun, nous sommes tous différents. Je pense qu’un moyen de se qualifier serait de lister les compétences requises par catégorie. Un Testeur doit être curieux et rigoureux. Un Chef d’équipe technique doit avoir de l’empathie, avoir des capacités à prévoir et à gérer une équipe. Une personne avant-vente doit avoir une culture de l’entreprise pour comprendre les problèmes du client.
Cela ressemble finalement à la création d’un jeu, où nous serions les premiers rôles, et où chaque fiche serait la représentation exacte de votre niveau de développeur.
La reconnaissance des pairs
Après avoir défini ce que nous appelons un Novice ou un Expert, il est intéressant de revenir à la création d’un outil d’évaluation objectif et impartial de chaque développeur. Or le moyen le plus simple que je vois aujourd’hui, c’est de mesurer l’activité de développeur open-source.
Si nous pouvons reconnaître l’expertise et le travail d’un développeur, en mesurant par exemple son activité sur un projet open-source, je pense que cela peut permettre de valoriser et mettre en avant ce que l’on appelle simplement « un bon développeur ». Le recruteur pourra identifier la personne rare, et le développeur pourra être reconnu sur son investissement subjectif et sur le travail réellement accompli.
Je ne vois pas comment reconnaître facilement le travail réalisé en entreprise pour un site comme l’eXpress-Board, alors qu’il s’agit de la majorité de ce ce que nous faisons. Il existe des sites où vous pouvez classer chaque personne afin de juger « celui qui est le meilleur » (ou la meilleure).
Plus intéressant, aux Etats-Unis de plus en plus de services permettent de vous donner rapidement une mesure et un profil détaillé pour un développeur. MasterBranch avec qui je travaille offre un système qui permet de vous donner votre niveau d’implication en tant que développeur OpenSource.
Bien entendu, il faut que le développeur soit inscrit sur ce service, et donc qu’il soit dans une démarche où il souhaite trouver un nouveau job. Avant de criez au loup, pensez comme nos amis américains : vous êtes un produit qui doit se vendre à un prix. En vous inscrivant sur ce service, vous améliorez votre visibilité volontairement et vous expliquez ce que vous faites.
Regardez pour terminer différents essais, essentiellement construit à partir de mes projets GitHub:
- Profil sur Coderwall
- Mon Resume sur GitHub
- Les sujets sur lesquels j’interviens sur Quora
- Mon profil MasterBranch
- Mon profil sur Ohloh
- Mon cercle d’influence sur Klout se base sur mon activité sur Twitter (@nmartignole)
Conclusion
Nous avons expliqué les différences de niveau et d’expertise en se basant sur le modèle de Dreyfus. Puis si l’idée de définir une fiche type comme dans un jeu de rôle est intéressant, il est compliqué de remonter l’expertise d’un développeur en entreprise. La voie de l’open-source permet d’identifier 5% de la communauté des développeurs en France, ce qui reste marginal. Elle doit permettre cependant de mettre en avant les personnes actives et reconnues dans la communauté.
Pourrait-on imaginer un outil d’analyse de la qualité du développeur basé uniquement sur le code écrit ? Je ne pense pas. Un bon développeur c’est aussi quelqu’un de connecté, à même de trouver d’autres développeurs pour votre entreprise. C’est peut-être aussi une personne qui s’investit dans des projets associatifs ou dans le développement open-source. C’est peut-être aussi une personne avec un savoir-être et des capacités de communications pour l’entreprise, parfait pour le consultant… Bref retenez que mesurer le code écrit n’est pas suffisant pour qualifier quelqu’un de « bon développeur ». Il est intéressant aussi d’avoir l’avis aussi de ses anciens collègues, de sa capacité à travailler en équipe, chose que l’on trouve sur LinkedIn via les recommandations.
Le recrutement s’attache surtout à valider les acquis d’une personne, ce qu’elle sait. Or ce qu’il faut aussi chercher, pour un informaticien, c’est la capacité à se tenir au courant, à apprendre de nouveaux langages et de nouvelles techniques. Pourquoi s’attarder sur le CV ? Cela ne devrait prendre que 20% de votre entretien je pense. Demandez ce que la personne souhaite faire. Demandez-lui de vous expliquer un bout de code, ou de vous présenter un outil ou une technique de développement…. Essayons de dépasser l’IED Bac+5 qui me fait tant rire. Pour ceux qui ne sont pas R.H, IED veut dire « Ingénieur Etude et Developpement ». Comme « Findus » veut dire « poisson surgelé » en quelque sorte.
Ce que je retiens en ayant travaillé sur cet article plusieurs mois, c’est qu’il y a de plus en plus de services essayant de mesurer notre activité open-source. Les premières lignes de ce long billet datent de mars 2011.
Et vous, quel type de développeur êtes-vous finalement ?
Références
[1] 3 dimensions of a Software programmer, how to get things done
[2] le modèle de Dreyfus Dreyfus, modèle d’acquisition
[3] « A poor programmer in a company could consume 5 to 20 times more in time, effort and equipment resources than a good one« , Laughery R and Laughery K « Human Factors in Software Engineering: A review of the litterature » Journal of Systems and Software, 5, 1985, p3-14
[4] Reconnaissance, étude de l’Université de Laval
0 no like
Thématique intéressante, bravo ! Petite précision, il me semble que Masterbranch est plutôt développé en Espagne, non ? En tout cas c’est l’impression que j’en avais eu.
Ces échelles sont intéressantes, mais probablement trop linéaires, et à une seule dimension. Comme tu l’as dit on peut être expert sur un domaine, et novice sur un autre. On peut avoir des compétences en management, en fire fighting, en open source, en écriture d’articles de blog…
Trop souvent, les CV se résument à une liste de mots clés. Votre CV en ligne ( ou votre CV de consultant de SSII) comporte toutes un tas de noms de technos sans autre appréciation : « Java, C++, Netbeans, Struts, JSP, SoapUI »… Y compris si vous avez fait du C++ pendant 2h en école d’ingé et plus rien depuis. En fait, la je décris un peu le CV du junior, qui a un peu peur du vide et fait du remplissage.
Une version améliorée consiste à mettre ces mots clés associés à une note (X étoiles sur 5, ou « expert » / « utilisé » / « joué avec »). Mais on est assez vite débordé.
Ce qui m’amène à penser que des graphes radar (en toile d’araignée) serait probablement plus adaptés. En regroupant des ensembles de technos par couleur. Ainsi, vous auriez une portion de la toile d’araignée liée au JEE (Java, Spring, Hibernate, etc), une autre à Android (frameworks, UI, tablettes, fragments), une autre aux méthodes agile (Scrum, Kanban, …) Ce qui permet d’établir une cartographie de vos compétences, et de donner rapidement une idée de votre profil.
Une autre idée intéressante est de partir sur le principe des « tests de l’été » => établir des profils, et en fonction de vos réponses, vous positionner dans un profil. Attention cependant, il faut éviter les classements type « vous êtes un faignant / vous êtes bon / vous êtes un superhéro ».
Par ex, un influenceur, ce n’est pas forcément le top de ce dont une équipe a besoin. Il passe nécessairement du temps à faire autre chose que « faire avancer le projet », et c’est normal.
L’idéal serait ensuite de résumer ça pour donner une note sur plusieurs grands axes, et pouvoir ensuite identifier rapidement les profils.
On a envie de paraître bon partout, mais à un moment il faut connaître ses limites. Par ex :
– Je n’ai que très peu d’XP en management, et ça ne m’intéresse pas pour le moment
– Je suis très bon pour répondre à un challenge rapidement, mais je ne suis pas forcément autonome dans la durée (=> donnez moi plein de challenges, souvent)
– Si c’est pas marrant, jme fais chier, si jme fais chier, jme casse.
– La veille que j’effectue me permet de parler avec assurance de pas mal de technos, mais mon jugement peut-être superficiel : ne vous lancez pas sur mes bons conseils sans avoir effectué un minimum de tests de votre côté.
Je sais, ça peut faire peur comme ça, mais il me paraît évident qu’être honnête est la meilleur des choses à faire. Mettre en avant vos limites permettra ensuite de faire ressortir vos points forts.
La notion d’influenceur m’a bien fait rire… Il n’y a pas que des experts dans les « influenceurs », loin de là AMHA.
Bien qu’une telle caractéristique soit intéressante pour une boîte de service (vendant son bonhomme, donc plus il est connu plus il est bien vendu), elle n’a au final que peu de lien avec les compétences. Il s’agit beaucoup d’être partant pour moultes conférences et de ne pas économiser sa salive.
Quand on regarde le nombre de concepts/frameworks étant ou ayant été à la mode et leurs qualités intrinsèques, on peut douter même d’un certain nombre « d’influenceurs », du moins techniquement…
Bref, perso, je la mettrai à part.
++
Un thème chouette, effectivement, et bien traité dans l’article!
Pour partager mon expérience sur le sujet: j’ai récemment été « PetitChef », avec une équipe à recruter, former, animer et faire grandir. Je pense qu’une idée intéressante à exploiter, lors du recrutement, est la vérification active de compétences, au delà d’une lecture passive des CV et des tests classiques qui peuvent être mis en place par les RH:
– une vérification « légère », à travers des questions sur les technologies et techniques de programmation,
– une vérification « moyenne », à travers des « interview questions », sortes d’exercices à résoudre pendant la session (on apprécie à la fois le résultat obtenu par le candidat, et sa démarche de réflexion / analyse / résolution),
– une vérification « lourde », avec un exercice de programmation à résoudre à la maison, en quelques jours, et à renvoyer par email.
A titre d’illustration:
– vérification « légère »: qu’est-ce qu’une classe? Le polymorphisme? Un Composite ou un Décorateur? Un objet de première classe ou un contexte lexical? Une architecture multi-couches? Le principe d’inversion de contrôle?
– vérification « moyenne »: problème d’algorithme (ex. problème des pirates), analyse de code par le candidat,
– vérification « lourde »: import d’un fichier plat dans une base de données, avec structure de base imposée ou non, technologie imposée ou non. Cela paraît simple, mais on est souvent surpris (généralement déçu) des résultats.
Bien entendu, il reste toujours la période d’essai pour que tant le programmeur que son employeur valident que la relation fonctionne bien. Mais un recrutement coûte cher (en temps, en argent), d’autant que l’on va former la personne recrutée… donc autant maximiser les chances dès le départ.
Je rejoins également M.Piwaï sur la nécessité absolue de l’honnêteté lors du recrutement: si le candidat ou le recruteur cache des choses, l’adéquation sera maladroite et incomplète, et ni l’un ni l’autre ne seront vraiment heureux de travailler ensemble.
Bonne journée à tous 🙂
« Avant de criez au loup, pensez comme nos amis américains : vous êtes un produit qui doit se vendre à un prix. »
Ça semble en contradiction avec :
« Or le recrutement aujourd’hui ne sait travailler que sur un catalogue produit. Chaque développeur est étiqueté « Ingénieur(h/f) Java J2EE » pour être placé dans le rayon charcuterie, à côté de la barquette de viande certifiée Bio. »
Il ne faut pas oublier qu’avant d’être des produits, nous sommes des êtres humains.
La culture américaine où tout peut et doit se vendre ne me fait pas rêver une demie seconde (ils ne sont peut-être pas dans une situation aussi catastophique aujourd’hui pour rien)
Ecrire salaire et motivation au sein d’une même phrase est toujours quelque chose de risqué.
« Il y a clairement aucun rapport entre le salaire payé chaque mois à un développeur et sa productivité/motivation. »
Comment expliquer alors que mes collègues n’ayant pas eu d’augmentation ont vu leur motivation toucher complètement le fond? Et comment expliquer que nos collègues les plus brillants / expérmimentés, devant des salaires pas si bas, mais pas mirobolants, aient posé leur démission et ne soient déjà plus là?
Ne pas donner un bon salaire à ceux qui le méritent les démotive. En revanche, je suis d’accord que donner un gros salaire à des gens démotivés ne les motivera pas nécessairement. Il ne s’agit pas là d’une relation bijective.
« Les recruteurs arrêteront de nous traiter comme de la viande lorsque nous serons en mesure de montrer notre motivation […] »
La motivation est une variable, pas une constante. Je vois difficilement un outil capable de mesurer ma motivation « moyenne » quand à mon métier… Ma motivation a des hauts et des bas, en fonction du projet, du client, de l’ambiance entre collègues, de l’ambiance avec la hiérarchie, des tâches à accomplir, etc…
« Si nous pouvons reconnaître l’expertise et le travail d’un développeur, en mesurant par exemple son activité sur un projet open-source, je pense que cela peut permettre de valoriser et mettre en avant ce que l’on appelle simplement « un bon développeur ». »
Tous les bons développeurs ne font pas tous de l’open source ni au travail, ni pour leur plaisir à la maison. Certains ont des projets info perso et privés à la maison; d’autres préfèrent aller faire du ski ou visiter la famille / les amis. Se baser sur un indice comme le niveau d’activité sur du dev open source, *peut* aider à comparer entre profils de gens qui font du dev open source; certainement pas entre gens qui en font et ceux qui n’en font pas; de fait, dans ce dernier cas, la valorisation est caduque.
Formaliser davantage les fiches des candidats au travers de nouveaux outils additionnels, c’est aussi paradoxalement apporter un peu plus de rigidité et de restriction quand à l’expression de la candidature. C’est amener à nouveau le risque de trouver des gens « qui ne rentrent pas dans la procédure« , au même titre que l’IED bac+5. Les gens on de plus en plus de mal à penser en dehors de leur outil: avec leur cerveau, en gens sensés et doués d’intelligence.
Je préfère mille fois le rapport d’humain à humain pour un recrutement, qu’une fiche produit réductrice, aussi étoffé de graphes en tous genres soit elle, qui ne me donnera même pas l’opportunité de m’adresser au recruteur.
Il ne faut pas non plus oublier que recruteur est un métier qui ne se limite pas à classer et trier des fiches avec des filtres automatiques sur des critères de choix qui seront nécessairement restreints (ce qui est malheureusement déjà bien trop le cas). Combien de mails j’ai reçu pour des postes de dev .NET alors que mes profils online indiquent noir sur blanc que je veux continuer ma spécialisation dans la techno Java? Et quand j’en reçois un concernant une offre Java, c’est pour des profils débutants de 1 à 3 ans d’xp alors que j’en ai plus de 6?
Le problème vient bien plus des recruteurs qui ne sont pas formés à faire du recrutement informatique.
Alors, par exemple, quand est-ce que les recruteurs sauront vraiment ce qui différencie Java de .NET, au delà d’une simple définition de dictionnaire? Quand les recruteurs comprendront ils que tous les développeurs ne sont pas voués à devenir chefs de projet?
Leur rajouter des outils, qui vont les transformer un peu plus en assistés, alors qu’ils ne sont déjà pas en mesure d’exploiter correctement les informations (simples) dont ils disposent est il bien pertinent?
Traiter la cause plutôt que le symptôme? Les former mieux à leur job en leur proposant des formations faites par des informaticiens, des vrais?
Il ne faut pas oublier non plus que rajouter des outils à destination des recruteurs n’évitera très probablement pas de passer douze entretiens de suite avec les différents niveaux de hiérarchie des entreprises; ça ne réduira très probablement pas le nombre de recruteurs; ça ne fera probablement pas non plus baisser leur salaire; et ça n’évitera pas non plus la période d’essai renouvelable. L’argument du gain de temps et d’argent par l’ajout de filtres en amont est il vraiment plus important que tout ce qui suit cette phase?
Je préfère mille fois une boite avec qui j’aurais un rapport humain permettant tout de suite de savoir à quoi s’en tenir et qui me prendra à l’essai, plutôt que de ne même pas passer des filtres de recherche trop étroits…
J’entends aussi pas mal parler de tests techniques, en entretien, ou hors entretien. Pour en avoir passé, c’est une méthode qui peut être bonne tout comme elle peut être catastrophique. La qualité du test en lui-même est un problème. J’en ai eu où il fallait débusquer des erreurs de fuites mémoires dans du code C, et où je m’en suis très bien sorti. J’en ai eu avec des questions ambigües au possible ou complètement inutiles (par ex: savoir si la méthode de « destruction » d’une servlet s’appelle _destroy(), destroy() ou finalize()), auxquelles on ne sait même pas quoi répondre tant c’est navrant. De fait, ces boites se privent d’entrée de pas mal de profils compétents (jusqu’à présent, tout ce que j’ai produit est en prod, est utilisé et fonctionne). Pour ce point, je n’ai pas spécialement de proposition (je m’y suis pas vraiment penché)
Bonne soirée.
Cordialement,
Nicolas
Je me suis recemment heurte a des entretiens d’embauches en France. J’ai tellement ete degoute par les contacts avec les RH que je n’ai donne suite a rien.
Au final c’est un manager avec qui j’avais eu l’occasion de travailler qui m’a propose un job sur un projet que je trouve genial et sur une techno que je ne connais absolument pas. Bref, encore le reseau qui joue.
Quand je fais une retrospective de ma jeune carriere (2 ans et demie d’experience), j’ai eu 4 differends stages et jobs. Je n’en ai decroche aucun sans beneficier de mon reseau.
Mais les choses changent. Ici (Silicon Valley) et meme a Paris, certaines start-ups se rendent comptent que le process de recrutement ‘standard’ ne fonctionne pas.
De plus en plus, il est demande aux candidats de resoudre en probleme chez eux puis d’envoyer le code source le lendemain. Ou bien carrement de le resoudre pendant l’entretien en utilisant un IDE et internet. Les questions portent aussi plus sur l’experience passee et la capacite a evoluer dans l’entreprise. Ici par exemple: Redesigning the technical hiring process
J’adore l’idee de PY sur le graphe radar. Des la prochaine occasion je l’experimenterais sur mon CV 🙂
Cela permet en un coup d’oeil de qualifier l’experience d’une personne. Meme s’il faut plus que cela, l’apporter en standard peut peut-etre aider les recruteurs. D’ailleurs je suis curieux d’avoir l’avis d’un RH la dessus…
Comme tu le dis, se baser sur la participation aux projets open-source, c’est se priver de 95% des candidats.
Bref, recruter est tres complexe. J’ai ete du cote ‘decisionaire’ quant a l’embauche du candidat et le travail n’est pas facile. Le probleme c’est que les recruteurs ne peuvent absolument pas se baser sur l’honnetete du candidat. Il faut donc creuser et parfois les recruteurs creusent au mauvais endroit (moi le premier). Je suis persuade d’etre passe a cote de profils excellents parce que je ne posais pas les bonnes questions.
En france c’est tout specialement difficile car non seulement il faut recruter un candidat qui va bien travailler mais il faut etre sur qu’il va continuer a bien travailler meme apres la periode d’essai. Certains n’hesitent pas a mettre la ceinture de securite et le frein a main des que celle-ci est terminee.
De meniere un peu extreme (dans le but de lancer le debat) je pense que fluidifier les embauches (et les debauches) participerais a la resolution du probleme. Je trouve que les 3 mois de preavis sont une absurdite. 2 semaines c’est la bonne duree pour faire un transfert de connaissances 🙂 Se faire virer devrait couter a une entreprise mais ca ne devrait pas couter un bras a une PME.
– Nicolas
De l’importance du processus d’embauche.
Dans une précédente boite, j’ai entendu un gars signalant que les pbs de cohésion interne avaient débuté quand ils avaient commence à embaucher à la va-vite car un afflux de commandes les avait poussé à bacler le processus d’embauche.
Il me semble aussi que l’importance du processus de l’embauche peut être vu à travers du dit-processus chez Google. Mon idée, c’est que Google a compris qu’un très bon développeur coutait 2 à 3 plus cher que le prix de base, mais qu’il était 5 fois plus productif : la différence entre les 2 ratios est tout benef pour Google. En fait, la différence entre ces 2 ratios (et donc, l’avantage pour Google) est encore supérieur : on est ici dans une évaluation linéaire, mais en matière de travail en équipe, le cout des échanges se fait en n^2 et donc, l’avantage compétitif que tire Google de son processus d’embauche est aussi en n^2.
Coté open source…
Je pense que l’open source est en avance en matière de pratique.
De ma fréquentation de la communauté Eclipse, il y a qques années, avant que cela n’explose, je m’étais dit que IBM s’était sans doute lancé dans l’open source pour induire, par influence, les bonnes pratiques de l’open source au sein d’IBM, faute d’espérer un grand succès d’une plan d’amélioration qui serait uniquement interne seulement à IBM. Je pense encore qu’il doit y avoir de cela.
Bref, si MasterBranch apparait comme outil open source, je pense que l’on devrait voir ensuite l’équivalent en termes d’outils internes. Pourquoi pas un MasterBranch intégré à des outils comme Sonar ou Squale ?
Peut être que l’on devrait aussi assister à d’autres initiatives dans le monde open source. J’ai par ex idée que « Open source communities may benefit from leveraging distributed social networks » http://www.jroller.com/dmdevito/entry/open_source_communities_may_benefit mais les organisations open source (Eclipse, Apache, OW2…) ne se sont pas lancées dans le mouvement.
Ce qui est « marrant », dans ces démarches, c’est que cela donne l’idée que les informaticiens ne sont jamais aussi bien servi que par eux-mêmes. Et de fait, de nombreux processus de recrutement m’ont donné l’idée que l’on pouvait aisément se passer de certains RH… Heureusement que l’on appartient à une profession qui peut créer ses propres outils pour faire avancer les choses…
Sinon, pour filer la métaphore, coté recrutement, avec le CV standard, c’est comme si on en était encore au terminal VT100 ou du MS-DOS N/B (que ce CV soit dispo en version papier, ou même sur le web, c’est la même chose ici).
Utiliser des diagrammes comme un graphe radar, c’est l’équivalent de l’irruption d’une interface graphique.
MasterBranch, c’est encore le stade au dessus: c’est l’équivalent de la venue du web 2.0 en matière de CV.
Il est peut être temps effectivement que le bon vieux CV tire parti de technologies plus récentes.
Au niveau visualization du CV style ‘web 2.0’ il y a ca: http://vizualize.me/?beta=vizme
– Nicolas
C’est vrai que dans les SSII j’ai toujours eu l’impression que leurs questions n’étaient pas très pertinentes…
J’ai déjà eu des « QCM JEE » de 15 questions dont 5 sur struts (alors que j’en avais jamais fait) du style « comment s’appelle le fichier de configuration de struts? »
Alors forcement c’est super pratique pour avoir un bon score.
Je crois que c’était sur le site de PeopleCentric ou il y a des QCM qui sont un peu plus chauds sur le Java (dans le genre SCJP) mais la encore c’est cool si tu maîtrises le langage, l’api servlet mais on ne sait toujours pas si tu sais bien les utiliser en pratique, si tu es un bon designer…
Le blog makinggoodsoftware a un peu parlé de ces problématiques aussi
http://www.makinggoodsoftware.com/2009/07/16/3-tips-to-know-how-good-is-the-candidate-you-are-interviewing/
http://www.makinggoodsoftware.com/2009/09/16/top-4-mistakes-interviewing-programmers/
Article très intéressant, et j’opterais aussi pour le radar, surtout quand on a plusieurs quinquennats sous les semelles.
Comme d’autres ici, il y a bien longtemps, j’ai subit des QCM d’évaluation au java.. mais bon sang, la gamine de 20 ans des RH qui me recevait devait à peine savoir que Java n’est pas qu’une danse des années 30 !
Comment évaluer la compétence sur une techno comme Java qui compte plus de 100 000 API et plusieurs domaines étanches (embarqué!=web!=transactionnel…) ?
Le comble est que, pour un poste de Chef de Projet technique, toute l’évaluation a tourné autour de mes connaissances de développeur.
Non, le gros pépin est du coté des RH : qui ils choisissent pour mener leurs recrutements (la dernière stagiaire qui se fait les dents ou un cabinet spécialisé) ? qu’attendent-ils de leur recrue (j’occupe un rouage de la machine ou j’apporte une valeur ajoutée )
Personnellement, j’ai adopté en 2nd page de mon CV une grille chronologique (en ordonnée la gamme de job dev j2ee/cdp/dp/dsi..etc, en abscice mes années d’expérience et je noirci les cases) : comme ça, en un graphique, il mesure ce que j’ai fait de mes 15 ans dans le métier, et comprend mon parcours …
Article et liens intéressants.
Mais la vision peux être nuancée
Tout d’abord le contexte :
Les critères ne sont pas les mêmes quand on monte une « dream team » pour un projet au forfait de 3 mois ou lorsque l’on embauche un collaborateur pour du long terme.
-Dans le premiers cas on privilégiera les compétences et la capacité à être opérationnel rapidement.
-dans le second cas on préférera le potentiel à l’acquis
En suite je ne suis pas sûr que les compétence techniques soient le premier facteur de réussite.
Pour ma part le critère N°1 c’est : Pas de sale cons chez moi !!!
Le gars le plus compétent du monde s’il te pourrit l’ambiance d’une équipe par sa prétention, son égoïsme, son arrogance… j’en veux pas ! Le gain de productivité lié à sa compétence ne compensera pas la perte sur le moral des autres membres de l’équipe. Les sales cons coûtent cher.
Ensuite une bonne équipe est une équipe complémentaire. Il y a des créatifs, des organisateurs, des fourmis ouvrières etc…
Les créatifs sont rarement les meilleurs dans le suivi et la mise en œuvre ils sont forts pour donner des directions, pour avoir une vision à moyen ou long terme, ils changent facilement d’avis et remettent facilement en question leur propres choix. Ils ont besoin de personnes plus ‘rigides’ pour les accompagner dans mise en œuvre.
Enfin il y a des sujets que l’on aime et d’autres que l’on déteste… On est toujours bon sur les sujets que l’on aime et plus surprenant : il y a des sujets que l’on déteste que d’autres aiment faire…
Je ne défend pas l’idée qu’il ne faut confier aux personnes que les sujets qui les intéressent : un bon professionnel c’est justement quelqu’un qui ne sabote pas les sujets qu’il déteste en espérant qu’on ne les lui confie plus.
Enfin le rôle du manager dans la gestion des compétences de son équipe :
Un développeur qui n’aime pas un sujet peut avoir plusieurs raisons (bonnes ou mauvaises) généralement on aime rester dans notre zone de confort (là où on est compétent, on accepte facilement d’aller dans les zones qui nous intéressent et qui entreront facilement dans notre zone de confort et on freine des 4 fers pour ne pas aller sur les sujet qui ne nous plaisent pas….
On a du mal à faire passer un développeur Play! sur un framework maison d’un client basé sur Struts 1 (Loooose!). On aura du mal à faire passer un javaïste convaincu sur .Net (the dark side !) et idem pour un développeur VB vers Cobol.
Mais ne nous y trompons pas : on peux apprendre beaucoup de chose sur un projet Cobol…. On a pas toujours besoin d’un marteau en Or pour enfoncer un clou !
Enfin les raisons qui font que l’on aime pas un sujet sont très diverses.
– Peur de l’échec
– Influence de la mode (buzz)
– etc…
Pour un manager faire progresser un collaborateur c’est avant tout comprendre ses blocages (Mais c’est une autre histoire…)
On veux tous travailler sur du hype et c’est facile d’être bon quand ça nous intéresse mais un bon candidat c’est avant tout :
– Bonne humeur
– Engagement
– Ouverture d’esprit
– Compétences techniques
Et suivant les profils recherchés
– rigueur ou capacité conceptuelle
Enfin pour finir
Quand on fait un recrutement en interne il ne faut pas oublier que dans 5 ans l’expert technique sera devenu un dinosaure s’il s’accroche à sa zone de confort…
Pour la reconnaissance par les pairs, voir les outils présentés dans cet article: entaggle et mixtent http://wokier.posterous.com/geek-20