Quelles techniques utilisez-vous lors des entretiens avec les développeurs? [fermé]

28

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.

Paddyslacker
la source

Réponses:

21

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.

Sergio Acosta
la source
4
J'irais probablement jusqu'à dire que c'est la chose la plus importante à évaluer dans toute interview logicielle. Vous pourriez faire valoir que l'écriture de code est plus importante, mais les personnes qui ont couvert quelque chose de similaire récemment ou à l'université peuvent deviner leur chemin, alors qu'il est très difficile de simuler un intérêt réel et authentique.
Mike B
5
Je ne suis pas surpris que ce soit une réponse populaire sur ce site. Le public ici est par définition celui qui valorise la "culture du programmeur". (Je suis d'accord avec la réponse, mais j'ai rencontré plusieurs excellents programmeurs qui échoueraient à ce test, en particulier ceux parmi la foule des plus de 40 ans)
AShelly
2
@AShelly: Oui, je suis d'accord. C'est pourquoi je ne considère pas cette question comme essentielle pour rejeter ou accepter un programmeur. C'est juste une autre technique que vous pouvez utiliser lors de l'entretien.
Sergio Acosta
16

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".

grokus
la source
6
Oui, mais pas trop.
Damovisa
Écrire du vrai code vous aidera à entrer dans les portes des éditeurs de logiciels d'élite (Google, Amazon, Microsoft, ...) et n'hésitez pas à choisir le reste.
grokus
3
Veuillez développer votre réponse. Qu'entendez-vous par "vrai" code? Quel code n'est pas "réel"?
MAK
+1 @MAK: D'accord, quel est le vrai code? Si c'est du code que vous comptez utiliser dans votre logiciel de production ...
Steven Evers
1
Je considérerais le «vrai code» comme quelque chose comme demander à l'interviewé d'écrire une fonction «strdup ()». Il a une utilisation réelle et expose leur expérience et leurs attitudes à des choses comme la gestion de la mémoire et la gestion des erreurs.
JBRWilkinson
11

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.

Brian R. Bondy
la source
2
+1 pour "les entretiens ne doivent pas être menés uniquement par les managers". Si la nouvelle recrue ne peut pas couper le code aussi bien que leurs collègues, il y aura des troubles au sein de l'équipe.
JBRWilkinson
7

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 :)

Geai
la source
6

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:

  • TCP ou UDP?
  • Langage dynamique ou typé statiquement?
  • Application monolithique ou plusieurs applications plus petites?
  • Que feriez-vous pour la communication interprocessus?
  • Procédures stockées ou ORM?

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.

Plie d'Evan
la source
La seule mise en garde que j'ajouterais à cela est de s'assurer que la question n'est pas spécifique au domaine de l'entreprise qui effectue l'entretien.
JBRWilkinson
1

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).

Josip Medved
la source
8
Je ne suis pas d'accord. Les listes liées et le tri sont tous deux des problèmes prédéfinis assez connus pour un problème commun. Quiconque en a écrit un sait comment ils fonctionnent, mais la plupart des gens ne se soucient pas d'écrire le leur, car la plupart des langues le font déjà très bien.
Evan Plaice
Je suis d'accord avec Evan. En pratique, il suffit souvent de connaître les performances des différents algorithmes de tri / recherche et des structures de données de base. Savoir comment les mettre en œuvre est soigné, mais finalement inutile. De plus, dans la plupart des travaux de programmation, il est plus important de savoir comment choisir le bon framework / bibliothèque pour la tâche que d'implémenter QuickSort en trois lignes.
Alan Plum
0

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.

Mark Brackett
la source