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

À moins que vous n'utilisiez la programmation par paire de manière intensive dans votre développement réel, j'hésiterais beaucoup à l'utiliser. J'ai rencontré un grand nombre de développeurs professionnels de qualité qui ont mentionné une forte aversion pour la programmation en binôme et dont les compétences ne seraient pas bien évaluées dans un tel processus.

Answer 2

J'espère que vous avez un tas d'étapes à franchir avant celle-ci. Pour que ça marche, tu dois avoir un excellent CV et une bonne sélection téléphonique. Vous ne voulez pas perdre un temps fou avec des candidats à qui vous ne devriez pas parler en premier lieu.

Vous suggérez donc un premier entretien et éventuellement d'avoir le deuxième entretien comme une session de programmation en binôme ? - Ted Smith (1 min ago)

Ouais. Vous pourriez même envisager de faire passer un simple entretien de codage sur le web en utilisant quelque chose comme CoPilot .

Answer 3

Le moyen le plus simple est de donner à chaque personne le même programmeur avec lequel travailler et le même morceau de code.

Le problème que vous allez rencontrer, c'est que l'embauche n'est pas comme la programmation. Il n'y a pas de processus étape par étape qui mène à la bonne réponse quant à la personne à embaucher. (Vous pouvez avoir plusieurs étapes pour rendre la décision plus facile). Vous devez évaluer chacun d'entre eux en fonction de leurs points forts, etc. et essentiellement faire une supposition éclairée quant à la meilleure personne à embaucher. Parfois, vous vous trompez.

L'autre aspect de la programmation en binôme auquel vous devrez faire attention est le temps nécessaire pour faire passer ce genre de test à chaque candidat à ce stade. Si je cherchais un emploi, j'hésiterais à passer un entretien dans une entreprise qui me demanderait de faire cela. Pourquoi ? Parce que c'est beaucoup de temps, et si je passe des entretiens à plusieurs endroits, je pourrais passer littéralement des jours à passer des entretiens pour des emplois que je n'obtiendrai ou ne voudrai peut-être même pas. Des endroits comme Google ou MS seraient une exception, mais la plupart des endroits ne sont pas comme ces deux-là. (Sans parler du fait que s'ils travaillent sur du vrai code, vous leur demandez essentiellement de faire le travail de quelqu'un gratuitement).

Answer 4

Je viens d'avoir un entretien avec une entreprise de San Francisco qui est fière de ses méthodes agiles, etc. Je devais interviewer le PDG lui-même. J'ai une vingtaine d'années d'expérience dans le secteur, mais je n'ai jamais fait de programmation en binôme ni développé en utilisant l'approche TDD. On m'a dit qu'il s'agirait d'un "entretien de programmation", mais je n'avais aucune idée de ce à quoi je devais m'attendre, et avant de commencer, le type m'a dit qu'il pensait que je serais d'accord pour que tous les entretiens se déroulent de cette manière. (ce qui, rétrospectivement, n'était rien d'autre qu'une déclaration arrogante).

Bref, lors de l'entretien, l'exercice consistait à développer une classe en utilisant le TDD. Il m'a fallu une seconde pour ajuster ma pensée sur l'ensemble du processus, encore une fois parce que je n'avais jamais fait de programmation en binôme ou de TDD. Bien que j'aie trébuché ici et là, je m'en suis bien sorti à la fin. Mais il m'a répondu que je ne présentais pas la nature agressive du va-et-vient qu'ils exigent pour leur environnement de programmation en binôme. Maintenant, cela pourrait aussi être une manière sournoise de dire que "je n'ai pas trouvé que tu avais bien travaillé".

Heureusement, je n'ai pas eu besoin de ce travail et, pour être honnête, cette expérience m'a fait comprendre que je préférais trouver une autre carrière que celle d'ingénieur logiciel qui doit travailler à deux, jour après jour, pour développer du code. Le plus étrange, c'est qu'il m'est arrivé de travailler simultanément avec une autre personne sur du code, donc tout est possible.

En fin de compte, je suppose que c'était un bon résultat puisqu'ils ne pensaient pas que je convenais et que je n'aimais pas leurs méthodes de travail. Mais nous serions arrivés à la même conclusion si j'avais parlé un peu plus de moi pendant quelques minutes et s'il m'avait donné un peu plus d'informations sur leur façon de travailler. Ce qui veut dire qu'il y a d'autres moyens de trouver un candidat qui convient que de lui faire subir le stress de la programmation en binôme avec un parfait inconnu, ce qui n'est pas un bon moyen d'évaluer les compétences.

Answer 5

À titre d'anecdote personnelle, j'ai été malmené lors d'un entretien à cause d'une technique de ce type. J'étais allé loin dans leur processus d'entretien ; j'avais passé les vérifications du CV, la soumission du code et c'était la partie face à face de l'entretien.

Je venais de sortir de l'université et je n'avais jamais programmé en binôme ni fait de TDD. Ils m'ont fait asseoir pour faire un exercice de jeu de cartes et ça a foiré. Un échec cuisant ! Je ne comprenais pas pourquoi l'interviewer écrivait des tests qui semblaient si stupides* (par exemple "return null ;") et ils n'ont pas expliqué pourquoi et, bien sûr, étant étranger à TDD, je ne savais pas quelles questions poser. Le résultat final était que j'avais l'impression de ne pas pouvoir programmer pour sortir d'un sac en papier.

Si vous faites ce type d'exercice, vous devez vous adapter à la personne interrogée, car ses aptitudes seront différentes. Cela signifie que vous obtiendrez différentes évaluations qui ne seront peut-être pas basées sur le talent réel et qui seront donc fortement biaisées.

* Maintenant que je comprends le TDD, je comprends les tests de ce type et comment ils sont censés fonctionner, mais bon sang, cela semblait stupide à l'époque !