Publié par

Il y a 7 ans -

Temps de lecture 5 minutes

Software Craftsmanship 2012 – Pair Programming Interviews


L’événement nous ayant fait bonne impression l’année dernière (voir les billets écrits à l’époque), trois xebians sont repartis cette année à la conférence Software Craftsmanship, à Bletchley Park, aux alentours de Londres. Au programme cette année encore : des ateliers autour de notre pratique quotidienne du développement, le but étant de tendre vers une plus grande conscience du besoin de l’utilisateur et une réalisation plus pragmatique.

Un menu alléchant donc, qui a attiré beaucoup de participants. Ce qui a peut-être un peu nui à l’événement… Nous avons en effet déploré cette année le manque de discussion à la suite de la plupart des ateliers, qui ne se résumaient de fait plus qu’à des exercices assez scolaires (séquences de De Bruijn, algorithme A*, machine Enigma).

Mais nous avons tout de même trouvé quelques bons morceaux, que nous allons vous restituer sur ce blog, et ce dès la section suivante.

Pair Programming Interviews

Déroulement de l’atelier

Cet atelier avait pour but de faire découvrir à certains, et de peaufiner pour d’autres, la pratique de la programmation à deux à des fins d’entretien d’embauche. La technique consiste à se mettre sur un poste avec le candidat afin de voir et « sentir » ses capacités à concevoir et coder la résolution d’un problème, mais aussi à collaborer avec ses futurs collègues.

Les organisateurs ont proposé à cette fin aux participants de se répartir en groupes de trois personnes, chacune ayant un rôle à jouer :

  • un candidat : il doit résoudre l’exercice, son but est de se faire embaucher ;
  • une personne conduisant l’entretien : il introduit l’exercice au candidat, l’aide un peu au besoin, le questionne sur ses choix, et conclut l’entretien ;
  • un observateur : il ne participe absolument pas et note tout ce qui retient son attention à propos du candidat ou de l’interviewer : questions, réponses, choix techniques, méthodologie, etc…

Deux sessions d’une heure ont été réalisées ainsi, chacun changeant de groupe et/ou de rôle entre les deux. Les exercices étaient assez simples pour ne perdre personne, avec juste la touche de complexité nécessaire à la situation :

  • le premier exercice proposait d’écrire un programme calculant le montant total d’un panier d’articles, certains articles pouvant être sujets à des offres promotionnelles en fonction de leur nombre ;
  • le deuxième exercice revisitait la suite de Fibonacci en demandant une fonction retournant la somme des nombres pairs d’une suite de taille N, N étant donné en paramètre.

Bilan collectif

Suite à ces deux sessions, une discussion générale sur la pratique a été lancée, dont voici les points principaux.

Tout d’abord, certains ont été grandement pénalisés par l’environnement utilisé : coder du Java sous Eclipse avec un clavier français va forcément laisser un goût amer à un Rubyiste codant habituellement sous IntelliJ avec un clavier US (désolé Andy, mais j’avais mis le layout US pourtant :D ). Au delà de cet exemple extrême, il est probablement préférable de laisser le choix de son environnement au candidat, quand cela est possible et en accord avec le poste pressenti pour lui. En effet, un entretien c’est court, et l’on aura au mieux peu d’impressions sur le candidat, et au pire une impression biaisée si on le met dans ces conditions. Même s’il montre des capacités d’adaptation, cela risque d’être insuffisant.

Ensuite, les consignes de l’exercice ne proposaient pas de faire du pair programming stricto sensu, le clavier restant dans les mains du candidat. Nous étions quasiment unanimes sur le fait que bien que cela soit intéressant au début, il est ensuite encore plus intéressant de vraiment pairer avec le candidat, en échangeant le clavier avec lui, et en suivant par exemple un rythme de TDD : j’écris un test, tu le fais passer et écris le test suivant, je le fais passer et écris le test suivant, etc… Cela nous renseigne sur les capacités d’adaptation et de collaboration du candidat : est-il prêt à travailler avec nous ? S’intégrera-t-il bien dans l’équipe ? Et à l’inverse : sommes-nous capables de travailler avec lui ? Après tout, l’entretien peut aussi être riche d’enseignements pour l’interviewer.
On notera que des participants ont mentionné des entreprises allant déjà plus loin dans cette pratique : le candidat y est carrément engagé pour une journée de travail réel en pair programming au sein de l’équipe, suite à quoi il sera invité à rester ou non.

L’entretien à distance a également été l’objet de la discussion. Est-il souhaitable ? Donne-t-il les mêmes résultats ? L’un des sponsors de l’évènement, 7digital, a déclaré faire de tels entretiens, quand le candidat était trop éloigné. À la manière de Google, ils utilisent des solutions permettant de faire l’exercice en direct (visualisation de l’écran du candidat, voire édition collaborative) afin d’être au plus près des conditions réelles, et ils s’en disent satisfaits.

Enfin, l’observateur a fait en général beaucoup de retours très intéressants à la fois sur le candidat et sur l’interviewer. Au point que l’on pourrait se poser la question d’introduire un observateur lors d’entretiens réels, afin d’avoir un avis plus précis sur le candidat, mais aussi dans une optique d’amélioration continue de l’entretien. Évidemment, ce qui fonctionne lors d’un rassemblement de software craftsmen peut être plus difficile à faire passer dans en situation générale.

Conclusion

Beaucoup d’autres points ont encore été mentionnés, comme par exemple la manière et le moment de déclarer l’entretien terminé si le candidat ne convient pas. Je dirais que ces points sont moins liés à la pratique du pair programming elle-même qu’à la gestion d’un entretien d’une manière générale. Ce qui est marquant au final, c’est que tous étaient convaincus de la pertinence de cette pratique pour conduire un entretien d’embauche, tant pour évaluer les compétences techniques que sociales du candidat. Chez Xebia également nous en sommes convaincus : c’est une des étapes de l’embauche :-)

Quel est votre avis sur la question ?

Publié par

Publié par Nicolas Demengel

Nicolas est arrivé chez Xebia en 2010 et a 5 ans d'expérience sur le développement d'applications Java/Web.

Nicolas est un développeur passionné et pragmatique. Il aime la technologie mais n'oublie pas que la finalité d'un produit, c'est le service rendu à l'utilisateur.
Son credo : un produit doit se construire et prouver sa qualité avec du feedback et des tests !

Pour cette raison, Nicolas travaille également sur le plug-in MoreUnit pour Eclipse.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.