Discussion :

[Michael Guilloux]

Programmation : qu’est-ce qui est recherché chez un candidat dans un entretien technique ?
Un spécialiste répond à la question

Si vous êtes candidat à un poste de développeur, vous devez vous attendre à écrire du code sur un tableau blanc lors de votre entretien technique. Et ce n’est pas du tout une tâche facile selon Eric Lippert, ex-développeur principal chez Microsoft.

Chez la firme de Redmond, M. Lippert a interviewé à plusieurs reprises des candidats à des postes de développement pour des équipes Visual Studio et à travers un récent billet de blog, il propose d’exposer ce que recherchent les recruteurs chez un candidat lors d’un entretien technique.

Passer au tableau peut rendre difficiles même les exercices les plus simples. « C’est difficile, en partie parce que vous ne disposez pas d'IntelliSense ou la coloration de syntaxe ou l'un des autres outils à votre disposition quand vous écrivez normalement du code ». Comme l’explique Lippert, les recruteurs ne s’attendent donc pas à ce que les candidats leur sortent des codes parfaits, mais se contentent de poser des questions simples qui pourraient leur permettre d’évaluer la capacité du prétendant à résoudre des problèmes. « Je ne suis pas à la recherche de personnes qui peuvent cracher du code syntaxiquement parfait », a déclaré Lippert; « ce n'est pas du tout le point de l'exercice de codage. J’essaie de découvrir comment vous résolvez les problèmes », a-t-il ajouté.

Ce qu’il recherche chez le candidat, c’est de savoir si ce dernier se jette immédiatement à l’eau et commence à coder ou prend soin de réfléchir à tous les contours du problème. Le candidat essaie-t-il de clarifier les zones d’ombre ou préfère-t-il émettre un tas d’hypothèses ? Le candidat préfère-t-il faire d’une pierre deux coups ou prend-il soin de découper le problème en morceaux et le résoudre progressivement ? Comment attaque-t-il le problème, par les parties faciles ou celles qui sont difficiles en premier ? Voici un ensemble de questions auxquelles Lippert essaie de trouver des réponses lorsqu’il est en face d’un candidat.

Le candidat idéal doit être « une personne bien organisée avec de bonnes compétences en résolution de problèmes », capable d’expliquer ce qu’il fait pendant qu’il le fait. Et le code résultant doit être « clair, bien organisé, lisible et au moins vaguement syntaxiquement correct ». Cela permet de juger facilement si le code est bien conçu et libre de bugs.

Lorsque le candidat arrive à proposer une solution, les recruteurs s’intéressent également à savoir si ce dernier fait confiance à sa solution et ce qu’il fait pour prouver qu’elle est correcte. Selon Lippert, le candidat ne devrait pas juste plaquer un code et dire que c’est correct, mais il devrait être en mesure de le prouver par des tests simples.

Après l’écriture du code, le candidat devrait également s’interroger sur sa robustesse et sa maintenabilité. Il devrait encore se demander si son code est déboguable, portable ou extensible.

Pour les candidats fraichement sortis des écoles, les recruteurs sont conscients qu’ils ont souvent très peu d'expérience avec le monde réel. Ce qui est donc évalué chez ces derniers, c’est la « puissance intellectuelle brute, leur talent de codage et le potentiel à long terme. »

Si l’entretien technique est un exercice difficile auquel des gens brillants peuvent échouer, M. Lippert pense cependant qu’on pourrait mieux le préparer avec les exemples classiques de n’importe quel livre d’introduction à la programmation.

Source : Blog d’Eric Lippert

Et vous ?

Qu’en pensez-vous ?

[Orgoff]

Qu’en pensez-vous ?

Que le "spécialiste" utilise le BABA du recrutement pour évaluer les candidats, cela en valait-il la peine d'en faire un article ?

[DarkBakura]

Que le "spécialiste" utilise le BABA du recrutement pour évaluer les candidats, cela en valait-il la peine d'en faire un article ?

Comme le démontrent les commentaires qui ont suivi, tout le monde ici n'est pas forcément doté d'une longue expérience professionnelle jonchée de candidatures diverses. Il n'était donc pas inutile de relayer l'avis d'un recruteur, bien que ce ne soit jamais une vérité universelle, et ce même si ça te parait être le B-A-BA. Si beaucoup de recruteurs suivent la même logique par manque de connaissances du milieu dans lequel ils recrutent, d'autres peuvent être plus pointus ou avoir des aspirations différentes concernant leurs candidats.

