Comment être vraiment sûr de recruter un mauvais ingénieur informatique
Par Oaz le 25 juin 2006, 00:30 - En français - Lien permanent
Vianney Lecroart explique comment recruter un mauvais ingénieur informatique. Dans l'ensemble, les règles décrites dans ce billet me semblent bien illustrer certaines erreurs classiques de recrutement dans le développement logiciel.
Malheureusement, ces règles ont un défaut. Elles laissent transparaître, de manière diffuse, un des travers que l'on retrouve de plus en plus souvent chez les agilistes : la croyance que constituer une équipe de développement consiste principalement à réunir un ensemble de personnes très ouvertes au dialogue et capables d'acquérir les connaissances qu'elles n'ont pas.
Je propose donc ici quelques règles supplémentaires qui peuvent permettre de se laisser définitivement phagocyter par cette idéologie.
Malheureusement, ces règles ont un défaut. Elles laissent transparaître, de manière diffuse, un des travers que l'on retrouve de plus en plus souvent chez les agilistes : la croyance que constituer une équipe de développement consiste principalement à réunir un ensemble de personnes très ouvertes au dialogue et capables d'acquérir les connaissances qu'elles n'ont pas.
Je propose donc ici quelques règles supplémentaires qui peuvent permettre de se laisser définitivement phagocyter par cette idéologie.
1. Accorder peu d'importance à la communication écrite
Lors d'un entretien, faire complètement abstraction de ce qu'à pu écrire un candidat (CV et lettre de motivation) permet de se concentrer uniquement sur la personne.
Il est bien connu que seules les interactions face à face entre développeurs sont importantes. L'importance des capacités de synthèse et de concision qui permettent de rédiger des documents diffusables aux divers intervenants d'un projet ne doit pas être surestimée.
Les correcteurs grammaticaux et orthographiques des traitements de texte ont rendu obsolète le jugement des qualités rédactionnelles. Celles-ci ne sont d'ailleurs représentatives que de sa capacité à assimiler des conventions et structurer sa pensée.
2. Ne juger que sur les éléments directement évaluables lors de l'entretien
Les diplômes qu'a pu obtenir un candidat ne doivent pas être pris en compte car ils ne représentent qu'une vision partielle des domaines dont il a montré une certaine maîtrise.
Une mention 'Bien' ou 'Très Bien' à un baccalauréat ne permet, au mieux, que de se rendre compte de l'ouverture et l'éclectisme dont a su faire preuve un candidat face à des domaines aussi variés que les mathématiques, l'histoire, la littérature ou les sciences naturelles.
En ce sens, un entretien d'une heure où l'on va pouvoir évoquer ses quelques réalisations informatiques et ses activités extraprofessionnelles du moment est beaucoup plus représentatif de sa capacité d'ouverture aux sujets nouveaux.
3. Se comporter en bon copain
Il faut faire en sorte que l'entretien se déroule dans une ambiance de franche camaraderie en évitant autant que possible de stresser le candidat et en veillant bien à ne pas monopoliser le dialogue.
Le développeur évolue naturellement dans une bulle protectrice mise en place autour de l'équipe. Il n'a qu'une très faible probabilité de se retrouver face à un client récalcitrant, un fournisseur roublard ou un collègue mal intentionné. Sa potentielle incapacité à savoir faire entendre son opinion face à un beau parleur qui lui opposerait des arguments fallacieux n'a que peu d'importance.
4. Se reposer sur la capacité à apprendre
Tout contrôle des connaissances techniques du candidat est une perte de temps. La capacité à apprendre des choses nouvelles est bien plus importante que les connaissances déjà acquises. Il suffit d'interroger le candidat sur la façon dont il a su évoluer lorsqu'il s'est trouvé confronté à un manque de connaissance sur un sujet.
L'interrogation sur des points techniques précis et la mise en condition réelle d'apprentissage sur les points que le candidat ne maîtrise pas ne montreraient rien de plus que la véracité de ses propos. Il est inutile de la mettre en cause puisque l'on a par ailleurs su établir une bonne ambiance de confiance réciproque.
5. Répéter inlassablement que 'développer' c'est, avant tout, 'utiliser des outils de développement'
Faire travailler un candidat sur un support papier est une hérésie car le vrai développement est celui qui se fait face à la machine et qui produit directement du logiciel exécutable. Les outils modernes de développement tels que l'aide contextuelle à la saisie, la compilation à la volée en phase d'exécution ou le remaniement de code rendent inutiles les fastidieuses phases de réflexion sur papier que l'on a pu connaître par le passé.
Ainsi, demander à un candidat d'écrire du code ou de lire le code de quelqu'un d'autre sans avoir tous les outils informatiques nécessaires à portée de main ne serait qu'une perte de temps. Cela ne montrerait que sa capacité d'abstraction et de conceptualisation face à un problème de développement logiciel.
Ces capacités, qui sont essentielles lorsque l'on doit prendre du recul par rapport à une activité de codage, sont aujourd'hui obsolètes puisqu'il suffit désormais de lancer sans relâche son compilateur jusqu'au succès complet de l'ensemble des tests unitaires automatisés pour réaliser un logiciel.
Lors d'un entretien, faire complètement abstraction de ce qu'à pu écrire un candidat (CV et lettre de motivation) permet de se concentrer uniquement sur la personne.
Il est bien connu que seules les interactions face à face entre développeurs sont importantes. L'importance des capacités de synthèse et de concision qui permettent de rédiger des documents diffusables aux divers intervenants d'un projet ne doit pas être surestimée.
Les correcteurs grammaticaux et orthographiques des traitements de texte ont rendu obsolète le jugement des qualités rédactionnelles. Celles-ci ne sont d'ailleurs représentatives que de sa capacité à assimiler des conventions et structurer sa pensée.
2. Ne juger que sur les éléments directement évaluables lors de l'entretien
Les diplômes qu'a pu obtenir un candidat ne doivent pas être pris en compte car ils ne représentent qu'une vision partielle des domaines dont il a montré une certaine maîtrise.
Une mention 'Bien' ou 'Très Bien' à un baccalauréat ne permet, au mieux, que de se rendre compte de l'ouverture et l'éclectisme dont a su faire preuve un candidat face à des domaines aussi variés que les mathématiques, l'histoire, la littérature ou les sciences naturelles.
En ce sens, un entretien d'une heure où l'on va pouvoir évoquer ses quelques réalisations informatiques et ses activités extraprofessionnelles du moment est beaucoup plus représentatif de sa capacité d'ouverture aux sujets nouveaux.
3. Se comporter en bon copain
Il faut faire en sorte que l'entretien se déroule dans une ambiance de franche camaraderie en évitant autant que possible de stresser le candidat et en veillant bien à ne pas monopoliser le dialogue.
Le développeur évolue naturellement dans une bulle protectrice mise en place autour de l'équipe. Il n'a qu'une très faible probabilité de se retrouver face à un client récalcitrant, un fournisseur roublard ou un collègue mal intentionné. Sa potentielle incapacité à savoir faire entendre son opinion face à un beau parleur qui lui opposerait des arguments fallacieux n'a que peu d'importance.
4. Se reposer sur la capacité à apprendre
Tout contrôle des connaissances techniques du candidat est une perte de temps. La capacité à apprendre des choses nouvelles est bien plus importante que les connaissances déjà acquises. Il suffit d'interroger le candidat sur la façon dont il a su évoluer lorsqu'il s'est trouvé confronté à un manque de connaissance sur un sujet.
L'interrogation sur des points techniques précis et la mise en condition réelle d'apprentissage sur les points que le candidat ne maîtrise pas ne montreraient rien de plus que la véracité de ses propos. Il est inutile de la mettre en cause puisque l'on a par ailleurs su établir une bonne ambiance de confiance réciproque.
5. Répéter inlassablement que 'développer' c'est, avant tout, 'utiliser des outils de développement'
Faire travailler un candidat sur un support papier est une hérésie car le vrai développement est celui qui se fait face à la machine et qui produit directement du logiciel exécutable. Les outils modernes de développement tels que l'aide contextuelle à la saisie, la compilation à la volée en phase d'exécution ou le remaniement de code rendent inutiles les fastidieuses phases de réflexion sur papier que l'on a pu connaître par le passé.
Ainsi, demander à un candidat d'écrire du code ou de lire le code de quelqu'un d'autre sans avoir tous les outils informatiques nécessaires à portée de main ne serait qu'une perte de temps. Cela ne montrerait que sa capacité d'abstraction et de conceptualisation face à un problème de développement logiciel.
Ces capacités, qui sont essentielles lorsque l'on doit prendre du recul par rapport à une activité de codage, sont aujourd'hui obsolètes puisqu'il suffit désormais de lancer sans relâche son compilateur jusqu'au succès complet de l'ensemble des tests unitaires automatisés pour réaliser un logiciel.
Commentaires
J'ai passé la plupart des TPs avec le même camarade, issu d'un IUT, donc très bon au niveau programmation. Nous avions deux approches différentes : lui consacrait 40% du temps à coder très vite et 60% à débugger, et moi je consacrais 70% du temps à coder (en soignant la conception), et 30% à débugger. Au bout du compte nous terminions presque en même temps à chaque fois. Par contre, après discussion, l'architecture que j'avais conçue permettait souvent plus de flexibilité et de stabilité.
En résumé, prendre un peu de temps pour concevoir une architecture propre, et produire ainsi un code déjà débuggé en majorité, ça marche aussi bien que de coder comme un fou et passer un temps fou à débugger avec le compilateur...
Pour ma part, je prefère recruter un ingénieur métier maitrisant le developpement qu'un ingénieur informaticien essayant de comprendre le métier (bonjour les dégats)!!!
Un ingénieur informaticien quant à son rôle réel c'est le développement des outils de developpement, la disponibilité et la sécurité des SI et des infrastructures.
Cette dichotomie est un faux problème. Il est tout aussi illusoire de croire qu'une équipe composée uniquement d'"ingénieurs informaticiens" va être capable de développer un truc correspondant aux besoins du métier sans véritables connaisseurs du métier faisant partie intégrante à temps plein de l'équipe de développement que d'imaginer qu'une personne connaissant bien le métier mais sans véritable connaissance approfondie de techniques de développement (qui ne s'apprennent pas en quelques semaines) puisse écrire du code bien testé, maintenable et efficace.