Jak praca dla Google to tylko w Dolinie Krzemowej — Marcin Kamiński

Dla naszego rozmówcy praca w Google’u była marzeniem, ale o nią nie zabiegał. Zespół rekrutacyjny sam przysłał propozycję pracy, a po procesie rekrutacji kurierem przysłał propozycję wynagrodzenia. — Ciężko było stwierdzić czy to dobra, czy zła propozycja, bo nie miałem porównania. Jak na polskie warunki to oczywiście wypas, ale czy na amerykańskie? — zastanawiał się. Marcin zasięgnął opinii u znajomych i stwierdził, że to słaba oferta.

O tym, jak na to zareagował Google, o tym jak wyglądają pierwsze dni pracy w tej korporacji, ale też o tym, jak można rozwijać swoje zainteresowania w firmie, która zatrudnia setki developerów – tego wszystkiego dowiecie się z poniższej rozmowy z Marcinem Kamińskim, który jest Site Reliability Engineer w Google.

Każda ścieżka kariery rozpoczyna się od pierwszego projektu, za który dostało się pieniądze. Pamiętasz swoje pierwsze zlecenie? Jak je pozyskałeś, a może ono znalazło Ciebie?

Moje pierwsze zlecenie dostałem jak byłem w I czy II klasie liceum. Programowałem wtedy gry, najczęściej w dziwnej kombinacji Pascal+Assembler. Spodobał mi się Turbo Vision (taka obiektowa biblioteka do tworzenia okienkowych aplikacji w trybie tekstowym w Turbo Pascalu) i kolega załatwił mi zlecenie na napisanie programu magazynowego dla sklepu bodajże meblowego. Pożyczyli mi do tego drukarkę igłową, bo musiały drukować się faktury. Oczywiście nie był to żaden SQL, ja wtedy lubiłem wszystko niskopoziomowo, więc stan magazynu zapisywał się w pliku binarnym własnego formatu.

W sumie za zlecenie kasy nie dostałem, bo z klientem nie rozmawiałem bezpośrednio, tylko przez kolegę, więc wymagania raczej odbiegały do tego, co sobie wyobraziłem, że klient chce. Ale za to miałem sporo radochy.

A pierwsze zlecenie za pieniądze? Na czym polegało?

Pierwsze “poważne” i zapłacone zlecenie pozyskałem dopiero na studiach. Dostałem szablony w HTMLu i musiałem zrobić z tego sklep. W sumie wtedy zainteresowałem się e-commerce’m, chociaż ten pierwszy sklep najwyższej jakości to raczej nie był. Ale nauczyłem się PHPa, sklep wdrożyłem i rozwijałem przez jakiś czas. Klient był ciężki w obyciu, ale kasa dla biednego studenta była.

Z Best.net współpracowałeś przez 11 lat, to bardzo długo jak na developera. Jak przez ten czas rozwijały się Twoje umiejętności? Pamiętasz jakiś projekt, dzięki któremu nauczyłeś się najwięcej?

Best.net to firma, z którą wiązała się praktycznie cała moja kariera zawodowa przed przejściem do Google’a. Zaczęło się od tego, że znajomy znajomego szukał admina do nowopowstałej firmy zajmującej się hostingiem i stronami. Pracowałem wtedy na Linuksie kilka lat i dla sportu konfigurowałem wszystko co się da, więc z chęcią przyjąłem zlecenie na porządne skonfigurowanie i zabezpieczenie ich serwera. Standardowy RedHat+Apache+QMail, wtedy chyba nawet bez PHPa czy bazy danych. Współpraca podobała się obu stronom, więc zaangażowałem się bardziej.

Śmieszne jest to, jak otrzymałem pierwszą “zapłatę”. Otóż klient nie miał za dużo kasy, za to miał jakiś deal z dostawcą artykułów biurowych i napojów, w tym soku Karotka. Uwielbiałem sok marchewkowy, więc przez jakiś czas zamiast pieniędzy dostawałem zgrzewki Karotki. Dla studenta mieszkającego w akademiku i wydającego jak najmniej pieniędzy to nie był taki zły układ.

Kolejny raz pracowałeś za darmo – fajny początek kariery.

