Quelle est la meilleure façon d’évaluer les nouveaux programmeurs? [fermé]

Quelle est la meilleure façon d’évaluer les meilleurs candidats pour obtenir un nouvel emploi (parler uniquement en termes de compétences en programmation)? Dans mon entreprise, nous avons eu beaucoup de mauvaises expériences avec des personnes qui ont de bonnes notes mais qui n’ont pas de réelles compétences en programmation. Leurs compétences ne sont que des singes à code, sans la capacité d'analyser les problèmes et de trouver des solutions.

Plus de choses que je dois noter:

• Le système éducatif dans mon pays est nul, vraiment nul. Les personnes qui sont bonnes dans ce genre de travail sont bonnes parce qu'elles ont du talent ou essaient vraiment d'apprendre par elles-mêmes.

• Le diplôme universitaire / de troisième cycle / de troisième cycle ne signifie pas nécessairement que vous savez exactement comment faire les choses.

• Les certifications ne veulent rien dire non plus parce que les responsables du cours de certification n’ont pas non plus de compétences (ou occupent des emplois peu rémunérés).

Nous devons vraiment trouver les bons candidats flexibles et qui n’ont pas de mentalité mécanique (parce que ce type de personnes expérimentées a une faible performance).

Nous sommes dans une institution gouvernementale et les candidats ne viennent pas forcément de l'extérieur, mais nous avons la possibilité d'accepter ou non des candidats jusqu'à ce que nous trouvions le bon.

J'espère que je ne parais pas trop agressif dans ma question; et BTW je suis un programmeur moi-même.

edit: J'ai compris que demandait quelque chose de vraiment complexe ici. Je désélectionnerai "la bonne réponse" uniquement pour laisser la discussion se dérouler sans difficulté.

En ce qui concerne la sélection des candidats, je choisis généralement un plan en trois temps:

• Test régulier avec des questions de codage de type FizzBuzz et de nombreuses questions de connaissances où ils doivent donner des exemples codés. Selon le poste occupé, il peut s'agir des principes OO, des principes de conception SQL, etc. J'incrémente les difficultés des questions tout au long du test pour voir jusqu'où elles peuvent aller. L'idée n'est pas vraiment d'avoir toutes les réponses aux questions (si c'est le cas, mieux c'est), mais aussi de voir s'ils peuvent reconnaître quand ils ne savent pas quelque chose. La confiance est essentielle et je ne veux pas que quelqu'un me mente dans mon équipe.

• Revenez sur le test avec le candidat et discutez des réponses. Extension possible des questions pour atteindre les limites du candidat. Cela peut être vaste, et plus c'est vaste, mieux c'est.

• Dernière partie, mais non la moindre, The Code Review . Je demande au candidat d'apporter un morceau de code (j'espace en général le test / la discussion précédente et cette critique de quelques jours, afin de les laisser écrire et peaufiner un morceau de code). Nous procédons ensuite à une révision de code régulière avec deux personnes: une personne qui travaillera directement avec le candidat et la personne qui a précédemment examiné le test avec le candidat. En ce qui concerne la révision du code, vous pouvez lire cet article de JohnFX .

À la fin de tout cela, vous devriez pouvoir décider si vous voulez que ce candidat fasse partie de votre équipe ou non.

Commencez par leur donner FizzBuzz à résoudre. Cela devrait éliminer le pire d'entre eux.

Quelque chose de plus difficile, par exemple, comment inverser une chaîne sans utiliser les fonctions de bibliothèque intégrées. Demandez-leur de parler tout en résolvant afin de voir quel est leur processus de pensée.

Vous pouvez continuer à poser des problèmes plus difficiles s’ils les trouvent très faciles, jusqu’à ce que vous soyez convaincus qu’ils peuvent marcher et ne pas se contenter de parler.

Il suffit de chercher la passion pour le travail.

Pour citer Joel, recherchez des personnes qui sont " intelligentes et faites avancer les choses " .

Le reste n'a pas d'importance

Sur la base de mes 25 années de programmation (qui, certes, ne comprend que 5 ou 6 instances d’embauche d’autres programmeurs):

