Comment reconnaître un bon programmeur? [fermé]

Notre société recherche de nouveaux programmeurs. Et voici le problème: de nombreux développeurs ont l'air vraiment géniaux 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. une équipe, l'écriture de code prend beaucoup de temps, 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? Existe-t-il de simples «bonnes» questions qui pourraient révéler les problèmes futurs? ... ou s'agit-il simplement de votre "sentiment" sur la personne (c'est-à-dire principalement de votre expérience) et de l'essayer?

Edit: Selon la réponse de Manoj, voici la question relative à 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 passionné par la programmation, mais qui ne sait pas coder. Elles existent peut-être bien entendu - 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 plate-forme préférées. Comment pourraient-ils réparer les choses? Qu'aimeraient-ils voir dans la prochaine version? Ont-ils des projets de passe-temps? S'ils ont un blog, lisez-le. Vérifiez leur présence générale en ligne.

Il est difficile d' embaucher de bonnes personnes .

Il a fallu de vraies erreurs pour que je réussisse mieux. Vous commencez à faire davantage confiance à votre tractus intestinal après les deux premières fois où vous ne le faites pas et que vous le regrettez.

J'ai beaucoup de respect pour les questions de Steve Yegge sur l'écran de mon téléphone et je les ai utilisées comme base pour interroger des personnes avec un certain succès.
Je pense aussi que je suis devenu plus apte à interviewer des gens après avoir lu le guide de Joel sur l'interview de guérilla (maintenant à la version 3.0, c'est en avance sur la version pour le Web et tout le reste, ça doit être bon).

Il y a aussi 57 autres questions (au 20/11/2008) sur l' ingénierie logicielle Stackexchange marquées avec une interview et certaines d'entre elles ont l'air très pertinentes, alors jetez-y un coup d'œil.

Quelques idées:

• Posez plusieurs questions ouvertes sous différents angles:

  • Passez en revue du code. Qu'est-ce qui est identifié? Erreurs techniques, incohérences de style, commentaires, algorithmes, maintenabilité, etc.
  • Écrivez du code. Rechercher des processus, des systèmes pare-balles, de la lisibilité, etc.
  • Créez une conception de haut niveau pour un petit système. Rechercher la compréhension du problème, l'approche, les communications, la complétude, 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 - le candidat prétend bien savoir. Posez une question simple puis, en fonction de la réponse, posez-en une autre, légèrement plus détaillée, et continuez à "creuser" jusqu'à atteindre la limite des connaissances du candidat. Cela vous donne une idée de:

  • Honnêteté: sait-il autant qu'il le prétend?
  • Profondeur de la connaissance: dans quelle mesure apprend-il / elle des choses?
  • Communication: dans quelle mesure explique-t-il quelque chose d'inconnu? Le processus de pensée est-il logique?
  • Réaction à des situations stressantes: a-t-il du mal à répondre? Est-ce qu'il / elle fait semblant? L'inévitable "je ne sais pas" est-il facile ou difficile?

• Demandez - lui comment le candidat traité diverses situations un des emplois précédents: le travail d' équipe, des projets en retard, le débogage, etc . Les réponses sont-elles positives ou négatives? Passionné? Intelligent? Arrogant?

Je trouve les meilleurs candidats pour être enthousiaste, expérimenté, confiant mais poli, 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 bien comprendre tout ce qui se dit et ce qui se fait pendant l’entrevue, 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 connaître très bien le sujet sur lequel vous posez des questions.

Une autre chose est d'éviter les questions sur les détails qui pourraient facilement être googlé. Ces questions montrent seulement à quel point le candidat est doué pour se rappeler des choses, et non s'il possède réellement les connaissances et la compréhension que vous recherchez.

Ma recommandation est d'obtenir l'aide de quelqu'un qui connaît beaucoup de programmes et qui possède de bonnes aptitudes en relations humaines pour participer aux entrevues.

Edit: J'ai aussi écrit un commentaire sur les interviews ici .

Rappelez-vous que la capacité de programmation ne fait pas tout. Vous pourriez avoir le meilleur programmeur au monde qui travaille pour vous, mais s’ils détestent travailler avec d’autres personnes, vous ne les trouverez pas très utiles.

Une personnalité de programmeurs devrait être plus haut sur la liste que la plupart des employeurs semblent le classer. Dans mon lieu 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, mais ils ne peuvent généralement pas apprendre à être de meilleurs êtres humains.

Faites-leur du code. Donnez un problème qui peut être résolu en 4 ou 5 heures et inspectez le code pour la documentation, le style de codage, comment 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 la programmation, de la langue de leur choix et de choses du genre. Vous pouvez reconnaître la passion chez un bon programmeur. Demandez combien de sites liés à la programmation ils suivent, comme stackoverflow. Les blogs qu'ils suivent peuvent également être un bon indicateur.