Od tego się zaczęło, ale w krótkim czasie zostałem adminem i głównym developerem systemowym Besta. System hostingowy, zarządzanie pocztą, domenami itp. To wszystko robiłem czując się nie jako zleceniobiorca, ale jako integralna część firmy (chociaż pracownikiem nie byłem). Trzon firmy stanowił oddział handlowy, dla którego na początku byłem “Szarą Eminencją”, osobą której nikt nie widział, ale która wszystko trzyma w garści. Biedni byli handlowcy, którzy “prosili” mnie o coś, co nie zgadzało się z moimi niepisanymi zasadami. “Zjebki” leciały na prawo i lewo. Teraz jak o tym myślę to aż wstyd… Ale wtedy to działało, a mi wydawało się, że jak jestem jedyną osobą, która kontroluje wszystko, to tylko świetlana przyszłość przede mną. Potworny błąd i ostrzeżenie dla innych — poczucie “ważności” jest złudne, powoduje tylko nadmiar roboty i niechęć innych. Adminowanie to fajna sprawa, ale jednak wolałem coś tworzyć i ciągnęło mnie do e-commerce, który widziałem jako przyszłość.

W Beście mogłeś realizować to zainteresowanie? Udało Ci się stworzyć kolejne e-sklepy?

Dla Besta stworzyłem dwa systemy sklepowe. Pierwszy oparty na PHPie, którego celem były szybkie wdrożenia i łatwa sprzedaż. Bardzo ustandaryzowane funkcjonalności, grafika oparta na prostych szablonach itp. Działało to fajnie i mieliśmy na tym sporo wdrożeń dla małych klientów. Baza danych oparta była na mySQLu, wspólna dla wszystkich klientów.

Na V roku studiów zacząłem się mocniej interesować Javą (moja praca magisterska, którą wspólnie robiliśmy z Filipem była w Javie). Próbowałem wtedy wielu różnych frameworków i bibliotek. W końcu zabrałem się za tworzenie od nowa systemu e-commerce właśnie w Javie. Nie było to żadne zlecenie, po prostu chciałem zobaczyć, jak to wszystko się składa w realnym projekcie, którego zasady biznesowe już znałem. No i wyszło całkiem nieźle, na tyle, że Best.net chciał to sprzedawać. Target był całkiem inny niż poprzednio — tym razem chodziło o dużych klientów, gdzie każdy miał własne pomysły, a możliwości integracji były bardzo rozbudowane.

Duzi klienci – to pewnie było spore wyzwanie dla młodego developera. Sam pracowałeś nad tym systemem?

System stawał się za duży, żebym za programowanie odpowiadał sam (we wszystkich projektach odpowiadałem za kod, nigdy za grafikę lub usability, bo w tym zupełnie się nie znajdowałem), więc Best zatrudnił kolejnych ludzi. Wśród nich szczególnie muszę wyróżnić Michała, który był nie tylko świetnym programistą, ale także świetnym biznesmenem rozumiejącym e-commerce jak nikt inny. W dodatku był pierwszą osobą (poza Błażejem — CEO Best.net.pl), który był gotów poddać w wątpliwość moje pomysły i przekonania. To bardzo ważne mieć taką osobę w pobliżu, inaczej własne błędy tylko się pogłębiają. To kolejna ważna lekcja — warto pracować z ludźmi, którzy patrzą na świat inaczej niż Ty i potrafią obronić swoje poglądy.

Projekty “shopsy” jest zdecydowanie najważniejszym dla mnie projektem podczas kariery przed Googlem. Nie tylko ogromnie rozwinął moje umiejętności techniczne, ale także zmusił mnie do rozmów z klientami, pokazał co to znaczy zarządzać zespołem i co to znaczy biznes. Przez lata pracy nad tym projektem starałem się minimalizować czas spędzany nad adminowaniem, a maksymalizować czas spędzany nad biznesowym rozwijaniem shopsów.

W tzw. międzyczasie dostałeś ⅓ etatu jako operator NOC w Poznańskim Centrum Superkomputerowo-Sieciowym. Czym zajmuje się to centrum?

PCSS jest (lub był) technicznym centrum Poznania. Był operatorem sieci miejskiej POZMAN, a także naukowych sieci ogólnopolskich jak POL-34, POL-155 czy PIONIER. PCSS jako jednostka naukowa udostępniał “klasy” oraz kadrę Politechnice Poznańskiej, tak więc miałem tam zajęcia zanim tam pracowałem. NOC (Network Operating Center) to miejsce, gdzie znajduje się cały monitoring urządzeń sieciowych i obliczeniowych sieci. NOC zapewnia całodobowy monitoring sieci, ale oczywiście nie ma tam osób, które pracują w innych strefach czasowych, tak więc gdy doświadczeni pracownicy NOC idą do domu, potrzebni są inni, którzy zapewnią całodobową obsługę sieci. I właśnie do tego powstało stanowisko “operator NOC”, które jest idealne dla studentów późniejszych lat studiów.