Indicateurs positifs:

• Passionné de technologie

• Les programmes comme passe-temps

• Parlerait d'un sujet technique si on l'encourageait

• Projets parallèles personnels importants (et souvent nombreux) au fil des ans

• Apprend par lui-même les nouvelles technologies

• Opinion sur les technologies qui conviennent le mieux à divers usages

• Très mal à l'aise à l'idée de travailler avec une technologie qu'il ne croit pas avoir "raison"

• Clairement intelligent, peut avoir d'excellentes conversations sur une variété de sujets

• A commencé à programmer bien avant l'université / le travail

• A des "icebergs" cachés, de grands projets personnels sous le radar du CV

• Connaissance d'une grande variété de technologies non liées (peut ne pas être sur CV)

Indicateurs négatifs:

• La programmation est un travail de jour

• Je ne veux pas vraiment “parler boutique”, même quand on les encourage à

• Apprend les nouvelles technologies dans les cours sponsorisés par l'entreprise

• Heureux de travailler avec toutes les technologies que vous avez choisies, «toutes les technologies sont bonnes»

• Ne semble pas trop intelligent

• Commencé à programmer à l'université

• Toute l'expérience de programmation est sur le CV

• Axé principalement sur une ou deux piles technologiques (par exemple, tout ce qui concerne le développement d’une application java), sans expérience en dehors de celle-ci

En plus, je suggérerais:

