Échantillons de code et interviews? [fermé]

J'ai vu un certain nombre de questions depuis que je suis ici où, dans la réponse, quelqu'un a affirmé qu'il n'utiliserait jamais de portefeuilles ou d'échantillons de code codés en dehors du processus d'entrevue pour juger un candidat, car il est possible que code ayant été écrit par quelqu'un d'autre. Je m'étonne de cela.

D'après ce que je vois, si je demande à quelqu'un de venir résoudre un problème simple sur place, je ne peux pas en tirer grand-chose. Je ne travaille pas pour une entreprise comme Google où les emplois sont recherchés et je peux demander une journée de temps à quelqu'un. Mais un morceau substantiel de code écrit par un passe-temps peut m'en dire beaucoup.

Oui, il existe un risque de plagiat, mais ils devront être très bien encadrés pour passer une discussion d'une heure sur ce code. Et si tel est le cas, ils devront être des apprenants très rapides pour passer leur probation de 3 mois (au cours de laquelle je pourrai m'en débarrasser sans raison et sans préavis). S'ils deviennent de bons programmeurs aussi vite, assez bien, j'ai été dupé, mais j'ai toujours un bon programmeur.

Au final, le coût pour notre entreprise et l'avantage pour le candidat au plagiat est très minime.

Cela m'a fait penser à d'autres industries. Artistes, photographes, designers utilisent tous des portefeuilles et personne ne s'inquiète trop du plagiat là-bas. Un auteur sera financé pour un livre basé sur des chapitres qu'il a écrits en son temps. Vous ne demanderiez pas à un architecte de venir dessiner les spécifications de conception d'une maison lors de l'entretien.

Alors qu'est-ce qui nous rend différents? Pourquoi est-il si important de mettre quelqu'un devant un ordinateur et de lui faire coder une fusion de données ou une calculatrice factorielle, parfois sans avoir accès aux outils mêmes que nous utilisons au quotidien, comme Internet? Quel est le problème avec l'idée d'un portefeuille de codes?

Je suis vraiment intéressé de savoir, au cas où je ferais potentiellement une énorme erreur qui ne m'a pas encore brûlé.

Mon objection à un portefeuille n'a rien à voir avec le risque que l'entreprise soit dupée par quelqu'un qui copie du code à partir d'Internet ou, plus probablement, qui fait passer du code écrit par une équipe de développeurs comme travail. Comme vous le faites remarquer à juste titre, vous pouvez en apprendre au moins autant en demandant à un développeur de parler d'un projet qu'il connaît généralement pendant une heure que de le faire coder une calculatrice factorielle à partir de zéro.

Mon objection à un portefeuille est que le fait d'exiger un portefeuille élimine de nombreux développeurs talentueux de la considération. Étant donné que, contrairement à un artiste ou à un photographe, je ne conserve pas le droit d'auteur sur le code que je produis - il appartient à mon employeur et / ou à l'entreprise qui a passé un contrat avec mon employeur - je ne peux pas montrer la grande majorité des " intéressant "code que j'ai écrit. Si je code sur mon propre temps, ce sera généralement un projet parallèle au travail qui me facilitera la vie ou qui me dérangera juste que je ne pourrai pas montrer dans un portfolio. J'ai des tonnes de messages dans divers forums, mais la plupart d'entre eux sont, par conception, relativement peu profonds. Il y a une population assez importante de développeurs solides qui sont dans une position similaire - leur code intéressant appartient à quelqu'un d'autre. Et si tu'

Un entretien technique où tous les candidats sont invités à coder quelque chose à partir de zéro fournit au moins des conditions équitables. En supposant que vous fassiez un travail raisonnable pour faire l'écran du téléphone et que vous pouvez restreindre les candidats à une liste raisonnable, je préférerais de beaucoup, en tant que candidat, avoir un problème à résoudre que vous savez que cela va prendre 8 heures d'effort que de proposer un portefeuille cohérent d'applications de jouets sans problème de droit d'auteur.