En tout cas, pour ma part et même après avoir passé plusieurs entretiens, ça m'intéresse toujours de voir ce que pensent les recruteurs lors de ces moments. Même si au fond je trouve le principe de faire écrire du code en partant d'une feuille blanche, et ce dans un laps de temps réduit, assez peu pertinent car bien différent de ce qui se passe dans la réalité du terrain, là où l'IDE et les ressources documentaires facilitent le travail de développement.

[didier.cabale]

Que le "spécialiste" utilise le BABA du recrutement pour évaluer les candidats, cela en valait-il la peine d'en faire un article ?

ah ben si justement, car la grande majorité des recruteurs ne procèdent pas ainsi. Ils s'attachent, au contraire, à savoir si vous maitrisez le Framework xxxx version yyyy, ainsi que le Framework zzzz version aaaa .. ce qui montre qu'ils n'ont rien compris au métier, et que, n'y ayant rien compris, ils préfèreront "ne prendre aucun risque" vis à vis de leur client, en tentant de délivrer le mouton à cinq pattes dont leur client avait rêvé.

[didier.cabale]

Ne t’avance pas trop vite non plus
Autre point très important en France et particulièrement con et injuste : la dictature des diplômes.

.. je dirais même: "la dictature des diplômes .. jusqu'à l'absurde", et je me permets de dire çà parce que, justement, je suis diplômé.
En effet, travaillant à l'étranger, je peux attester qu'en Suisse, les recruteurs sont plus ouverts et pragmatiques, et qu'au lieu de se concentrer sur vos diplômes et sur la maîtrise théorique de la technologie lambda, version x, sous-version y, ils vont plutôt s'attacher à connaître votre parcours au sens large (et pas seulement vos années d'étude qui ont mené à votre diplôme, il y a x années), et *surtout* la façon dont vous abordez les problèmes.
Cette façon de procéder me parait beaucoup plus intelligente à mes yeux que la façon mécanique et scolaire qu'ont la plupart des cabinets de recrutement ou (soit-disant) SSCI en France.

[bmoraut]

Bonjour,

Je me base sur un constat et une analyse approfondie des méthodes de recrutement, au vue des nombreuses expériences que j'ai vécu, et mes collègues, rencontrés au quelques entretiens que j'ai eut, et aux choix fait par les sociétés sur ces postes.

En plus, il y a bien l’École 42, dont le patron dit qu'il n'y a pas de bon informaticien, mais qui veut, avec tous ceux qui n'ont pas réussi à décrocher un BAC, faire l'informatique de Demain.
Il semble qu'il déchante, car maintenant il parle de 3 à 5 ans de formation (ce qui est la formation d'un ingé à partir du niveau BAC).

Et une expérience, sur un échantillon n'est pas révélatrice, mais des phénomènes systématiques et répétés, deviennent des indicateurs.

D'abord, je peut vous dire que j'ai été autodidacte, et que pendant plusieurs années, je n'ai eu aucun problème pour travailler comme informaticien.

Réalisant que l'informatique évoluait, j'ai donc repris des études.

Entre temps, les méthodes de recrutements ont évoluées, et les intérêts aussi.

J'ai fait l'expérience de plusieurs candidatures, qui passaient par des cabinet de recrutement, qui étaient systématiquement écartées dès la réception du CV, alors que par un autre canal, l'entreprise soit:
- ne comprenait pas pourquoi le cabinet m'avait pas au moins présenté pour un entretien
- me recevait au moins en entretien
- avaient abandonné ou modifié le poste, alors que moi ou plusieurs collègue avaient envoyé leur candidature au cabinet mandaté
- me prenait moi ou un collègue directement

Ensuite, quand je relançait ses cabinets, les réponses de refus des candidatures étaient complètement irrationnelles:
- Si vous avez reprise des études, c'est que vous manquez de confiance en vous
- Votre diplôme ne vaux rien
- Vous êtes trop expérimenté
- Dans votre CV vous n'avez pas fait de "Multi-threading" (mon stage et rapport de validation du diplôme était de créer et paralléliser des calculs)
- Vous n'avez pas fait telle ou telle technologie (alors que je l'avais employé plusieurs années, le tout noté sur le CV...)
- Vous êtes trop vieux
- etc...