Czym zajmował się taki student?

Taki operator siedział sobie w pomieszczeniu NOC (za moich czasów było to na Noskowskiego, aktualnie jest w nowej siedzibie PCSS nad Wartą, koło Politechniki) i jeśli odpalany jest alert (nie wiem jak to wygląda teraz, ale za moich czasów to był trap SNMP) albo dzwoni klient to trzeba zareagować. Oczywiście jest do tego specjalny playbook, opisujący co należy zrobić (i chwała za to, playbook to jest najważniejsze narzędzie do emergency response w IT). W przypadku superkomputerów (a było ich trochę), reakcja polegała na odpowiednim zamknięciu systemu, aby jak najmniej obliczeń naukowców poszło na marne; w przypadku sieci należało sprawdzić stany interfejsów, czasem gdzieś zadzwonić itp. Ogólnie praca mało kreatywna, ale jednak dająca kontakt z realnym światem problemów technicznych.

Ponieważ nie było dużo obowiązków niezwiązanych z sytuacjami awaryjnymi (poza kserowaniem dokumentów dla kadry naukowej i technicznej), to praca ta polegała głównie na siedzeniu przed komputerem i robieniem swoich rzeczy (np. projektu na studia). A jak nie było co robić w nocy, to za szafą ze sprzętem sieciowym leżała karimata. Niestety wtedy nauczyłem się, co to znaczy paranoja budząc się i słysząc alerty, podczas gdy nic się nie działo. Praca miała jeszcze jedną zaletę – dostęp do Thymusa. Niestety nie mogę wyjaśnić co to znaczy, ale wtajemniczeni wiedzą o co chodzi.

Możesz podać przykład jakiegoś typowego zadania w NOC?

Alerty przychodziły głównie jako trapy SNMP, czyli asynchroniczne odpowiedzi UDP od urządzeń sieciowych i obliczeniowych. Należało wtedy zrobić “coś”. Na początku człowiek uczył się playbooka co należy zrobić, potem robiło się to już z pamięci. A sprawy były różne — od przeciążenia urządzenia sieciowego, poprzez przecięcie światłowodu, aż do awaryjnego wyłączania superkomputerów takich jak Cray czy SGI. Przydawała się wiedza z zakresu niskopoziomowej sieci czy Unixa, ale ogólnie każdy mógłby to robić. Polecam każdemu studentowi.

Nadal współpracowałeś z Best.net – stworzyłeś dla tej firmy m.in. sklep internetowy napisany w Javie. Wtedy większość takich projektów powstawała w Pythonie, skąd zatem decyzja o Javie?

W sumie to większość projektów e-commerce powstawała w PHPie, nie w Pythonie. Szczerze powiem, o ile PHPa w pewnym momencie zacząłem darzyć wielką niechęcią, to nie jestem w stanie przecenić jego wkładu w rozwój Internetu. W swoim czasie to był naprawdę genialny język do wszelkiego rodzaju aplikacji Internetowych. Potem okazało się jak słabym językiem do większych projektów jest PHP, ale i tak swoje zrobił. Python zdecydowanie nie ma takiej pozycji na frontendzie.

No właśnie, frontendzie. To były czasy kiedy aplikacje były w pełni “server-rendered”, czyli strona jako HTML + ewentualnie JS były generowane dynamicznie po stronie serwera. Dynamicznie, czyli coś wykorzystujące zasoby serwera musiało wygenerować ten kod i zazwyczaj korzystało to z jakiejś bazy SQL (bo SQL to normalizacja danych, efektywne ich przechowywanie i tego uczyli na studiach). PHP traktował każdy request niezależnie. To bardzo prosty mechanizm dla programistów, po prostu jedziesz od początku do końca i wpisujesz kod dla przeglądarki. Mi to nie pasowało.

Dlaczego Tobie to nie pasowało? Przecież z tego sposobu korzystali wszyscy.

