Programmation en binôme pour un entretien d'embauche

Question

Notre entreprise a envisagé d'abandonner nos procédures d'entretien et de faire venir chaque candidat pour un entretien de 4 à 5 heures avec certains des programmeurs et de faire simplement de la programmation en binôme.

J'aime l'idée en théorie mais je ne suis pas sûr que l'on puisse vraiment rendre les choses équitables pour chaque candidat. Comment les évalueriez-vous ? Leur contribution ne dépendrait-elle pas vraiment de ce sur quoi chaque programmeur travaille ce jour-là ?

Je cherche à savoir si c'est une bonne ou une mauvaise idée ou comment la faire fonctionner.

A la vôtre !

EDITAR:

RÉSULTAT - Comme demandé

Nous allons procéder aux premières étapes de l'entretien de la même manière que précédemment. Téléphone puis face à face. Au lieu de les faire revenir pour un troisième et dernier entretien, nous allons faire revenir 3 développeurs pour qu'ils s'assoient avec les 7 membres de l'équipe. Nous avons décidé de laisser l'équipe décider qui sera ensuite embauché.

Nous sommes parvenus à cette conclusion pour plusieurs raisons. Nous pensons que cela donnera plus de pouvoir aux développeurs en leur permettant de choisir avec qui ils travaillent. La deuxième raison est la dynamique de groupe. Nous pensons qu'il est très important d'avoir une bonne dynamique de groupe et il est difficile de savoir, avant d'engager une personne, si elle s'intégrera ou non.

Le résultat final est donc que nous allons poursuivre les sessions de programmation en binôme, mais d'une manière complètement différente et pour un objectif complètement différent de celui qui était prévu à l'origine.

Toute réflexion ou critique sur cette approche est plus que bienvenue ! (cette modification est affichée comme une réponse ci-dessous, alors n'hésitez pas à décoter si vous pensez que ce n'est pas la meilleure approche).

Answer 1

J'ai eu un entretien de programmation en binôme il y a quelques jours et, pour être honnête, je n'aime pas vraiment ça. J'en ai été informé un jour avant l'entretien et l'interviewer m'a dit que la programmation en binôme était ce que je ferais de toute façon au travail. Je me suis rendu au bureau et j'ai été jumelé avec un ingénieur logiciel très expérimenté. L'entreprise est située à San Francisco et elle est réputée pour la programmation en binôme, tout le monde programme en binôme au bureau. Au début, tout semblait bien se passer, il m'a expliqué tous les outils qu'ils utilisaient, leur propre cadre de test unitaire qu'ils construisent, et un peu du projet. Il a ensuite écrit une série de tests unitaires et voulait que je travaille sur l'implémentation pour les faire passer. Juste pour info, la base de code qui existe déjà est énorme, je dirais 10 000 lignes, ce n'est pas un projet super complexe, mais il est complexe pour quelqu'un de se lancer et d'écrire du code sans compréhension préalable de la hiérarchie des classes, etc. J'ai vraiment du mal à croire qu'il s'attende à ce que quelqu'un saute tout de suite dans un code source de 10 000 lignes qui existe déjà. Je trouve vraiment difficile de croire qu'il s'attend à ce que quelqu'un se lance immédiatement dans un code source de 10 000 lignes qui existe déjà. Cela ne correspond pas à un entretien de programmation en binôme. J'ai eu un peu de mal à naviguer dans les classes et à faire des allers-retours parce que je ne me souviens pas des noms des classes et que j'étais submergé par la quantité de classes/code qui existe déjà. Pour être honnête, cela m'a vraiment fait mal lors de l'entretien. À la fin, je ne me sentais pas vraiment bien. Je n'ai jamais fait de programmation en binôme auparavant, la plupart du temps, c'était juste pendant les devoirs de mon année universitaire.

Selon moi, la puissance de la programmation en binôme peut être exploitée si vous êtes déjà compétent et à l'aise avec votre binôme, mais elle ne convient pas vraiment aux entretiens. Parfois, j'aimerais poser des questions à mon binôme, mais je me suis dit que si je posais trop de questions, ils penseraient que je suis stupide et que je ne peux pas être performant. Si c'était déjà dans un vrai travail, je n'hésiterais pas à demander, mais dans un entretien, c'est difficile vous voulez demander parce que votre binôme devrait vous aider quand vous êtes bloqué, mais en même temps, c'est un entretien, donc vous ne pouvez pas vraiment demander beaucoup.

C'est juste l'expérience que j'ai acquise lors d'un entretien de programmation en binôme, ma suggestion si vous voulez vraiment le faire :

1. Assurez-vous que vous ne donnez pas au candidat la possibilité de travailler avec une grande base de code, mais plutôt avec une base plus petite. plus petite, ce qui lui permettra de montrer ses compétences au maximum.
2. soyez franc avec le candidat avant l'entretien de programmation en binôme, vous pouvez poser des questions lorsque vous êtes bloqué, devez-vous être capable de faire ceci et cela, que ne pouvez-vous pas faire ?
3. être aussi détaillé que possible

En fin de compte, je ne le suggérerais pas. Il est difficile de mesurer les performances d'un candidat en programmation en binôme, et cela pourrait aussi être biaisé.

Answer 2