Je vais aussi répondre aux "jaloux" des diplômes:

Le fait de réussir un diplôme, surtout un diplôme scientifique, ce n'est pas un attestation qui certifie que l'on a empilé des connaissances, mais que l'on est capable d'analyser un problème complexe et de lui trouver des solutions.

C'est pour cela que les épreuves des examens existent (pour ma part j'ai validé 27 UV). Et que en plus le tous est validé par un stage en entreprise, souvent sur un sujet non-conventionnel, où il faut innover.

Si en plus, cela fait des années que l'on fait ce métier, c'est bien la preuve que l'on est capable de le faire et qu'on le fait.

Ceux qui ont échoué, sont soit des génies qui n'ont pas travaillé, soit ne sont pas si bon qu'ils veulent le faire croire.

Si on a réussi, l'informatique étant vaste, il faut s'adapter et l'on a prouvé ces capacités, tant sur le théorique, que sur le pratique.

Moi je pense que cette pénurie vient de plusieurs phénomènes conjugués:
Mais le marché actuel est fait pour les société de travail en régie, qui se gavent sur le dos des développeurs.
Ils ne leur faut pas des bons, mais des "pisseurs de codes" qui laisse un travaille non pas simple, mais jamais fini.
La preuve, une grosse société canadienne, l'a compris et vient de s'installer sur le marché Français: ils sont la pour faire corriger
ce qui a été mal fait au départ. Ils ont fait une étude de marché et m'ont avoué que c'était un marché très juteux:
- Les Logiciels sont refaits jusqu'à 6 fois et très mal faits, avec un nombre de lignes inconsidérés et de fonctions répétées, mais jamais factorisées
- Que une fois a peut près fini, il y a encore au moins 6 interventions à faire pour les corriger, car comme les mêmes fonctionnalités sont répétées, il y a de quoi vendre des heures de développement pour corriger les bugs
- Les demandeurs (clients) ne connaissent rien, et sont manipulables
- Ils ne font pas la différence avec un utilisateur avancé, et un informaticiens (Php par exemple ou ingénieur grande Ecole) dont les travaux sont reconnus

Ensuite le marché de l'informatique a attiré tout un tas de "passionné" mais qui malheureusement "plafonnent" à un niveau assez bas, mais suffisamment haut pour impressionner les demandeurs.
Pour des sites, ou de la maintenance de basent ils se débrouillent très bien pour le b.a.bas mais dès que le niveau monte:
- Ils empêchent l'embauche d'ingénieurs plus qualifiés
- Ils ne se rendent pas compte des risques de sécurité
- Ils ne voient pas les possibilités d'évolutions et sont en complet dénie fasse aux possibilités d'évolution de leur logiciels, ou réseau, et font plafonner leur entreprise à leur plafond personnel

Quelques exemple:
- Un amis autodidacte, qui se vantais d'êtres très concret sur la tenu du réseau de son usine, que les ingénieurs n'étaient que des théoriciens, s'est aperçu que depuis des années, au moment de vouloir attaquer le marché chinois, en rencontrant un futur partenaire chinois, que celui-ci n'avait plus besoin d'eux car il copiait la base de données de clients et de plans depuis des années. Il n'avait rien vu.
- J'ai postulé pour aider à sécuriser les données d'une préfecture. La réponse a été que moi et les autres candidats (Ingénieurs grande école, Masters en Info etc..) étaient "sur diplômé" et "surdimensionné' pour le poste, par le responsable auto proclamé "ingénieur". Résultat il a pris des gens moins qualifié que lui.
Peu de temps après toutes la bases de la préfecture a été piratée (donnée confidentielles comprises).

Un autre phénomène est que la multiplicité des systèmes, fait que personne ne peut être opérationnel instantanément sur une technologie particulière.
Résultat: de nombreuses boites élimine le candidat de haut niveau qui saura s'adapter rapidement, à celui qui a un niveau limité, mais qui a eut la chance, lors de son parcours de faire la même chose.
C'est pourquoi, je pense que "Frederic Latour" est soit tombé sur un de ces ingénieurs auto proclamé, attiré par un salaire de 2 fois le smic, soit sur un ou des candidats, bien que brillant, ne connaissait pas le sujet.
Pour preuve, je peux lui faire passer un test sur lequel il sera incapable de répondre, car l'informatique couvre un champs de connaissance qui touche toutes les autres sciences, et à moins d'être ovni-scien, ou un petit génie que 7 doctorat, il sera bien embêté.

