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

Le , par Michael Guilloux, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Orgoff Orgoff - Membre averti https://www.developpez.com
le 02/06/2015 à 22:00
Citation Envoyé par Michael Guilloux Voir le message
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 ?
Avatar de axellink axellink - Membre à l'essai https://www.developpez.com
le 02/06/2015 à 23:26
Citation Envoyé par Orgoff
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.
Avatar de 23JFK 23JFK - Membre expérimenté https://www.developpez.com
le 03/06/2015 à 0:43
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 ?
Avatar de lankoande lankoande - Membre confirmé https://www.developpez.com
le 03/06/2015 à 3:07
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é.
Avatar de DotNET74 DotNET74 - Membre expérimenté https://www.developpez.com
le 03/06/2015 à 7:32
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 ....
Avatar de Reward Reward - Membre confirmé https://www.developpez.com
le 03/06/2015 à 9:38
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.
Avatar de RyzenOC RyzenOC - Inactif https://www.developpez.com
le 03/06/2015 à 9:59
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
Avatar de DarkBakura DarkBakura - Membre actif https://www.developpez.com
le 03/06/2015 à 11:01
Citation Envoyé par Orgoff Voir le message
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.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 03/06/2015 à 11:59
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

Citation Envoyé par Michael Guilloux Voir le message

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.
Avatar de Reward Reward - Membre confirmé https://www.developpez.com
le 03/06/2015 à 14:19
Citation Envoyé par Saverok Voir le message

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é.
Contacter le responsable de la rubrique Accueil