
Tytuł artykułu brzmi jak epic fail, ale tak naprawdę sprawa nie jest tak jednoznaczna. Ogólnie rzecz biorąc, ta historia zakończyła się dość pozytywnie, chociaż nie w Google. Ale to już temat na inny artykuł. W tym artykule opowiem o trzech rzeczach: jak przebiegał mój proces przygotowań, jak wyglądały rozmowy kwalifikacyjne w Google oraz dlaczego moim zdaniem sprawa nie jest tak jednoznaczna, jak może się wydawać.
Jak to się wszystko zaczęło
Pewnego chłodnego zimowego wieczoru na Cyprze nagle przyszła mi do głowy myśl, że moja wiedza z dziedziny klasycznej informatyki jest znacznie poniżej przeciętnej i że trzeba coś z tym zrobić. Jeśli ktoś jeszcze nie czytał, dlaczego wieczór był cypryjski i zimny, to można się tego dowiedzieć. . Po pewnych przemyśleniach zdecydowałem, że najpierw muszę przejść kurs online na temat algorytmów i struktur danych. Od jednego z byłych kolegów słyszałem o kursie Roberta Sedgewicka na Coursera. Kurs składa się z dwóch części ( i ). Jeśli linki się zmienią, można zawsze wyszukać je po nazwisku autora. Każda z części trwa 6 tygodni. Na początku tygodnia udostępniane są wykłady, a w ciągu tygodnia należy także wykonać ćwiczenia. Pierwsza część kursu obejmuje podstawowe struktury danych, główne rodzaje sortowania i złożoność algorytmów. Druga część jest już bardziej zaawansowana, zaczyna się od grafów i kończy na takich rzeczach jak programowanie liniowe i trudności. Po przemyśleniu wszystkiego, doszedłem do wniosku, że dokładnie tego potrzebuję. Tutaj z ciekawością zapytać może dociekliwy czytelnik, co ma wspólnego z tym Google. I rzeczywiście, do tego momentu nie miał on tu zupełnie nic wspólnego. Ale potrzebowałem celu, ponieważ uczenie się przez 12 tygodni wieczorami bez celu jest dość trudne. A jaki może być cel zdobywania nowej wiedzy? Oczywiście, jej zastosowanie w praktyce. W codziennym życiu jest to dość problematyczne, ale na rozmowie kwalifikacyjnej w dużej firmie jest to jak najbardziej możliwe. Szybkie wyszukiwanie pokazało, że Google (przepraszam za tautologię) jest jedną z największych firm w Europie (a ja rozważałem właśnie Europę), która przeprowadza takie rozmowy kwalifikacyjne. A dokładniej, ich biuro znajduje się w Zurychu, w Szwajcarii. Tak więc postanowione — uczymy się i idziemy na rozmowę kwalifikacyjną do Google.
Przygotowanie do pierwszego podejścia
12 tygodni minęło niezauważalnie, a ja ukończyłem oba kursy. Moje wrażenia z kursów są więcej niż pozytywne i mogę je polecić wszystkim zainteresowanym. Kursy przypadły mi do gustu z następujących powodów:
- Wykładowca mówi dość wyraźnym angielskim
- Materiał jest dobrze zorganizowany
- Wspaniałe prezentacje, pokazujące wnętrza każdego algorytmu
- Odpowiedni dobór materiału
- Interesujące ćwiczenia
- Ćwiczenia są automatycznie sprawdzane na stronie, po czym generowany jest raport
Moja praca nad kursami zazwyczaj przebiegała w następujący sposób. W ciągu 1-2 dni słuchałem wykładów. Następnie przystępowałem do szybkiego testu wiedzy. Resztę tygodnia spędzałem na ćwiczeniu w kilku iteracjach. Po pierwszym osiągałem 30-70%, kolejne podnosiły wynik do 97-100%. Ćwiczenie zazwyczaj polegało na zaimplementowaniu jakiegoś algorytmu, na przykład lub .
Po ukończeniu kursów zdałem sobie sprawę, że wiele wiedzy to wiele smutków. Jeśli wcześniej po prostu wiedziałem, że nic nie wiem, to teraz zacząłem zdawać sobie sprawę, co dokładnie wiem.
Ponieważ był jeszcze maj, a rozmowę kwalifikacyjną zaplanowałem na jesień, postanowiłem kontynuować swoje eduakację. Po zapoznaniu się z wymaganiami oferty, podjąłem decyzję, aby jednocześnie pójść w dwóch kierunkach: kontynuować naukę algorytmów i przejść podstawowy kurs z uczenia maszynowego. W przypadku pierwszego celu zdecydowałem się przełączyć z kursów na książkę i wybrałem monumentalne dzieło Stevena Skieny „Algorytmy. Przewodnik po projektowaniu”. Nie tak monumentalne jak u Knutha, ale mimo to. Dla drugiego celu znów poszedłem na Courserę i zapisałem się na kurs prowadzony przez Andrew Nga .
Minęło jeszcze 3 miesiące i ukończyłem kurs oraz książkę.
Zacznijmy od książki. Czytanie okazało się dość interesujące, choć niełatwe. W zasadzie, poleciłbym tę książkę, ale nie od razu. Generalnie rzecz biorąc, książka daje głębszą analizę tego, czego nauczyłem się na kursach. Dodatkowo odkryłem dla siebie (z formalnego punktu widzenia) takie pojęcia jak heurystyki i programowanie dynamiczne. Oczywiście wcześniej miałem do czynienia z nimi, ale nie wiedziałem, jak się nazywają. W książce znajduje się również pewna ilość anegdot z życia autora (War Story), które nieco przełamują akademicki charakter wykładu. Drugą połowę książki można zresztą pominąć, tam raczej opisane są istniejące problemy i metody ich rozwiązania. Przydatne, jeśli regularnie stosowane w praktyce, w przeciwnym razie szybko zostanie zapomniane.
Kurs bardzo mnie zadowolił. Autor wyraźnie zna się na rzeczy i opowiada w ciekawy sposób. Dodatkowo spora część, a mianowicie algebra liniowa i podstawy sieci neuronowych, pamiętałem jeszcze z uniwersytetu, więc nie napotkałem na większe trudności. Struktura kursu jest dość standardowa. Kurs podzielony jest na tygodnie. Każdego tygodnia najpierw odbywają się wykłady przeplatane krótkimi testami. Po wykładach przydzielane jest zadanie, które należy wykonać, wysłać, a ono zostanie automatycznie sprawdzone. W skrócie, lista tematów omawianych na kursie jest następująca:
— funkcja kosztu
— regresja liniowa
— spadek gradientu
— skalowanie cech
— równanie normalne
— regresja logistyczna
— klasyfikacja wieloklasowa (jeden przeciwko wszystkim)
— sieci neuronowe
— wsteczna propagacja
— regularyzacja
— błąd/odchylenie
— krzywe uczenia się
— metryki błędu (precyzja, recall, F1)
— maszyny wektorów nośnych (klasyfikacja z dużym marginesem)
— K-średnie
— analiza głównych składowych
— wykrywanie anomalii
— filtrowanie kolaboratywne (system rekomendacji)
— stochastyczne, mini-partia, batch spadki gradientu
— uczenie online
— map reduce
— analiza sufitowa
Po ukończeniu kursu zrozumienie tych wszystkich tematów było obecne. Po 2 latach prawie wszystko naturalnie zapomniane. Polecam go tym, którzy nie znają się na uczeniu maszynowym i chcą uzyskać solidną podstawę do dalszego rozwoju.
Pierwsze podejście
Był już wrzesień i nastał czas, aby pomyśleć o rozmowie kwalifikacyjnej. Ponieważ aplikowanie przez stronę to dość kiepski pomysł, zająłem się poszukiwaniem znajomych pracujących w Google. Wybór padł na , ponieważ był jedyną osobą, którą znałem osobiście (choć nie osobiście). Zgodził się przekazać moje CV, a wkrótce później otrzymałem od rekrutera wiadomość, proponującą zarezerwowanie slotu w jego kalendarzu na pierwszą rozmowę. Po kilku dniach odbyła się rozmowa. Próbowałem komunikować się przez Hangouts, ale jakość była okropna, więc przeszliśmy na telefon. Najpierw szybko omówiliśmy standardowe pytania jak, dlaczego i po co, a potem przeszliśmy do technicznego skanowania. Składało się ono z dziesięciu pytań w stylu „jakie trudności występują przy wstawianiu do mapy haszującej”, „jakie znasz zrównoważone drzewa”. Nie jest to trudne, jeśli ma się podstawową wiedzę na ten temat. Skanowanie poszło dobrze i w wyniku tego postanowiono zorganizować pierwszą rozmowę kwalifikacyjną za tydzień.
Rozmowa kwalifikacyjna również odbyła się przez Hangouts. Najpierw przez około 5 minut rozmawialiśmy o mnie, a potem przeszliśmy do zadania. Zadanie dotyczyło grafów. Szybko zrozumiałem, co trzeba zrobić, ale wybrałem niewłaściwy algorytm. Kiedy zacząłem pisać kod, uświadomiłem sobie to i przeszedłem na inny wariant, który dokończyłem. Rekruter zadał kilka pytań dotyczących złożoności algorytmu, zapytał, czy można to zrobić szybciej. Jakoś się zaciąłem i nie potrafiłem. Na tym czas się skończył i pożegnaliśmy się. Po około 10 minutach dotarło do mnie, że zamiast algorytmu Dijkstry, którego użyłem, konkretnie w tym zadaniu można byłoby użyć przeszukiwania wszerz, co byłoby szybsze. Po chwili zadzwonił rekruter i powiedział, że ogólnie rozmowa poszła dobrze i trzeba by zorganizować jeszcze jedną. Dogadaliśmy się na kolejne spotkanie za tydzień.
Tym razem sprawy poszły gorzej. Jeśli za pierwszym razem interviewer był przyjazny i rozmowny, to tym razem był jakiś ponury. Nie udało mi się od razu zgadnąć zadania, chociaż pomysły, które przedstawiałem, mogły w zasadzie prowadzić do rozwiązania. Ostatecznie, po kilku wskazówkach od interviewera, dotarłem do rozwiązania. Tym razem znowu okazało się, że to wyszukiwanie wszerz, tylko z kilku punktów. Rozwiązanie napisałem w czasie, ale zapomniałem o przypadkach brzegowych. Po jakimś czasie zadzwonił rekruter i poinformował, że tym razem interviewer był niezadowolony, ponieważ jego zdaniem potrzebowałem zbyt wielu wskazówek (3 lub 4) i ciągle zmieniałem kod podczas pisania. Po wynikach dwóch rozmów kwalifikacyjnych podjęto decyzję, aby dalej nie iść, a odłożyć następne interview na rok, jeśli będę miał na to ochotę. Na tym zakończyliśmy rozmowę.
Z tej historii wyciągnąłem kilka wniosków:
- Teoria to dobrze, ale trzeba szybko się w niej orientować.
- Teoria bez praktyki nie pomoże. Należy rozwiązywać zadania i doprowadzić pisanie kodu do automatyzmu.
- Wiele zależy od interviewera. I na to nic nie można poradzić.
Przygotowanie do drugiej próby
Po przemyśleniu sytuacji podjąłem decyzję, aby spróbować jeszcze raz za rok. Lekko zmieniłem cel. Jeśli wcześniej głównym celem była nauka, a interview w Google dalekim marzeniem, to teraz przejście przez interview stało się celem, a nauka środkiem.
Został opracowany nowy plan, w który wchodziły następujące punkty:
- Kontynuować naukę teorii poprzez czytanie książek i artykułów.
- Rozwiązać algorytmiczne zadania w ilości 500-1000 sztuk.
- Kontynuować naukę teorii poprzez oglądanie filmów.
- Kontynuować naukę teorii poprzez kursy.
- Poznać doświadczenia innych ludzi w zakresie przechodzenia rozmów kwalifikacyjnych w Google.
Plan został zrealizowany przeze mnie w ciągu roku. Następnie opiszę, co dokładnie robiłem w każdym z punktów.
Książki i artykuły
Ilość przeczytanych artykułów już nawet nie pamiętam, czytałem je zarówno po rosyjsku, jak i po angielsku. Najbardziej przydatną stroną okazała się prawdopodobnie . Zebrano tu opisy wielu ciekawych algorytmów z przykładami kodu.
Przeczytałem 5 książek: 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). Można je podzielić na 2 kategorie. W pierwszej znajdują się książki Sedgewicka i Cormena. To teoria. Pozostałe to przygotowanie do rozmowy kwalifikacyjnej. Sedgewick w książce opisuje to samo, co w swoich kursach. Po prostu w wersji pisemnej. Nie ma szczególnego sensu dokładnie czytać, jeśli przeszło się kurs, ale warto rzucić okiem. Jeśli kurs nie był oglądany, to ma sens przeczytać. Cormen wydał mi się zbyt nudny. Szczerze mówiąc, ledwo go przeszedłem. Wyniosłem stamtąd tylko , oraz kilka rzadko używanych struktur danych (Fibonacci heap, van Emde Boas tree, radix heap).
Książkę do przygotowania do rozmowy kwalifikacyjnej warto przeczytać przynajmniej jedną. Wszystkie są zbudowane według podobnej zasady. Opisują proces rozmowy kwalifikacyjnej w dużych firmach technologicznych, podają podstawowe rzeczy z informatyki, zagadki na te podstawowe rzeczy, rozwiązania zagadek i rozbiór rozwiązań. Z tych trzech chyba polecałbym Cracking the Coding Interview jako główną, a pozostałe według uznania.
Zadania algorytmiczne
To chyba był najciekawszy punkt przygotowania. Można, oczywiście, usiąść i bezmyślnie rozwiązywać zadania. Jest wiele różnych stron do tego. Ja głównie korzystałem z trzech: , i . Na CodeChef zadania są podzielone według trudności, ale nie według tematów. Na Hackerrank według trudności i tematów.
Jednak jak od razu się dowiedziałem, jest ciekawszy sposób. A są to zawody (programming challenges lub programming contests). Wszystkie trzy strony je oferują. Niestety z LeetCode jest problem — niewygodna strefa czasowa. Dlatego nie brałem udziału w tym serwisie. Hackerrank i CodeChef oferują wystarczającą ilość różnych zawodów, trwających od 1 godziny do 10 dni. Różne formaty mają różne zasady, ale można by o tym długo opowiadać. Główna istota, dlaczego zawody są dobre, to wprowadzenie rywalizacyjnego (i znowu tautologia) elementu do procesu nauki.
Łącznie wziąłem udział w 37 zawodach na Hackerrank. Z tego 32 były w rankingu, a 5 sponsorowanymi (nawet otrzymałem 25$ w jednym z nich) lub dla zabawy. W zawodach rankingowych 10 razy znalazłem się w top 4%, 11 razy w top 12% i 5 razy w top 25%. Moje najlepsze wyniki to 27/1459 w 3-godzinnym i 22/9721 w tygodniowym.
Przeszedłem na CodeChef, gdy na Hackerrank zawody zaczęły odbywać się rzadziej. Łącznie wziąłem udział w 5 zawodach. Najlepszym wynikiem było 426/5019 w dziesięciodniowych zawodach.
Ogólnie, w zawodach i dla zabawy rozwiązałem nieco ponad 1000 zadań, co wpisywało się w plan. Teraz niestety nie mam wolnego czasu na kontynuowanie działalności konkursowej, ani celu, pod który mógłbym przypisać czas, który nie jest wolny. Ale to było zabawne. Polecam tym, którzy się tym interesują, znaleźć towarzyszy myśli. We dwoje lub w grupie jest znacznie ciekawiej. Zajmowałem się tym z przyjacielem, dlatego może tak dobrze mi szło.
Oglądanie wideo
Po przeczytaniu książki Skiena zainteresowałem się tym, czym się zajmuje. Podobnie jak Sedgwick, jest profesorem na uniwersytecie. W związku z tym w sieci można znaleźć nagrania jego wykładów. Postanowiłem obejrzeć kurs . Nie powiem, że bardzo mi się spodobało. Po pierwsze jakość wideo nie była najlepsza. Po drugie nie próbowałem samodzielnie rozwiązywać zadań omawianych w kursie. Tak więc zaangażowanie było niewielkie.
Również podczas rozwiązywania zadań, próbując znaleźć odpowiedni algorytm, natknąłem się na wideo Tushara Roya. Pracował w Amazonie, a teraz pracuje w Apple. Jak później ustaliłem, ma on , na którym umieszcza analizy różnych algorytmów. W momencie pisania artykułu kanał zawiera 103 filmy. I trzeba powiedzieć, że analizy w jego wykonaniu są bardzo przyzwoite. Próbowałem oglądać innych autorów, ale jakoś mi nie pasowało. Tak więc ten kanał zdecydowanie mogę polecić do oglądania.
Uczestnictwo w kursach
Tutaj nie zajmowałem się niczym szczególnym. Obejrzałem filmy z Android Developer Nanodegree od Google i przeszedłem kurs od ITMO . Nanodegree jest całkiem w porządku, chociaż oczywiście nic nowego stamtąd nie dowiedziałem się. Kurs od ITMO był nieco chaotyczny w teorii, ale zadania były interesujące. Nie polecałbym zaczynać od niego, ale ogólnie czas spędzony na nim nie był stracony.
Poznać doświadczenia innych ludzi
Oczywiście wiele osób próbowało dostać się do Google. Niektórzy się dostali, inni nie. Niektórzy pisali o tym artykuły. Z ciekawych rzeczy może zaznaczę i . W pierwszym przypadku, osoba przygotowała dla siebie listę tego, co musi się nauczyć, aby zostać inżynierem oprogramowania i dostać się do Google. Ostatecznie trafił do Amazona, ale to już nie jest takie ważne. Drugi poradnik został napisany przez inżyniera Google, Larisę Agarową (). Oprócz tego dokumentu, można również przeczytać .
Warto poczytać opinie o rozmowach kwalifikacyjnych na Glassdoor. Wszystkie są mniej więcej podobne, ale można wyciągnąć jakąś użyteczną informację.
Linków do innych drobnych artykułów nie będę podawał, sami z łatwością znajdziecie je w Google.
Drugie podejście
I tak minął rok. Był to bardzo intensywny czas pod względem nauki. Jednak do nowej jesieni podchodziłem z dużo głębszą wiedzą teoretyczną i wypracowanymi umiejętnościami praktycznymi. Do końca wyznaczonego mi roku na przygotowania pozostało jeszcze kilka tygodni, kiedy nagle na moją skrzynkę mailową przyszła wiadomość od rekrutera z Google, w której pytał, czy nadal mam ochotę pracować w Google i czy nie przeszkadzałoby mi, gdybyśmy porozmawiali. Oczywiście nie miałem nic przeciwko. Umówiliśmy się na rozmowę telefoniczną za tydzień. Poproszono mnie również o zaktualizowane CV, do którego dołączyłem krótkie podsumowanie tego, co zrobiłem przez rok w pracy i w ogóle.
Po rozmowie o życiu ustalono, że za tydzień odbędzie się wywiad na Hangouts, wszystko jak w zeszłym roku. Tydzień minął, nadszedł czas na rozmowę, ale przekładający się nie pojawił. Minęło 10 minut, już zaczynałem się denerwować, gdy nagle ktoś wdarł się do czatu. Jak się później okazało, mój rozmówca z jakiegoś powodu nie mógł się pojawić i pilnie znaleziono mu zastępstwo. Osoba ta była niezbyt przygotowana zarówno pod względem konfiguracji komputera, jak i prowadzenia wywiadu. Ale potem wszystko poszło dobrze. Rozwiązałem zadanie szybko, opisałem, gdzie mogą być pułapki, jak je można ominąć. Omówiliśmy kilka różnych wariantów zadania, złożoność algorytmu. Potem jeszcze przez 5 minut porozmawialiśmy, inżynier opowiedział o swoich wrażeniach z pracy w Monachium (w Zurychu najwyraźniej nie znaleźli pilnego zastępstwa), na tym się rozstaliśmy.
Tego samego dnia skontaktował się ze mną rekruter i poinformował, że rozmowa kwalifikacyjna poszła świetnie i są gotowi zaprosić mnie na rozmowę w biurze. Następnego dnia połączyliśmy się przez Hangouts i omówiliśmy szczegóły. Ponieważ musiałem załatwić wizę, postanowiliśmy umówić się na rozmowę za miesiąc.
Podczas przygotowywania dokumentów równocześnie omawiałem z rekruterem nadchodzącą rozmowę kwalifikacyjną. Standardowa rozmowa w Google składa się z 4 algorytmicznych i jednej dotyczącej System Design. Jednakże, ponieważ aplikowałem jako programista Android, powiedziano mi, że część rozmowy będzie miała specyfikę Androida. Jakie dokładnie pytania będą zadawane i w czym będzie ta specyfika, nie udało mi się od rekrutera uzyskać. Zrozumiałem, że to wprowadzono stosunkowo niedawno i sam nie był zbyt zorientowany. Zaplanowano mi także dwie sesje treningowe: jak przeprowadzać rozmowę algorytmiczną i jak przeprowadzać rozmowę System Design. Sesje były średnio przydatne. Nikt nie mógł mi także powiedzieć, co pytają programistów Android. Dlatego moja przygotowania w tym miesiącu sprowadziły się do:
- Zakupu tablicy markerowej i zapisania na niej z pamięci 2-3 dziesiątek najpopularniejszych algorytmów. Po 3-5 dziennie. Z kolei każdy z nich był zapisany kilka razy.
- Odświeżenia w pamięci różnych informacji dotyczących Androida, których nie używam na co dzień.
- Obejrzenia kilku filmów o dużych skalach i tym podobnych.
Jak już mówiłem, równocześnie przygotowywałem dokumenty na podróż. Na początku poprosili mnie o dane, aby sporządzić zaproszenie. Potem długo próbowałem ustalić, kto na Cyprze zajmuje się wizami do Szwajcarii, ponieważ szwajcarska ambasada tym się nie zajmuje. Okazało się, że to konsulat Austrii. Zadzwoniłem i umówiłem się na wizytę. Tam zażądano wielu dokumentów, ale nic szczególnego. Zdjęcia, paszport, zezwolenie na pobyt, mnóstwo różnych zaświadczeń i oczywiście zaproszenie. Tymczasem zaproszenie wciąż nie nadchodziło. W końcu pojechałem z zwykłym wydrukiem i to wystarczyło. Same zaproszenie przyszło jeszcze po około 3 dniach, przy czym cypryjski FedEx nie potrafił znaleźć mojego adresu i musiałem po nie jechać osobiście. Przy okazji odebrałem w tym samym FedExie paczkę, której również nie mogli mi dostarczyć, bo nie znaleźli adresu, a która tam leżała od czerwca (5 miesięcy, Karl). Ponieważ nie wiedziałem o niej, co naturalnie i nie przewidywałem, że ją mają. Wizę otrzymałem na czas, po czym zarezerwowano mi hotel i zaproponowano opcje lotów. Opcje dostosowałem, aby było wygodniej. Bezpośrednich lotów już nie było, ostatecznie leciałem tam przez Ateny, a wracałem przez Wiedeń.
Po załatwieniu wszystkich formalności związanych z podróżą minęło jeszcze kilka dni i faktycznie wyleciałem do Zurychu. Dotarłem bez przygód. Z lotniska do miasta dojechałem pociągiem — szybko i wygodnie. Trochę poszukując po mieście, znalazłem hotel i się zameldowałem. Ponieważ hotel był zarezerwowany bez posiłków, zjadłem kolację w pobliskiej restauracji i poszedłem spać, ponieważ lot był poranny i byłem już zmęczony. Następnego dnia zjadłem śniadanie w hotelu (za dodatkową opłatą) i udałem się do biura Google. W Zurychu Google ma kilka biur. Moje rozmowy kwalifikacyjne nie odbywały się w centralnym. W sumie biuro wyglądało dość standardowo, więc nie miałem okazji zobaczyć wszystkich udogodnień „normalnego” biura Google. Zarejestrowałem się u administratora i usiadłem, czekając. Po jakimś czasie wyszedł rekruter i opowiedział mi plan dnia, po czym zaprowadził do pokoju, w którym miały odbyć się rozmowy. W planie było 3 rozmowy, lunch i jeszcze 2 rozmowy.
Rozmowa kwalifikacyjna numer jeden
Pierwsza rozmowa kwalifikacyjna dotyczyła Androida. Co ciekawe, w ogóle nie była związana z algorytmami. Niespodzianka, prawda? Cóż, nawet lepiej, w końcu to bardziej znajome. Poproszono mnie o stworzenie określonego komponentu UI. Najpierw omówiliśmy, co i jak zrobić. Zaproponowałem rozwiązanie oparte na RxJava, opisałem, co dokładnie i dlaczego chciałbym zrobić. Powiedzieli, że to oczywiście dobrze, ale zróbmy to przy użyciu narzędzi frameworka Android. A przy okazji napiszmy kod na tablicy. Nie tylko komponent, ale całą Activity wykorzystującą ten komponent. Na to nie byłem przygotowany. Jedna rzecz to pisać na tablicy algorytmy na 30-50 linijek, a inna to klikać w Androidzie, nawet skracając i pisząc komentarze w stylu „no, tego nie będę pisał, bo to i tak oczywiste”. Wyszło coś jak sałatka na trzech tablicach. To znaczy, że zadanie rozwiązałem, ale wyglądało to źle.
Rozmowa kwalifikacyjna numer dwa
Tym razem rozmowa dotyczyła algorytmów. A interviewerów było dwóch. Jeden był głównym interviewerem, a drugi młodszym padawanem (shadow interviewer). Należało wymyślić strukturę danych o określonych właściwościach. Najpierw, jak zwykle, omawialiśmy problem. Zadawałem różne pytania, interviewer odpowiadał. Po pewnym czasie poprosili, żebym napisał kilka metod wymyślonej struktury na tablicy. Tym razem poszło względnie dobrze, chociaż było kilka drobnych błędów, które poprawiłem po wskazówkach interviewera.
Rozmowa kwalifikacyjna numer trzy
Tym razem system design, który nagle okazał się Androidem. Należało zaprojektować aplikację o określonej funkcjonalności. Omówiliśmy wymagania dotyczące aplikacji, serwera i protokołu komunikacji. Następnie zacząłem opisywać, jakie komponenty lub biblioteki chciałbym wykorzystać przy budowie aplikacji. A potem, przy wspomnieniu Job Scheduler, pojawił się pewien problem. Sęk w tym, że nigdy go nie używałem w praktyce, ponieważ w momencie jego wprowadzenia przeszedłem na wsparcie aplikacji, w których nie było zadań do jego zastosowania. Podczas opracowywania kolejnych projektów było to samo. To znaczy, teoretycznie wiem, co to jest, kiedy i jak to stosować, ale nie mam doświadczenia w używaniu tego. I to najwyraźniej nie spodobało się interviewerowi. Później poprosili, żebym napisał kod. Tak, podczas opracowywania aplikacji od razu trzeba pisać kod. Ponownie kod Androida na tablicy. Znów wyszło źle.
Obiad
Miał przyjść jeszcze jedna osoba, ale się nie pojawiła. Google również ma czasem potknięcia. W rezultacie na lunch poszedłem z poprzednim rozmówcą, jej kolegą, a chwilę później dołączył następny rozmówca. Lunch był całkiem przyzwoity. Znowu, ponieważ to nie była główna siedziba w Zurychu, stołówka wyglądała dość zwyczajnie, chociaż bardzo przyjemnie.
Rozmowa kwalifikacyjna numer cztery
Wreszcie algorytmy w czystej postaci. Pierwsze zadanie rozwiązałem dość szybko i skutecznie, co prawda nie trafiłem w jeden przypadek brzegowy, ale dzięki wskazówce rozmówcy (on podał ten właśnie przypadek brzegowy) znalazłem problem i go poprawiłem. Naturalnie musiałem pisać kod na tablicy. Następnie podano podobne zadanie, ale trudniejsze. Dla niego znalazłem kilka nieoptymalnych rozwiązań i prawie znalazłem optymalne, zabrakło mi 5-10 minut, aby dokończyć myśl. No i kod dla niego nie zdążyłem już napisać.
Rozmowa kwalifikacyjna numer pięć
I znowu rozmowa na temat Androida. Ciekawe, po co uczyłem się algorytmów przez cały rok?
Na początku było kilka prostych pytań. Potem rozmówca napisał kod na tablicy i poprosił o znalezienie w nim problemów. Znalazłem, wytłumaczyłem, poprawiłem. Omówiliśmy to. A potem zaczęły się kilka niespodziewanych pytań w stylu „co w klasie X robi metoda Y”, „co wewnątrz metody Y”, „co robi klasa Z”. Na coś z tego odpowiedziałem, ale potem powiedziałem, że w pracy ostatnio się z tym nie spotkałem i oczywiście nie pamiętam, kto, co i jak w szczegółach robi. Po tym rozmówca pytał, co teraz robię. I pytania zaczęły się na ten temat. Tutaj już odpowiadałem znacznie lepiej.
Po zakończeniu ostatniej rozmowy zabrałem kartę dostępu, życzyli mi powodzenia i wysłano mnie precz. Trochę pochodziłem po mieście, zjadłem kolację i poszedłem do hotelu, gdzie padłem spać, ponieważ lot znów był wcześnie rano. Następnego dnia szczęśliwie dotarłem na Cypr. Na prośbę rekrutera napisałem opinię na temat rozmowy i wypełniłem w specjalnej usłudze formularz na zwrot wydanych pieniędzy. Z wszystkich wydatków Google bezpośrednio opłaca tylko bilety. Hotel, jedzenie i transport są opłacane przez kandydata. Następnie wypełniamy formularz, dołączamy paragony i wysyłamy do specjalnej firmy. Oni to przetwarzają i dość szybko przelewają pieniądze na konto.
Przetwarzanie wyników rozmowy kwalifikacyjnej zajęło półtorej tygodnia. Po tym poinformowano mnie, że byłem "trochę poniżej wymaganego poziomu". Chodzi o to, że 2 rozmowy poszły dobrze, 2 trochę mniej, a System Design poszło bardzo źle. Gdyby chociaż 3 przeszły dobrze, mógłbym powalczyć, ale tak to bez szans. Zaproponowano mi, żeby spróbować ponownie za rok.
Na początku oczywiście byłem rozczarowany, ponieważ przygotowanie zajęło dużo czasu i już w momencie rozmowy kwalifikacyjnej myślałem o opuszczeniu Cypru. Praca w Google i przeprowadzka do Szwajcarii wydawały się świetną opcją.
Podsumowanie
I teraz przechodzimy do końcowej części artykułu. Tak, dwa razy nie przeszedłem rozmowy kwalifikacyjnej w Google. To smutne. Prawdopodobnie byłoby interesująco tam pracować. Ale można spojrzeć na sprawę z innej perspektywy.
- W ciągu półtora roku nauczyłem się ogromnej ilości rzeczy związanych z tworzeniem oprogramowania.
- Czerpałem wiele radości biorąc udział w zawodach programistycznych.
- Spędziłem kilka dni w Zurychu. Kiedy jeszcze tam się wybiorę?
- Zyskałem interesujące doświadczenie rozmowy kwalifikacyjnej w jednej z największych firm IT na świecie.
W ten sposób wszystko, co wydarzyło się w ciągu tych półtora roku, można po prostu traktować jako naukę lub trening. A wyniki tego treningu dały o sobie znać. Moja myśl o opuszczeniu Cypru dojrzała (z powodów rodzinnych), pomyślnie przeszedłem kilka rozmów kwalifikacyjnych w innej znanej firmie i po 8 miesiącach się przeprowadziłem. Ale to zupełnie inna historia. Niemniej jednak, uważam, że powinienem podziękować Google za te półtora roku, które pracowałem nad sobą, oraz za 2 interesujące dni w Zurychu.
Co mogę powiedzieć na koniec. Jeśli pracujesz w IT, przygotuj się do rozmowy kwalifikacyjnej w Google (Amazon, Microsoft, Apple itd.). Może kiedyś uda Ci się tam dostać. Nawet jeśli nie chcesz, uwierz, że dzięki takiemu przygotowaniu nie będzie Ci gorzej. W momencie, gdy zrozumiesz, że możesz (nawet jeśli tylko przy sprzyjających okolicznościach) przejść rozmowę w jednej z tych firm, przed Tobą otworzy się znacznie więcej dróg niż na początku Twojego przygotowania. A wszystko, czego potrzebujesz na tej drodze, to cel, determinacja i czas. Życzę powodzenia 🙂
Źródło: habr.com
