Je ne suis pas recruteur pour les grandes entreprises, mais j'ai beaucoup d'expérience avec les petites entreprises et un peu de bon sens.
En 2013, j'ai mené une campagne de recrutement très réussie sur AboutEcho.com qui a abouti à l'embauche de neuf ingénieurs seniors. Mes lecteurs russophones pourraient lire ici .
Tout cela me donne la confiance nécessaire pour critiquer les méthodes qu'utilisent les géants de l'Internet pour embaucher des ingénieurs à ce jour.
Ne visez pas la meilleure solution
Lorsque vous arrivez pour un entretien, l'enquêteur vous pose un problème et attend une solution en 0 à 2 minutes. Si vous prenez plus de temps, ils seront vraiment excités et leur demanderont de dire quelque chose.
C'est compréhensible - après tout, ils n'ont que 45 minutes et ils veulent discuter de beaucoup de choses avec vous.
Je ne comprends pas comment vous êtes jugé sur la qualité de la solution que vous avez trouvée en deux minutes. Parce que ce n'est pas ainsi que fonctionne la créativité humaine. Il est facile de trouver de nombreuses idées, mais il est étrange de s'attendre à ce que le meilleur passe toujours en premier. Même les génies ne peuvent pas générer de manière prévisible les meilleures idées du monde en peu de temps.
La créativité est la capacité d'évaluer et de filtrer le flux d'idées que vous proposez. Si cela vous intéresse vraiment, pourquoi ne pas demander à l'autre personne de comparer et d'évaluer plusieurs idées? Vérifier si une personne peut évaluer les propriétés de la solution proposée? S'il voit clairement les avantages et les inconvénients?
Et si vous demandez à trouver la meilleure solution en deux minutes, alors vous testez votre chance, rien de plus. Êtes-vous dans le métier de recruter des employés qui réussissent? Ou capable?
Ne posez pas d'énigmes
Comment puis-je vérifier si une liste liée a une boucle? Une boîte à N dimensions rentre-t-elle dans une autre boîte à N dimensions? Pouvez-vous échanger deux variables sans la troisième? Comment trouver la distance la plus courte entre deux navires en mouvement? Trouver toutes les permutations de N éléments en effectuant uniquement N-1 permutations?
Il est amusant de parler de ces énigmes et leurs solutions peuvent être très utiles. En tant qu'enfant, j'adorais que beaucoup d'entre eux lisent Math Fun et Essays . Ne vous méprenez pas, ils sont hilarants.
Cependant, aussi drôles soient-ils, ce ne sont que des anecdotes. La propriété d'un puzzle est que vous connaissez la réponse ou non. Cela ne vous dit rien d'autre. Cela n'a rien à voir avec les performances futures, les compétences, les capacités ou quoi que ce soit d'autre. Connaître une réponse précise ne signifie pas que vous disposez d'un appareil pour résoudre de vrais problèmes de manière générale et prévisible. La seule chose que cela vous dit, c'est que la personne était dans cette situation et que quelqu'un a partagé une solution avec elle. Ni plus ni moins. Arrêtez-vous déjà.
Comment être sauvé avant que la bougie ne brûle la corde?
Soyez ouvert aux alternatives
C'est quelque peu prévisible, mais les grandes entreprises semblent toujours tomber dans le piège. Si l'enquêté propose une solution alternative, vous, en tant qu'intervieweur, avez une chance d'apprendre quelque chose. C'est aussi une bonne chance pour une discussion plus approfondie si la solution proposée s'avère impossible ou mauvaise.
Cependant, j'ai été licencié pour une fois en proposant une solution alternative de la même complexité (et chargé d'une conférence sur «la seule vraie approche de ce problème»), et à une autre occasion j'ai strictement conduit à une solution spécifique. Dans ce dernier cas, l'intervieweur voulait vraiment ignorer toutes mes préoccupations et ne voulait discuter que de ce qu'il considérait comme une solution au problème, et a ensuite laissé une critique "pas impressionnante" sur moi.
Personne ne sait tout. Être ouvert. Ecoutez. Méditer. Oui, même si vous interviewez quelqu'un.
Soyez tolérant aux défauts
Les erreurs uniques sont largement reconnues comme l'un des problèmes les plus difficiles en CS pour une raison - tout le monde les fait. Les erreurs font partie de la vie d'un programmeur, pas quelque chose dont il faut se débarrasser. Un bon programmeur sait juste quoi faire à ce sujet. La qualité d'un programmeur n'est PAS déterminée par le peu d'erreurs qu'il commet.
Désormais, si vous ne sélectionnez que des personnes qui n'ont pas commis d'erreurs lors de l'entretien, vous n'obtenez pas comme par magie une équipe de programmeurs qui écrivent toujours un code impeccable. Vous ne savez tout simplement pas comment ils se comporteront lorsqu'ils feront inévitablement des erreurs.
Les erreurs sont donc bonnes, car vous apprendrez comment cette personne les corrige. Ne jugez pas les erreurs, évaluez comment l'interlocuteur les gère:
- code simple,
- diviser pour régner,
- autotests,
- invariants,
- déclaration,
- compilation et exécution,
- essai.
Oh, désolé pour les deux derniers. J'ai oublié que vous ne les laissez pas exécuter leurs programmes. Eh bien, à quoi vous attendiez-vous alors?
Laisse moi vérifier!
Sérieusement, qu'est-ce que l'écriture d'un programme sur un tableau blanc?
Je veux dire, je suis heureux de discuter des algorithmes - car discuter de choses abstraites est plus efficace.
Mais écrire des programmes pour de vrais programmeurs dans un cahier? Sans même les exécuter? À quoi ça sert? L'obtention du premier brouillon de code ne représente qu'un dixième de l'ensemble du processus, suivi de la compilation, de la validation, du réglage, des tests, de la validation, etc. De qui se moque-t-on? Ce sont des éléments essentiels du flux de travail de tout programmeur. Il est utile de ne regarder le code que lorsqu'il a déjà traversé tout cela, et pas avant.
C'est comme demander à l'artiste de dessiner un cheval puis l'arrêter à mi-chemin de la toute première esquisse, quand on voit les quatre lignes verticales des jambes et qu'on en juge. Combien apprenez-vous sur elle?
Explorez plus profondément
Cinq courtes interviews? Ou deux longs?
Avec cinq, vous obtenez cinq opinions indépendantes, ce qui est mieux que deux. Mais à quelle profondeur pouvez-vous plonger en 45 minutes? La pratique montre qu'il suffit d'écrire 20 à 30 lignes de code et de poser quelques questions très simples (quelle est la difficulté? Comment tester?).
L'enquêteur suivant répète simplement le même processus jusqu'à ce que le précédent. Cela ne durera pas longtemps. Pas pour longtemps.
Pourquoi ne pas en faire deux et les rendre vraiment solides? Par exemple, un avant le déjeuner et un après? Trois heures, ce n'est pas beaucoup non plus, mais au moins vous avez la chance de voir comment une personne teste le code, comment elle le change, comment elle travaille avec les exigences - le tout dans le contexte déjà établi, sans réinitialiser et recommencer à zéro toutes les 45 minutes ...
Avec autant de temps, vous pouvez même lui demander d'écrire le code comme s'il faisait partie d'un système, pas seulement un problème algorithmique abstrait dans le vide, et d'en apprendre une ou deux autres sur ses caractéristiques réelles.
Et si vous voulez plus d'avis? Ayez quelques intervieweurs dans la salle pour qu'ils se disputent plus tard.
Explorez l'arrière-plan
J'ai quatorze ans d'expérience (au moment de la rédaction, 2019). Je serais heureux de parler de programmation fonctionnelle, de systèmes distribués, de consensus, de réplication, de co-création, de CRDT, d'architectures parallèles, de cadres d'interface utilisateur, de processus d'équipe, de conception de produit, d'expérience utilisateur. J'ai une expérience pratique et de recherche dans tous ces domaines. Tous intéressent directement plus ou moins tous les géants de l'Internet que j'ai interviewés.
Ai-je déjà été interrogé à ce sujet? Non.
J'obtiens "Imaginez que vous avez une fonction qui prend une liste ..." cinq fois de suite. Les cinq tâches au niveau de l'école devraient vous donner une idée adéquate de quoi? Dans quelle mesure ai-je lu Cormen et al.? Pour être honnête, ils sont rarement interrogés à leur sujet non plus.
Personnalisez plutôt votre entretien en fonction de l'expérience du candidat. Parlez de ce qu'il fait. Vous aurez l'occasion de poser des questions profondes et d'en apprendre davantage sur le niveau d'expérience et les avantages qu'il apportera à votre entreprise.
Rendre le processus fluide
Mauvaise direction? Billets retardés? Formulaire de demande nécessitant l'installation spécifique d'Adobe Reader? Un ultrabook bon marché avec une disposition de clavier inconnue et un mauvais éditeur Web sans aucun raccourci qui ralentit même sur une machine locale? Désolé, je suis dans le bureau de la société informatique la plus compétente au monde, n'est-ce pas?
Dans mon cas, un recruteur faisait cinq entretiens par jour. Cinq personnes chaque jour. Multiplié par le nombre de recruteurs dans cette entreprise. Imaginez que tous ces candidats soient légèrement frustrés par le processus. Tous les jours. Année après année.
Vous pourriez penser que cela n'a pas d'importance. Dépend. Il y avait un épisode de l'émission télévisée "Louis" où le nom de la bande dessinée était écrit sur sa porte. Par conséquent, il a soutenu: oui, cette erreur est facile à commettre, mais elle est également facile à corriger. Ce n'est pas grave, c'est juste pour un jour, si vous êtes même un peu inquiet, faites-le bien.
Oui, je pense que tout le monde peut faire mieux.
Enfin
Si vous embauchez des ingénieurs en logiciel, les praticiens des grandes entreprises ne sont pas vos amis. Le bon sens, l'équité, la tolérance, le réel intérêt et l'ouverture d'esprit sont des amis.
Bonne location!