Tout d'abord, nous sommes des ingénieurs, pas des artistes. Nous travaillons en équipe, donc dans notre vraie expérience de travail, "notre" code est souvent le résultat d'un travail d'équipe, parce que c'est généralement ainsi que le vrai travail est effectué. Il n'y a pas beaucoup de code professionnel pour lequel je pourrais revendiquer la propriété exclusive.

Deuxièmement, la plupart des codes de mon portefeuille hypothétique seraient des codes que je ne pourrais montrer à personne, car ils sont confidentiels. Le code que j'ai créé pour mes projets personnels pour animaux de compagnie ne reflète pas nécessairement toutes mes compétences et mon comportement de travail typique.

J'ai interviewé beaucoup de gens pendant mon temps en tant que praticien de logiciel. J'ai atteint un point où je crois que les quiz et les affectations de programmation de jouets sont un gaspillage de bande passante précieuse. Les quiz et les affectations de programmation de jouets ne servent qu'à tester ce que l'intervieweur sait. Ils ne sont pas un moyen précis d'évaluer ce qu'un candidat sait. À ce stade de ma carrière, je n'accepte ce type de non-sens que si et seulement si j'ai la possibilité d'administrer mon propre test à la fin de l'entretien.

La meilleure façon d'évaluer les capacités d'un praticien du logiciel est de lui parler d'une voix calme et rassurante. Demandez au candidat de discuter des implications de son poste actuel. Lorsque le candidat évoque un domaine d'intérêt, demandez-lui de développer ce domaine. Le but ici est d'amener le candidat à baisser sa garde. Aucun encadrement ne peut préparer un candidat à l'interrogatoire "soft touch". Tôt ou tard, l'étau va se resserrer autour du cou d'un candidat qui essaie de se frayer un chemin à travers une interview.

Je demande un exemple de code pour les candidats et il est référencé lors de l'entretien. Cependant, je donne généralement plus de poids au codage du tableau blanc effectué pendant l'entretien.

Chaque entretien que je fais avec un développeur implique d'aller sur le tableau blanc pour implémenter la solution à un problème simple. Cependant, il existe des règles:

Le demandeur doit parler de la mise en œuvre au fur et à mesure.

• Je peux évaluer comment ils abordent un problème.
• Je peux voir à quel point le peut communiquer.
• Je peux mesurer leur vitesse avec un objectif clair.

J'ai trois problèmes dont les implémentations sont toutes similaires et je leur fais savoir qu'ils peuvent réutiliser ou refactoriser le code qu'ils ont écrit.

• Je peux voir s'ils peuvent se retirer pour jeter un coup d'œil à la situation dans son ensemble.
• Je peux voir s'ils implémentent et refactorisent, ou passent à la généralisation.
• Je peux avoir une idée plus précise de la façon dont l'ordre de leurs pensées.

Le point de tout cela, de tout entretien est d'essayer d'avoir une bonne idée des capacités des candidats et de la façon dont ils peuvent correspondre à l'emploi. La partie "pratique" de l'entretien, d'après mon expérience, m'a beaucoup aidé à cet égard. Cela m'aide également à évaluer l'exemple de code, car j'en sais beaucoup plus sur la façon dont le programme.

Un exemple de code est un moyen assez efficace d'éliminer les candidats - je peux juger un échantillon de code en 5 à 10 minutes, mais même un écran de téléphone prend 15 minutes et nécessite une planification (et n'est pas très utile pour éliminer autre chose que le très bas de la pile dans mon expérience).

Je pense que les principales objections aux exemples de code sont doubles et sont facilement surmontées:

• qu'exiger un échantillon de code constitue une barrière artificielle pour certains développeurs talentueux

