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 source
Réponses:
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
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
Mathématiques discrètes
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.
la source
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.
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.
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é.
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.
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! "
la source
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à .
la source
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.
la source
Peut-être un "excellent" programmeur ne viendra-t-il pas vous interviewer. Vous devez probablement le voler à quelqu'un d'autre.
la source
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
la source
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.)
la source
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:
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.
la source
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.
la source
Demandez-leur de coder sur un tableau blanc. Seul moyen de savoir s’ils savent écrire du code.
la source
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.
la source
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.
la source
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.
la source
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?
la source
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?
la source
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 :
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
la source
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?
la source
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.
la source