Chciałem, żeby nasz grafik, który jedwabiście robi HTMLe z całą otoczką robił strony, a od całej logiki byli programiści. Do tego nie chciałem zawalać bazy SQL w kółko tymi samymi zapytaniami. Java różniła się od PHPa tym, że była to aplikacja, nie “skrypt”. Można było współdzielić dane między zapytaniami. Można było cache’ować bez filesystemu. Można było nawet trzymać dane sesji w pamięci! (niestety błędem było to, że trzymałem nawet kod w sesji, co odbiło się na możliwości klastrowania aplikacji).

Wtedy myślałem, że JSP to rozwiązanie problemów z grafikami, którzy po prostu chcą zbudować schemat sklepu. Nie ma kodu w HTMLu, są tylko tagi, które można wrzucić w dokumentację grafika i już. Niestety nie, JSP jest strasznie słabe. Fakt, że JSP2 jest dużo lepsze od oryginalnego, ale już JSF to tragedia. Ale i tak udało się utrzymać grafikę sklepów na całkiem dobrym poziomie pod względem kodu. Trzeba przy tym brać pod uwagę to, że Michał (inny niż poprzednio) to jednak wyjątek, a nie reguła wśród grafików.

W shopsach używałem iBatisa, zapomnianej już dzisiaj biblioteki do komunikacji z bazą danych. Bez mapowania relacyjno-obiektowego, po prostu zoptymalizowane zapytania SQL mapowanie w postaci kodu na encje. Całkiem ciekawa alternatywa dla ORMów jak Hibernate, gdzie jak wsio działa to jest fajnie, ale jak coś jest wolne, to już gorzej.

Na koniec najważniejsza zaleta Javy w stosunku do PHP w tamtym czasie — statyczne typowanie + IDE zdecydowanie zwiększające wydajność pracy. To było ponad dekadę temu, i przez ten czas PHP nadrobił, ale wtedy naprawdę to miało znaczenie.

Przejdźmy teraz do historii z Google. W 2007 roku Twoją osobą zainteresowała się znana na całym świecie korporacja. Powiedzieli, jak Cię znaleźli?

LinkedIn. Po prostu. Jeśli ktoś nie jest znaną osobistością z publikacjami czy książkami na koncie, to LinkedIn jest chyba najlepszym sposobem na znalezienie pracy. Od kiedy mieszkam w Bay Area, to nie ma tygodnia żebym nie dostał maila od jakiegoś rekrutera. Ciężko mi stwierdzić na ile to co piszą rekruterzy to prawda, na ile nie, ale powiedzieli, że spodobało im się to jak łączę pracę admina, developera i managera — bo o tym pisałem w opisie profilu. Zdecydowanie to nie jest tak, że rekruter wiedział o moich osiągnięciach, oni masowo wysyłają maile do potencjalnych kandydatów, z których profili wynika, że mają szansę.

Jak przebiegał proces rekrutacyjny?

Najpierw była rozmowa z rekruterem — to zazwyczaj osoba niezbyt związana z firmą, która ma płacone za sukces, czyli zatrudnienie (ale nie zawsze, część rekruterów ma duży staż w tej samej firmie). Rekruter jest głównie zainteresowany doświadczeniem, wykształceniem, dotychczasową karierą, próbuje rozpoznać, w którą stronę skierować interview itp. Jak kandydat sam szuka roboty, to na careers.google.com znajduje odpowiadające mu stanowiska i kontaktują się z nim rekruterzy od tych stanowisk. W moim przypadku skontaktował się ze mną rekruter zajmujący się Site Reliability Engineeringiem, więc w sumie nawet nie wybierałem gdzie chciałbym pójść. W tamtym czasie naprawdę ceniłem sobie pracę w małej firmie i Google był jedyną korporacją, w której chciałbym pracować. Opis stanowiska mi się podobał, więc po prostu podszedłem do interview, bez żadnego szukania czy próby zmiany stanowiska.

Jak rekruter uzna, że coś może z tego być, to umawia telefoniczne interview techniczne (w tym przypadku, oczywiście jak ktoś idzie na stanowisko biznesowe lub inne to ma inne interview merytoryczne). Ta rozmowa nie musi być z osobą, z którą by się potencjalnie pracowało, ogólnie w Google system rozmów rekrutacyjnych zazwyczaj nie jest związany z zespołem, który szuka pracownika. Miałem jedną albo dwie takie rozmowy. Później zaproszono mnie na on-site interview, czyli spotkanie w biurze firmy. W tamtym czasie w Europie SRE miało biura w Dublinie i Zurychu, więc zapytano mnie, gdzie mi wygodniej pojechać. Już nie pamiętam czemu, ale wybrałem Dublin.

