40 votes

Programmation en binôme pour un entretien d'embauche

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

1voto

tkotitan Points 2109

Pour être équitable, il faudrait que chaque membre du personnel participant ait un problème préparé pour évaluer le candidat. De préférence, il s'agit d'un problème tiré du monde réel de leur expérience en entreprise, mais qui a déjà été résolu. C'est une bonne occasion d'évaluer les connaissances sur un problème et pas seulement les compétences en programmation.

Je déteste quand on répond à des questions trop spécifiques. Lors d'un entretien, un programmeur testait mes connaissances de la STL, que j'utilisais beaucoup, et essayait de me faire répondre qu'un allocateur personnalisé était nécessaire. J'en avais entendu parler mais je ne les avais jamais utilisés (surtout sous Windows) et j'ai dû me sentir stupide. Autrement dit, évitez de porter un jugement.

Ce que je veux dire, c'est qu'il faut poser des questions pratiques qui ne visent pas tant à tester les connaissances en programmation qu'à évaluer la personnalité et les approches de résolution de problèmes plus qualitatives si vous utilisez l'idée de la "programmation en binôme".

Bonne question !

1voto

chaos Points 69029

Honnêtement, cela semble être une excellente idée, bien que Jason Punyon ait certainement raison de dire que vous devriez faire beaucoup d'efforts avant de gaspiller une grande partie du temps de vos développeurs sur des abattages. Vous obtenez un aperçu d'une mesure importante qui est autrement presque impossible à obtenir lors d'un entretien : ce qu'il est agréable de travailler avec quelqu'un.

Je ne pense pas qu'il faille vraiment s'inquiéter de savoir si l'exercice est "équitable" en fonction du sujet ou si l'on essaie de présenter des situations cohérentes à différents candidats, si l'on conserve la bonne attitude d'évaluation - à savoir qu'il ne s'agit pas de savoir s'ils ont "la bonne réponse" ou s'ils ont franchi la bonne série d'obstacles, mais plutôt de savoir quel type d'effort, de résolution de problèmes, d'aptitude à la communication et de flexibilité ils ont montré. Vous perdriez la plupart des avantages de l'exercice en le transformant en un test artificiel, sans parler du fait qu'il ne s'agit plus d'un exercice dont vos développeurs peuvent tirer un certain bénéfice (ou du moins pendant lequel ils peuvent encore travailler) mais d'une perte de temps considérable.

0voto

antonm Points 1869

Joel Spolsky a un excellent Guide de guérilla pour les entretiens d'embauche qui traite, entre autres, des tâches de programmation.

Trivia : Joel Spolsky est co-fondateur de stackoverflow.com.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X