Encore un phénomène, est que justement, certaines entreprises ont un très haut niveau technique sur une technologie, et veulent, un informaticien qui connaisse leur technologie spécifique parfaitement , l'informatique étant secondaire.
L'Informatique est une science en elle même, et des ingénieurs, scientifique de haut niveau dans d'autre disciplines, sous estiment le contenu de l'informatique en elle même.
J'ai ainsi relevé des entreprises avec des logiciels "monstrueux" en taille, parce qu'il ne connaissent rien en informatique, mais qui cependant répond au besoin de leur technologie. Seulement, rien de l'informatique pur un peut avancé n'est utilisé: factorisation des fonction, POO, Merise, ou d'une façon complètement chaotique. Résultat: ils s'enfoncent dans une complexité sans pareil, avec des coût de développement qui s'envolent.
C'est simple de faire compliqué, mais c'est compliqué de faire simple.

Voilà voilà.
Cordialement

[Invité]

Je me base sur un constat et une analyse approfondie des méthodes de recrutement, au vue des nombreuses expériences que j'ai vécu, et mes collègues, rencontrés au quelques
entretiens que j'ai eut, et aux choix fait par les sociétés sur ces postes.

En plus, il y a bien l’École 42, dont le patron dit qu'il n'y a pas de bon informaticien, mais qui veut, avec tous ceux qui n'ont pas réussi à décrocher un BAC, faire
l'informatique de Demain.
Il semble qu'il déchante, car maintenant il parle de 3 à 5 ans de formation (ce qui est la formation d'un ingé à partir du niveau BAC).
etc....

Franchement, j'ai dû mal à vous suivre et à bien comprendre ce que vous tentez d'exprimer/expliquer. Essayons de récapituler les différentes thèmatiques:


Recrutement

• Vous étiez autodidacte et n'aviez dans ce cadre aucun problème pour travailler comme informaticien.
• Vous avez décidé de reprendre des études et une fois diplomé les ennuis ont commencé et avez eu toutes les peines du monde pour trouver du travail.

Vous expliquez cette situation paradoxale par le comportement irrationnel des cabinets de recrutement.

C'est quand même particulièrement étonnant car, jusqu'à preuve du contraire, en France, c'est lorsque vous êtes sous-diplomé que vous rencontrez des difficultés pour vous faire embaucher. Dans certaines sociétés, il n'est même pas utile de postuler si vous n'êtes pas BAC+5.
Vous êtes diplomés et expérimentés et, étrangement, contre toute logique cela semble poser plus de problèmes que d'opportunités.
Quant aux recruteurs, vous semblez conclure à l'irrationalité sans aucune analyse de leurs éventuelles motivations.
Au final ce n'est pas très clair; à part constater l'insoutenable irrationalité de l'être humain ...


Les diplômes

Vous semblez faire une fixette sur les diplômes.

Je vais aussi répondre aux "jaloux" des diplômes:
Le fait de réussir un diplôme, surtout un diplôme scientifique, ce n'est pas un attestation qui certifie que l'on a empilé des connaissances, mais que l'on est capable

d'analyser un problème complexe et de lui trouver des solutions.
C'est pour cela que les épreuves des examens existent (pour ma part j'ai validé 27 UV). Et que en plus le tous est validé par un stage en entreprise, souvent sur un sujet

non-conventionnel, où il faut innover.
Si en plus, cela fait des années que l'on fait ce métier, c'est bien la preuve que l'on est capable de le faire et qu'on le fait.
Ceux qui ont échoué, sont soit des génies qui n'ont pas travaillé, soit ne sont pas si bon qu'ils veulent le faire croire.
Si on a réussi, l'informatique étant vaste, il faut s'adapter et l'on a prouvé ces capacités, tant sur le théorique, que sur le pratique.

