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 ?