J'aime la réponse de la passion. Je crois que vous devez être passionné par le travail avec lequel vous travaillez pour vraiment être très bon.

Un bon programmeur programme en plus du travail (de temps en temps au moins). Il aime résoudre les problèmes de programmation. Et quand il / elle ne peut pas trouver un programme qui répond à un besoin particulier à la maison, il essayera généralement de le résoudre lui-même.

Mais il existe plusieurs types de programmeurs.

• Vous avez ceux qui aime documenter. Personnellement, je déteste documenter. Mais documenter ce qui est fait peut être important.
• Vous avez les "hackers". Celles qui sont résolues à résoudre un casse-tête complexe dans lequel, si vous vouliez chercher sur Google, ne trouveriez probablement pas de solution. Ils peuvent résoudre «n'importe quel» problème à condition de disposer des outils dont ils ont besoin.
• Vous avez ceux qui se renseignent pour devenir des programmeurs simplement parce que le marché était bon pour être embauché pour la programmation. Celles-ci sont généralement médiocres car elles manquent de passion.
• Vous avez des personnes qui sont douées pour la communication et qui "peuvent résoudre n'importe quoi", mais une fois qu'elles ont obtenu le travail, elles se tiennent sur toutes les autres pour obtenir de l'aide pour résoudre le problème qu'elles résolvent.

Si vous pouvez trouver le "pirate informatique" qui documente aussi très bien et qui possède de superbes capacités de communication, je pense que vous avez atteint le jackpot.

Oh, et une dernière chose. Vous ne voulez probablement pas qu'un programmeur ait des ambitions de chef, car il utilisera uniquement la programmation pour se lancer. Cela signifie que vous allez perdre cette ressource tôt ou tard.

Une question que je voudrais poser lors de l’embauche d’un programmeur serait: "Pourquoi vous êtes-vous formé en tant que programmeur?". Ce serait un cadeau mortel s'ils hésitaient là.

C'est mon opinion.

Un de mes amis travaille dans une entreprise où ils ont une étape supplémentaire dans le processus de recrutement: après la présélection et l’entretien, le candidat doit "tester le travail" pendant quelques jours. Il m'a dit que même si un candidat avait toutes les compétences et le talent requis, ils ne l'avaient pas embauché parce qu'il était une personne avec qui il n'était pas agréable de 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 compréhensible et maintenable
• est capable d'apprendre sur les nouvelles technologies

Vous avez donc quelques indices que vous pouvez trouver 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 capable d'apprendre de nouvelles choses et peut-être au courant des inconvénients de son langage / technologie préféré. 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 loisir et open-source. Les projets de loisir vous montrent qu'il aime programmer et le fait même pendant son temps libre (et améliore ainsi 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 avoir des indices sur ses compétences en équipe. Dans un projet OS, vous pouvez consulter les archives de la liste de diffusion pour en savoir plus.

Vous pourriez effectuer des tests lors de l'entretien.

Mais il arrive souvent que l'environnement de travail lui-même pose problème. Ce n’est peut-être pas le cas dans votre organisation, mais dans l’industrie du logiciel, il est fréquent que la dette technologique devienne trop importante. Ensuite, lorsque vous embauchez de nouvelles personnes, il n’est pas très utile qu’elles soient bonnes ou non, à cause de la dette. Maximiser la lisibilité et la compréhensibilité de votre code de programme aide les nouveaux arrivants à se mettre au travail.

De plus, beaucoup de personnes sont telles qu'elles peuvent coopérer, mais il n'y a parfois 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 dirige le projet de développement et tient des réunions et autres? Les développeurs normaux peuvent avoir l’impression de ne pas disposer du mandat nécessaire pour organiser des réunions et penser qu’interrompre les autres de temps en temps n’est pas la solution.

Communiquer les uns avec les autres ne devrait 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 au bon niveau, mais vous obtenez plus de résultats pour la même quantité de communication.

Je commence d’abord par les entretiens d’entretien habituels, que j’estime très important de voir si la personne qui se trouve 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 la discussion 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 identifier les parties dangereuses du code, donner des indications sur les améliorations à apporter, trouver des pièges sur la performance, un multi-threading ET qu’il puisse distinguer les remarques importantes des "remarques sur le goût". 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 à titre temporaire au début (deux semaines ou un mois, en fonction du travail). Si la personne vaut son sel, elle ne s'opposera pas, c'est en outre une garantie pour vous deux (vous pouvez le laisser partir et il pourrait finir par ne pas aimer le travail et partir).