Affirmer que l'obtention d'un diplôme (d'ingénieur ou non) signifie que vous avez nécessairement développé les qualités importantes qui feront de vous un bon informaticien relève de l'incantation qui ne se vérifie pas dans les faits.
Avez-vous déjà donné un problème complexe (ou simplement difficile) à des ingénieurs informaticiens qui viennent d'obtenir leur diplôme ?
L'élevage en batterie des Ingénieurs en Informatique est une vaste blague. Il n'est absolument pas possible de considérer le diplôme comme un élément très significatif tellement la différence de niveau entre 2 personnes sortant (pourtant avec le même diplôme) est importante. Les écoles s'appuient sur les stages conventionnés pour donner un peu de consistance à leur formation mais globalement cela ne vole pas très haut ... Le niveau est devenu médiocre car de très nombreuses personnes se sont logiquement engouffrés dans ce secteur dans l'espoir de gagner leur vie correctement, sans nécessairement avoir d'affinitiés pour cette activité.
Seulement, le développement d'une application ne relève pas d'un process complètement industrialisé qu'il suffirait d'appliquer. les combinaisons sont énormes, les options
multiples et les qualités intellectuelles qui sont nécessaires sont complexes. J'attends encore de voir une école qui développerait une vrai démarche sur le fond plutôt que d'apprendre un peu de langage A par ci, un peu de langage B par là.

Raisons de la pénurie

Vous revenez ensuite sur cette fameuse pénurie dont vous indiquiez initialement qu'elle était le fait du comportement "irrationel" des recruteurs...

Moi je pense que cette pénurie vient de plusieurs phénomènes conjugués:

Donc la pénurie ne serait plus uniquement le fait des méthodes de recrutement mais vous ajoutez 4 points que je vais tenter de résumer:

• Les ssii ne pensent qu'à faire de l'argent et ne sont donc pas intéressés par la compétence.
• Le milieu informatique est envahi de personnes passionnés (sous entendu... mais sous-diplômés) qui sont vite limités et tirent le niveau vers le bas.
• L'informatique est un sujet très vaste. De très nombreuses technologies qui ne peuvent être maitrisées par une seule personne...
• Certaines entreprises spécialisées cherche un spécialiste de la technologie particulière (sans se rendre compte de l'importance de l'informatique ...)

On peut se questionner sur le cheminement de votre raisonnement. Il est difficile d'établir une correlation entre les "méthodes des recruteurs" et les autres raisons évoqués ici ... hormis peut-être le point 1.
Les ssii qui placent des informaticiens en régie ne sont pas connues pour faire l'impasse sur le diplôme (ce qui est logique car c'est plus facile à vendre). En ce sens elles devraient, même involontairement, participer à l'élévation du niveau de qualité dû à la prolifération des ingénieurs placés en régie si l'on s'en tient à votre démonstration de la valeur d'un Ingénieur diplômé.


Faire passer un test - peut-être - mais il serait judicieux de s'en tenir aux arguments

Un autre phénomène est que la multiplicité des systèmes, fait que personne ne peut être opérationnel instantanément sur une technologie particulière.
Résultat: de nombreuses boites élimine le candidat de haut niveau qui saura s'adapter rapidement, à celui qui a un niveau limité, mais qui a eut la chance, lors de son parcours de faire la même chose.
C'est pourquoi, je pense que "Frederic Latour" est soit tombé sur un de ces ingénieurs auto proclamé, attiré par un salaire de 2 fois le smic, soit sur un ou des candidats, bien que brillant, ne connaissait pas le sujet....
Pour preuve, je peux lui faire passer un test sur lequel il sera incapable de répondre, car l'informatique couvre un champs de connaissance qui touche toutes les autres sciences, et à moins d'être ovni-scien, ou un petit génie que 7 doctorat, il sera bien embêté.

Voici ce que j'indiquais dans un message précédent:

Le niveau général est médiocre. En sortie d'école d'ingénieur, la plupart des élèves ne connaissent non seulement pas les bases des problématiques de développement avec les technologies actuelles mais surtout ne sont pas entrainés à établir des stratégies de résolution, structurer une problématique, abstraire ... et même si l'on écarte le développement, éventuellement sous le prétexte que les ingénieurs se destineraient plutôt à être chef de projet, ce n'est pas beaucoup mieux. Demandez un plan, l'écriture de besoins fonctionnels, d'une documentation

Je ne comprends pas vraiment l'intérêt d'avancer une explication ou d'émettre des hypothèses qui n'ont aucun rapport avec l'argumentation initiale:

• stratégie de résolution,
• structuration de problématiques,
• abstraction,
• définition d'un plan,
• écriture de besoins fonctionnels

