Quel est le meilleur moyen de discerner un excellent programmeur lors d’un entretien d’emploi?


82

Dans le cadre d'une interview: Quel est le meilleur moyen d'identifier de manière fiable quand quelqu'un est un excellent programmeur . J'entends par là qu'il fait partie de ceux qui sont 10-15 fois plus efficaces / rapides / meilleurs que ses pairs dans la partie inférieure du spectre.

Beaucoup d'entre nous ont entendu parler du problème FizzBuzz comme moyen d'éliminer les plus faibles. Certes, prendre 5 à 10 minutes pour résoudre ce problème est un indicateur sérieux du fait qu'un candidat est un candidat faible. Je pense qu’un bon indicateur est de pouvoir résoudre ce problème aussi rapidement que possible. Cela ne semble pas suffisant, cependant.

Est-ce que c'est peut-être quelque chose comme lui donner un programme de buggy moyennement compliqué, et voir à quelle vitesse il peut le maîtriser et en identifier tous les problèmes?


La question suppose que cela peut être fait de manière fiable.
Anthony


pas nécessairement. une réponse valide serait "il n'y a pas moyen du tout"
Claudiu

Réponses:


65

Mes excuses à quiconque ne se soucie pas des longues réponses, mais je pense qu'il est assez important de qualifier vos candidats avant de les engager. Quiconque a mené un nombre important d'entretiens dans cette industrie sait que la plupart des candidats ne dureront pas les 15 à 30 premières minutes d'un entretien. La plupart de cette liste ne sera donc pas nécessaire. Rappelez-vous combien il est coûteux (à la fois financièrement et émotionnellement) de virer quelqu'un avant de rejeter ma liste comme étant excessive. J'ai essayé de lister les sujets de mes entretiens ici par ordre d'importance.

Intelligence générale (casse-tête / puzzles logiques)

Connaissances en informatique

Exercices de programmation

  • GCD , Factorial , Fibonacci , Tours de Hanoi
  • Inversion de chaîne et de liste
  • Déterminer si une liste à lien unique a une boucle (pouvez-vous le faire avec seulement deux pointeurs?)
  • Trouvez le bug

Connaissance des techniques de programmation orientée objet et des modèles de conception courants

Analyse d'algorithme ( complexité d' exécution (n) et conditions de stockage)

Utilisation d'outils et de méthodologies

Connaissance des vulnérabilités de sécurité et des attaques courantes

Mathématiques de base

Cryptographie

  • Cryptographie à clé publique
  • Cryptographie à clé symétrique
  • Fonctions de hachage
  • Protocoles cryptographiques (partage de secret, preuves à zéro connaissance)