Swoją drogą to w tym samym czasie mój kolega z PCSSu (ja już wtedy tam nie pracowałem, ale mam tam dobrych znajomych) był także w procesie rekrutacyjnym i dzień przede mną miał rozmowę w Zurychu. Oczywiście podał mi na świeżo swoje pytania. W tamtym czasie jeszcze zdarzały się sławne pytania typu, ile kulek wejdzie do autobusu, na szczęście sporo lat temu już z tego zrezygnowano, bo nie miało to żadnej korelacji z późniejszymi wynikami pracowników.

Oferty pracy z

Praca w Google to dla wielu marzenie. Wielu pewnie całymi dniami przygotowywało się do rozmowy. A jak wyglądało to w Twoim przypadku?

Nie przygotowywałem się do interview pod względem technicznym. Podchodziłem do tego na zasadzie szansy, która się trafiła, a nie której szukałem. Jedyne co zrobiłem to przeczytałem książkę o historii Google’a, żeby coś powiedzieć jakby się zdarzyły typowo korporacyjne pytania jak “dlaczego chciałbyś pracować dla Google?”. Na szczęście interview było całkiem techniczne, bez żadnych testów osobowości itp. To był mój pierwszy raz w Dublinie, więc oczywiście zwiedziłem puby, pochodziłem po mieście itp. Hotel dostałem blisko biura.

Hotel blisko biura – skądś to znam. Pewnie przez cały dzień miałeś spotkania i rozmowy?

Mój dzień składał się z 5 rozmów i lunchu, co jest typowe dla interview technicznych. Strasznie mi się podobało, w sumie to było moje pierwsze prawdziwe interview. Rozmowy były interesujące i dociekliwe. Niestety jedna z nich nie przebiegła tak jakbym chciał no i po kilkunastu dniach rekruter do mnie zadzwonił, że tym razem podziękujemy, ale może następnym razem się uda.

Niestety nie udało mi się dowiedzieć, czy nie dostałem się z tego powodu co podejrzewałem, ale tak to działa. Nie ma co się spodziewać użytecznego feedbacku. Są ku temu przyczyny. Nie przejąłem się tym zbytnio, bo dobrze mi się pracowało z Bestem, a tą całą rekrutację potraktowałem jako darmowy wyjazd do Dublina.

Za pierwszym razem nie udało się dostać pracy, ale trzy lata później Google znowu sobie o Tobie przypomniał. Rozmawiałeś z tymi samymi ludźmi, co wtedy? Czym różniła się ta rekrutacja od poprzedniej?

Rekruterzy byli inni, także osoby od rozmów technicznych były chyba inne. Nie jestem pewien, gdyż mam bardzo słabą pamięć do ludzi, a nie da się tego sprawdzić (dane na temat rekrutacji są tajne, nawet jak się zacznie pracować w Google’u to ma się dostępu na temat własnego interview; wielu znajomych pamięta swoich rekruterów, ja niestety nie, a w mailach są tylko nazwiska osób z działu rekrutacji, nie technicznych).

Sam proces był podobny — rozmowa z rekruterem, 1 czy 2 rozmowy telefoniczne i potem on-site. Od samego początku mówiłem, że interesuje mnie tylko praca w centrali, a nie w Europie czy jakimś innym biurze w USA, więc rekruter stwierdził, że na on-site pojadę do Mountain View! No mocno się wtedy ucieszyłem, bo jednak darmowy wyjazd do USA był w strefie marzeń. Niestety ktoś rekrutera doprowadził do porządku i jednak pojechałem znowu do Dublina.

Było tak blisko. No, ale ok – rozmowa miała odbyć się w Dublinie, ale pracować miałeś w Mountain View, więc wydawało się wszystko w porządku. Czym miałeś się zajmować?

W 2010 brałem udział w projekcie, w którym nie mogłem być zewnętrznym kontraktorem, jak zazwyczaj, tylko musiałem być zatrudniony na etat. To był bardzo dobry etat, więc do propozycji Google’a podszedłem na jeszcze większym luzie, niż za pierwszym razem. Stwierdziłem, że z chęcią sobie pojadę znowu na koszt Google’a do Dublina, ale nie miałem żadnych większych oczekiwań. Rekruter był bardzo elastyczny — napisał do mnie w kwietniu 2010, jak mu napisałem o projekcie, to stwierdził, że znowu skontaktuje się w lipcu. W sierpniu miałem rozmowę telefoniczną i już następnego dnia miałem wiadomość, że chcą zrobić kolejny phone interview, który odbył się na koniec sierpnia. Po 10 dniach napisali, że chcą robić on-site. Odbył się 22 września.

