Quelle est l'efficacité des défis de programmation dans le processus de recrutement? [fermé]

Je pense que notre entreprise peut créer des défis conçus pour trouver des candidats ingénieurs logiciels qui sont:

• Bon pour résoudre les problèmes, pas pour épater les recruteurs.
• Plus susceptibles d'avoir peur de venir à nous lors d'un salon de l'emploi.
• Plus susceptibles d'être sous-utilisés dans leur travail de programmation actuel, mais sont trop introvertis pour y faire quoi que ce soit.

Pour un exemple, consultez cet article qui explique que Facebook cache une adresse e-mail dans une image à l'aide de Piet .

Je ne peux tout simplement pas trouver d'études ou de données fiables sur le fait que cela fonctionne ou non.

Comme tout outil, ils peuvent être extrêmement utiles ou extrêmement dangereux. Une perceuse électrique vous facilitera la vie tellement - jusqu'à ce que vous percez le haut de votre main et que vous vous posiez aux urgences. Il en va de même pour les problèmes de programmation liés au recrutement.

Le bon : cela peut être un moyen efficace de détecter quelqu'un qui, sur le papier, n'est peut-être pas si convaincant en tant que programmeur. Celui qui a un diplôme dans quelque chose qui a très peu à voir avec ce que les gens considèrent normalement comme des domaines liés à la "programmation" - biologie, science politique, histoire de l'art ...

S'ils traversent vos défis, c'est parfait. Ils ont appris la programmation, d'une manière ou d'une autre, et c'est apparemment bloqué. S'ils s'embourbent, leur demande peut vraiment être quelque chose qui a glissé dans les RH.

Le mauvais : un défi de programmation mal écrit n'évalue pas réellement les compétences en programmation . Il teste la résolution d'énigmes via des compétences en programmation . Le problème est que la dernière est une question à deux variables - êtes-vous bon dans la résolution de casse-tête, et pouvez-vous faire cette résolution de casse-tête via du code. Il est possible d'avoir un programmeur parfaitement talentueux qui échoue complètement à la partie de résolution de casse-tête.

La plupart des défis de programmation que j'ai vus échouent également à détecter les personnes proches de ce que vous voulez, selon la façon dont cela est écrit.

Il existe des moyens d'atténuer les deux. Pour ce dernier, j'envisagerais d'accepter le «crédit partiel» sous la forme de solutions qui ne semblent pas vraiment y arriver, «voici comment je résoudrais cela ...» etc. si vous cherchez vraiment un problème solveurs. Après tout, très peu de gens codent tout seuls, et si leur réponse aurait été juste s'ils pouvaient demander à un collègue senior "Hey Jim, connaissez-vous une bonne façon de mettre en œuvre X?", Cela pourrait très bien être quelqu'un sur qui vous voulez ton équipe.

Le premier est un peu plus difficile, car le fardeau est à votre charge. Choisissez des puzzles / problèmes / défis qui comptent. Si personne dans votre groupe n'a jamais rencontré quoi que ce soit de semblable à distance au problème du voyageur de commerce dans son travail, ne faites pas un tour intelligent au voyageur de vente le défi que vous rencontrez. De cette façon, s'ils échouent à l'aspect de résolution de problèmes de "résoudre le problème et le coder", ils échouent au moins à quelque chose qui va réellement se produire, plutôt qu'à un peu d'intelligence arbitraire que votre équipe a craché pendant le déjeuner.

Très efficace.

... tant que votre processus de recrutement ne contient pas seulement des défis de programmation. Alors que je FRET et déteste faire l'évaluation technique de toute entrevue, il fait agir comme simple , jauge pour filtrer les idiots. Et filtrer les idiots est au cœur du processus de recrutement, vous pouvez donc consacrer plus de temps à ceux qui sont aptes à occuper ce poste.

Lors des entretiens, je considère qu'il est très important de voir ce que les gens disent sous pression. S'ils sont enclins à cracher un tas de merde flagrante, c'est facilement identifiable et je sais que cette personne ne vaut pas mon temps.

Plus susceptibles d'avoir peur de venir à nous lors d'un salon de l'emploi.

Ce n'est pas une mauvaise chose. Si votre candidat potentiel n'est pas prêt à parier qu'il mérite d'être employé là-bas, voulez-vous vraiment le recruter de toute façon?

Je suppose que vous voulez que quelqu'un travaille en équipe - en tant que tel, le meilleur programmeur est la personne qui travaille mieux avec les membres de l'équipe existants. Vous voulez rassembler un groupe de personnes qui peuvent communiquer efficacement entre elles, qui s'entendent bien entre elles (elles ne doivent pas nécessairement être amies, mais elles ont besoin de bonnes relations et de respect), qui sont utiliser des normes de développement communes (code et processus), qui sont prêts à aider leurs collèges lorsqu'ils font face à un nouveau problème ou ont un blocage mental (théorie des quatre yeux). Vous devez également trouver un mélange de types de personnalité, donc si vous avez une équipe d'introvertis qui parlent rarement, alors faire appel à un membre de l'équipe plus bavard peut bien améliorer la dynamique de l'équipe, ce qui rendra l'équipe plus productive. D'autre part,

Après avoir fait en sorte qu'une personne s'intègre dans ce mélange, envisagez les compétences / aptitudes techniques. Celles-ci aussi doivent compléter. Chacun a des domaines différents dans lesquels il est fort, d'autres où il va bien et certains où il n'a aucune idée. Vous devez donc rassembler un ensemble de forces pertinentes pour le projet en cours. N'oubliez pas qu'un codeur intermédiaire qui fonctionne bien avec un bon codeur verra le niveau de son travail élevé par la personne la plus forte. Le maillon faible de la chaîne est les relations, pas les compétences (à condition que la compétence soit dans l'équipe)

Bonne chance pour mettre cela ensemble.