Mathématiques discrètes

  • Logique
  • Théorie des ensembles
  • La théorie des graphes
  • Théorie de l'information
  • Combinatoire
  • Preuves (comme l'existence de nombres irrationnels, des nombres premiers infinis)

Vous voudrez peut-être aussi jeter un coup d'œil à l'ouvrage Programming Interviews Exposed . C'est une bonne référence sur le sujet.


10
Ouf, ça doit être une longue interview.
Rick Minerich

8
Aujourd'hui, j'ai tenté de résoudre "Crossing Bridges" avec mon coéquipier du concours ACM Programming. La seule différence est que nous devons le résoudre pour n'importe quel nombre de personnes. Cela nous a pris environ 30 minutes pour résoudre n'importe quel nombre de personnes .. mais dans une interview, j'ai l'impression que les énigmes sont une mauvaise métrique.

52
Dans une interview, les énigmes sont nuls parce que la personne interrogée est nerveuse, ne pense pas clairement, etc. De plus, de nombreux intrigues sont a-ha! tapez des choses qui ne vous disent vraiment rien sur le candidat.

11
Je trouve ces problèmes mathématiques de grande difficulté. Après avoir obtenu votre diplôme en informatique pendant 10 ans, comment pouvez-vous vous rappeler comment prouver des nombres irrationnels et autres?

14
Le problème avec les énigmes est que la plupart des gens ne les ont pas résolus; ils ont juste vu les réponses avant. Ainsi, les candidats les plus avisés feindront de ne pas les avoir vus et trouveront la réponse qu'ils connaissent déjà. Si votre objectif est d'embaucher des personnes intelligentes, pas des personnes trompeuses, les puzzles sont un mauvais choix.
Kyralessa

28

Ah, l'éternelle question.

J'ai eu beaucoup d'entretiens cette année (deux candidats sont prévus demain) et, selon mon expérience, l'embauche concerne davantage le ressenti physique et les aptitudes relationnelles, et moins les connaissances techniques.

  1. Prenez votre temps avec les CV. Certains CV peuvent être rejetés en quelques secondes, d'autres prennent une demi-heure. Parfois, je pense à un candidat basé sur CV beaucoup plus longtemps que je ne l’interviewe. À quelques reprises, j'ai préparé des questions d'entretien spécifiquement pour ce candidat, même si je n'ai généralement pas de questions préparées.

  2. Connaissances techniques - il y a un minimum que je veux, et c'est généralement assez facile à dire. En cas de doute, discutez des projets mentionnés dans votre CV lors de l'entretien et allez aussi loin que vous le souhaitez. C'est généralement plus que suffisant pour vous dire ce qu'il sait et ce qui le motive. L'éducation n'est pas importante, les emplois précédents importent, les projets personnels possibles ont un score élevé.

  3. Demandez ce qu'il veut faire et où il veut aller dans sa carrière - avez-vous besoin de ce qu'il a et pouvez-vous lui fournir ce qu'il veut? En outre, vers la fin de l'entretien, je pose généralement la question du salaire préféré. S'il est hors de portée, ou si je ne paie pas autant pour ce qu'il sait, c'est là que se termine l'entretien.

  4. Plus important encore, le candidat doit s’intégrer à l’équipe et je suis convaincu que nous pourrons travailler ensemble. Je n'ai pas besoin de l'apprécier, mais je dois être capable de le gérer et il doit être capable de me gérer. Si ce n'est pas le cas, je vais passer, car je ne pourrai pas utiliser ses connaissances techniques. D'un autre côté, si c'est le cas et s'il apprend vite, son manque de connaissances techniques ne m'empêchera pas de l'embaucher.

J'ai formé des filles des ressources humaines à me transmettre tous les CV dès qu'elles les ont reçues; Je programme l'entretien personnellement, aussi vite que possible (idéalement après demain après avoir reçu un CV pour un bon CV). Ensuite, il reçoit une interview d'une demi-heure ou d'une heure avec au moins un collègue (généralement mon patron ou un membre de l'équipe), où je le connais et répondais à toutes les questions. Même si je rejette sa candidature sur-le-champ, il reçoit une visite de l'entreprise de 20 à 30 minutes et je parle de ce que nous faisons et de la façon dont nous le faisons. Ensuite, je l'envoie aux ressources humaines pour un test psychologique et un peu de codage sur papier vraiment très basique / SQL. Les deux tests ne jouent presque jamais un rôle important dans ma décision, il s’agit plutôt d’une vérification que j’ai jugée correctement lors de l’entretien. Après les résultats, c’est un entretien de 15 minutes au cours duquel je lui fais une offre et, si nous négocions les conditions pour lesquelles nous sommes satisfaits, il est embauché.

C’est un processus pour lequel j’ai dû me battre par le biais de la bureaucratie de la société, après avoir raté quelques excellents candidats, et qui fonctionne, car c’est moi qui décide d’embaucher (bien que j’écoute les conseils des RH et de mes collègues, mon le mot est final). Plus de décideurs, processus plus long. Plus le processus est long, plus vous devez faire appel à Google pour réussir.

Dès que je suis certain que ce n'est pas un match, je termine l'entretien, il commence la tournée de la compagnie et c'est fini. Cela peut prendre aussi peu que deux minutes au téléphone lors de la planification d'une entrevue. Même si vous refusez un candidat, vendez l'entreprise. Si vous avez fait du bon travail, une bonne embauche peut se faire par le bouche à oreille d'un candidat rejeté.

En outre, un conseil. Envoyez des lettres de rejet (ou des courriels) pour chaque candidature que vous recevez. Dans mon entreprise actuelle, je laisse généralement cela aux RH (en dehors de celles que j’ai racontées lors de l’entretien), mais à un moment donné, il était inestimable d’obtenir une réponse enthousiaste du candidat rejeté dans les lignes "MERCI! Vous êtes la première entreprise qui a répondu au lieu de me laisser se demander s’ils répondraient un jour! "


Tests psychologiques?

5
@ Ink-Jet: non, les tests psychologiques étaient corrects - le candidat est invité à écrire le code qui sera maintenu par un homme violent qui connaît également l'adresse de son domicile.

C'est ce que je lis comme la première fois, pour être honnête.