Ta wyprawa do Irlandii miała wiele niespodzianek, np. rekruter wynajął pokój w jednym hotelu, a potem przebookował do innego, jednak mail o tym do mnie nie dotarł. Na szczęście był jeden pokój wolny w pierwotnym hotelu, ale to był jakiś ogromny apartament z dwoma pokojami, zdobionymi krzesłami itp. No ale cóż, zapłaciłem z własnych z nadzieją, że jednak Google zwróci. Niestety apartament był wolny tylko na jedną noc, a w Dublinie miałem być dwie. Następnego dnia była totalna ulewa, a hotel był spory kawałek od biura. Dotarłem tam totalnie przemoczony. Nie zapowiadało się więc za dobrze.

Tym razem ze wszystkich rozmów wyszedłem zadowolony. Największy wpływ na to chyba miał luz z jakim do tego podszedłem. Nie próbowałem przewidzieć co rekruter chce usłyszeć, po prostu mówiłem co uważam i to przyniosło bardzo dobre skutki. Ze wszystkimi technicznymi rekruterami znalazłem wspólny język, mogłem opowiadać o prawdziwych sytuacjach jakie przydarzyły mi się podczas wieloletniej pracy w Beście i u klientów.

Z biura wyszedłem bardzo zadowolony i chociaż cały czas była ulewa, to pozwiedzałem kawał śródmieścia, wliczając typowe dla Dublina atrakcje. Skontaktowałem się też wcześniej z prowadzącym rekruterem, który załatwił mi hotel na drugą noc, niestety całkiem daleko i musiałem w ulewie drałować kawał drogi. Jakoś nie przyszło mi do głowy, że Google przecież zapłaciłby za moją taksówkę…

Co było dalej? Wróciłeś do domu i czekałeś za telefonem od HRu?

29 września dostałem maila, że komisja zarekomendowała zatrudnienie, ale ze względu na moje dodatkowe wykształcenie (ukończyłem podyplomowe studia z Zarządzania Przedsiębiorstwami na Akademii Ekonomicznej w Poznaniu) chcieliby mnie przesłuchać telefonicznie na stanowisko Technical Program Manager. Ta rozmowa odbyła się 11 października i nie była techniczna, a raczej z zarządzania. Rekruter wyczuł, że jednak lepiej się czuję w kwestiach technicznych, niż ludzkich i propozycja przyszła na stanowisko SRE, nie TPM (jak dobrze!).

Po tym była cała formalna otoczka, musieli zrobić mi screening (czyli sprawdzić, czy byłem karany itp). Musiałem też dostarczyć listy referencyjne i kontakty do pracodawców, itp. Co ciekawe, dopiero wtedy dałem im CV, więc to była raczej podkładka, a nie kluczowy dokument. Te formalności trwały od 18 października od 5 listopada (podaję te wszystkie daty, żeby pokazać, ile takie rzeczy trwają).

Ciekawostką jest to, że ludzie od relokacji skontaktowali się ze mną zanim jeszcze zobaczyłem propozycję na oczy. Pytali o rzeczy typu jak mam duże mieszkanie, ile osób, ile rupieci itp. To było dziwne, bo nawet nie wiedziałem, czy będę się przeprowadzał czy nie.

Możesz zdradzić jaka była propozycja ze strony Google’a? Negocjowałeś wysokość wynagrodzenia? Pakiet relokacyjny?

Propozycja przyszła Fedexem. Kwota roczna, bonus, akcje, urlop itp. Ciężko było stwierdzić czy to dobra, czy zła propozycja, bo nie miałem porównania. Jak na polskie warunki to oczywiście wypas, ale czy na amerykańskie? Tego nie widziałem, skontaktowałem się ze znajomymi, którzy pracowali w Stanach (w tym w Google’u) i w sumie wyszło, że zbyt różowo nie jest. No więc powiedziałem, że spodziewałem się więcej. Do tego chciałem przełożyć o dwa miesiące datę startu.

Zgodzili się?

