Le titre de l'article peut sembler être un échec épique, mais en réalité, tout n'est pas si évident. De plus, dans l'ensemble, cette histoire s'est terminée de manière plutôt positive, même si ce n'était pas chez Google. Mais c'est un sujet pour un autre article. Dans cet article, je vais parler de trois choses : comment mon processus de préparation s'est déroulé, comment se sont passés les entretiens chez Google et pourquoi, selon moi, tout n'est pas si simple qu'il n'y paraît.
Comment tout a commencé
Un soir froid d'hiver à Chypre, j'ai soudain eu l'idée que mes connaissances en informatique classique étaient assez éloignées de la moyenne, et qu'il fallait faire quelque chose à ce sujet. Si jamais quelqu'un n'a pas encore lu pourquoi la soirée était chypriote et froide, vous pouvez en apprendre davantage. . Après quelques réflexions, j'ai décidé de commencer par suivre un cours en ligne sur les algorithmes et les structures de données. J'avais entendu parler d'un cours de Robert Sedgewick sur Coursera. Le cours se compose de deux parties ( et ). Si jamais les liens changent, vous pouvez toujours rechercher le nom de l'auteur. Chaque partie dure 6 semaines. Au début de chaque semaine, des cours sont dispensés, et tout au long de la semaine, il faut également réaliser des exercices. La première partie du cours couvre les structures de données de base, les principaux types de tri et la complexité des algorithmes. La deuxième partie est plus avancée, elle commence par les graphes et se termine par des sujets comme la programmation linéaire et l'intractabilité. Après avoir réfléchi à tout cela, j'ai conclu que c'était exactement ce dont j'avais besoin. D'ailleurs, le lecteur curieux pourrait se demander quel rapport cela a avec Google. En effet, jusqu'à ce moment-là, il n'y avait aucun lien. Mais j'avais besoin d'un objectif, car étudier pendant 12 semaines le soir sans but peut être assez difficile. Et quel pourrait être l'objectif d'acquérir de nouvelles connaissances ? Bien sûr, leur application pratique. Dans la vie quotidienne, c'est assez problématique, mais lors d'un entretien dans une grande entreprise, c'est tout à fait possible. Quelques recherches rapides ont montré que Google (pardonnez la tautologie) est l'une des plus grandes entreprises en Europe (et je ne considérais que l'Europe) où de tels entretiens ont lieu. En effet, leur bureau se trouve à Zurich, en Suisse. Ainsi, c'est décidé : nous étudions et nous allons passer des entretiens chez Google.
Préparation pour la première tentative
Douze semaines sont passées sans que je m'en rende compte, et j'ai terminé les deux cours. Mes impressions sur les cours sont plus que positives et je peux les recommander à tous ceux qui sont intéressés. J'ai aimé ces cours pour plusieurs raisons :
- Le conférencier parle un anglais suffisamment clair.
- Le matériel est bien structuré.
- Des présentations magnifiques, montrant le fonctionnement interne de chaque algorithme.
- Une sélection de matériel bien pensée.
- Des exercices intéressants.
- Les exercices sont automatiquement corrigés sur le site, après quoi un rapport est généré.
Mon travail sur les cours se déroulait généralement comme suit. En 1 à 2 jours, j'écoutais les conférences. Ensuite, je passais un rapide test de connaissance du matériel. Le reste de la semaine, je réalisais l'exercice en plusieurs itérations. Après la première, j'obtenais entre 30 et 70 %, et les suivantes amélioraient le résultat jusqu'à 97-100 %. L'exercice consistait généralement à mettre en œuvre un algorithme quelconque, par exemple : ou .
Après avoir terminé les cours, j'ai réalisé que beaucoup de connaissances entraînent beaucoup de chagrins. Si auparavant je savais simplement que je ne savais rien, maintenant je commence à comprendre ce que je ne sais pas.
Puisqu'il n'était encore que mai, et que j'avais prévu mon entretien pour l'automne, j'ai décidé de poursuivre mon éducation. Après avoir examiné les exigences du poste, j'ai décidé de me concentrer sur deux axes parallèles : continuer à étudier les algorithmes et suivre un cours de base sur l'apprentissage automatique. Pour le premier objectif, j'ai décidé de passer des cours à un livre et j'ai choisi l'ouvrage monumental de Steven Skiena « Algorithms. A Designer's Manual ». Pas aussi monumental que celui de Knuth, mais tout de même. Pour le deuxième objectif, je suis de nouveau allé sur Coursera et je me suis inscrit au cours d'Andrew Ng .
Trois mois ont encore passé, et j'ai terminé le cours et le livre.
Commençons par le livre. La lecture s'est avérée assez intéressante, bien que pas facile. En principe, je recommanderais le livre, mais pas immédiatement. En général, le livre offre une analyse plus approfondie de ce que j'ai appris dans mes cours. De plus, j'ai découvert (d'un point de vue formel) des concepts comme les heuristiques et la programmation dynamique. Bien entendu, je les avais déjà utilisés auparavant, mais je ne savais pas comment ils s'appelaient. Le livre contient également un certain nombre d'histoires vécues par l'auteur (War Story), qui atténuent un peu le caractère académique de l'exposé. D'ailleurs, la seconde moitié du livre peut être omise, car elle décrit plutôt les problèmes existants et les méthodes de leur résolution. Cela peut être utile si appliqué régulièrement en pratique, sinon on oublie immédiatement.
Le cours m'a ravi. L'auteur connaît clairement son sujet et raconte de manière captivante. De plus, une partie importante, à savoir l'algèbre linéaire et les principes des réseaux neuronaux, je m'en souvenais encore de l'université, donc je n'ai pas rencontré de difficultés majeures. La structure du cours est assez standard. Le cours est divisé en semaines. Chaque semaine commence par des conférences entrecoupées de courts tests. Après les conférences, un devoir est donné, qu'il faut réaliser, envoyer, et il sera automatiquement corrigé. En résumé, voici la liste des sujets enseignés dans le cours :
— fonction de coût
— régression linéaire
— descente de gradient
— mise à l'échelle des caractéristiques
— équation normale
— régression logistique
— classification multiclasses (un contre tous)
— réseaux neuronaux
— rétropropagation
— régularisation
— biais / variance
— courbes d'apprentissage
— métriques d'erreur (précision, rappel, F1)
— Machines à vecteurs de support (classification à marges larges)
— K-means
— Analyse en composantes principales
— détection d'anomalies
— filtrage collaboratif (système de recommandation)
— descentes de gradient stochastiques, par mini-lots, par lots
— apprentissage en ligne
— map reduce
— analyse de plafond
Après avoir suivi le cours, la compréhension de tous ces sujets était là. Au bout de 2 ans, j'avais déjà presque tout oublié naturellement. Je recommande cela à ceux qui ne sont pas familiers avec l'apprentissage automatique et qui souhaitent acquérir une bonne compréhension des concepts de base pour avancer.
Première tentative
Nous étions déjà en septembre et il était temps de penser à l'entretien d'embauche. Étant donné que postuler par le biais du site était assez délicat, je me suis mis à chercher des connaissances travaillant chez Google. J'ai choisi , car il était le seul que je connaissais directement (même si ce n'était pas en personne). Il a accepté de transmettre mon CV, et peu de temps après, j'ai reçu un email du recruteur me proposant de réserver un créneau dans son calendrier pour un premier entretien. Quelque jours plus tard, l'appel a eu lieu. Nous avons essayé de communiquer via Hangouts, mais la qualité était terrible, donc nous avons changé pour le téléphone. Au début, nous avons rapidement discuté des questions standard comme le quoi, le pourquoi et le comment, puis nous sommes passés au screening technique. Cela consistait en une dizaine de questions du type « quelle est la complexité de l'insertion dans une hash map », « quels arbres équilibrés connaissez-vous ». Ce n'était pas difficile, si on a des connaissances de base à ce sujet. Le screening s'est bien passé et, suite aux résultats, nous avons décidé d'organiser un premier entretien dans une semaine.
L'entretien s'est également déroulé via Hangouts. Nous avons d'abord parlé de moi pendant environ 5 minutes, puis nous sommes passés à un exercice. Le sujet portait sur les graphes. J'ai rapidement compris ce qu'il fallait faire, mais j'ai choisi le mauvais algorithme. Lorsque j'ai commencé à écrire le code, je m'en suis rendu compte et je suis donc passé à une autre option que j'ai complétée. L'intervieweur a posé quelques questions sur la complexité de l'algorithme, m'a demandé s'il était possible de faire plus vite. J'ai eu un blanc et je n'ai pas pu répondre. À ce moment-là, le temps était écoulé et nous nous sommes quittés. Puis, environ 10 minutes plus tard, j'ai réalisé qu'au lieu de l'algorithme de Dijkstra que j'avais utilisé, on aurait pu utiliser la recherche en largeur pour ce problème, ce qui aurait été plus rapide. Un peu plus tard, le recruteur m'a appelé et a dit que l'entretien s'était globalement bien passé et qu'il fallait organiser un autre entretien. Nous avons convenu d'un nouvel entretien pour la semaine suivante.
Cette fois-ci, les choses se sont mal passées. Alors que lors du premier entretien, l'intervieweur était aimable et communicatif, cette fois, il était plutôt maussade. Je n'ai pas pu comprendre tout de suite le problème, même si les idées que j'ai proposées auraient pu conduire à sa résolution. Au final, après quelques indices de l'intervieweur, j'ai fini par trouver la solution. Il s'agissait encore une fois d'une recherche en largeur, mais à partir de plusieurs points. J'ai écrit les solutions et respecté le temps imparti, mais j'ai oublié les cas limites. Après un certain temps, le recruteur m'a appelé pour me dire que cette fois, l'intervieweur n'était pas satisfait, car, selon lui, j'avais eu besoin de trop d'indices (3 ou 4) et je changeais constamment mon code pendant que je l'écrivais. À la suite de ces deux entretiens, il a été décidé de ne pas poursuivre et de repousser le prochain entretien d'un an, si je le souhaitais. Et c'est ainsi que nous nous sommes dit au revoir.
Et de cette histoire, j'ai tiré quelques conclusions :
- La théorie, c'est bien, mais il faut s'y orienter rapidement.
- La théorie sans pratique n'aidera pas. Il faut résoudre des problèmes et automatiser l'écriture du code.
- Beaucoup dépend de l'intervieweur. Et il n'y a rien à y faire.
Préparation pour une seconde tentative
Après avoir réfléchi à la situation, j'ai décidé d'essayer à nouveau dans un an. J'ai légèrement ajusté mon objectif. Si auparavant l'objectif principal était l'apprentissage, et l'entretien chez Google comme une carotte lointaine, maintenant le passage de l'entretien était l'objectif, et l'apprentissage le moyen.
Ainsi, un nouveau plan a été élaboré, comprenant les points suivants :
- Continuer à étudier la théorie en lisant des livres et des articles.
- Résoudre un nombre d'environ 500 à 1000 problèmes algorithmiques.
- Continuer à étudier la théorie en regardant des vidéos.
- Continuer à étudier la théorie via des cours.
- Étudier l'expérience d'autres personnes concernant le passage d'entretiens chez Google.
Le plan a été réalisé par mes soins en un an. Plus loin, je décrirai ce que j'ai fait pour chaque point.
Livres et articles
Je ne me souviens même plus du nombre d'articles que j'ai lus, je les ai lus tant en russe qu'en anglais. Le site le plus utile a probablement été . Il contient une description d'un grand nombre d'algorithmes intéressants avec des exemples de code.
J'ai lu 5 livres : Algorithms, 4th edition (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4th edition (Gayle Laakmann), Programming Interviews Exposed 2nd edition (Mongan, Suojanen, Giguere), Elements of Programming Interviews (Aziz, Lee, Prakash). Ils peuvent être répartis en 2 catégories. Dans la première se trouvent les livres de Sedgewick et Cormen. Ce sont des théories. Les autres sont consacrés à la préparation aux entretiens. Sedgewick y aborde à peu près les mêmes sujets que dans ses cours, mais par écrit. Il n'est pas particulièrement utile de lire attentivement si vous avez suivi le cours, mais il vaut la peine de le parcourir. Si vous n'avez pas suivi le cours, il est bon de le lire. Cormen m'a semblé un peu ennuyeux. J'avoue que je l'ai lu avec difficulté. J'en ai retenu seulement , ainsi que quelques structures de données peu utilisées (tas de Fibonacci, arbre de van Emde Boas, tas radix).
Il vaut la peine de lire au moins un livre pour la préparation aux entretiens. Ils sont tous construits à peu près selon le même principe. Ils décrivent le processus d'entretien dans les grandes entreprises technologiques, fournissent des bases en informatique, des exercices liés à ces bases, des solutions et une analyse des solutions. Parmi les trois mentionnés, je recommanderais probablement Cracking the Coding Interview comme livre principal, et les autres selon vos besoins.
Les problèmes algorithmiques
C'était probablement le point le plus intéressant de ma préparation. Bien sûr, on peut s'asseoir et simplement résoudre des problèmes. Pour cela, il existe de nombreux sites différents. J'ai principalement utilisé trois : , et . Sur CodeChef, les problèmes sont classés par difficulté, mais pas par thèmes. Sur Hackerrank, ils le sont à la fois par difficulté et par thèmes.
Mais comme je l'ai immédiatement réalisé, il existe une méthode plus intéressante. Ce sont les compétitions (challenges de programmation ou concours de programmation). Les trois sites en offrent. Cependant, il y a un problème avec LeetCode : le fuseau horaire est peu pratique. Donc, je n'ai pas participé sur ce site. Hackerrank et CodeChef proposent un grand nombre de compétitions, allant de 1 heure à 10 jours. Diferents formats ont différentes règles, mais on peut en parler longtemps. L'essentiel est que, pourquoi les compétitions sont bénéfiques, c'est qu'elles introduisent un élément compétitif (et encore une tautologie) dans le processus d'apprentissage.
J'ai participé à 37 compétitions sur Hackerrank. Parmi elles, 32 étaient des compétitions classées et 5 étaient soit sponsorisées (j'ai même gagné 25 $ dans l'une d'elles) soit juste pour le plaisir. Dans les compétitions classées, je suis entré 10 fois dans le top 4 %, 11 fois dans le top 12 % et 5 fois dans le top 25 %. Mes meilleurs résultats étaient 27/1459 en trois heures et 22/9721 en une semaine.
Je suis passé à CodeChef lorsque les compétitions sur Hackerrank ont commencé à se faire rares. J'ai pu participer à 5 compétitions. Mon meilleur résultat était 426/5019 dans une compétition de dix jours.
En tout, lors de compétitions et simplement pour le plaisir, j'ai résolu un peu plus de 1000 problèmes, ce qui était dans mes objectifs. Malheureusement, je n'ai plus de temps libre pour continuer cette activité compétitive, tout comme je n'ai pas d'objectif qui justifierait le temps non libre. Mais c'était amusant. Je recommande à ceux qui s'y intéressent de trouver des amis partageant les mêmes idées. À deux ou en groupe, c'est beaucoup plus intéressant. Je me suis amusé avec un ami, c'est peut-être pour ça que ça a aussi bien marché.
Visionner des vidéos
En lisant le livre de Skiena, je me suis intéressé à ce qu'il fait. Comme Sedwick, il est professeur à l'université. Par conséquent, on peut trouver des enregistrements vidéo de ses cours en ligne. J'ai décidé de suivre le cours . Je ne dirais pas que j'ai beaucoup aimé. Tout d'abord, la qualité de la vidéo n'était pas très bonne. Ensuite, je n'ai pas essayé de résoudre moi-même les problèmes abordés dans le cadre du cours. Donc l'engagement n'était pas très élevé.
Aussi, en essayant de résoudre des problèmes et de trouver le bon algorithme, je suis tombé sur les vidéos de Tushar Roy. Il a travaillé chez Amazon, et maintenant il travaille chez Apple. Comme je l'ai découvert plus tard, il a , où il publie des analyses de différents algorithmes. Au moment de la rédaction de cet article, la chaîne contient 103 vidéos. Je dois dire que l'analyse qu'il propose est très bien réalisée. J'ai essayé de regarder d'autres auteurs, mais ça ne m'a pas vraiment intéressé. Donc, je recommande définitivement cette chaîne.
Suivi de cours
Je n'ai pas vraiment fait grand-chose ici. J'ai regardé des vidéos du programme Nanodegree de développeur Android de Google et j'ai suivi un cours de l'ITMO . Le Nanodegree est plutôt bon, même si je n'y ai naturellement rien appris de nouveau. Le cours de l'ITMO est un peu brouillon en termes de théorie, mais les problèmes étaient intéressants. Je ne recommanderais pas de commencer par celui-là, mais en soi, le temps passé n'était pas perdu.
Étudier l'expérience des autres
Il va de soi que de nombreuses personnes ont essayé de rejoindre Google. Certains ont réussi, d'autres non. Certains ont écrit des articles à ce sujet. Parmi les choses intéressantes, je noterais probablement et . Dans le premier cas, une personne a établi une liste des éléments à apprendre pour devenir ingénieur logiciel et rejoindre Google. Finalement, il a atterri chez Amazon, mais ce n'est pas si important. Le deuxième manuel a été écrit par une ingénieure de Google, Larisa Agarova (). En plus de ce document, vous pouvez également consulter .
Il vaut la peine de lire les avis sur les entretiens sur Glassdoor. Ils sont tous plus ou moins similaires, mais on peut en tirer certaines informations utiles.
Je ne vais pas fournir de liens vers d'autres petits articles, vous pourrez les trouver vous-même sur Google.
Deuxième essai
Et voilà, un an s'est écoulé. Cela a été une année très riche en enseignement. Mais à l'automne, j'abordais la nouvelle saison avec des connaissances théoriques beaucoup plus approfondies et des compétences pratiques bien développées. Il restait encore quelques semaines avant la fin de mon année de préparation, lorsque soudain un mail d'un recruteur de Google est tombé dans ma boîte, me demandant si j'avais toujours envie de travailler chez Google et si j'étais d'accord pour discuter avec lui. Évidemment, j'étais partant. Nous avons convenu d'un appel pour la semaine suivante. Ils m'ont également demandé un CV mis à jour, auquel j'ai ajouté une brève description de ce que j'avais fait au travail et en général au cours de l'année.
Après notre conversation, il a été décidé qu'un entretien sur Hangouts aurait lieu dans une semaine, tout comme l'année précédente. Une semaine s'est écoulée, l'heure de l'entretien est arrivée, mais l'intervieweur n'est pas apparu. Dix minutes se sont écoulées, j'ai commencé à m'inquiéter, quand quelqu'un est soudainement apparu dans le chat. Il s'est avéré un peu plus tard que mon intervieweur n'avait pas pu se présenter pour une raison quelconque et qu'une remplaçante avait été trouvée en toute urgence. La personne n'était pas vraiment prête, tant au niveau de la configuration de l'ordinateur que pour mener l'entretien. Mais ensuite, tout s'est bien passé. J'ai résolu le problème rapidement, décrivant où se trouvaient les pièges possibles et comment les contourner. Nous avons discuté de plusieurs options différentes pour le problème, de la complexité de l'algorithme. Puis nous avons encore discuté pendant cinq minutes, l'ingénieur a partagé ses impressions sur son travail à Munich (à Zurich, apparemment, ils n'ont pas trouvé de remplaçant en urgence), et nous nous sommes séparés sur cela.
Le même jour, un recruteur m'a contacté pour me dire que l'entretien s'était très bien passé et qu'ils étaient prêts à m'inviter à un entretien au bureau. Le lendemain, nous avons eu un appel via Hangouts pour discuter des détails. Comme j'avais besoin d'un visa, nous avons décidé de fixer l'entretien dans un mois.
Pendant que je préparais les documents, je discutais également avec le recruteur de l'entretien à venir. Un entretien standard chez Google se compose de 4 questions d'algorithmique et d'une conception système. Cependant, comme je postulais en tant que développeur Android, on m'a dit qu'une partie de l'entretien aurait une spécificité Android. Je n'ai pas réussi à obtenir du recruteur les détails précis. D'après ce que j'ai compris, cela a été introduit relativement récemment et il n'était pas très au courant lui-même. J'ai également été inscrit à deux sessions d'entraînement : une sur la façon de réussir un entretien algorithmique et une sur la conception système. Les sessions ont été d'une utilité moyenne. Personne n'a pu me dire ce que l'on demande aux développeurs Android. Ma préparation ce mois-ci s'est donc résumée à ceci :
- L'achat d'un tableau blanc et l'écriture de 2 à 3 dizaines des algorithmes les plus populaires sur celui-ci de mémoire. De 3 à 5 chaque jour. Au total, chacun a été écrit plusieurs fois.
- Rafraîchir en mémoire différentes informations sur Android que je n'utilise pas tous les jours.
- Regarder plusieurs vidéos sur le Big Scale et tout ça.
Comme je l'ai déjà mentionné, j'ai également préparé des documents pour le voyage en parallèle. Tout d'abord, on m'a demandé des informations pour préparer une lettre d'invitation. Ensuite, j'ai longuement cherché qui pouvait faire des visas pour la Suisse à Chypre, car l'ambassade suisse ne s'en charge pas. J'ai découvert que c'était le consulat autrichien qui s'en occupait. J'ai appelé et pris un rendez-vous. Ils ont exigé un tas de documents, mais rien de particulièrement intéressant. Une photo, un passeport, un permis de séjour, une multitude de certificats différents et bien sûr, la lettre d'invitation. Pendant ce temps, la lettre ne parvenait pas. En fin de compte, je suis parti avec une simple impression et cela a très bien fonctionné. La lettre est finalement arrivée trois jours plus tard, mais le FedEx chypriote n'a pas réussi à trouver mon adresse, il a donc fallu que j'aille la chercher moi-même. J'ai également récupéré dans le même FedEx un colis qu'ils n'avaient pas pu me livrer car ils ne trouvaient pas l'adresse, et qui était là depuis juin (5 mois, Carl). Comme je n'étais pas au courant de son existence, je ne m'étais donc pas attendu à ce qu'ils l'aient. J'ai obtenu mon visa à temps, après quoi on m'a réservé un hôtel et proposé des options de vol. J'ai ajusté les options pour qu'elles soient plus pratiques. Il n'y avait plus de vols directs, donc je suis allé à Athènes puis de retour via Vienne.
Après que toutes les formalités liées au voyage aient été réglées, quelques jours se sont écoulés et j'ai finalement décollé pour Zurich. Je suis arrivé sans incidents. J'ai pris le train de l'aéroport à la ville — rapide et pratique. Après m'être un peu perdu dans la ville, j'ai trouvé l'hôtel et je me suis enregistré. Comme l'hôtel était réservé sans repas, j'ai dîné à proximité et me suis écroulé de sommeil, car j'avais un vol matinal et j'étais déjà fatigué. Le lendemain, j'ai pris mon petit-déjeuner à l'hôtel (contre des frais supplémentaires) et je suis parti pour le bureau de Google. Google a plusieurs bureaux à Zurich. Mon entretien n'avait pas lieu dans le central. Le bureau s'est en fait avéré assez ordinaire, donc je n'ai pas eu l'occasion de voir tous les avantages d'un « vrai » bureau Google. Je me suis enregistré auprès de l'administrateur et j'ai attendu. Au bout d'un moment, le recruteur est sorti et m'a expliqué le programme de la journée, puis m'a conduit dans la salle où les entretiens devaient se dérouler. Au programme, il y avait 3 entretiens, un déjeuner et encore 2 entretiens.
Entretien numéro un
Le premier entretien portait sur Android. Il n'était en fait pas du tout lié aux algorithmes. Quelle surprise ! Bon, c'était même plus familier ainsi. On m'a demandé de créer un certain composant UI. D'abord, nous avons discuté de ce qui était à faire. J'ai proposé une solution en RxJava, en décrivant ce que je ferais et pourquoi. Ils ont dit que c'était bien, mais qu'ils préféraient utiliser les outils du framework Android. Et en même temps, nous devions écrire le code au tableau. Pas juste un composant, mais toute l'Activity qui utilise ce composant. Ça, je ne m'y attendais pas. C'est une chose d'écrire un algorithme de 30 à 50 lignes au tableau, et une autre de coder du code Android, même avec des abréviations et des commentaires du style « bon, ça, je ne vais pas l'écrire, c'est évident ». C'était un véritable méli-mélo sur 3 tableaux. Donc, j'ai résolu le problème, mais ça avait l'air un peu moche.
Entretien numéro deux
Cette fois, l'entretien portait sur des algorithmes. Et il y avait deux intervieweurs. Un qui était l'intervieweur principal, et l'autre était un jeune padawan (intervieweur fantôme). Il fallait concevoir une structure de données avec des propriétés spécifiques. Comme d'habitude, nous avons discuté du problème. Je posais différentes questions, l'intervieweur répondait. Après un certain temps, on m'a demandé d'écrire plusieurs méthodes de la structure imaginée au tableau. Cette fois, j'ai réussi à peu près, bien que j'aie fait quelques petites erreurs que j'ai corrigées avec l'aide de l'intervieweur.
Entretien numéro trois
Cette fois, c'était le design système, qui s'est également révélé être sur Android. Il fallait développer une application avec une fonctionnalité spécifique. Nous avons discuté des exigences de l'application, du serveur, du protocole de communication. Ensuite, j'ai commencé à décrire quels composants ou bibliothèques j'utiliserais pour construire l'application. Puis, en mentionnant le Job Scheduler, j'ai eu un petit blocage. En fait, je n'avais jamais utilisé cela en pratique, car au moment de sa sortie, je venais de passer au support d'applications où il n'y avait pas de tâches pour son utilisation. Cela a été la même chose pour les applications suivantes. Donc, en théorie, je sais ce qu'est cet outil, quand et comment il est utilisé, mais je n'ai pas d'expérience pratique. Cela n'a pas semblé plaire à l'intervieweur. Puis, on m'a demandé d'écrire le code. Oui, lors du développement d'une application, il faut tout de suite écrire du code. Encore du code Android au tableau. Ça avait encore l'air un peu moche.
Déjeuner
Un autre homme devait arriver, mais il ne s'est pas présenté. Même Google a ses ratés. Finalement, j'ai déjeuné avec l'intervieweur précédent, son collègue, et un peu plus tard, le prochain intervieweur a rejoint. Le déjeuner était tout à fait convenable. Encore une fois, puisque ce n'est pas le bureau principal à Zurich, la cafétéria avait un aspect assez ordinaire, bien que très agréable.
Entretien numéro quatre
Enfin des algorithmes à l'état pur. J'ai résolu le premier problème assez rapidement et efficacement, bien que j'ai raté un cas limite, mais grâce à l'indice de l'intervieweur (il a donné ce cas limite), j'ai trouvé le problème et l'ai corrigé. Bien sûr, il fallait écrire du code sur un tableau. Ensuite, une tâche similaire mais plus difficile a été donnée. Pour celle-ci, j'ai trouvé quelques solutions non optimales et j'ai presque trouvé l'optimale, il me manquait 5 à 10 minutes pour finaliser ma pensée. Et je n'ai pas eu le temps d'écrire le code pour celle-ci.
Entretien numéro cinq
Encore un entretien Android. Je me demande pourquoi j'ai étudié les algorithmes toute l'année ?
Au début, il y a eu quelques questions simples. Puis l'intervieweur a écrit du code sur le tableau et a demandé de trouver les problèmes. J'ai trouvé, expliqué, corrigé. Nous en avons discuté. Et là, des questions plus inattendues ont commencé : « que fait la méthode Y dans la classe X ? », « que se passe-t-il à l'intérieur de la méthode Y ? », « que fait la classe Z ? ». Bien sûr, j'ai répondu à certaines, mais j'ai ensuite dit que je n'avais pas été confronté à cela dans mon travail récemment et que je ne me souvenais pas, évidemment, de qui faisait quoi et comment en détail. Après cela, l'intervieweur a demandé ce que je faisais actuellement. Les questions ont alors porté sur ce sujet. Là, j'ai répondu beaucoup mieux.
Après la fin du dernier entretien, on m'a pris mon badge, on m'a souhaité bonne chance et on m'a renvoyé chez moi. J'ai un peu flâné dans la ville, dîné et suis allé à l'hôtel où je me suis effondré de sommeil, car le vol était encore tôt le matin. Le lendemain, je suis arrivé sain et sauf à Chypre. J'ai écrit un retour d'expérience sur l'entretien à la demande du recruteur et j'ai rempli un formulaire dans un service spécial pour le remboursement des frais engagés. Parmi toutes les dépenses, Google ne couvre directement que les billets. L'hôtel, la nourriture et le transport sont à la charge du candidat. Ensuite, nous remplissons le formulaire, joignons les reçus et l'envoyons à une société spécialisée. Ils traitent cela et versent assez rapidement l'argent sur le compte.
Il a fallu une semaine et demie pour traiter les résultats de l'entretien. Après cela, on m'a informé que j'étais « un peu en dessous de la barre ». En d'autres termes, je n'ai pas réussi à atteindre le niveau requis. Pour être plus précis, deux entretiens se sont bien passés, deux autres un peu moins, et le System Design a été très difficile. Si au moins trois entretiens s'étaient bien déroulés, j'aurais pu me battre, mais là, il n'y avait pas de chance. Ils m'ont proposé de revenir dans un an.
Au début, j'étais bien sûr déçu, car j'avais consacré beaucoup de temps et d'énergie à ma préparation, et au moment de l'entretien, j'avais déjà l'idée de quitter Chypre. Travailler chez Google et déménager en Suisse semblaient être une excellente option.
Conclusion
Et ici, nous arrivons à la dernière partie de l'article. Oui, j'ai échoué deux fois à l'entretien chez Google. C'est triste. Il aurait certainement été intéressant de travailler là-bas. Mais on peut aussi voir les choses sous un autre angle.
- En un an et demi, j'ai appris un énorme nombre de choses liées au développement de logiciels.
- J'ai pris beaucoup de plaisir à participer à des compétitions de programmation.
- J'ai passé quelques jours à Zurich. Quand y retournerai-je ?
- J'ai obtenu une expérience intéressante d'entretien dans l'une des plus grandes entreprises IT au monde.
Ainsi, tout ce qui s'est passé pendant ces un an et demi peut simplement être considéré comme un apprentissage ou un entraînement. Et les résultats de cet entraînement ont été visibles. Mon idée de quitter Chypre a mûri (en raison de circonstances familiales), j'ai réussi plusieurs entretiens dans une autre entreprise réputée et, après huit mois, j'ai déménagé. Mais c'est une autre histoire. Néanmoins, je pense qu'il est juste de remercier Google pour ces un an et demi que j'ai passés à me perfectionner ainsi que pour ces deux jours intéressants à Zurich.
Que puis-je dire pour conclure ? Si vous travaillez dans le secteur IT, préparez-vous aux entretiens chez Google (Amazon, Microsoft, Apple, etc.). Peut-être qu'un jour vous pourrez y entrer. Même si vous ne le souhaitez pas, croyez-moi, une telle préparation ne pourra que vous être bénéfique. Au moment où vous réaliserez que vous pouvez (même si c'est uniquement grâce à de bonnes circonstances) réussir un entretien dans l'une de ces entreprises, de nombreuses portes s'ouvriront à vous par rapport au début de votre préparation. Et tout ce dont vous aurez besoin en chemin, c'est d'un objectif, de détermination et de temps. Je vous souhaite du succès 🙂
Source : habr.com
