Comment reconnaître un bon programmeur?
Notre entreprise recherche de nouveaux programmeurs. Et voici le problème - il y a beaucoup de développeurs qui ont fière allure lors de l'entretien, semblent connaître la technologie dont vous avez besoin et ont une bonne expérience professionnelle, mais après deux mois de travail, vous découvrez qu'ils ne sont pas en mesure de travailler dans une équipe, écrire du code leur prend très longtemps, et de plus, le résultat n'est pas aussi bon qu'il devrait l'être.
Alors, utilisez-vous des tests formalisés (y en a-t-il?)? Comment reconnaissez-vous un bon programmeur - et une bonne personne? Y a-t-il de "bonnes" questions simples qui pourraient révéler les problèmes futurs? ... ou s'agit-il simplement de votre "sentiment" à propos de la personne (c'est-à-dire, principalement votre expérience), et de l'essayer?
Edit: Selon la réponse de Manoj, ici est la question liée à la tâche de codage lors de l'entretien d'embauche.
Demandez-leur de parler de ce qui les intéresse. Je n'ai pas encore rencontré de développeur qui soit vraiment passionné par la programmation mais qui ne sait pas vraiment coder. Ils peuvent bien sûr exister - et votre entretien devrait également vérifier la compétence - mais la passion est un bon indicateur de mon expérience. (Notez que ce n'est pas la même chose que de pouvoir "parler" en termes de mots à la mode.)
Demandez-leur ce qu'ils n'aiment pas dans leur langue ou plateforme préférée. Comment régleraient-ils les choses? Qu'aimeraient-ils voir dans la prochaine version? Ont-ils des projets de loisir? S'ils ont un blog, lisez-le. Vérifiez leur présence générale en ligne.
L'embauche de bonnes personnes est difficile .
Il m'a fallu de vraies erreurs pour m'améliorer. Vous commencez à faire beaucoup plus confiance à votre tractus intestinal après les premières fois où vous ne lui faites pas confiance et le regrettez.
J'ai un grand respect pour les questions sur l'écran du téléphone de Steve Yegge et j'ai utilisé cela comme base pour interviewer des gens avec un certain succès.
Je pense aussi que je suis devenu meilleur en interviewant les gens après avoir lu Le guide de Joel sur les entrevues de guérilla (maintenant à la version 3.0, c'est en avance sur la version pour le web et tout, ça doit juste être bon) .
Il y a aussi 57 autres questions (au 20/11/2008) sur Software Engineering Stackexchange marquées avec interview et certaines d'entre elles semblent très pertinentes, alors vérifiez-les.
Quelques idées:
Posez plusieurs questions ouvertes sous différents angles:
- Examinez du code. Qu'est-ce qui a été identifié? Erreurs techniques, incohérences de style, commentaires, algorithmes, maintenabilité, etc ...
- Écrivez du code. Recherchez le processus, la protection contre les balles, la lisibilité, etc.
- Créer une conception de haut niveau pour un petit système. Rechercher la compréhension du problème, l'approche, les communications, l'exhaustivité, les détails.
- Décrivez le processus de développement logiciel. Recherchez la conception, la collaboration, la révision, les tests, les bonnes/mauvaises habitudes et l'expérience globale.
Choisissez quelque chose - n'importe quoi - que le candidat prétend bien connaître. Posez une question simple puis, sur la base de la réponse, posez-en une autre, un peu plus détaillée, et continuez à "creuser" jusqu'à ce que vous atteigniez la limite des connaissances du candidat. Cela vous donne une idée de:
- Honnêteté: sait-il autant qu'il le prétend?
- Profondeur des connaissances: comment apprend-il bien les choses?
- Communication: dans quelle mesure vous explique-t-il quelque chose qui ne vous est pas familier? Le processus de pensée est-il logique?
- Réaction à des situations stressantes: quelle est la difficulté à répondre? Est-ce qu'il/elle le simule? L'inévitable "je ne sais pas" est-il facile ou difficile?
Demandez comment le candidat a géré diverses situations d'un emploi précédent: travail d'équipe, projets en retard, débogage, , etc. . Les réponses sont-elles positives ou négatives? Passionné? Intelligente? Arrogant?
Je trouve les meilleurs candidats enthousiastes, aguerris, confiants mais polis, et le plus important, présent. Vous devez savoir qu'il y a quelqu'un à l'intérieur. :-)
Pour reconnaître un bon programmeur, vous devez être un bon programmeur. Cela signifie que vous devez très bien connaître la programmation pour voir à travers ce qui est dit et fait dans l'interview, et vous devez savoir quelles questions poser.
J'ai vu des candidats donner une mauvaise réponse lors de l'entretien, mais leurs explications ont montré qu'ils connaissaient le sujet (et pouvaient donc facilement obtenir la bonne réponse en cherchant sur le net). Pour voir cela, vous devez très bien connaître le sujet sur lequel vous posez la question.
Une autre chose est d'éviter les questions sur les détails qui pourraient facilement être recherchés sur Google. Cette question montre seulement à quel point le candidat est bon de se souvenir des choses, pas s'il a vraiment les connaissances et la compréhension que vous recherchez.
Ma recommandation est d'obtenir de l'aide de quelqu'un qui connaît beaucoup de programmes et qui possède de bonnes aptitudes relationnelles pour aider avec les entretiens.
Edit: j'ai aussi écrit un commentaire sur les interviews ici .
N'oubliez pas que la capacité de programmation n'est pas tout. Vous pourriez avoir le meilleur programmeur du monde travaillant pour vous, mais s'ils détestent travailler avec d'autres personnes, vous ne les trouverez pas très utiles.
La personnalité d'un programmeur devrait figurer plus haut sur la liste que la plupart des employeurs ne semblent la classer. Dans mon milieu de travail actuel, ils font très attention à embaucher le bon type de personne.
Les gens peuvent généralement apprendre à être de meilleurs programmeurs, les gens ne peuvent généralement pas apprendre à être de meilleurs êtres humains.
Faites-les coder. Donnez un problème qui peut être résolu en 4 ou 5 heures par exemple et inspectez le code pour la documentation, le style de codage, la façon dont il a planifié la solution avant de commencer à coder, etc. Il n'a pas besoin de résoudre le problème. Et comme Jon Skeet l'a mentionné, faites-leur parler de programmation, de leur langage de choix et de choses comme ça. Vous pouvez reconnaître la passion d'un bon programmeur. Demandez combien de sites liés à la programmation ils suivent, comme stackoverflow. Les blogs qu'ils suivent peuvent être un bon indicateur.
J'aime la réponse passion. Je crois que vous devez être passionné par ce avec quoi vous travaillez pour être vraiment très bon dans ce domaine.
Un bon programmeur programme en plus de travailler (au moins de temps en temps). Il aime résoudre des problèmes de programmation. Et quand il/elle ne peut pas trouver un programme qui résout un besoin particulier à la maison, il essaiera généralement de le résoudre lui-même.
Mais il existe plusieurs types de programmeurs.
- Vous avez ceux qui aiment documenter. Personnellement, je déteste documenter. Mais documenter ce qui est fait peut être important.
- Vous avez les "hackers". Ceux qui sont résolus à résoudre un casse-tête complexe où, si vous recherchez Google, ne trouveraient probablement pas de solution. Ils peuvent résoudre "n'importe quel" problème tant qu'ils disposent des outils dont ils ont besoin.
- Il y a ceux qui apprennent à être programmeurs simplement parce que le marché était bon pour être embauché pour la programmation. Ceux-ci sont généralement médiocres car ils manquent de passion.
- Il y a ceux qui sont excellents dans la communication et qui "peuvent tout résoudre" mais une fois qu'ils ont le travail, ils pèsent sur tous les autres pour obtenir de l'aide pour le problème qu'ils résolvent.
Si vous pouvez trouver le "pirate" qui documente également très bien et possède de superbes compétences en communication, je pense que vous avez touché le jackpot.
Oh, et une dernière chose. Vous ne voulez probablement pas d'un programmeur qui a des ambitions de leader, car il n'utilisera que la programmation pour se lancer. Cela signifie que vous perdrez cette ressource tôt ou tard.
Une question que je poserais lors de l'embauche d'un programmeur serait: "Pourquoi vous êtes-vous formé en tant que programmeur?". Ce serait un cadeau mort s'ils hésitent là-bas.
Voilà mon opinion.
Un de mes amis travaille dans une entreprise où il a une étape supplémentaire dans le processus d'embauche: après une sélection initiale et un entretien, un candidat doit "tester le travail" pendant quelques jours. Il m'a dit que même si un candidat avait toutes les compétences et les talents nécessaires, ils ne l'ont pas embauché parce qu'il était un un pas une personne sympa avec qui travailler.
Il est très difficile de reconnaître un programmeur basé uniquement sur un entretien d'embauche.
Certaines choses qui décident que quelqu'un est un bon programmeur sont:
- capable de travailler en équipe
- écrit un bon code qui est compréhensible et maintenable
- est capable de se renseigner sur les nouvelles technologies
Vous avez donc quelques petits conseils à découvrir dans une interview:
- Le candidat connaît-il une technologie/un langage de programmation ou en connaît-il plusieurs? S'il connaît différentes langues, il semble être en mesure d'apprendre de nouvelles choses et il connaît peut-être les inconvénients de sa technologie/langue préférée actuelle. Demandez donc des connaissances en plus de la technologie que vous utilisez dans votre entreprise.
- Demandez des projets dans lesquels il a déjà travaillé, en particulier des projets de loisirs et open source. Les projets de passe-temps vous montrent qu'il aime programmer et le faire même pendant son temps libre (et ainsi améliorer ses compétences). Dans un projet open source, vous pouvez rechercher le code qu'il a écrit. Si le projet implique plus d'une personne, vous pouvez obtenir des indices sur ses compétences en équipe. Dans un projet OS, vous pouvez rechercher les archives de la liste de diffusion pour en savoir plus.
Vous pouvez effectuer un test dans l'interview.
Mais souvent, il y a aussi un problème avec l'environnement de travail lui-même. Ce n'est sûrement pas le cas dans votre organisation, mais il est assez courant dans le domaine de l'industrie du logiciel que la dette technologique devienne trop importante. Ensuite, lorsque vous embauchez de nouvelles personnes, cela n'aide pas beaucoup si elles sont bonnes ou non, à cause de la dette. Maximiser la lisibilité et l'intelligibilité de votre code de programme aide les nouveaux arrivants à se mettre au travail.
De nombreuses personnes sont également telles qu'elles peuvent coopérer, mais parfois il n'y a aucun moyen de coopérer. Par exemple, si toutes les personnes sont des développeurs, elles sont censées faire leur travail. Eh bien, ils le font. Mais avez-vous un architecte qui pilote le projet de développement et garde les réunions et autres? Les développeurs normaux peuvent penser qu'ils n'ont pas le mandat nécessaire pour démarrer des réunions et ils peuvent penser qu'interrompre les autres de temps en temps n'est pas la solution.
Communiquer entre eux ne doit pas être l'objectif final. Moins la communication est nécessaire, mieux c'est, mais seulement si moins est possible. Moins devient possible si vous avez un architecte. La quantité totale de communication peut rester à un bon niveau, mais vous obtenez plus de résultats pour la même quantité de communication.
je commence par les entretiens habituels, je considère très important de voir si la personne en face de moi vaut quelque chose, et de déterminer ses compétences et ses connaissances.
Après cela, j'utilise quelques techniques dans le domaine de Java, comme discuter de certains principes, principalement tirés de Effective Java.
À ce stade, quand je pense que je pourrais avoir un bon programmeur devant moi, je lui donne un morceau de code pour le réviser. Ce que je veux voir, c'est qu'il peut localiser les parties dangereuses du code, donner quelques conseils sur les améliorations, trouver des écueils sur les performances et un multi threading ET qu'il peut faire la distinction entre les remarques importantes et les "goûts-remarques". Tout cela m'aide à trouver un employé plus compétent.
mais au final je me souviens toujours que l'embauche est une sorte de jeu ... très très difficile à anticiper ...
Je sais que cela ne répond pas à ce que vous demandez mais je recommande, si les lois le permettent, de toujours embaucher temporairement au début (deux semaines ou un mois, selon le travail). Si la personne vaut son sel, elle ne s'y opposera pas, en plus c'est une sauvegarde pour vous deux (vous pouvez le laisser partir et il pourrait finir par ne pas aimer le travail et partir).