@Grundlefleck - ouais, c'est à peu près correct. :)
Domchi

2
Si je recevais votre lettre de refus, je vous remercierais. J'ai été rejeté par le silence après être allé jusqu'à une entrevue téléphonique, ce qui est éprouvant pour les nerfs.
01d55

24

Cette réponse est un peu en dehors de la boîte, mais je pense que c'est un point précieux.

Les meilleurs programmeurs interviewent rarement. Ils n'ont pas à le faire . Si votre société est en train de changer le monde, ou si elle est entourée de secrets, ou si plusieurs programmeurs qu’ils respectent y sont déjà allés, elles pourraient alors postuler, mais les grands programmeurs obtiennent généralement des emplois par l’intermédiaire de leur réseau d’associés, et non par envoi de CV.

Donc: la meilleure façon de dire à un excellent programmeur lors d’un entretien d’emploi est qu’il n’est pas là .


2
tellement vrai ... bon point. :)
Arnis Lapsa

5
Alors .... c'est "qui vous connaissez" plutôt que "ce que vous faites"? Les véritables programmeurs obtiennent également leur travail par l'intermédiaire de leurs amis et de leur famille. Oh, je suis désolé "réseau d'associés".
Philippe

17

Toute réponse doit inclure des exemples de code. Engager un programmeur sans voir son code, c'est aimer embaucher un chef sans essayer sa cuisine.


11

Peut-être un "excellent" programmeur ne viendra-t-il pas vous interviewer. Vous devez probablement le voler à quelqu'un d'autre.


doh! cette réponse semble devenir populaire. Tout comme je dois commencer à postuler et à postuler à des emplois ...
Interstar,

9

Une façon de distinguer les programmeurs passionnés des programmeurs "Je veux juste un travail" est de leur demander quel livre ils lisent cette semaine. Puis interrogez-les sur les livres qu'ils ont lus au cours des dernières semaines.

J'ai constaté que les programmeurs passionnés lisaient TOUJOURS, et la liste inclura généralement quelques programmes / Comp. Sci. livres dans la liste récente.

Il ne s’agit pas seulement de rester "au diapason de la profession" - les programmeurs passionnés ont un désir et un amour de la programmation et ont tendance à dévorer de la documentation sur de nombreux sujets - pas seulement le langage qu’ils utilisent à présent, mais aussi les méthodologies, d’autres langages nouveaux ou "étranges" ou anciens), d'autres aspects de l'informatique (peut-être la robotique, ou l'IA, ou les jeux, ou ...)

S'ils n'ont pas du tout une liste de livres récente, ils ne sont probablement pas très programmeurs, selon mon expérience.

À votre santé,

-R


8
Ma liste de livres récente est presque toujours une fiction. Ma récente lecture technique est presque entièrement en ligne, car elle est plus à jour.

1
Mieux encore, demandez-leur quel livre ils ont écrit ce mois-ci. :)

7

Il existe différentes échelles de temps auxquelles une personne peut être "rapide": certaines personnes intelligentes peuvent résoudre des énigmes difficiles en quelques secondes, mais certaines personnes intelligentes produisent beaucoup de bons codes en un mois, même si elles ne sont peut-être pas aussi rapides aux questions posées lors des entretiens.

Demandez aux candidats s'ils sont actifs dans un projet open source où vous pouvez revoir une partie de leur code et passez un certain temps à lire les archives de la liste de diffusion et les journaux de validation de ces projets. Cela vous en dira beaucoup plus que tout ce que les candidats peuvent démontrer en entrevue. (Bien sûr, cela ne peut pas remplacer l'entretien, car tous les bons codeurs ne travaillent pas en open source.)


7

Le livre " Intelligent et fait les choses: Le guide concis de Joel Spolsky pour trouver le meilleur talent technique " peut aider à trouver une réponse.

Table des matières:

  • introduction
  • Chapitre 1: "Frapper les notes hautes"
  • Chapitre 2: "Trouver de grands développeurs"
  • Chapitre 3: "Guide de terrain pour les développeurs"
  • Chapitre 4: "Tri des CV"
  • Chapitre 5: "L'écran du téléphone"
  • Chapitre 6: "Le guide d'interrogatoire de la guérilla"
  • Chapitre 7: "Correction des équipes sous-optimales"
  • Annexe: "Le test de Joël"

L'article de Joel "Le guide d'interrogatoire de Guerrilla (version 3)" peut également être utile.

Et l'article "Fait, et obtient des choses intelligentes" de Steve Yegge sur le sujet.


