Présentation

L'un des aspects de MANY LinkedIn qui me bogue est le "comment interviewer les messages des développeurs". Il y a une TON d'entre eux et ils sont dans 3 camps :

Les Comment déplaceriez-vous le mont Fuji? approche avec des puzzles logiques et des théseurs de cerveau.
L'approche 'Voyons à quel point vous pouvez vous souvenir de votre diplôme en informatique' avec des questions algorithmiques.
L'approche 'watch you while you write code' avec des exercices de codage.

Au fil des ans, j'ai interviewé des dizaines de fois et engagé des centaines de développeurs pour diverses entreprises de Microsoft à Dell aux petites startups. J'ai aussi été un psychologue de recherche spécialisé en psychométrie (la science de la mesure des capacités mentales) et un développeur de logiciels. J'ai donc vu le processus de tous les côtés.

Le problème

Le codage n'est souvent pas une activité sociale. Bien sûr, les "compétences douces" sont d'une importance vitale, mais elles sont souvent orthogonales pour la pratique de l'écriture de code pour résoudre les problèmes des utilisateurs. Alors comment interviewez-vous quelqu'un pour un travail qui concerne surtout l'écriture de code?

Notre profession est également ravagée par le syndrome de l'imposteur. Je l'ai vu en moi-même et dans beaucoup d'autres. C'est une vraie chose. Alors comment interviewez-vous quelqu'un qui se sent déjà comme une fraude?

Notre profession est très embarrassante sur le plan social (et oui comme moi-même un peu autiste); une interview qui est à la fois stressante et nécessite une interaction sociale tout en résolvant les problèmes de codage est une recette de désastre. Alors comment interviewez-vous quelqu'un qui est socialement maladroit?

La solution

Lisez d'abord leur curriculum vitae; ne leur parlez même pas si leur curriculum vitae n'indique pas clairement qu'ils ont une expérience suffisante pour le poste pour lequel vous embauchez. Ce n'est pas seulement respectueux de leur temps, mais aussi le vôtre.

Deuxièmement, la mise en place de l'entrevue (ou des entrevues) devrait être aussi libre que possible de stress pour les participants. Cela signifie:

Donnez un préavis adéquat. Ne ressortez pas une entrevue sur quelqu'un avec un préavis de 24 heures (ou pire le même jour).
Préciser quel sera le format de l'entrevue, qui sera là et les résultats attendus (est-ce la finale, un écran technique, etc.).
Lisez le résumé de la personne. Je ne peux pas le souligner assez. Si vous interviewez quelqu'un, vous devriez connaître son CV à l'intérieur. Ce n'est pas seulement respectueux, mais il vous donne aussi l'occasion de poser des questions sur leur expérience.
Assurez-vous que vous avez les détails dans le MAIL; si c'est Teams / Zoom assurez-vous qu'ils ont le lien. Si c'est en personne, assurez-vous qu'ils savent où aller.

L'interview

Soyez à l'heure; rien ne rend une personne plus anxieux que d'attendre qu'une entrevue commence. Si tu es en retard, tu commences déjà au mauvais pied. S'ils sont en retard, donnez-leur quelques minutes; ils n'ont probablement pas été à l'arrière des réunions de sorte que leur configuration pourrait être visqueuse.

Est-ce qu'ils semblent être quelqu'un qui s'adapterait à l'équipe en termes de tempérament; sont-ils bons pour l'équipe? C'est important, vous pouvez avoir le meilleur codeur au monde, mais s'ils sont un abruti, ils n'en valent pas la peine.

Un conseil que j'ai trouvé (après des années de questions de séquence de Fibonacci, tableaux inversés, listes liées, etc) est.

Les médecins aiment parler de code qu'ils savent.

Cela signifie que si vous faites une évaluation technique, la personne qui effectue l'entrevue doit pouvoir parler du code qu'elle voit. Si c'est un cadre que vous ne connaissez pas (comme moi interviewant Angular devs) ne vous inquiétez pas trop.

Donc avant l'entrevue avec assez de préavis (5 jours est généralement bon) leur dire que vous leur demanderez de parler d'un morceau de code qu'ils ont écrit. Je ne demande pas généralement un lien GitHub (beaucoup de personnes aux niveaux supérieurs pourraient ne pas avoir cela; j'ai travaillé sur de nombreux projets qui sont propriétaires et ne peuvent pas être partagés).

Dites clairement que vous ne demandez pas un grand projet / un code innovant étonnant. C'est juste du code dont ils peuvent parler. Beaucoup de gens ont ces choses 'famille', les chances sont qu'ils n'ont pas été un contributeur 365 jours série à un grand projet Open Source.

Vous n'embauchez pas en fonction de combien de temps libre quelqu'un a

Pourquoi?

Alors pourquoi préfère-t-on cette approche? Pourquoi je pense que c'est une meilleure façon d'interviewer les développeurs?

C'est moins stressant. La personne interrogée parle de quelque chose qu'elle sait. Ils n'essayent pas de résoudre un problème qu'ils n'ont jamais vu auparavant; vraiment la plupart du temps quand vous codez vous inquiétez de COMMENT ils écrivent du code quand ils ont le temps de l'écrire. La plupart d'entre nous ne font pas d'algorithmes fous pour faire des choses que notre cadre de choix fait déjà pour nous.
Vous pouvez évaluer s'ils mentent sur leur expérience. S'ils ne peuvent pas parler d'un code qu'ils ont écrit, ils ne l'ont probablement pas écrit.
Vous pouvez creuser dans le code de manière plus naturelle; pourquoi ils ont choisi cette approche par rapport à une autre, pourquoi ils n'ont pas utilisé une bibliothèque, etc.
Vous voyez le code qu'ils veulent vous montrer. C'est un gros. Si vous leur demandez d'écrire du code sur place, vous voyez du code qu'ils écrivent sous pression. Si vous leur demandez de parler de code, ils ont écrit que vous voyez le code qu'ils ont écrit quand ils ne sont pas sous pression. Encore une fois, à moins que votre lieu de travail ne soit un panier, la plupart du temps, vous n'écrivez pas de code sous pression.

Exceptions à la règle

Il y a donc des exceptions ici, les codeurs super juniors ont parfois besoin d'un peu d'exercice de codage, mais prenez-le lentement. Leur demander d'analyser et de refactorer / de fixer une base de code énorme est juste cruel. Pour eux, vous pouvez vous poser des questions sur les concepts de base comme les boucles, les conditions, etc. (conservez-les centrés sur le travail pour lequel vous embauchez). Des modèles? J'ai vu beaucoup de gens qui ne peuvent pas nommer un modèle, mais qui peuvent vous dire quand ils l'ont utilisé. Alors ne t'accroche pas trop à ça.

Des puzzles logiques? Je n'en ai jamais vu l'intérêt. Je n'ai jamais vu de travail où vous devez déplacer le mont Fuji. Je n'ai jamais vu un travail où tu dois savoir combien de balles de golf correspondent à un 747. Je n'ai jamais vu de boulot où tu as besoin de savoir combien de tuners de piano il y a à New York.

Suivi

Après l'entrevue, assurez-vous de suivre le candidat. S'ils n'ont pas obtenu le travail, dites-leur pourquoi (vous ne m'avez pas montré assez de votre expérience, vous n'étiez pas clair en expliquant votre code, etc.). Ce n'est pas seulement respectueux, mais il les aide aussi à s'améliorer pour la prochaine entrevue. S'ils ont obtenu le travail, assurez-vous qu'ils savent à quoi s'attendre.