Une entreprise particulière utilise une technique appelée entretiens extrêmes . Pour l'entretien extrême, ils font venir 30 développeurs et les regroupent en 15 paires. Ils expliquent qu'ils recherchent des personnes qui travaillent bien avec les autres. Qu'ils prendront une décision d'embauche uniquement sur la base de leur capacité à travailler avec les autres.

Ils fourniront un problème que les paires devront résoudre. Ils insisteront sur le fait que la solution ne les intéresse pas, mais seulement la capacité de chaque programmeur à travailler avec d'autres. Pour chaque paire, ils fourniront un observateur de la paire. Pendant l'exercice (d'une durée de 2 à 4 heures), l'observateur prendra des notes sur la capacité de la personne à travailler en binôme... et non sur la solution.

Ils sont étonnés de voir combien de programmeurs se concentrent sur la résolution du problème au lieu de collaborer. Sur les 15 paires, ils identifieront environ 4 à 6 développeurs pour un second entretien. Ces développeurs sont invités à revenir et à passer une semaine avec l'équipe (ils sont payés). Après une semaine, ils décident qui garder. En général, environ la moitié d'entre eux (2 à 3 développeurs).

Lorsqu'ils ont terminé, ils ont des développeurs capables de collaborer et, après une semaine de travail avec différents binômes, l'équipe a une bonne idée de qui peut développer efficacement un logiciel. Le processus est à la fois innovant et efficace. L'entreprise a obtenu un taux de réussite élevé avec les personnes qu'elle a embauchées.

Answer 3

J'aime cette idée. Cependant, je pense qu'elle pourrait être difficile à réaliser car elle exigerait que le candidat ait une certaine connaissance du projet sur lequel vous seriez en binôme avec lui. En outre, 4 à 5 heures semblent un peu longues. Et si vous voyez immédiatement que ça ne va pas marcher, allez-vous rester assis pendant toute la session avec le candidat ?

Bonne question cependant. Des choses auxquelles il faut penser.

Answer 4

Pourquoi pas ? De plus, ce n'est pas comme si les entretiens étaient toujours (ou jamais) équitables. Vous devriez évaluer les résultats finaux de la nouvelle approche par rapport à l'approche traditionnelle basée sur les entretiens.

De même, un mini entretien avant la session de programmation en binôme pourrait être utile pour éviter de faire perdre du temps aux programmeurs avec des personnes qui ne conviendraient pas.

Answer 5

D'après mon expérience limitée, mes sentiments sont mitigés. J'aime l'idée du jumelage dans le cadre d'un entretien, surtout si l'entreprise y a souvent recours, car cela permet aux deux parties de mieux se rendre compte de l'adéquation. En tant que candidat, j'ai souvent passé des entretiens où j'étais assis dans une pièce à répondre à des questions pendant quelques heures, mais où je n'avais pas une bonne idée de ce que ce serait vraiment de travailler dans cet environnement. Le travail en binôme peut être plus bénéfique qu'un exercice de codage aléatoire, à moins que l'examinateur ne soit capable de faire travailler quelqu'un sur ces exercices. Et j'aime pouvoir discuter des aspects techniques des deux côtés. Et en tant que candidat, je préfère interagir avec quelqu'un plutôt que de me contenter de répondre à des questions ou de résoudre des problèmes de code tout seul.

Mais... comme d'autres l'ont noté, le temps nécessaire peut être un problème. J'ai passé quelques jours d'entretiens d'appariement et j'ai trouvé certaines périodes bonnes, tandis que d'autres m'ont donné l'impression d'avoir perdu quelques heures : l'une parce que le développeur ne travaillait pas sur quelque chose qui se prêtait à l'appariement (compte tenu de mon expérience), l'autre parce qu'un problème d'environnement a empêché tout travail utile pendant un certain temps. Si le travail n'aboutit pas, il peut être frustrant d'avoir pris un jour ou deux de congé pour cela.

Une entreprise qui a essayé cette approche n'était pas sûre de devoir faire travailler une personne extérieure à l'entreprise sur le projet d'un client. Elle craignait également que l'explication du domaine et du travail effectué ne prenne trop de temps, sans quoi le candidat ne serait peut-être pas en mesure d'apporter une grande contribution. Ils ont donc choisi un projet open source sur lequel l'employé travaillait.

Cela semble être un point essentiel : il doit y avoir une tâche bien choisie que le candidat peut comprendre rapidement et à laquelle il peut contribuer. Cette dernière partie dépendra quelque peu des compétences du candidat. La capacité de l'employé à évaluer quelqu'un avec cette approche sera également déterminante. Tout le monde n'est pas doué pour les entretiens normaux, et c'est probablement plus vrai pour les entretiens en binôme.

En outre, si une entreprise ne fait pas beaucoup d'appariement, ce type d'entretien peut ne pas être aussi utile. Il semble y avoir un avantage à voir quelqu'un coder (comme le note Joel Spolsky), et cela pourrait être un bon moyen de le faire. Mais si le jumelage n'est pas une partie typique du travail, alors peut-être qu'une session complète de jumelage n'est pas appropriée. Peut-être une version modifiée.

Je serais curieux de savoir ce que les entreprises qui ont adopté cette approche pensent des résultats. La lecture de certaines des autres réponses à cette question montre qu'elle ne semble pas toujours idéale du point de vue du candidat.