Przysłali kolejną propozycję, na większe kwoty i zgodziłem się. Szczerze powiem, że gdybym zgodził się na pierwszą propozycję, to po roku by mnie tam nie było, bo bym nie przetrwał w Dolinie Krzemowej. Pakiet relokacyjny obejmował wszelkie koszty wizy, przeprowadzki (do wyboru miałem transport rzeczy statkiem, lub samolotem), wynajem samochodu itp. Pierwszy raz ktoś mnie wtedy przeprowadzał i muszę przyznać, że firma od przeprowadzek była niesamowita.

Co ostatecznie przekonało Cię do przeprowadzki i pracy właśnie w Google’u? W Dolinie Krzemowej jest mnóstwo innych ciekawych firm.

Nie zakładałem wcześniej pracy w korporacji. Podoba mi się klimat małych firm, gdzie każdy ma ogromny wpływ na całość firmy, wszyscy się znają i można zebrać wspaniałą ekipę. Nie wyobrażałem sobie pracy w Microsofcie, Oraclu czy Allegro. Ale Google było inne, strasznie podobało mi się to co robili, że robili rzeczy użyteczne dla wszystkich, a przy tym tworzyli technologię, która potrafi zafascynować geeków. Że udostępniali produkty typu GWT, API od mapsów itp. To była jedyna korporacja, dla której byłem gotów pracować.

Jak praca dla Google’a to tylko w Dolinie Krzemowej. Legenda tego miejsca mnie pociągała. Nie miałem żadnych czysto praktycznych informacji na temat Doliny, po prostu wiedziałem, że jest w Kalifornii i jest mekką informatyków. Dlatego od razu mówiłem, że nie interesuje mnie praca w Dublinie czy Zurychu.

Od znajomych z Doliny Krzemowej dowiedziałeś się, że pierwsza propozycja, którą dostałeś od Google’a nie jest za dobra. Co mówili o samym życiu w Dolinie? Ich opowieści sprawdziły się?

Znajomi mieli różne opinie o Dolinie. Jeden znany spec od bezpieczeństwa miał bardzo złe zdanie o życiu tutaj i wrócił do Polski. Inny znajomy zachwalał. Szczerze powiem, że wtedy wydawało mi się, że życie tutaj wygląda jak w “Gotowych na wszystko” (pomijając wątki kryminalne), gdzie ludzie żyją w dużych domach na przedmieściach, dzieci spokojnie grają na ulicy itp. Z drugiej strony miałem wizję, że jak w złym miejscu zjadę z autostrady, to mnie ktoś zastrzeli. Decyzja jednak była szybka i zdecydowana. Idziemy na całość. W momencie podejmowania decyzji moja córka miała 3 lata, a syn niecały rok. W sumie najlepszy czas na duże zmiany.

Jak wyglądał pierwszy dzień pracy? Kto wdrożył Cię w procedury?

Cały pierwszy dzień (w sumie tydzień albo dwa) to były szkolenia. Część z tego to korporacyjna gadka na temat firmy, część praktyczne informacje jak uzyskać dostęp do niezbędnych narzędzi. Niestety nikt nie chciał nic powiedzieć na temat podatków, bo im nie wolno, a to w sumie jedna z ważniejszych rzeczy, bo na samym początku trzeba podjąć sporo decyzji, które na podatki wpływają.

Zanim zacząłem pracować to dostałem ankietę — jaki username chcę, na jakim sprzęcie chcę pracować (Linux, Mac, Windows) itp. Nigdy wcześniej nie miałem Maca, więc zdecydowałem się na niego z ciekawości. Na szczęście po dwóch latach mogłem wymienić go na normalnego Linuksowego laptopa Thinkpada. Pod koniec dnia przyszedł po mnie Leslie — mój Googlowy mentor. Dopiero wtedy dowiedziałem się w jakim zespole będę pracował (Search SRE, czyli zespół odpowiedzialny za nieprzerwane działanie wyszukiwarki). Oprowadził mnie po biurze, gdzie pracowała reszta teamu, opowiedział co nieco.

Teraz jest inaczej, Nooglersów (czyli nowych Googlersów) widzimy zazwyczaj po 1-2 tygodniach, bo na początku całkiem zajęci są szkoleniami. Ja też miałem zajęte 2 tygodnie szkoleniami, ale jednak mój mentor cały czas znajdował czas dla mnie. Dużo Lesliemu zawdzięczam!

To było Twoje pierwsze zetknięcie z korporacją, ale wcześniej mówiłeś, że bardzo podobała Ci się praca w małej firmie. Co z korporacyjnych procedur, warto przenieść do software house’ów?