Il ne me semble pas que cela relève de la connaissance d'une technologie en particulier. Vous n'avez donc aucune raison d'avancer l'hypothèse d'un candidat qui ne connaîtrait pas le sujet hormis le manque de rigueur ou la mauvaise foi.

L'argument qui consisterait à me faire passer un test auquel je ne pourrais pas répondre pour prouver on ne sait pas trop quoi (car si vous relisez la phrase cela ne veut rien dire mais bref) ne présente pas beaucoup d'intérêt. Les candidats ne débarquent pas de Mars. On imagine qu'ils ont un minimum de compétences sur le sujet en question.


Au final
Votre argumentation est vraiment décousue. Il n'y a aucun niveau de lecture qui permettrait de comprendre où vous voulez en venir. De nouveaux arguments sont venus compléter (mais en même temps contredire) votre postulat initial sans un poil d'explication. Vous semblez écrire les idées comme elles vous viennent.
Vous vous targuez d'être un bon Informaticien et, en même temps, vous réalisez un exposé qui se situe au niveau de ce que produisent ces "informaticiens" qui pensent être développeurs parce qu'ils alignent quelques lignes de code avec un poil de logique ...

Quand on se lance dans une longue explication, le minimum serait de faire un plan, de s'assurer que l'on répond à l'argumentation, que l'on n'avance pas des hypothèses contredites par les arguments déjà avancés, que toutes les phrases ont un sens. Tout ce qu'un informaticien de haut niveau rompu à la logique, l'analyse, la structuration, le refactoring devrait être capable de faire ...

