Je me rends compte qu'il y a eu beaucoup de discussions sur ce type de choses et elles se transforment souvent en dogme pour savoir si vous posez des questions du type "100 pirates logiques" ou si vous leur demandez d'écrire "fizz buzz".
Je m'intéresse aux techniques et aux questions qui vous ont été efficaces lorsque vous interviewez des développeurs potentiels pour des emplois.
Une technique par réponse pour que nous puissions voter sur ces réponses, s'il vous plaît.
Réponses:
Outre de vraies questions techniques, et généralement à la fin de l'interview, j'essaie de comprendre leur niveau d'intérêt pour l'industrie et sa culture avec des questions comme:
Avez-vous vu quelque chose récemment lié à la programmation que vous avez trouvé intéressant et que vous aimeriez recommander à d'autres collègues programmeurs? Un nouveau langage, outil, plateforme, technique, site Web?
Pouvez-vous nommer une personne bien connue dans notre industrie dont le travail vous plaît ou vous inspire et pourquoi? (développeur, fondateur du site Web, auteur, conférencier, etc.)
Que lisez-vous maintenant ou quel est le dernier livre sur les logiciels que vous avez lu?
Quels sites liés à la programmation fréquentez-vous?
Bien que ne pas répondre à ces questions (cela arrive malheureusement très souvent) ne signifie pas pour moi un `` non-embauche '', ils en disent long sur la façon dont une personne aborde la profession de développeur de logiciels.
Faites-leur écrire du code, du vrai code.
L'intervieweur peut vous laisser choisir le langage de programmation avec lequel vous êtes le plus à l'aise, que ce soit C ++, Java, C # ou quoi que ce soit et vous demander de résoudre un problème simple, par exemple en travaillant avec une chaîne ou une liste doublement liée ou autre. Si vous avez du mal à utiliser votre meilleure langue pour résoudre un problème simple, il y a un problème. Veuillez consulter l' article de blog de Steve Yegge et en particulier la section "Préparation mentale".
Demandez à plusieurs personnes de votre équipe de les interroger indépendamment. Partagez vos pensées après, ne parlez pas entre les deux avant de les interroger. Parler entre les deux influencera votre jugement et vous n'aurez pas d'évaluations indépendantes.
Pour les techniciens qui les interviewent, faites-leur écrire du code. Pour les non techniques, n'essayez pas de demander des choses avec lesquelles vous n'êtes pas expérimenté. Assurez-vous cependant d'avoir au moins quelques personnes techniques à interviewer.
Les entretiens ne devraient pas être menés uniquement par les gestionnaires, ils devraient être extrêmement importants pour chaque travailleur avec qui ils travailleront à l'avenir.
J'aime avoir un interviewé pour expliquer leurs projets précédents et ce qu'ils ont fait. À partir de cette réponse, je peux poser des questions de suivi: pourquoi ils ont fait les choses d'une certaine manière, comment ont-ils résolu un problème particulier s'ils en ont mentionné un, mais surtout quel était le but du projet et quel problème commercial cela a résolu.
Je fais cela pour voir s'ils peuvent articuler d'une manière qui me fait comprendre ce qu'ils faisaient, et voir s'ils ont également compris ce qu'ils faisaient.
Il est surprenant que la dernière question sur le but du projet et le problème commercial résolu qui fait voyager beaucoup de gens. Ils n'ont aucune idée POURQUOI le projet sur lequel ils travaillaient se faisait du tout. Si vous ne savez pas pourquoi votre projet existe en premier lieu, cela me fait me demander si vous apportez des solutions ou si vous faites simplement ce qu'on vous dit.
(J'ai pensé que je jette celui-ci là-dedans, car toutes les autres réponses ont tendance à être techniques. Je veux des gens qui savent pourquoi ils résolvent les problèmes qu'ils résolvent aussi, sinon, ils ont tendance à résoudre les mauvais problèmes que l'utilisateur final ne fait pas '' t se soucient :)
Demandez-leur leur avis sur une décision architecturale importante
Par exemple. Voici le programme x qui exécute y nombre de sous-tâches simultanément. Que choisiriez-vous, une structure multi-processus ou de filetage.
Quels sont les avantages / inconvénients des deux. Dans quelle mesure fonctionneraient-ils et comment pourraient-ils être utilisés pour tirer parti d'une plate-forme multicœur et multiprocesseur, quelle est votre préférence personnelle? Les préjugés personnels peuvent aider à déterminer s'ils ont déjà dû appliquer les connaissances et leur donner un point de départ pour partager leurs expériences?
Il y a des tonnes de questions qu'un intervieweur pourrait poser comme celles-ci:
La plupart de ces sujets sont des types qui impliquent une connaissance intime de comment / pourquoi un système informatique fonctionne comme il le fait. Ce sont tous des problèmes / solutions à des problèmes qui n'ont pas de réponse définitive, de sorte qu'ils donnent une idée de la capacité de cette personne à s'adapter ou à surmonter les défis à relever. Pas le type de concepts qui peuvent être facilement repris sans une certaine expérience pratique.
Remarque: demander au demandeur d'écrire du code pesudo est également indispensable, mais cette réponse est déjà prise.
Donnez-leur simplement du code de base à faire sur le tableau blanc - par exemple, implémentation de liste liée, tri ou quelque chose de similaire.
Vous pouvez juger à quel point ils sont à l'aise avec leur langage sans l'aide du compilateur et vous pouvez juger de leur processus de réflexion (surtout s'ils n'ont jamais implémenté une telle chose - la plupart des "nouveaux" programmeurs ne l'ont jamais fait).
Ayez une conversation, laissez-la dériver et serpenter le long de l'itinéraire technique et professionnel et recherchez des commentaires perspicaces ou stupides en cours de route. Cela vous permet d'obtenir 3/4 de ce dont vous avez besoin à partir d'une entrevue, d'une évaluation des compétences et de la personnalité des personnes, de l'intelligence générale et d'une évaluation approximative des compétences techniques.
Utilisez vos "questions" d'entrevue comme initiateurs de sujets et pour maintenir la conversation sur des sujets techniques - vous devrez peut-être réinitialiser la conversation de temps en temps (comme faire un exercice de codage) pour sonder correctement les sujets de préoccupation / d'intérêt.
Le vrai truc de cette technique est de s'assurer qu'ils parlent bien, sinon vous courez le risque d'une évaluation favorable car ils vous ont fait sentir intelligent en écoutant / en étant d'accord avec tout ce que vous avez dit.