• Le test FizzBuzz (ou quelque chose de similaire pour tester l'aptitude de base à écrire un algorithme.
• Version plus dure du test FizzBuzz (pour les amener au point d'échec ou presque).
• Discutez de leur code et voyez s'ils sont disposés à s'auto-critiquer et cherchez des améliorations (ce qu'ils n'auraient probablement pas eu le temps de faire dans un court test sur place) tels que:
  • bons noms de variables (des codeurs expérimentés ont utilisé des variables en production comme "flag" (WTF ??)
  • modularisation.
  • Anticiper les problèmes et faire du "codage défensif"
• Une volonté de voir les "défauts" comme des opportunités d'amélioration. Je pense que les meilleurs codeurs recherchent toujours les défauts de leur code précédent. Ils ne sont pas assez égocentriques pour penser que trouver une faille est un affront personnel. Ils y voient une opportunité de faire mieux. (Ceux qui ne peuvent pas regarder les défauts de manière irréfléchie sont soit dépassés par le fait de voir un défaut (et deviennent super confiants, ou, pour éviter cela, ils ignorent les défauts).
• Peuvent-ils déboguer?
• Peuvent-ils tester l'unité? (J'ai parlé à un trop grand nombre de programmeurs qui disent "le CQ fait ça". Je ne parle pas de test, je parle de test: vous écrivez une fonction, ça marche? Fait-il des efforts raisonnables pour le gérer? Problèmes probables (entrée NULL, etc.) Si vous ne pouvez pas le faire, comment savoir quand vous avez terminé?
• Ont-ils de bonnes compétences en communication? (au minimum: bonne compréhension et connaissance de soi du moment où ils comprennent et ne comprennent pas et volonté de dire "je ne comprends pas, veuillez l'expliquer à nouveau".

Une grande partie du résumé ci-dessus est tirée de Comment repérer un bon programmeur , un excellent article, qui est un peu plus axé sur les indicateurs à plus long terme. Cela confirme définitivement mes intuitions et mon expérience. C'est aussi beaucoup de choses (comme "passion") qui ne sont normalement pas mentionnées dans une liste de contrôle "Qu'est-ce qu'un bon programmeur".

L'évaluation de l'intelligence de programmation est une forme de test de Turing. Ainsi, il n’existe (actuellement) aucune procédure d’évaluation sous forme fermée qui fonctionne. Les programmeurs intelligents doivent reconnaître d'autres programmeurs intelligents, mais avec une probabilité raisonnable.

Vos chances seront meilleures si vous avez des enquêteurs dans votre équipe qui peuvent sentir les emplois de neige et qui, instinctivement, n'aiment pas travailler avec des personnes stupides (même ceux qui sont beaux, ont un CV impressionnant et peuvent jaillir de toutes les solutions habituelles conservées de mémoire). .

(Une des méthodes possibles pour améliorer la qualité du stackoverflow consiste à déterrer d'anciennes questions relatives au stackoverflow, liées d'une certaine manière aux exigences de votre travail mais qui, à votre avis, ont des réponses inférieures. Demandez à la personne interrogée comment elle répondrait, et demandez-leur de l'afficher s'il s'agit d'une bonne réponse. Semblable à un récapitulatif pour la reconnaissance optique de caractères par le grand public.)

Donnez-leur un problème, de préférence associé au domaine de problème sur lequel ils vont travailler, et demandez-leur de discuter de la façon dont ils l'aborderaient. Vous pouvez leur demander simplement de discuter, de pseudo-code ou d'écrire des bits de code réel en fonction de votre confiance en leur niveau de compétence.

Par exemple, si votre organisation a organisé des conférences, demandez-leur de décrire comment coder un système d'enregistrement en ligne sécurisé. Ils devraient être capables de couvrir une partie des bases et de poser de bonnes questions sur ce qui doit être mis en œuvre. Lors de vos interactions, vous devriez être en mesure de déterminer si elles conviendront bien à votre organisation et le rôle que vous devez leur confier.

Je ne suis pas un grand partisan de la programmation de tests-questionnaires et de casse-têtes. Bien qu'elles puissent être amusantes pour certaines personnes, elles peuvent également gêner et / ou stresser d'autres personnes, y compris des personnes qui pourraient bien être la meilleure solution pour votre équipe. De plus, des informations sur de nombreux tests de ce type sont facilement disponibles en ligne et encourageront le bourrage pour les tests et autres tactiques qui affaibliraient leur viabilité pour évaluer les capacités du programmeur.

La lecture de cette question et de certaines des réponses reçues m'a incité à rédiger un article qui pourrait être d’intérêt:

Pratiques de recrutement étranges lors de l'embauche de développeurs de logiciels

Ok, le titre de l’article est donc nul, mais l’article touche au cœur du problème. Ce n'est pas le problème du candidat que vous ayez choisi de l'interviewer, même si cela ne convient pas au rôle que vous envisagez. Si vous ne parvenez pas à définir une procédure de recrutement bien calculée pour vous permettre de trouver les pierres précieuses de manière approximative, vous devrez alors en supporter les conséquences, et oui, cela signifie que vous obtiendrez quelques candidats ne jamais répondre à vos attentes. Pour filtrer vos candidats en fonction de leurs lettres et curriculum vitae, vous devez d’abord demander à vos candidats d’écrire une lettre sur eux-mêmes et sur ce qu’ils souhaitent du poste, puis de voir comment le curriculum vitae est rédigé. Si vous ne pouvez interroger qu'un ou deux candidats potentiels, vous avez probablement correctement effectué la présélection.

Lorsque vous finissez par trouver les 1 ou 2 candidats que vous considérez comme valant la peine, ne posez pas simplement une poignée de questions de testeurs aliénés, mais investissez plutôt le temps de faire connaissance avec ces personnes et d'engager des discussions ouvertes sur les logiciels. ingénierie en général. Une approche informelle sur le candidat vous en apprendra plus que dans une situation d'entrevue traditionnelle (et quelque peu conflictuelle). En outre, ne vous contentez pas d'un entretien unique, mais organisez plutôt avec vos candidats clés plusieurs réunions au cours desquelles une discussion ouverte est utilisée et où le candidat peut rencontrer leurs collègues éventuels. Le temps n'est jamais perdu, car les candidats inappropriés ne réussiront pas très bien dans une discussion très technique et montreront très vite leurs défauts au fur et à mesure qu'ils baisseront la garde.

Vous n'avez pas dit pour quelle langue, mais il est assez facile de tester les connaissances de quelqu'un. Cela dépend aussi du niveau que vous recherchez, mais il y a un assez grand nombre de questions concernant les questions de l'entretien.

Quoi que vous décidiez de faire avec votre entretien, ne posez pas ces questions lors d'un entretien "puzzle latéral" .

Je vous suggère d'y aller avec une question FizzBuzz et d'embaucher la première qui passe. Les autres tests ont tendance à être défectueux, car tous les bons programmeurs ne vont pas aborder un problème comme vous, ni gérer une interview sans bégayer, ni connaître les langues que vous souhaitez, que vous vous souciez de la bêtise ou l’échange d’entiers comme une troisième variable (qui a besoin de cela quand même? I signifie, puisque la RAM a dépassé 128 octets?).

Pensez-y. Si la question FizzBuzz élimine 199 sur 200, elle supprime simplement des centaines d'interviews. Alliez-vous vraiment interviewer des centaines de prospects?

Cela semble juste comme des rendements décroissants après FizzBuzz. Cela en supposant que 199/200 est même à peu près proche. Et je présume que votre temps est précieux aussi ...

Je ne suis pas sûr qu'il s'agisse d'un commentaire ou d'une réponse, mais essentiellement de ce que Matthieu a dit. Vous voulez des questions faciles stupides qui prennent une minute ou deux (mais pas plus de 5) minutes à faire et elles devraient concerner différents domaines.

De tels exemples de question stupide et facile sont des questions sur la récursivité, telles que vous avez une liste et que vous devez l’imprimer en ordre inverse sans utiliser de boucle. Une question de regex simple si regex est normalement fait dans votre développement. Une question sur les bits et les octets si vous utilisez C ++ (écrivez un modèle qui accepte les caractères trop longs et affiche la représentation binaire. Une spécialisation n'est pas nécessaire, utilisez simplement sizeof () pour déterminer la longueur en bits)

Cela devrait vous prendre environ <= 3 minutes par question

Demandez-leur quel est le défi de programmation le plus intéressant qu'ils aient jamais essayé de résoudre mais ne pouvaient pas, quelle approche ont-ils adoptée pour le résoudre, pourquoi ils ne pouvaient pas le résoudre et quelle autre approche pourrait, à leur avis, le résoudre.

Cela me suffit pour juger des capacités d'un programmeur en tant que programmeur.

1. Peuvent-ils défendre ce qu'ils prétendent savoir? Ils l'ont mis sur le CV en tant que compétence ou quelque chose qu'ils ont fait sur un autre projet. Voyez à quel point ils peuvent approfondir le sujet.

2. Peuvent-ils apprendre quelque chose de nouveau? Parlez d'un aspect de haut niveau de la technologie que vous utilisez ou de quelque chose de spécifique au domaine de l'entreprise dans lequel vous travaillez et voyez s'il peut comprendre le sujet. Est-ce qu'ils posent des questions intelligentes? Peuvent-ils proposer une analogie? Est-ce similaire à quelque chose qu'ils ont fait dans une autre industrie ou technologie?

3. Préféreraient-ils programmer? Ce n'est pas obligatoirement le numéro un sur leur liste, mais ils doivent montrer une préférence pour l'écriture de code. Et je veux dire réellement écrire du code et créer quelque chose, ne pas rester assis à parler de cela ou dessiner au tableau toute la journée. Pas pour minimiser la planification ou pour promouvoir le codage des cow-boys, mais vous devrez éventuellement avoir du code. Évitez ceux qui évitent le clavier. Ce n'est pas une position de gestion.

Vous pouvez marquer des points sur une échelle allant de un à dix ou simplement vous fier à votre propre odeur.

Si vous vous sentez mieux, de mauvais programmeurs existent dans presque tous les pays. Comment les éliminer est le problème.

Le premier désherbage est le CV. Ce que je recherche, c’est beaucoup d’expérience linguistique revendiquée et rien qui puisse décrire ce qu’ils ont fait dans cette langue. J'ai vu des résumés qui prétendent connaître toutes les langues jamais inventées et pourtant, leur expérience montre qu'ils n'ont travaillé qu'avec Access et Visual Basic. Ceux-ci vont à la poubelle. 10 pages de CV vont droit dans la corbeille (en particulier 10 pages de personnes avec moins de 2 ans d'expérience que j'ai eu). De récents diplômés d'université peu expérimentés, vous devez être très pointilleux sur la façon dont ils se présentent. Les meilleurs candidats font attention à leur curriculum vitae, ils n'ont pas d'erreur. Êtes-vous vraiment à la recherche de quelqu'un qui s'en soucie si peu qu'il ne se soit pas donné la peine de corriger son CV?

Les curriculum vitae préparés par les professionnels vont également à la poubelle. Une fois que vous avez lu des centaines de CV, vous pouvez les choisir car ils utilisent exactement le même phrasé. Vous ne pouvez pas faire confiance au contenu d'un CV préparé par un professionnel et vous savez que la personne n'a pas fait sa propre préparation. C'est le genre de personne qui comptera sur les autres pour résoudre ses problèmes, le voulez-vous vraiment dans une position de programmation?

Cherchez des éléments qui font que la personne se démarque de ceux que vous choisissez. C'est plus difficile bien sûr avec ceux qui viennent juste de sortir de l'école, mais cherchez des réalisations, des contributions à l'open source, etc.

La prochaine élimination est l'interview téléphonique. Renseignez-vous sur les concepts de base liés au travail que vous avez. Si les gens ne possèdent pas les connaissances de base des concepts dont vous avez besoin, ils ne valent pas la peine de les apporter à un entretien personnel. Les jeunes pensent souvent que c'est injuste car ils peuvent tout rechercher sur Internet, mais la vérité est que je n'ai jamais rencontré de bon programmeur qui devait tout rechercher sur Internet. Vous devriez avoir une certaine connaissance de votre profession que vous n'êtes pas obligé de regarder à chaque fois.

Après l'entretien téléphonique, vous devez choisir les 4-5 meilleurs candidats et les interviewer. Bien sûr, si vous n'avez qu'un ou deux bons candidats, n'ayez pas la peine d'interviewer des personnes que vous avez déjà éliminées. Maintenant, vous allez poser les questions difficiles et vous faire une idée de la façon dont ils abordent les problèmes. Je n’utiliserais jamais le test fizzbuzz car il est trop bien connu pour que les réponses ne vous apprennent rien. Au lieu de cela, créez des problèmes à partir de votre propre base de code. Je pourrais leur donner une exigence et un morceau de code et leur demander si le code répond à l'exigence et, sinon, pourquoi pas et ce qu'ils pourraient faire pour que cela réponde à l'exigence. Je leur demanderais de décrire le problème de programmation le plus difficile qu’ils ont eu à résoudre et quelles mesures ils ont prises pour trouver la réponse. Je voudrais poser des questions techniques plus approfondies. N'oubliez pas que vous essayez de vous familiariser avec leurs compétences techniques, leurs capacités de résolution de problèmes et de débogage, ainsi que leur capacité à s'intégrer à votre équipe existante. Je leur pose aussi des questions dont ils ne connaissent probablement pas la réponse pour juger de la manière dont ils gèrent le stress, c'est un travail stressant, je ne veux pas de quelqu'un qui passe l'interview parce que le stress de son travail est supérieur à celui de l'interview . Je recherche des atouts dans les domaines dans lesquels nous sommes actuellement faibles et notre capacité à travailler en équipe et à se présenter aux clients (nos développeurs traitent beaucoup avec les utilisateurs), votre liste peut être différente. t veulent une personne qui se couche pendant l’entrevue parce que le stress de l’emploi est supérieur à celui de l’entrevue. Je recherche des atouts dans les domaines dans lesquels nous sommes actuellement faibles et notre capacité à travailler en équipe et à se présenter aux clients (nos développeurs traitent beaucoup avec les utilisateurs), votre liste peut être différente. t veulent une personne qui se couche pendant l’entrevue parce que le stress de l’emploi est supérieur à celui de l’entrevue. Je recherche des atouts dans les domaines dans lesquels nous sommes actuellement faibles et notre capacité à travailler en équipe et à se présenter aux clients (nos développeurs traitent beaucoup avec les utilisateurs), votre liste peut être différente.

Il faut donner aux candidats un problème du monde réel à résoudre avec la liberté d'utiliser n'importe quelle technologie.

Si elle sort aux couleurs éclatantes, elle est dedans!