Au delà du manque de rigueur de votre exposé (c'est en tout cas mon avis), je ne comprends toujours pas où vous voulez en venir ... ni même comment vous pourriez avoir des soucis sur le marché si vous êtes diplomé, expérimenté et compétent.

[axellink]

Que le "spécialiste" utilise le BABA du recrutement pour évaluer les candidats, cela en valait-il la peine d'en faire un article ?

Bah personnellement je trouve oui, je sors d'école d'ingé et même si je me doute bien qu'il faut donner le meilleur de soit même aux entretiens jamais je n'aurais pensé à une telle profondeur dans la réflexion du recruteur, enfin pour être exact, je n'aurais jamais su exactement sur quoi se focalise un recruteur. Je me serais focalisé sur un code qui tend à l'optimisation et qui soit relativement propre plutôt qu'à un code vraiment réfléchi qui soit facilement maintenable et déboggable.

[DonQuiche]

Bah personnellement je trouve oui, je sors d'école d'ingé et même si je me doute bien qu'il faut donner le meilleur de soit même aux entretiens jamais je n'aurais pensé à une telle profondeur dans la réflexion du recruteur, enfin pour être exact, je n'aurais jamais su exactement sur quoi se focalise un recruteur. Je me serais focalisé sur un code qui tend à l'optimisation et qui soit relativement propre plutôt qu'à un code vraiment réfléchi qui soit facilement maintenable et déboggable.

Un petit conseil : concentre-toi sur l'écriture d'un code propre (y compris maintenable et déboguable), oublie l'optimisation.

C'est vrai en général puisqu'on se fout des perfs dans 95% des cas et c'est encore plus vrai lors d'un entretien où il te suffit de dire "bon, ici on pourrait optimiser en faisant ça si c'est nécessaire".

N'hésite pas à demander, par exemple, "je peux vous proposer un algo en O(n²) et un autre plus long en O(n.ln(n)) mais puisque la liste n'a que quelques éléments je recommande de privilégier la lisibilité" (surtout qu'avec quelques éléments la complexité asymptomatique n'est pas forcément pertinente).

Comme expliqué dans l'article, justifier tes choix est important.

[23JFK]

le code résultant doit être « clair, bien organisé, lisible et au moins vaguement syntaxiquement correct ». Cela permet de juger facilement si le code est bien conçu et libre de bugs.

ça à l'air au point, leurs méthodes... Et la méthode pour recruter les recruteurs, il la décrit comment ?

[lankoande]

Pour ma part, cet article est le bienvenu.Il m'arrivait de me demandé ce qui pouvait bien se passer dans un tel recrutement.
C'est du même coût des conseils devant me permettre, de corriger mes habitudes obsolètes pour ne pas faillir à de pareils recrutements !!
Sur ce, merçi pour l'article.
Je le considère comme un conseil d'ainé.

[DotNET74]

Comme tout ce qui est fait par des recruteurs c'est du grand n'importe quoi !!!!

Ecrire du code sur un tableau blanc c'est revenir en arrière ...

On va faire quoi dans un entretien d'une heure sur un tableau blanc ?

un Hello Word !!!!

Ouahou quel niveau d'enfer !!!!

Avec ça, on recrute un super programmeur y a pas de doutes ....

[Reward]

Je peux comprendre l'exercice du tableau blanc. Je l'utilise moi-même pour raisonner en "patatoïde" et écrire des algos.

Cependant, si je recrute un dev, ce qui m'intéresse c'est de savoir si il est à l'aise avec son environnement.

Parvient il à utiliser correctement Visual Studio ? Eprouve t il des difficultés ? Est il lent ? Sait il utiliser un point d'arrêt ? des quick Watch ? Régler les propriétés du projet ?

C'est tout aussi intéressant à savoir je trouve, surtout depuis l'enrichissement de l'outil avec notamment TFS, le contrôleur de code source, etc...

C'est, à mon goût, incomplet.

[Luckyluke34]

Comme tout ce qui est fait par des recruteurs c'est du grand n'importe quoi !!!!

Ce n'est pas un recruteur mais Eric Lippert, programmeur qui a fait partie de l'équipe à l'origine du langage C# et lead developer sur le compilateur C# pendant longtemps.

On va faire quoi dans un entretien d'une heure sur un tableau blanc ?

Des exercices du genre implémenter une table de hachage, un programme qui mélange les éléments d'un tableau, etc. comme indiqué dans le blog.

Comme il le dit également, l'idée n'est pas de vérifier la syntaxe ou de faire que ça "compile" sur le tableau blanc mais de voir le raisonnement du candidat dans les grandes lignes et si c'est globalement propre et bien réfléchi.

Ca ne me parait pas totalement déconnant comme approche.

[Jitou]

Evaluer un candidat à un poste technique en informatique comme on ferait un casting pour un concours de chant ne répondra certainement pas au besoin de l'entreprise sur la durée. On recherche bien autre chose sur les projets que des compétences techniques bruts comme mentionné dans l'article. D'ailleurs très peu de RH on une idée précise de ce qui se passe dans un projet au quotidien et de la manière les différents protagonistes interagissent.

La capacité d'une personne à collaborer dans une équipe et être force de proposition mais aussi être porteur d'une certaine capacité de composer avec différents tempéraments sont des atouts majeurs pour bien avancer sur les projets. Les compétences purement techniques sont vraiment secondaires, on sait très bien que l'on peut être au top sur une techno sur un projet et devenir une bouse sur une autre techno sur le projet suivant et pourtant il faut faire avec et ça tous les décideurs opérationnels des SSII le savent très bien. Donc c'est là que le fonctionnement en équipe et pas en tant que compétiteur est crucial pour qu'une équipe projet fonctionne.

J'ai vu trop souvent des soit disant cracks recrutés uniquement pour l'étalage de leurs compétences techniques sur leur CV et qui étaient sur le terrain des projets incapables d'échanger avec d'autres qu'ils considèrent incompétents, souvent arrogants dans leur attitude et parfois suffisamment perfides pour verrouiller des composants du projet afin de démontrer leur toute puissance.

[RyzenOC]

Perso, je le testerais plus sur sa capacité a raisonné que de lui faire pisser du code.

Car c'est ça l'info pour moi, savoir traduire du français en langage algorithmique, pour les détails techniques, je lui fait confiance pour regarder la doc.

Comme dit précédemment, il y a aussi la connaissance de l'environnement de développement et de production a prendre en compte (l'os+l'ide), c'est loin d’être un détails

[Saverok]

C'est ce passage qui est le plus important pour moi et correspond assez bien à ce que je recherche à évaluer lorsque je fais passer un entretien

Ce qu’il recherche chez le candidat, c’est de savoir si ce dernier se jette immédiatement à l’eau et commence à coder ou prend soin de réfléchir à tous les contours du problème. Le candidat essaie-t-il de clarifier les zones d’ombre ou préfère-t-il émettre un tas d’hypothèses ? Le candidat préfère-t-il faire d’une pierre deux coups ou prend-il soin de découper le problème en morceaux et le résoudre progressivement ? Comment attaque-t-il le problème, par les parties faciles ou celles qui sont difficiles en premier ? Voici un ensemble de questions auxquelles Lippert essaie de trouver des réponses lorsqu’il est en face d’un candidat.

la syntaxe ou encore l'environnement de travail sont assez secondaire pour moi car cela s'acquière relativement rapidement.
A chaque fois que l'on change d'entreprise (ou client pour les presta), tout cela change
Ce n'est pas le principal, de mon point de vu.

Ce qui compte ; c'est l'analyse et la méthode

En général, je donne un code d'une cinquantaine de lignes max et je demande au candidat de l'analyser :
* qu'est ce qui ne va pas ? et pourquoi ? (le pourquoi est plus important encore que de trouver l'erreur)
* comment le corriger ? pour quel gain ? (en tenant compte de tous les aspects : maintenabilité, compréhension, évolution, perf, robustesse, etc.)

