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 ?

[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.

[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.

[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

[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.

[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é.

[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.

[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 !

[Frédéric Latour]

Un bon développeur est une personne qui est capable d'établir des stratégies de résolution de problèmes.
Développer un logiciel c'est résoudre des problèmes.
Le développeur a à sa disposition un ensemble d'outils : environnement de développement, documentation (google, articles, ...), formation (patterns, différents principes de développement formalisés), logique, ...
L'expérience m'a montré que ce qui fait la différence entre plusieurs développeurs c'est la capacité à établir rapidement une stratégie de résolution pertinente ...

J'ai un problème dont je n'ai pas la solution à priori (normal). Quelle stratégie de résolution vais-je mettre en oeuvre?

Il est tout à fait possible d'écrire un programme simple en exploitant uniquement de la logique de base. Confronter un développeur à un bug, une anomalie ou une problématique plus complexe permet de se rendre compte si ce dernier est capable de créer une stratégie de résolution efficace. Et là les choses se compliquent souvent ...

En la matière, dans la plupart des écoles, c'est le néant ... Dans les faits, soit l'ingénieur (ou presque ingénieur) a développé personnellement des qualités intellectuelles lui permettant d'établir ce type de stratégies soit c'est juste la misère ... Je sais que ce commentaire ne plaira ni aux écoles qui s'appuient sur leur (supposée) réputation pour attirer, ni aux élèves bien évidemment ...
Mais au final, l'école n'a strictement aucune importance ... les différences de niveau entre ingénieurs d'une même école (on non) sont considérables ... et relève surtout des qualités personnelles de l'ingénieur...

Quelques remarques:
Le concept de developpeurs qui ne sauraient pas analyser me semble complètement farfelu ... Passer de l'expression des besoins à un programme sans analyse? Développer à partir d'une analyse détaillée qui serait tellement détaillée qu'elle constituerait presque un programme n'a pas de sens ... Elle n'en n'avait pas plus à l'époque où c'était pourtant une habitude dans le développement de logiciels de gestion spécifiques ...

Au final, je trouve l'article d'Eric Lippert plutôt pertinent ... Il décrit assez bien la démarche qui permet de tenter d'évaluer les qualités intéressantes chez un développeur...

[sgaze]

Quand j'ai vu le titre de cet article, je m'attendais à un article plus exhaustif.
L'écriture de code sur tableau blanc n'est pas systématique. Dans mon cas, 1 fois sur 5 entretiens techniques.

Souvent on est confronté à un QCM a remplir en quelques minutes avec des questions de type "certification".
Ou alors à une conversation à battons rompus sur différents thèmes : algorithme, conception, bonnes pratiques, sécurité, design patterns etc.
Egalement des questions de culture générales pour mesurer l'implication dans les communautés techniques, la veille technique etc.

[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é.

[serenodo]

Super cet article.
Si j'avais su cela avant je serai en place comme développeur et non comme technicien helpdesk Niv1.
J'aurai agit totalement différemment lors de mes rares entretiens de programmeur.

[Saverok]

Super cet article.
Si j'avais su cela avant je serai en place comme développeur et non comme technicien helpdesk Niv1.
J'aurai agit totalement différemment lors de mes rares entretiens de programmeur.

Ne t’avance pas trop vite non plus
Comme dit par didier.cabale, malheureusement, l’entretien technique n’est pas tjrs assuré par un technicien.
La manière de mener l’entretien technique tel que préconisé par M. Lippert ne peut se faire que par un technicien.
Un RH, un commercial ou un CP non technique ne possède pas le niveau de compétence pour être dans la discussion et dans l’analyse du raisonnement. Eux, ils raisonnent par grille et attendent des termes et expressions précises car justement, ils ne maîtrisent pas le sujet.
Rien de plus normal, ce n’est pas leur job.
C’est juste regrettable qu’ils se retrouvent à le faire, beaucoup trop souvent.

Autre point très important en France et particulièrement con et injuste : la dictature des diplômes.
En France, il faut un diplôme pour chaque chose.
Les grilles de salaires se construisent comme ça et les RH sont incroyablement butés là-dessus jusqu’à l’absurde.
Ce n’est pas tout de savoir répondre à un entretien technique, encore faut-il arriver jusque-là.
Personnellement, tous les candidats que je rencontre passent par le filtre RH avant et je n’ai jamais eu l’occasion de m’entretenir avec un candidat qui avait moins qu’un BAC+3 informatique. Plus généralement, ce sont même des BAC+5…

[landry161]

Bon article.