Nie mam wielkiego zaufania do korporacyjnych procedur, ale za to bardzo dużo nauczyłem się na temat procedur stosowanych w produkcji przy dużej skali. Jako SRE moim obowiązkiem jest przede wszystkim utrzymywanie produkcji w użytecznym stanie, z minimalnymi przestojami i awariami. Ale nie jest to praca admina, chodzi przede wszystkim o zapobieganie możliwościom wystąpienia znaczących awarii i takie projektowanie systemów, by wpływ awarii minimalizować.

1. Monitoring to podstawa — bez monitoringu nie ma mowy o mierzeniu niezawodności i skuteczności zmian.

2. Zmiany powinny być szybko wycofywalne – podstawowym narzędziem nie jest naprawianie błędów, a przywracanie bezpiecznego stanu.

3. Zmiany powinny być stopniowane, aby potencjalne problemy nie uderzały we wszystkich.

4. Awarie powinny być traktowane jako materiał do nauki, a nie powód do winienia ludzi. Kultura “blameless postmortems” to jeden z najważniejszych czynników pozwalających na rozwój systemów i ludzi.

Jak wygląda ścieżka rozwoju w Google’u? Jakie ma się możliwości? Jak często odbywają się rozmowy dot. Twoich planów, potrzeb?

W Google promocja na wyższy poziom, to nie jest widzimisię menadżera. Należy przygotować pakiet promocyjny, który oceniają ludzie często nie mający bezpośredniego pojęcia o pracy danej osoby. Proces ten ulega zmianom każdego roku, ale ogólnie to nie jest tak, że idziesz do szefa i mówisz “chcę podwyżkę”. Za promocją muszą iść konkretne, mierzalne wyniki oraz opinie innych, wyżej postawionych pracowników.

Różne zespoły mają różnie zorganizowane spotkanie z menedżerami, dyskusje na temat kariery itp. Ogólnie bezpośredni menedżer to nie powinien być szef, to powinna być osoba wspierająca zespół. Na przykład w moim zespole zadania nie są odgórnie narzucane, sami decydujemy co jest ważne, a góra ma nam zapewnić odpowiednie warunki pracy, żebyśmy te ważne zadania mogli wykonać. Oczywiście są też zadania idące z góry, ale stanowi to mniejszość. Są jednak zespoły, u których wygląda to inaczej.

Każdy może wybrać sobie projekt, w którym chce pracować?

Na początku ma się na to wpływ podczas rekrutacji, gdzie podaje się stanowiska na jakie chce się kandydować. W moim przypadku to raczej rekruter chciał mnie przesłuchać na konkretne stanowisko.

W Google można zmieniać projekty i zespoły. Są jakieś czasy minimalne, podczas których powinno się zostać w jednym miejscu, gdyż inaczej to by było nieefektywne, ale założenie jest takie, że lepiej jak pracownik zmieni projekt/zespół niż firmę. Wdrożenie pracownika w firmie takiej jak Google, gdzie prawie wszystko jest tworzone in-house zajmuje sporo czasu, więc jak dobry pracownik się nudzi, to lepiej niech pomoże przy czymś innym w firmie, niż poza nią.

Niestety są pewne bariery formalne, np. ja jako SRE System Engineer, żeby przejść do zespołu developerskiego musiałbym przejść ponowne interview (nie całość, tylko obszary nie pokrywające się pomiędzy stanowiskami).

Na koniec pytanie trochę niebanalne. Freelancerkę i pracę w Poznańskim Centrum Superkomputerowo-Sieciowym rzuciłeś ze względu na znużenie projektami. W Google’u nigdy nie jest nudno?

Nuda też się zdarza. Na początku oszczędzanie milionów dolarów przez jakąś optymalizację wydaje się niesamowite, potem nie fascynuje to już tak bardzo. Staram się jednak uczestniczyć w projektach, które mnie w danym momencie interesują, chociaż zdarzają się kwartały, kiedy tłucze się to samo. Jak wszędzie.

---

Marcin Kamiński. Site Reliability Engineer w Google. Zaczynał od Atari, a aktualnie zarządza systemami działającymi na milionach procesorów. Zainteresowany zarówno wysokopoziomowymi problemami takimi jak niezawodność i skalowalność systemów, jak i niskopoziomowymi szczegółami działania sieci i systemów operacyjnych. Przed pracą w Google był biznesowo związany z branżą e-commerce.

Zdjęcie główne artykułu pochodzi z compelo.com.