Le tableau blanc n'est là que comme support pour expliciter la conception.
Je ne demande jamais au candidat de réécrire toute la classe proposée, juste quelques fragments

Personnellement, dans mes équipes, je recherche des analystes développeurs.
L'erreur que font beaucoup de gens, surtout les débutants, c'est de ce focaliser sur la partie dev pure et de zapper l'analyse.
C'est une énorme erreur.
Si on veut "juste un dev", je prends de l'offshore.
La valeur ajoutée vient de l'analyse.

[Reward]

Ce qui compte ; c'est l'analyse et la méthode

En général, je donne un code d'une cinquantaine de lignes max et je demande au candidat de l'analyser :
* qu'est ce qui ne va pas ? et pourquoi ? (le pourquoi est plus important encore que de trouver l'erreur)
* comment le corriger ? pour quel gain ? (en tenant compte de tous les aspects : maintenabilité, compréhension, évolution, perf, robustesse, etc.)


Personnellement, dans mes équipes, je recherche des analystes développeurs.
L'erreur que font beaucoup de gens, surtout les débutants, c'est de ce focaliser sur la partie dev pure et de zapper l'analyse.

Je trouve que c'est une remarque très pertinente. L'analyse amènera une vraie plus value, notamment en termes de bonnes pratiques et d'œil avisé.

[Invité]

« Je ne suis pas à la recherche de personnes qui peuvent cracher du code syntaxiquement parfait », a déclaré Lippert; « ce n'est pas du tout le point de l'exercice de codage. J’essaie de découvrir comment vous résolvez les problèmes », a-t-il ajouté.

Le candidat idéal doit être « une personne bien organisée avec de bonnes compétences en résolution de problèmes », capable d’expliquer ce qu’il fait pendant qu’il le fait. Et le code résultant doit être « clair, bien organisé, lisible et au moins vaguement syntaxiquement correct ». Cela permet de juger facilement si le code est bien conçu et libre de bugs.

[...]

Lorsque le candidat arrive à proposer une solution, les recruteurs s’intéressent également à savoir si ce dernier fait confiance à sa solution et ce qu’il fait pour prouver qu’elle est correcte. Selon Lippert, le candidat ne devrait pas juste plaquer un code et dire que c’est correct, mais il devrait être en mesure de le prouver par des tests simples.

Bravo ! Eric Lippert viens de nous apprendre qu'un bon candidat programmeur est un bon algorithmicien. C'est quand même la base. Même si j'avoue qu'un certain nombre de programmeurs sortant des études n'en sont pas forcément conscients.

Pour les candidats fraichement sortis des écoles, les recruteurs sont conscients qu’ils ont souvent très peu d'expérience avec le monde réel. Ce qui est donc évalué chez ces derniers, c’est la « puissance intellectuelle brute, leur talent de codage et le potentiel à long terme. »

Que suis-je censé comprendre par "puissance intellectuelle brute" et "talent de codage" ?

[Traroth2]

C'est le point 11 du Spolsky-test permettant d'évaluer simplement la qualité méthodologique d'une équipe de développement.

http://www.joelonsoftware.com/articl...000000043.html

L'article date de 2000, quand même...

Comme le dit Joel Spolsky : si vous êtes responsable d'une boite de logiciel (par opposition à une DSI) et que votre équipe score à moins de 10, posez-vous des questions, parce que des boites comme Microsoft, Apple ou Google ont 12 sur 12 tout le temps !