L'année dernière, j'ai passé d'innombrables heures à interviewer des candidats pour divers postes chez Facebook. Et, puisque maintenant j'ai eu l'occasion de visiter les deux côtés du processus de sélection, je voudrais vous aider - les étudiants qui tentent de faire leur premier stage, les développeurs plus expérimentés qui se préparent à déménager dans une autre entreprise, ou ceux qui veulent se lancer dans la programmation d'un environnement professionnel complètement différent.
Dans cet article, je veux souligner les leçons les plus importantes que j'ai apprises de l'expérience d'interviewer des programmeurs sur Facebook. J'espère qu'ils ont mis en lumière certaines caractéristiques de ce processus, qui très, très nombreux nerfs très épuisants.
Format
Les entretiens pour les programmeurs, en règle générale, prennent la forme d'une conversation, d'une durée de 45 minutes et visent à tester vos connaissances des structures de données et des algorithmes. Les stagiaires n'ont généralement besoin de passer qu'une seule entrevue où ils montrent leurs compétences en écriture de code. Les développeurs de niveau supérieur devront probablement assister à deux ou trois entretiens de rédaction de code, un ou deux entretiens où ils testeront leurs compétences en conception de systèmes, ainsi qu'à une réunion séparée pour évaluer leurs qualités personnelles. Ici, je ne parlerai que des interviews de code.
Récemment, on m'a demandé: "Et si je ne trouve pas de solution à ce problème tout de suite?" J'ai répondu: "Eh bien, si la tâche est choisie correctement, vous ne devriez pas la trouver immédiatement." Sinon, à quoi ça sert? Le but de l'entretien est de comprendre à quel point vous êtes bon en programmation. Dans l'équipe Facebook, les informations qui répondent à cette question s'appellent un signal. L'intervieweur cherche à tirer le meilleur parti de lui. En d'autres termes, si nous comprenons que vous connaissez déjà la tâche proposée, notre responsabilité est de vous en donner une autre.
Nous devons voir comment vous gérez les difficultés. Si, par hasard, vous pouvez réciter la solution par cœur directement à partir de Cracking The Coding Interview, alors nous ne savons rien de votre capacité à résoudre des problèmes.
Meilleures pratiques pour les entretiens d'embauche
Les meilleurs des meilleurs candidats deviennent le moteur de l'entretien - ils ont eux-mêmes une conversation et n'ont pratiquement pas besoin de l'employé de l'entreprise pour les pousser dans la bonne direction. Habituellement, ces programmeurs sur un coup de tête, sans invite de l'extérieur, procédez comme suit:
- Posez des questions de clarification.
- Analyser les options de solution, leurs avantages et leurs inconvénients
- Projet de code
- Afficher la mise en œuvre de la solution
- Tester votre solution
Ne confondez pas initiative et hâte. Une position active ne signifie pas que vous devez immédiatement vous précipiter pour écrire du code. Au contraire, si vous démarrez le code dans les cinq premières minutes de la conversation, cela peut considérablement ruiner l'impression. La première étape d'un entretien d'embauche brillant est de clarifier les questions intelligemment.
Clever Ask QuestionsAvant de prendre une décision, vous devez bien comprendre le problème. Quelques raffinements réfléchis peuvent sérieusement augmenter vos chances de succès. En voici quelques exemples:
- Est-ce que cela doit être fait sans mémoire supplémentaire?
- Sur quel apport devrions-nous nous concentrer?
- Quoi de plus important - performances ou faible consommation de mémoire?
De cette façon, vous pouvez vous concentrer sur ce qui compte vraiment et retirer tout le reste de votre tête. Savoir ce à quoi vous ne pouvez pas penser n'est pas moins précieux que de savoir que cela nécessite une attention particulière.
Ne pense pasTrès souvent, les candidats commencent à ajouter une sorte de spéculation par eux-mêmes (les variables ne sont que des nombres positifs, les tableaux ne peuvent pas être vides, toutes les données d'entrée sont sûres). C'est une grave cloche. N'ajustez jamais les conditions pour trouver plus facilement une solution. Demandez.
"Supposons-nous que toutes les valeurs sont positives?"
Nulle part est plus facile. S'ils disent oui, c'est super. Aucun contrôle supplémentaire n'est requis. Sinon, une seule déclaration de condition suffit pour protéger votre code de toute chance. Souvent, à l'aide de ces questions, vous pouvez obtenir une indication de la direction à prendre.
Options de solutionLes intervieweurs aiment beaucoup quand les candidats mettent en avant plusieurs solutions. Cela montre que vous comprenez: vous pouvez aborder n'importe quelle tâche sous différents angles et, plus important encore, cela oblige l'interviewé à vous le dire sans demandes directes de votre part. Ouais!
Nous ne pouvons pas simplement prendre et mettre en place la bonne réponse pour vous. Mais si vous proposez deux options, A et B, et demandez: «Quelle approche, à votre avis, est la plus appropriée ici?», Alors nous choisirons certainement ce qui ressemble le plus à celle souhaitée.
Rédiger votre solution sous forme de codeLors des entretiens techniques, l'écriture est le plus souvent nécessaire sur le tableau noir. Par conséquent, il ne fonctionnera pas pour insérer des opérateurs quand et où il le souhaite. Vous devriez avoir une bonne idée de ce que vous allez faire avant de commencer à écrire.
Respirez profondément et commencez à planifier votre code. Il peut s'agir d'un projet de code, d'un schéma, l'essentiel est que vous sachiez quelles structures de données seront utilisées et quelles variables vous intéresseront. Je pense que personne ne veut que le résultat de son travail ressemble à ceci:
Écrivez l'implémentationÀ ce stade, tout cale généralement, bien que ce ne soit pas le cas. En théorie, la mise en œuvre de la solution est la plus simple. Vous avez posé des questions intelligentes, envisagé différentes approches, pensé à l'algorithme - il ne reste plus qu'à tout peindre. En attendant, n'oubliez pas ...
La communication!Parlez à haute voix. Il est assez difficile de vous amener au bon point si je ne sais pas du tout ce que vous pensez. Si vous vous transportez quelque part au mauvais endroit, j'interviendrai. Si vous vous déplacez dans la bonne direction, je ne vais probablement pas vous renverser.
Cependant, une mise en garde doit être faite: le style d'entrevue personnelle décide beaucoup. Quelqu'un intervient plus activement au cours de la décision, quelqu'un préfère rester à l'écart.
TestCurieusement, cette étape est le plus souvent négligée. Je dirais que 98% des développeurs qui ont assisté à mes entretiens devraient accorder plus d'attention à la vérification de leurs décisions.
Au début de l'entretien, le candidat reçoit généralement une option de test avec la tâche. À la fin des travaux sur la solution, ils exécutent le code via le test approprié. Mais il y a un problème: nous vous proposons l'option de test la plus primitive. En règle générale, cela n'affecte pas les cas limites et ne permet pas de vérifier le code comme il se doit. Avec ces paramètres, votre algorithme donne la sortie souhaitée; avec d'autres, il se peut que ce ne soit pas le cas.
La façon la plus simple de se montrer lors d'un entretien technique est de passer des tests. Plus c'est mieux. Plus c'est dur, mieux c'est. Plus c'est complet, mieux c'est. Dans la plupart des cas, cela vous permettra d'attraper des bogues avant de les signaler. Et de telles choses parlent en votre faveur.
Que faire si vous ne savez pas quoi faire
Alors, que faire quand on vous confie une tâche et que vous ne trouvez pas de solution tout de suite?
Procédez par étapes. Rappelez-vous: la tâche vous semblera peut-être semblable à celles que vous avez résolues auparavant. Beaucoup des tâches que j'ai proposées lors des entretiens étaient des tâches de base, qui sont démontées dans tous les cours où les algorithmes et les structures de données sont étudiés - mais avec un subvert.
Si rien ne vous vient à l'esprit, ne paniquez pas. Tout va bien. Ne vous inquiétez pas d'essayer de trouver immédiatement la solution la plus efficace - commencez par la plus simple. Puis, en prenant un point de départ, pensez: quels sont les goulots d'étranglement ici? Qu'est-ce qui nécessite le plus d'optimisation? Comment cela peut-il être optimisé?
Réduisez les faiblesses du système grâce aux atouts des structures de données. Lorsque vous devez rendre un algorithme plus efficace, les structures de données viennent souvent (mais pas toujours) à la rescousse. Chacun d'eux a ses propres avantages et inconvénients (la table de hachage est la vitesse de recherche des données, l'arbre de recherche binaire les trie et ainsi de suite). Les meilleures solutions sont obtenues lorsque vous parvenez à fermer un goulot d'étranglement en raison de la force de l'une ou l'autre structure de données.
Eh bien, par exemple, vous avez une tâche:
Étant donné une proposition, calculez combien de fois chaque lettre de l'alphabet y apparaît.
Si vous utilisez la méthode de recherche exhaustive, vous devrez compter chaque lettre tour à tour, puis résumer les données dans le résultat final. L'inefficacité de la méthode réside dans la nécessité de stocker et de rechercher des informations: nous sauvegardons les données que nous avons reçues pour chaque lettre, puis nous les extrayons pour former un résultat global. Si vous regardez les structures de données disponibles, vous remarquerez que l'une se démarque des autres dans la façon dont nous avons besoin:
- Arbre de recherche binaire
- Array
- Table de hachage
- Arbre AVL
- Pile
- File d'attente
La table de hachage stocke et récupère le plus efficacement les données. Si vous l'utilisez, vous n'avez pas à analyser la proposition vingt-six fois - une seule suffit.
Cherchez un indice
Souvent, un indice est introduit dans les tâches de programmation qui ouvre la voie à une solution plus pratique. Habituellement, c'est une sorte de bagatelle, une condition inhabituelle en raison de laquelle vous pouvez agir avec une plus grande efficacité qu'avec d'autres conditions initiales. Vérifiez s'il y a quelque chose comme ça dans votre tâche.
Disons:
Étant donné deux tableaux triés de type Integer, A et B; il est nécessaire de fusionner B de A. On suppose que A peut accueillir tous les éléments de B; le nombre d'éléments initialisés dans les tableaux est respectivement m et n.
La tâche est directement tirée du livre How To Crack the Coding Interview. Vous avez remarqué un indice? On pourrait nous donner seulement deux tableaux pour la fusion, mais non: dans notre scénario, l'un est complètement placé dans l'autre. C’est de cela que je parle. Si vous remarquez de telles réservations, sachez qu'elles ne sont pas incluses accidentellement.
Ici, l'espace libre vous donne la possibilité d'optimiser le processus de fusion. La solution complète peut être consultée
ici .
Demandez de l'aide
Il arrive parfois que vous passiez toutes les étapes, mais que vous restiez dans une impasse. Dans ce cas, il vous suffit de contacter les enquêteurs pour obtenir de l'aide.
Du fait que nous resterons assis dix minutes en silence, cela ne deviendra plus facile pour personne. Si vous ne savez vraiment pas quoi faire, demander des indices sera la meilleure solution. Chacun de nous a besoin de conseils de temps en temps. Tout décide comment vous pourrez l'utiliser.
En conclusion
Un entretien technique est le même test standardisé que ceux que nous connaissons depuis l'obtention du diplôme et l'inscription à l'université. Les tâches diffèrent dans les détails, mais les concepts de base et les stratégies de solution restent plus ou moins standard.
Beaucoup de candidats sont coupés de choses très simples: ils inventent leurs propres conditions, ne prononcent pas le fil de la pensée, testent mal leur décision. Toutes ces erreurs peuvent être corrigées et «certainement pas» peut se transformer en une «prise». Utilisez le système que j'ai esquissé dans cet article et vous serez en bonne forme.