4

Posez-leur une série de questions qui les obligent à coder et posez les questions plus difficiles. S'ils semblent apprécier le défi, vous en avez probablement un en direct.

S'ils ne peuvent pas répondre à la première question facile, comme "écrire une boucle for" ou quelque chose de bêtement facile, alors vous savez que cette personne ne peut pas coder.


4

Demandez-leur de coder sur un tableau blanc. Seul moyen de savoir s’ils savent écrire du code.


Je ne sais pas pourquoi cela a été voté. Si un programmeur ne peut pas écrire du code sur un tableau blanc, qu'est-ce qui vous fait penser qu'il sera capable de l'écrire sur un ordinateur?
Kristopher Johnson

3
@Kristopher: Si un programmeur peut écrire du bon code sur un ordinateur, qu'est-ce qui vous fait penser qu'il sera capable de l'écrire sur un tableau blanc? Ce sont des environnements considérablement différents.
David Thornley

Le "test de tableau blanc" n'est pas destiné à simuler le codage réel. C'est une chance de voir comment le candidat pense, s'il peut décrire ce qu'il fait, à quelle vitesse le candidat forme-t-il une solution dans sa tête, etc. même problème sur un ordinateur.
Kristopher Johnson

3

Vous devriez principalement juger du travail qu'ils ont déjà fait. Tout code ou toute idée généré par une personne au cours d’une interview angoissée est un piètre indicateur de ce qu’elle peut réellement produire au sein d’une équipe.

Pour relever des défis de codage, utilisez la messagerie instantanée avec quelque chose comme codepad.com et laissez-les le faire dans le confort de leur maison. Est-ce que vous écrivez une grande partie de votre code sur un tableau blanc devant votre patron, avec un délai de 30 minutes et votre bonus en ligne? Je ne.

Alors, l'entretien est-il inutile? Non, mais l'accent devrait être mis sur leur explication de ce qu'ils ont fait et de ce qu'ils ont apporté.

Vous allez également être sujet à toutes sortes de préjugés psychologiques une fois que vous rencontrerez quelqu'un en face à face. N'embauchez pas accidentellement un programmeur, car il établit un meilleur contact visuel ou est plus grand que quelqu'un d'autre. Pour les parcourir, je conduisais l'entretien le plus possible par messagerie instantanée / courrier électronique avant que vous ne les rencontriez face à face.


Vous pouvez inverser cet effet en observant les préjugés psychologiques des autres candidats dans l’historique d’embauche des candidats. Les personnes de petite taille qui ont occupé des postes de direction et qui ont obtenu des résultats sont probablement vraiment très bonnes. Les personnes de grande taille ayant la même histoire seront en moyenne moins bonnes et se débrouilleront avec des points de halo.
Tim Williscroft

2

La langue n'a pas d'importance. La logique fait. Je veux dire que les développeurs et les développeurs sont si bons de nos jours que tout bon programmeur peut choisir n'importe quelle langue (ok peut-être pas assembleur) en une semaine; devenir décent en quelques semaines et être très bon en quelques mois.

C'est son cerveau que vous devez confirmer. Et vous faites ça ma conversation. Je leur demande de résoudre des problèmes simples. Pas en écrivant du code, mais en me guidant dans leur logique pour trouver une solution.

Mais je l'avoue, s'il ne peut pas écrire une simple boucle comptant de 1 à 10, vous avez des problèmes.


1

Tout d'abord, il y a un moyen de se faire une idée avant même le début de l'entretien:

S'ils ont un blog ou contribuent à un ou plusieurs projets open source, il suffit de regarder le code et les articles qu'ils ont écrits. Tout d’abord, s’ils ont fait l’un ou l’autre de ces objectifs, ils ont alors l’initiative de faire avancer les choses. En outre, vous pouvez comparer ces éléments à l'expérience de travail qu'ils ont indiquée dans leur CV et avoir une idée s'ils rentrent chez eux et en apprennent plus après leur travail, ou s'ils rentrent chez eux et oublient leur travail après 17 heures.

Essentiellement, ont-ils une passion pour la programmation ou non? C'est la vraie question.


1

Avoir un bon programmeur présent dans l'interview est le meilleur à mon avis.

Seul un expert peut juger si le postulant sait simplement beaucoup de questions d'entrevue ou s'il pense réellement aux problèmes et peut entrer dans les détails. N'oubliez pas que vous ne voulez pas embaucher des gens pour résoudre des énigmes d'entrevues, mais les engager pour faire du travail réel.

