L'une des choses qui m'embêtent sur LinkedIn est le post "comment interviewer les développeurs". Il y en a beaucoup, et ils tombent presque tous dans trois camps:
Au fil des ans, j'ai interviewé des dizaines de fois et j'ai embauché centaines de développeurs pour diverses entreprises - de Microsoft et Dell aux petites startups. J'ai également eu une vie ancienne comme un psychologue de recherche spécialisé en psychométrie (la science de la mesure des capacités mentales). tous les côté.
Le code d'écriture n'est souvent pas une activité sociale. Bien sûr - les compétences douces comptent. Mais elles sont souvent orthogonales à la pratique réelle de l'écriture de code pour résoudre de vrais problèmes d'utilisateur.
Alors comment interviewez-vous quelqu'un pour un travail qui est principalement à propos de l'écriture du code ?
Notre profession est également en rapport avec syndrome de l'imposteur - Je l'ai vu en moi-même et en d'innombrables autres. déjà C'est une escroquerie ?
Et nous sommes souvent un groupe socialement embarrassant (y compris moi-même). Une entrevue qui est à la fois stressante et exige la résolution de problèmes en direct est une recette pour le désastre.
Alors comment interviewez-vous quelqu'un qui est nerveux, embarrassant, ou qui doute déjà d'eux-mêmes ?
Ne fais pas ça. début à moins que leur expérience ne s'aligne. Cela respecte leur temps et Le tien.
Faire en sorte que le processus soit clair et humain.
Être à l'heureS'ils sont en retard, donnez-leur quelques minutes.
Demandez-vous : Est-ce qu'ils s'adapteraient tempérament à l'équipe ? Un codeur brillant qui est un abruti est une perte nette.
Après des années de questions de Fibonacci et de marathons de liste liés, j'ai appris une vérité fondamentale:
Les codeurs adorent parler de code qu'ils connaissent.
C'est le secret. Et ça ne fonctionne que si l'intervieweur comprend vraiment ce qui est montré. Si vous ne connaissez pas le cadre (Angulaire, Réagir, quoi qu'il en soit) - encore bien. Concentrez-vous sur la structure, la clarté, la dénomination, l'intention.
Alors, dis-leur. à l'avance (5 jours, c'est juste) que vous voudrez discuter du code qu'ils ont écrit. Montre-moi quelque chose dont tu peux parler.
Ils pourraient ne pas avoir GitHub – c'est ok. Un extrait personnel ou de travail est bien. Le but n'est pas de trouver le génie. C'est de trouver Propriété.
Vous n'embauchez pas en fonction de combien de temps libre quelqu'un a.
Annexe I ça me rend très anxieux - même si j'ai construit des centaines de systèmes. C'est UNNECESSAIRE.
Voici pourquoi cette approche est meilleure :
Candidats subalternes peut Il faut un petit test pratique - mais gardez-le humain. Ne les faites pas refactorer un fichier d'héritage de 4 000 lignes.
Interrogez-vous sur les boucles, les conditions, les bases du monde réel.
Les modèles de conception? Beaucoup de gens les utilisent tous les jours sans connaître le nom. Ne soyez pas accrochés sur les étiquettes.
Les puzzles logiques ? Jamais eu besoin d'eux dans le vrai travail. Jamais vu une utilisation réelle pour savoir combien de tuners de piano existent à New York.
Que le candidat ait ou non le rôle - suivi.
S'ils ne l'ont pas eu. Expliquez pourquoi. Donnez-leur quelque chose d'utile à emporter.
S'ils l'ont eu : Dites-leur à quoi s'attendre. Laissez-les respirer.
Parce qu'en fin de compte :
Un entretien devrait révéler la capacité - pas protéger l'ego. Il devrait ajouter de la valeur - même si la réponse est non.
L'entrevue la plus précise que j'ai jamais trouvée est simple : Laissez les candidats parler de code dont ils sont fiers. Parce que dans le code, l'honnêteté se manifeste. La pression le cache.
Quand les gens quittent votre interview se sentent respectés — même en cas de rejet — Tu as déjà construit quelque chose qui mérite d'être rejoint.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.