Évidemment, c'est vrai. Toute barrière dans le processus de candidature ou d'embauche peut potentiellement éliminer un candidat souhaitable. L'important ici est de connaître votre public - si vous avez 1000 CV pour votre seule ouverture, vous pouvez vous permettre de faux négatifs au service de l'efficacité. Si vous avez cinq curriculum vitae, vous pouvez vous permettre quelques inefficacités dans le processus de sélection.

Ce que je pense que la plupart des gens manquent, cependant, c'est que les entretiens et l'embauche sont essentiellement un jeu de "trouver une raison de ne pas embaucher cette personne". Pour tout emploi décent, il y a beaucoup de candidats qualifiés - le dernier candidat est généralement celui qui n'a déclenché aucun drapeau rouge en cours de route. Il est facile de voir le meilleur des gens ou de ne pas être engagé, mais cela ne vous aide pas à embaucher, car vous vous retrouverez avec 10 candidats différents avec lesquels vous êtes à l'aise. Cela ne vous rapproche pas d'une décision.

Chaque friandise que vous collectez en passant en revue, en sélectionnant, en interviewant, etc. pourrait potentiellement déclencher une décision de non-embauche. Vous devez équilibrer la sensibilité de votre déclencheur sans embauche avec vos perspectives actuelles (et futures potentielles). Si vous êtes dans une industrie ennuyeuse, avec beaucoup de code hérité, de bureaucratie et de mauvais salaires (souvent des choses hors de votre contrôle), votre déclencheur doit être moins sensible que, par exemple, Google. Sinon, vous risquez de ne jamais embaucher personne.

Personnellement, je trouve que le compromis le plus simple pour moi a été de demander mais pas d' exigerun exemple de code. Si j'en reçois un, c'est juste un point de données supplémentaire pour évaluer le candidat. De même, s'il m'arrive d'avoir une connaissance qui a travaillé avec le candidat dans le passé, j'attacherai un certain poids aux opinions de cette connaissance. Cependant, le fait de ne pas avoir travaillé avec quelqu'un que je connais ne disqualifie aucun candidat - cela signifie simplement que mon travail d'évaluation est un peu plus difficile (et inclura probablement un exercice de codage s'ils parviennent à un entretien). Si votre échantillon est médiocre (ou que ma connaissance vous embrouille), c'est à peu près sans embauche. Ceux qui fournissent un échantillon peuvent ou non avoir une petite longueur d'avance sur ceux qui ne le font pas lors du dépistage initial - selon la qualité et la quantité de la pile de CV et des échantillons, plus d'informations peuvent être meilleures ou pires que pas d'informations.

• que les échantillons sont facilement truqués

Ben ouais. Il en va de même pour les CV - mais nous les collectons toujours. Pourquoi? Pour trois raisons principales - un CV ou un échantillon médiocre est une solution facile à embaucher, se faire prendre en train de truquer un CV ou un échantillon est une solution sans embauche facile, et ce sont de bons sujets de conversation dans une interview. Plus vite je peux comprendre que le candidat est un idiot, mieux c'est pour tout le monde.

Si vous êtes assez intelligent pour plagier un bon échantillon sans être pris, parlez-en intelligemment et passez l'entretien - je n'ai pas de problème particulier avec la façon dont vous avez passé la projection. Il peut y avoir des problèmes éthiques ici, mais ce n'est pas vraiment mon domaine d'expertise, donc je ne vais pas m'empêcher d'évaluer le caractère moral lors d'une entrevue. Pour moi, c'est pratiquement la même chose que mon patron me demande d'interviewer une personne qui n'a pas passé le processus de présélection en tant que faveur. Une fois que vous êtes au stade de l'entretien, peu importe comment vous y êtes arrivé, car il y a tellement plus d'informations de meilleure qualité qui sortiront pendant l'entretien.

TL; DR - un exemple de code est un excellent outil de filtrage, mais vous devez bien réfléchir si vous pouvez l'exiger ou non. Une fois le dépistage passé, pondérez l'interview beaucoup plus haut qu'un échantillon.