Les puzzles doivent exclure les personnes qui ne maîtrisent pas les bases. Si vous souhaitez tester vos compétences, préparez quelques éléments que vous (ou votre "bon programmeur") pouvez entrer dans les détails et vous concentrer sur ceux sur lesquels le candidat doit réfléchir pendant un certain temps. Comment aborde-t-il les problèmes dont il ne connaît pas immédiatement la solution?


1

Je ne pense pas que vous devriez parler de passion lors de l'entretien. Franchement, cela ressemble à une entreprise qui recherche la «passion» signifie vraiment «travailler pour pas d'argent pour l'idée».

La passion ne justifie même pas l'excellence. Je veux dire, je passe presque toute ma vie à programmer, à lire sur la programmation, à apprendre des langages fous comme Erlang ou Clojure et je ne suis pas payé pour cela. Pourtant, je suis nul en programmation.

Je pense qu'un excellent programmeur devrait avoir une trace des projets réussis dans lesquels il a été activement impliqué. Ainsi, obliger un programmeur à écrire quoi que ce soit au-dessus de FizzBuzz de base est inutile dans l'interview. Parlez de leurs projets passés et de ce qu’ils ont fait. Embauchez-vous des programmeurs pour résoudre les cubes de Rubik et compter les billes ou travaillez-vous sur des projets logiciels volumineux et épuisants de plus de 50 lignes de coe?


1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

De l'article:


Les critères à puces

En résumé, voici quelques indicateurs et contre-indicateurs qui devraient vous aider à reconnaître un bon programmeur.

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


cela vous dérangerait-il d'expliquer davantage ce qu'il fait et pourquoi le recommandez-vous comme réponse à la question posée? Les "réponses en lien uniquement" ne sont pas tout à fait les bienvenues à Stack Exchange
Gnat,

0

Un excellent programmeur sera également capable de travailler avec ces pairs du spectre inférieur. Tant qu'ils peuvent faire le test et ne se vautrent pas dans leur ego, vous avez un bon candidat, non?

Ce test de fizzbuzz est un peu drôle cependant. La solution à laquelle je peux penser utilise l'opérateur modulo. Ce que je connais uniquement en travaillant sur les coordonnées cartographiques des feuilles de personnage (jamais mentionnées à l'école ou au collège). Le programmeur moyen serait-il même au courant de cela ou ai-je eu une éducation de merde?


Je suis surpris que vous n'ayez pas rencontré l'opérateur de modulo. On m’y a présenté dans les différentes langues que j’ai apprises au cours de l’année.

2
Si vous vous êtes spécialisé en CS au collège, l'opérateur de Modulo est en

étonnamment, des choses comme bit-shift et modulo sont ignorées au collège
Claudiu

Je pense que cela dépend du genre de choses qu’ils essaient de vous enseigner au collège. Je ne pense pas avoir jamais utilisé modulo dans un problème du monde réel, ni l'enseigner explicitement. Mais c'est très courant dans ce genre d'exercice (et dans les questions d'examen).
Interstar

2
En fait, ils sont généralement enseignés au primaire. à ce stade, ils sont appelés "le reste" et "multipliant par 10".
Intuition le

0

L'un des critères que j'utilise est de voir le «type» de langues et d'outils sur lesquels il a travaillé, que ce soit dans des projets académiques ou professionnels, et ce qu'il a exactement réalisé. A-t-il toujours travaillé au niveau de l'application en utilisant des bibliothèques standard (toujours un type C # ou VB6?) Ou a-t-il réalisé un projet en C utilisant Linux traitant des choses difficiles comme les pointeurs, la gestion de la mémoire, la récursivité, la synchornisation des processus, l'exclusion mutuelle, les événements, etc. S'il a toujours utilisé ces concepts de base et fondamentaux sous une couche d'abstraction, j'en doute.

C'est évidemment en plus de lui faire écrire du code. Rien ne se substitue à cela. Cependant, je tiens compte du fait que certaines personnes peuvent écrire du code plus rapidement que d’autres, et que les temps de réponse des personnes lorsqu’ils se présentent dans des interviews sont différents.


récursivité, synchronisation des processus, exclusion mutuelle. Ces technologies sont tout aussi importantes, que vous travailliez avec C #, VB.NET, C ou en langage assembleur.

-1 - C'est complètement faux. Le "type" de langues et les outils sont "sans importance" à 100%.
Morgan Herlocker
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.