Le titre de l’article ressemble à un échec épique, mais en réalité tout n’est pas si simple. Et en général, cette histoire s'est terminée de manière très positive, mais pas sur Google. Mais c'est un sujet pour un autre article. Dans ce même article, je parlerai de trois choses : comment s'est déroulé mon processus de préparation, comment se sont déroulés les entretiens chez Google et pourquoi, à mon avis, tout n'est pas aussi clair qu'il y paraît.
Comment tout a commencé
Par une froide soirée d'hiver chypriote, l'idée m'est soudain venue que mes connaissances en informatique classique étaient très loin d'être moyennes et qu'il fallait faire quelque chose à ce sujet. Si, en passant, quelqu'un n'a pas encore lu pourquoi la soirée est chypriote et froide, alors vous pouvez le découvrir . Après réflexion, il a été décidé de commencer par suivre un cours en ligne sur les algorithmes et les structures de données. Par l’un de mes anciens collègues, j’ai entendu parler du cours de Robert Sedgewick sur Coursera. Le cours se compose de deux parties ( и ). Si soudainement les liens changent, vous pouvez toujours rechercher le nom de l’auteur sur Google. Chaque partie dure 6 semaines. Les cours ont lieu en début de semaine, et pendant la semaine il faut encore faire des exercices. La première partie du cours couvre les structures de données de base, les types de tri de base et la complexité des algorithmes. La deuxième partie est déjà plus avancée, commençant par les graphiques et se terminant par des éléments tels que la programmation linéaire et l'intraitabilité. Après avoir réfléchi à tout ce qui précède, je suis arrivé à la conclusion que c'était exactement ce dont j'avais besoin. À propos, un lecteur curieux pourrait se demander : qu’est-ce que Google a à voir avec cela ? Et en effet, jusqu’à présent, il n’avait rien à voir avec cela. Mais j'avais besoin d'un objectif, car étudier 12 semaines le soir sans objectif est un peu difficile. Quel pourrait être le but d’acquérir de nouvelles connaissances ? Bien entendu, leur application dans la pratique. Dans la vie de tous les jours, c’est assez problématique, mais lors d’un entretien avec une grande entreprise, c’est facile. Un rapide coup d'œil sur Google a montré que Google (pardonnez la tautologie) est l'une des plus grandes entreprises d'Europe (et je regardais spécifiquement l'Europe) à mener de tels entretiens. À savoir, leur bureau est situé à Zurich, en Suisse. C'est donc décidé : étudions et partons pour un entretien chez Google.
Préparation à la première approche
Les 12 semaines se sont écoulées rapidement et j'ai complété les deux cours. Mes impressions sur les cours sont plus que positives et je peux les recommander à toute personne intéressée. J'ai aimé les cours pour les raisons suivantes :
- Le conférencier parle un anglais assez clair
- Le matériel est bien structuré
- De superbes présentations montrant l'intérieur de chaque algorithme
- Sélection compétente du matériel
- Des exercices intéressants
- Les exercices sont automatiquement vérifiés sur le site, après quoi un rapport est généré
Mon travail sur les cours se déroulait généralement ainsi. J'ai écouté des conférences en 1-2 jours. Ensuite, ils ont passé un test rapide de leurs connaissances du matériel. Le reste de la semaine, j'ai fait l'exercice en plusieurs itérations. Après le premier, j'ai obtenu mes 30 à 70 %, les suivants ont porté le résultat à 97 à 100 %. L'exercice impliquait généralement la mise en œuvre d'un algorithme, par ex. ou .
Après avoir terminé les cours, j’ai réalisé que beaucoup de connaissances s’accompagnent de beaucoup de chagrin. Si avant je savais simplement que je ne savais rien, maintenant je commençais à réaliser que c’était moi qui ne savais pas.
Comme nous n'étions qu'au mois de mai et que j'avais programmé l'entretien pour l'automne, j'ai décidé de poursuivre mes études. Après avoir examiné les exigences du poste vacant, il a été décidé d'aller dans deux directions en parallèle : continuer à étudier les algorithmes et suivre un cours de base en 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 « Algorithmes. Le manuel de conception d'algorithmes. Pas aussi monumental que celui de Knut, mais quand même. Pour le deuxième but, je suis retourné à Coursera et je me suis inscrit au cours d'Andrew Ng. .
Trois mois supplémentaires se sont écoulés et j'ai terminé le cours et le livre.
Commençons par le livre. La lecture s’est avérée assez intéressante, même si elle n’est pas facile. En principe, je recommanderais le livre, mais pas tout de suite. Dans l'ensemble, le livre fournit un aperçu plus approfondi de ce que j'ai appris pendant le cours. De plus, j'ai découvert (d'un point de vue formel) des choses telles que l'heuristique et la programmation dynamique. Naturellement, je les avais déjà utilisés auparavant, mais je ne savais pas comment ils s’appelaient. Le livre contient également un certain nombre de récits de la vie de l’auteur (War Story), qui diluent quelque peu le caractère académique de la présentation. À propos, la seconde moitié du livre peut être omise, elle contient plutôt une description des problèmes existants et des méthodes pour les résoudre. C’est utile s’il est régulièrement utilisé dans la pratique, sinon il sera immédiatement oublié.
J'ai été plus que satisfait du cours. L'auteur connaît clairement son métier et parle d'une manière intéressante. Et pas mal de choses, à savoir l'algèbre linéaire et les bases des réseaux de neurones, dont je me souvenais de l'université, donc je n'ai pas rencontré de difficultés particulières. La structure du cours est assez standard. Le cours est divisé en semaines. Chaque semaine, il y a des cours mêlés à de courts tests. Après les cours, vous recevez un devoir que vous devez faire, soumettre et il sera automatiquement vérifié. En résumé, la liste des choses enseignées dans le cours est la suivante :
- fonction de coût
- régression linéaire
- Descente graduelle
- mise à l'échelle des fonctionnalités
- équation normale
- régression logistique
— classification multiclasse (un contre tous)
- les réseaux de neurones
- rétropropagation
- régularisation
— biais/variance
— courbes d'apprentissage
— métriques d'erreur (précision, rappel, F1)
— Machines à vecteurs de support (classification à grande marge)
— K-moyennes
—Analyse des composantes principales
- Détection d'une anomalie
— filtrage collaboratif (système de recommandation)
— descentes de gradient stochastiques, mini-batch, batch
- apprentissage en ligne
- réduction de la carte
- analyse du plafond
Après avoir terminé le cours, une compréhension de tous ces sujets était présente. Au bout de 2 ans, presque tout était naturellement oublié. Je le recommande à ceux qui ne sont pas familiers avec l'apprentissage automatique et qui souhaitent bien comprendre les choses de base pour avancer.
Première exécution
Nous étions déjà en septembre et il était temps de penser à une interview. Comme postuler via le site est assez désastreux, j'ai commencé à chercher des amis qui travaillent chez Google. Le choix s'est porté sur , puisqu'il était le seul que je connaissais directement (même si ce n'était pas personnellement). Il a accepté de transmettre mon CV et j'ai rapidement reçu une lettre du recruteur me proposant de réserver une place sur son calendrier pour la première conversation. Quelques jours plus tard, l'appel a eu lieu. Nous avons essayé de communiquer via Hangouts, mais la qualité était épouvantable, nous sommes donc passés au téléphone. Tout d’abord, nous avons rapidement discuté du comment, du pourquoi et du pourquoi de la norme, puis nous sommes passés à l’examen technique. Il s'agissait d'une douzaine de questions dans l'esprit de « quelle est la difficulté d'insérer dans une carte de hachage », « quels arbres équilibrés connaissez-vous ». Ce n'est pas difficile si vous avez une connaissance de base de ces choses. La sélection s'est bien déroulée et, sur la base des résultats, ils ont décidé d'organiser le premier entretien dans une semaine.
L'entretien a également eu lieu via Hangouts. Ils ont d’abord parlé de moi pendant environ 5 minutes, puis sont passés au problème. Le problème venait des graphiques. J'ai rapidement compris ce qu'il fallait faire, mais j'ai choisi le mauvais algorithme. Lorsque j'ai commencé à écrire du code, je m'en suis rendu compte et je suis passé à une autre option, que j'ai complétée. L'intervieweur a posé plusieurs questions sur la complexité de l'algorithme et a demandé si cela pouvait être fait plus rapidement. D’une manière ou d’une autre, je suis devenu ennuyeux et je n’y arrivais pas. À ce stade, le temps était écoulé et nous nous sommes dit au revoir. Puis, après environ 10 minutes, je me suis rendu compte qu'au lieu de l'algorithme de Dijkstra que j'avais utilisé, dans ce problème particulier, je pouvais utiliser la recherche en largeur d'abord, et ce serait plus rapide. Après un certain temps, le recruteur a appelé et a dit que l'entretien s'était globalement bien passé et qu'un autre devrait être organisé. Nous nous sommes mis d'accord sur une autre semaine.
Cette fois, les choses ont empiré. Si la première fois l’intervieweur s’est montré sympathique et sociable, cette fois il s’est montré quelque peu sombre. Je n’ai pas pu comprendre le problème tout de suite, même si les idées que j’ai avancées pourraient, en principe, conduire à sa solution. En fin de compte, après plusieurs suggestions de l’intervieweur, la solution m’est venue. Cette fois, il s’est avéré qu’il s’agissait à nouveau d’une recherche en profondeur, uniquement à partir de plusieurs points. J'ai écrit les solutions, je les ai rencontrées à temps, mais j'ai oublié les cas extrêmes. Après un certain temps, le recruteur a appelé et m'a dit que cette fois l'intervieweur n'était pas satisfait, car à son avis j'avais besoin de trop d'indices (3 ou 4 morceaux) et je changeais constamment le code pendant l'écriture. Sur la base des résultats de deux entretiens, il a été décidé de ne pas aller plus loin, mais de reporter d'un an le prochain entretien, si je le souhaitais. C'est pourquoi nous nous sommes dit au revoir.
Et de cette histoire, j'ai tiré plusieurs conclusions :
- La théorie, c'est bien, mais il faut s'y retrouver rapidement
- La théorie sans la pratique ne servira à rien. Nous devons résoudre les problèmes et rendre le codage automatique.
- Cela dépend beaucoup de l'intervieweur. Et on ne peut rien y faire.
Préparation de la deuxième manche
Après avoir réfléchi à la situation, j'ai décidé de réessayer dans un an. Et légèrement modifié le but. Si auparavant l'objectif principal était d'étudier et qu'un entretien chez Google était comme une carotte lointaine, désormais réussir un entretien était l'objectif et étudier était le moyen.
Ainsi, un nouveau plan a été élaboré, qui comprenait les points suivants :
- Continuez à étudier la théorie en lisant des livres et des articles.
- Résolvez des problèmes algorithmiques d'un montant de 500 à 1000 XNUMX pièces.
- Continuez à apprendre la théorie en regardant des vidéos.
- Continuez à étudier la théorie à travers des cours.
- Étudiez les expériences d'autres personnes lors d'entretiens chez Google.
J'ai terminé le plan en un an. Ensuite, je décrirai ce que j'ai fait exactement pour chacun des points.
Livres et articles
Je ne me souviens même pas du nombre d'articles que j'ai lus, je les ai lus en russe et en anglais. Probablement le site le plus utile . Vous trouverez ici une description d'un grand nombre d'algorithmes intéressants avec des exemples de code.
J'ai lu 5 livres : Algorithms, 4e édition (Sedgewick, Wayne), Introduction to Algorithms 3e édition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4e édition (Gayle Laakmann), Programming Interviews Exposed 2e édition (Mongan, Suojanen , Giguère), Éléments d'entretiens de programmation (Aziz, Lee, Prakash). Ils peuvent être divisés en 2 catégories. Le premier comprend des livres de Sedgwick et Corman. C'est une théorie. Le reste est la préparation de l'entretien. Sedgwick raconte la même chose dans le livre que dans ses cours. Juste par écrit. Cela ne sert à rien de le lire attentivement si vous avez suivi le cours, mais cela vaut quand même la peine de le parcourir. Si vous n'avez pas regardé le cours, il est logique de le lire. Cormen me paraissait trop ennuyeux. Pour être honnête, j'ai eu du mal à le maîtriser. Je viens de le sortir de là , et plusieurs structures de données rarement utilisées (tas de Fibonacci, arbre de van Emde Boas, tas de base).
Cela vaut la peine de lire au moins un livre pour se préparer à un entretien. Ils sont tous construits à peu près sur le même principe. Ils décrivent le processus d'entretien dans les grandes entreprises technologiques, donnent les éléments de base de l'informatique, les problèmes liés à ces éléments de base, les solutions aux problèmes et l'analyse des solutions. Parmi les trois ci-dessus, je recommanderais probablement Cracking the Coding Interview comme principal, et les autres sont facultatifs.
Problèmes algorithmiques
C’était probablement le point de préparation le plus intéressant. Vous pouvez bien sûr vous asseoir et résoudre des problèmes bêtement. Il existe de nombreux sites différents pour cela. J'en ai principalement utilisé trois : , и . Sur CodeChef, les problèmes sont répartis par difficulté, mais pas par sujet. Sur Hackerrank à la fois par complexité et par sujet.
Mais comme je l'ai immédiatement découvert par moi-même, il existe un moyen plus intéressant. Et ce sont des concours (défis de programmation ou concours de programmation). Les trois sites les proposent. Certes, il y a un problème avec LeetCode - un fuseau horaire peu pratique. C'est pourquoi je n'ai pas participé sur ce site. Hackerrank et CodeChef proposent un assez grand nombre de compétitions différentes, d'une durée de 1 heure à 10 jours. Différents formats ont des règles différentes, mais nous pourrions en parler longtemps. La principale raison pour laquelle les compétitions sont bonnes est l’introduction d’un élément compétitif (et encore une fois tautologique) dans le processus d’apprentissage.
Au total, j'ai participé à 37 compétitions sur Hackerrank. Parmi ceux-ci, 32 étaient des évaluations, et 5 étaient soit sponsorisés (j'ai même reçu 25 $ dans l'un d'eux), soit pour le plaisir. Dans le classement, j'ai été 10 fois dans le top 4%, 11 fois dans le top 12% et 5 fois dans le top 25%. Les meilleurs résultats étaient de 27/1459 en 3 heures et de 22/9721 en semaine.
Je suis passé à CodeChef lorsque Hackerrank a commencé à organiser des compétitions moins fréquemment. Au total, j'ai réussi à participer à 5 compétitions. Le meilleur score a été de 426/5019 lors des dix jours de compétition.
Au total, lors des compétitions et comme ça, j'ai résolu un peu plus de 1000 problèmes qui s'inscrivaient dans le plan. Aujourd'hui, malheureusement, il n'y a pas de temps libre pour poursuivre des activités compétitives, tout comme il n'y a aucun objectif pour lequel le temps non libre peut être déduit. Mais c'était amusant. Je recommande à ceux qui sont intéressés par cela de trouver des personnes partageant les mêmes idées. Ensemble ou en groupe, c'est beaucoup plus intéressant. Je me suis bien amusé avec un ami, alors peut-être que ça s'est bien passé.
Voir la vidéo
Après avoir lu le livre de Skiena, je me suis intéressé à ce qu’il faisait. Comme Sedgwick, il est professeur d'université. À cet égard, des vidéos de ses cours sont disponibles en ligne. J'ai décidé de revoir le cours . Je ne peux pas dire que je l'ai beaucoup aimé. Tout d’abord, la qualité vidéo n’est pas très bonne. Deuxièmement, je n'ai pas essayé de résoudre moi-même les problèmes abordés dans le cours. L’engagement n’était donc pas très élevé.
Aussi, en résolvant des problèmes, en essayant de trouver le bon algorithme, je suis tombé sur la vidéo de Tushar Roy. Il a travaillé chez Amazon et travaille maintenant chez Apple. Comme je l'ai découvert par moi-même plus tard, il a , où il publie une analyse de divers algorithmes. Au moment de la rédaction, la chaîne contient 103 vidéos. Et je dois dire que son analyse a été très bien faite. J’ai essayé de regarder d’autres auteurs, mais cela n’a pas fonctionné. Je peux donc certainement recommander cette chaîne à regarder.
Suivre des cours
Je n'ai rien fait de spécial ici. J'ai regardé une vidéo du développeur Android Nanodegree de Google et suivi un cours de l'ITMO. . Nanodegree est plutôt bon, même si je n’en ai naturellement rien appris de nouveau. Le cours de l'ITMO est un peu biaisé au niveau théorique, mais les problématiques étaient intéressantes. Je ne recommanderais pas de commencer par cela, mais en principe, c'était du temps bien dépensé.
Apprendre des expériences des autres
Bien sûr, beaucoup de gens ont essayé de se lancer dans Google. Certains y sont entrés, d’autres non. Certains ont écrit des articles à ce sujet. Parmi les choses intéressantes que je mentionnerai probablement и . Dans le premier cas, la personne s'est préparée une liste de ce qu'elle doit apprendre pour devenir ingénieur logiciel et entrer chez Google. Il a finalement fini sur Amazon, mais ce n’est plus si important. Le deuxième manuel a été rédigé par l'ingénieur Google, Larisa Agarkova (). En plus de ce document, vous pouvez également lire .
Il est logique de lire les critiques d’entretiens sur Glassdoor. Ils sont tous plus ou moins similaires, mais vous pouvez obtenir des informations utiles.
Je ne fournirai pas de liens vers d’autres petits articles ; vous pouvez facilement les trouver sur Google.
Deuxième manche
Et maintenant, un an s'est écoulé. Cela s’est avéré très intense en termes d’études. Mais j’ai abordé le nouvel automne avec des connaissances théoriques beaucoup plus approfondies et développé des compétences pratiques. Il me restait encore quelques semaines avant la fin de l'année pour me préparer, quand soudain une lettre d'un recruteur de Google est arrivée par courrier, dans laquelle il me demandait si j'avais toujours envie de travailler chez Google et si je le ferais. Cela me dérangerait de parler avec lui. Naturellement, cela ne me dérangeait pas. Nous avons convenu de rappeler dans une semaine. Ils m'ont également demandé un curriculum vitae mis à jour, auquel j'ai ajouté une brève description de ce que j'avais fait au cours de l'année au travail et en général.
Après avoir communiqué pour la vie, nous avons décidé que dans une semaine il y aurait une interview Hangout, comme l'année dernière. Une semaine s'est écoulée, c'était l'heure de l'entretien, mais l'intervieweur ne s'est pas présenté. 10 minutes se sont écoulées, je commençais déjà à devenir nerveux, quand soudain quelqu'un a fait irruption dans la conversation. Comme il s'est avéré un peu plus tard, mon interlocuteur, pour une raison quelconque, n'a pas pu se présenter et un remplaçant a été trouvé d'urgence pour lui. La personne n’était pas du tout préparée, tant pour configurer l’ordinateur que pour mener l’entretien. Mais ensuite tout s'est bien passé. J'ai résolu le problème rapidement, décrit où les pièges étaient possibles et comment ils pouvaient être contournés. Nous avons discuté de plusieurs versions différentes du problème et de la complexité de l'algorithme. Ensuite, nous avons discuté pendant encore 5 minutes, l'ingénieur nous a fait part de ses impressions sur son travail à Munich (ils n'ont apparemment pas trouvé de remplaçant urgent à Zurich), puis nous nous sommes séparés.
Le même jour, un recruteur m'a contacté et m'a dit que l'entretien s'était bien passé et qu'il était prêt à m'inviter à un entretien au bureau. Le lendemain, nous avons appelé via Hangouts et discuté des détails. Comme je devais demander un visa, nous avons décidé de fixer un entretien dans un mois.
Pendant que je préparais les documents, j'évoquais simultanément le prochain entretien avec le recruteur. Un entretien standard chez Google comprend 4 entretiens algorithmiques et un entretien de conception de système. Mais comme je postulais en tant que développeur Android, on m'a dit qu'une partie de l'entretien serait spécifique à Android. Je ne pouvais pas expliquer au recruteur exactement quels seraient les détails et quels seraient les détails. D'après ce que je comprends, cela a été introduit relativement récemment et lui-même n'en était pas très conscient. J'ai également été inscrit à deux sessions de formation : comment réussir un entretien algorithmique et comment réussir un entretien de conception de système. Les séances étaient d'une utilité moyenne. Là aussi, personne ne pouvait me dire ce qu'ils demandaient aux développeurs Android. Ma préparation pour ce mois-ci se résumait donc à ce qui suit :
- Acheter un tableau de marqueurs et y écrire 2 à 3 douzaines d'algorithmes les plus populaires de mémoire. 3 à 5 pièces chaque jour. Au total, chacun a été écrit plusieurs fois.
- Rafraîchissez votre mémoire de diverses informations sur Android que vous n'utilisez pas tous les jours
- Regarder quelques vidéos sur Big Scale et des trucs comme ça
Comme je l'ai déjà dit, en même temps je préparais les documents pour le voyage. Pour commencer, ils m'ont demandé des informations pour rédiger une lettre d'invitation. Ensuite, j'ai longtemps essayé de savoir qui à Chypre délivre les visas pour la Suisse, car l'ambassade de Suisse ne s'en occupe pas. Il s’est avéré que c’est le consulat autrichien qui le fait. J'ai appelé et pris rendez-vous. Ils ont demandé un tas de documents, mais rien de particulièrement intéressant. Photo, passeport, permis de séjour, de nombreux certificats différents et, bien sûr, une lettre d'invitation. Entre-temps, la lettre n'est pas arrivée. Au final, j'ai opté pour une impression régulière et cela a plutôt bien fonctionné. La lettre elle-même est arrivée 3 jours plus tard, et FedEx de Chypre n'a pas pu trouver mon adresse et j'ai dû aller la chercher moi-même. Au même moment, j'ai reçu un colis du même FedEx, qu'ils n'ont pas non plus pu me livrer, car ils n'ont pas trouvé l'adresse, et qui traînait là depuis juin (5 mois, Karl). Comme je ne le savais pas, naturellement, je ne pensais pas qu’ils l’avaient. J'ai reçu mon visa à temps, après quoi ils m'ont réservé un hôtel et m'ont proposé des options de vol. J'ai ajusté les options pour le rendre plus pratique. Il n'y avait plus de vols directs, j'ai donc fini par prendre l'avion via Athènes et revenir via Vienne.
Une fois toutes les formalités du voyage réglées, quelques jours se sont écoulés et je me suis envolé pour Zurich. Je suis arrivé sans incident. De l'aéroport à la ville, j'ai pris le train - rapidement et facilement. Après avoir erré un peu dans la ville, j'ai trouvé un hôtel et je me suis enregistré. Comme l'hôtel était réservé sans nourriture, j'ai dîné à côté et je me suis couché, car le vol était le matin et je voulais déjà dormir. Le lendemain, j'ai pris le petit-déjeuner à l'hôtel (pour de l'argent supplémentaire) et je suis allé au bureau de Google. Google possède plusieurs bureaux à Zurich. Mon entretien n'était pas celui du centre. Et en général, le bureau avait l’air assez ordinaire, donc je n’ai pas eu l’occasion de regarder tous les avantages d’un bureau Google « normal ». Je me suis inscrit auprès de l'administrateur et je me suis assis pour attendre. Après un certain temps, le recruteur est sorti et m'a expliqué le programme de la journée, après quoi il m'a emmené dans la salle où devaient se dérouler les entretiens. En fait, le plan comprenait 3 entretiens, un déjeuner et 2 autres entretiens.
Entretien numéro un
La première interview était uniquement sur Android. Et cela n’avait rien à voir avec les algorithmes. Surprise cependant. Bon, d'accord, c'est encore plus courant de cette façon. On nous a demandé de créer un certain composant d'interface utilisateur. Nous avons d’abord discuté de quoi et comment. Il a proposé de créer une solution en utilisant RxJava, a décrit exactement ce qu'il ferait et pourquoi. Ils ont dit que c'était certainement une bonne chose, mais faisons-le en utilisant le framework Android. Et en même temps, nous écrirons le code au tableau. Et pas seulement un composant, mais toute l'activité qui utilise ce composant. C’est pour cela que je n’étais pas prêt. C'est une chose d'écrire un algorithme de 30 à 50 lignes sur le tableau, et une autre chose d'écrire des nouilles de code Android, même avec des abréviations et des commentaires du genre « eh bien, je n'écrirai pas ça, car c'est déjà évident ». Le résultat était une sorte de vinaigrette pour 3 planches. Ceux. J'ai résolu le problème, mais ça avait l'air stupide.
Entretien numéro deux
Cette fois, l’interview portait sur les algorithmes. Et il y avait deux intervieweurs. L’un est le véritable intervieweur et le second est un jeune padawan (intervieweur fantôme). Il fallait proposer une structure de données avec certaines propriétés. Tout d’abord, nous avons discuté du problème comme d’habitude. J'ai posé différentes questions, l'intervieweur a répondu. Après un certain temps, il leur a été demandé d'écrire au tableau plusieurs méthodes de la structure inventée. Cette fois, j’ai plus ou moins réussi, mais avec quelques erreurs mineures, que j’ai corrigées à la demande de l’intervieweur.
Entretien numéro trois
Cette fois-ci, System Design, qui s'est soudainement révélé être également Android. Il était nécessaire de développer une application dotée de certaines fonctionnalités. Nous avons discuté des exigences relatives à l'application, au serveur et au protocole de communication. Ensuite, j'ai commencé à décrire les composants ou les bibliothèques que j'utiliserais lors de la création de l'application. Et puis, en mentionnant Job Scheduler, il y a eu une certaine confusion. Le fait est que je ne l'ai jamais utilisé dans la pratique, puisqu'au moment de sa sortie, je venais de passer au support d'applications où il n'y avait aucune tâche pour son utilisation. La même chose s’est produite lors du développement des suivants. Autrement dit, en théorie, je sais ce qu'est cette chose, quand et comment elle est utilisée, mais je n'ai aucune expérience dans son utilisation. Et l’intervieweur n’a pas semblé beaucoup apprécier. Ensuite, ils m'ont demandé d'écrire du code. Oui, lors du développement d’une application, vous devez immédiatement écrire du code. Encore une fois le code Android au tableau. Cela s'est avéré encore une fois effrayant.
déjeuner
Une autre personne était censée venir, mais elle ne l’a pas fait. Et Google fait des erreurs. En conséquence, je suis allé déjeuner avec l'intervieweuse précédente, sa collègue, et un peu plus tard, l'intervieweuse suivante l'a rejoint. Le déjeuner était assez correct. Encore une fois, comme il ne s'agit pas du bureau principal à Zurich, la salle à manger avait l'air tout à fait ordinaire, bien que très agréable.
Entretien numéro quatre
Enfin, les algorithmes à l’état pur. J'ai résolu le premier problème assez rapidement et immédiatement efficacement, même si j'ai raté un cas extrême, mais à l'invite de l'intervieweur (il a donné ce cas très extrême), j'ai trouvé le problème et je l'ai corrigé. Bien sûr, j'ai dû écrire le code au tableau. Ensuite, une tâche similaire a été confiée, mais plus difficile. Pour cela, j'ai trouvé quelques solutions non optimales et j'ai presque trouvé la solution optimale, 5 à 10 minutes n'étaient pas suffisantes pour terminer la réflexion. Eh bien, je n’ai pas eu le temps d’écrire le code.
Entretien numéro cinq
Et encore une interview sur Android. Je me demande pourquoi j'ai étudié les algorithmes toute l'année ?
Au début, il y avait quelques questions simples. Ensuite, l'intervieweur a écrit du code au tableau et a demandé d'y trouver des problèmes. Je l'ai trouvé, expliqué, corrigé. Discuté. Et puis des questions inattendues ont commencé dans l'esprit de « que fait la méthode Y dans la classe X », « qu'est-ce qu'il y a à l'intérieur de la méthode Y », « que fait la classe Z ». Bien sûr, j’ai répondu à quelque chose, mais j’ai ensuite dit que je n’avais pas rencontré cela récemment dans mon travail et que, naturellement, je ne me souvenais pas en détail de qui faisait quoi et comment. Après cela, l'intervieweur m'a demandé ce que je faisais maintenant. Et les questions portaient sur ce sujet. J'ai déjà répondu bien mieux ici.
Après la fin du dernier entretien, ils ont pris mon laissez-passer, m'ont souhaité bonne chance et m'ont renvoyé. J'ai marché un peu dans la ville, j'ai dîné et je suis allé à l'hôtel, où je me suis couché, car le vol était encore tôt le matin. Le lendemain, je suis arrivé sain et sauf à Chypre. À la demande du recruteur, j'ai rédigé un retour sur l'entretien et rempli un formulaire auprès d'un service spécial pour restituer l'argent dépensé. De toutes les dépenses, Google ne paie directement que les billets. L'hôtel, la nourriture et les déplacements sont à la charge du candidat. Ensuite, nous remplissons le formulaire, joignons les reçus et l'envoyons à un bureau spécial. Ils traitent cela et transfèrent l’argent sur le compte assez rapidement.
Il a fallu une semaine et demie pour traiter les résultats de l'entretien. Après quoi, on m’a informé que j’étais « un peu en dessous de la barre ». Autrement dit, je suis tombé un peu à court. Plus précisément, 2 entretiens se sont bien déroulés, 2 un peu moins bien et System Design pas très bien. Maintenant, si au moins 3 s’étaient bien passés, alors nous aurions pu concourir, sinon il n’y a aucune chance. Ils ont proposé de revenir dans un an.
Au début, bien sûr, j'étais bouleversé, car beaucoup d'efforts avaient été consacrés à la préparation, et au moment de l'entretien, je pensais déjà à quitter Chypre. Rejoindre Google et déménager en Suisse semblait être une excellente option.
Conclusion
Et nous arrivons ici à la dernière partie de l’article. Oui, j'ai échoué deux fois à l'entretien Google. C'est triste. Ce serait probablement intéressant d'y travailler. Mais vous pouvez voir la question de l’autre côté.
- En un an et demi, j'ai appris énormément de choses liées au développement logiciel.
- J'ai eu beaucoup de plaisir à participer à des concours de programmation.
- Je suis allé à Zurich pendant quelques jours. Quand vais-je y retourner ?
- J'ai eu une expérience d'entretien intéressante dans l'une des plus grandes sociétés informatiques au monde.
Ainsi, tout ce qui s'est passé au cours de ces un an et demi peut simplement être considéré comme une formation, ou une formation. Et les résultats de cette formation se sont fait sentir. Mon idée de quitter Chypre a mûri (en raison de certaines circonstances familiales), j'ai passé avec succès plusieurs entretiens avec une autre entreprise bien connue et j'ai déménagé au bout de 8 mois. Mais c'est une histoire complètement différente. Cependant, je pense que je devrais quand même remercier Google à la fois pour l'année et demie sur laquelle j'ai travaillé moi-même et pour 2 jours intéressants à Zurich.
Que puis-je dire finalement ? Si vous travaillez dans l'informatique, préparez-vous aux entretiens chez Google (Amazon, Microsoft, Apple, etc.). Peut-être qu'un jour vous irez là-bas pour y arriver. Même si vous ne le souhaitez pas, croyez-moi, une telle préparation ne vous aggravera pas. Dès que vous réaliserez que vous pouvez (même si ce n'est qu'avec de la chance) obtenir un entretien avec l'une de ces entreprises, beaucoup plus de voies s'ouvriront à vous qu'avant de commencer votre préparation. Et tout ce dont vous avez besoin en cours de route, c'est de détermination, de persévérance et de temps. Je te souhaite du succès :)
Source: habr.com