Kiedyś próbowałem wytłumaczyć teściowi, co to jest Kubernetes

W poprzedniej części wywiadu, dowiedzieliście się o tym, że warto połączyć umiejętności techniczne z nietechnicznymi. Nieraz pewnie spotkaliście się z przekonaniem, że umiejętności programistycznych można się douczyć i w niektórych przypadkach na braki przymyka się oko. Z dzisiejszej części dowiecie się, że jest inaczej.

Karol Stępniewski, który dzisiaj pełni funkcję Senior Membera of Technical Staff w VMware, i zajmuje się się m.in. rekrutacją, nie zatrudnił kandydata, który „miał świetne umiejętności komunikacyjne”, ale zabrakło mu wiedzy technicznej, by dołączyć do zespołu VMware. Jak widzicie, każdy przypadek należy rozpatrywać indywidualnie, ale nie tylko o rekrutacji w Dolinie Krzemowej rozmawiamy z Karolem.

W drugiej części livestreamu (pierwszą znajdziecie pod tym adresem) dowiecie się więcej na temat tego, co Karol Stępniewski i Michał Miszczyszyn, Full Stack JavaScript Developer – współprowadzący wywiad, myślą na temat studiów informatycznych i bootcampów. Co ich zdaniem jest lepszym wyborem dla juniora?

---

PN: Widzę, że bardzo duży nacisk kładziesz na tą część umiejętności miękkich i w związku z tym nasunęło mi się pytanie. W tym momencie jesteś czynnym programistą, w zasadzie dwa tygodnie temu przeczytałeś na Wikipedii, co to jest OpenStack i VMware, ale chciałbyś się rozwijać, aby być takim Team Leaderem? Jak uważasz, bo skoro kładziesz duży nacisk na to, to też te kompetencje nabywasz. Jak widzisz swoją karierę?

KS: Mam takie podejście, że dla mnie liderzy często klarują się sami. Jestem zwolennikiem takiego organicznego bycia managerem. Nigdy nie myślałem o tym, aby samemu być managerem, ale jeżeli będę kiedyś technicznym liderem, a potem to automatycznie spowoduje, że będę liderem dla zespołu i będę widział, że mam szacunek ludzi, posłuch i zaufanie, to być może pójdę w tę ścieżkę. Na szczęście jestem w takim miejscu, gdzie ścieżka techniczna jest długa i można osiągnąć karierę. Wielu rzeczy nadal się uczę się i wiele staram się poznawać. Ostatnio mocno ten machine learning nieszczęsny wałkuję i wdrażamy go w naszym projekcie pewnie z mojej przyczyny.

Rozwój w stronę techniczną jest moim głównym priorytetem teraz, ale tak jak mówię, organiczny rozwój w tę stronę jest czymś, co biorę pod uwagę, jeżeli tak się wydarzy i stanie się to automatycznie. Ale widzę u siebie w firmie osoby, które stały się managerami, dlatego że stwierdzili, że chcą być managerem. I to widać. Mój szef z byłej firmy, w której pracowałem, zanim wyjechałem do USA, posiada taką naturalną cechę lidera. Ludzie wiedzą, że jeśli za nim pójdą, to osiągną sukces. Nie wiem czy taką cechę da się nabyć, to chyba przychodzi naturalnie. Wiadomo, pewne cechy da się wytrenować i widzę to po sobie, że pewne rzeczy udało mi się wytrenować, choć wcześniej wydawało mi się, że mogą przyjść naturalnie. Jednak żeby być dobrym Team Leaderem, to nie chcę powiedzieć, że jest to wrodzona umiejętność, ale jest to coś, co niektórym ludziom przychodzi łatwiej.

PN: Mam pytanie, które odnosi się do krótkiego bio, które mi przesłałeś. Jestem osobą nietechniczną i zastanowił mnie projekt Kubernetes. Spytałem się mojego kumpla programisty – czym jest ten cały Kubernetes? On mi odparł, że to nic, co łatwo zrozumieć. Stwierdziłem, że może mi w tym nieco pomożesz.

KS: Pamiętam, że kiedyś próbowałem wytłumaczyć teściowi, co to jest Kubernetes. Poległem na całej linii. Sam przestałem rozumieć, czym jest Kubernetes, więc nie wiem czy podejmę się tego wyzwania. Można powiedzieć, że jest to coś takiego, co pozwala traktować klaster serwerów, czyli ileś tam maszyn, jako jedną dużą maszynę, jeden duży serwer. Dzięki Kubernetes przestaje mieć znaczenie, ile tych serwerów jest, gdzie one są i jest to dla Ciebie jakby schowane. Ty masz tyle zasobów, tyle pamięci, i powiedz mi co chcesz z tym zrobić, co chcesz uruchomić, a ja już się zajmę resztą. Tu uruchomię tę aplikację, tu uruchomię taką aplikację i to wszystko będzie działać, tak jak sobie zażyczyłeś, ale nie musisz się martwić, który to będzie serwer, w którym to będzie miejscu itd. To nie jest dokładne wytłumaczenie, ale oddaje o co chodzi w Kubernetesie. Traktujemy klaster serwerów, jako jeden duży serwer. Nie wiem czy już rozumiesz, czym jest Kubernetes.

PN: Wyrobiłem sobie pewną wizję tego, z pewnością osoby, które są stricte techniczne, a nie były bliżej tematu, dzięki Twojemu wyjaśnieniu rozumieją więcej. Mam tu jeszcze pytanie, które idzie dalej za tym. Jakbyś porównał Kubernetes do Dockera?

KS: Zacznijmy od tego, że Kubernetes używa Dockera, tzn. nie musi tego robić, ale jest to domyślny silnik. Docker służy do zarządzania obrazami i kontenerami (kontener jest to coś, co pozwala zamknąć jakąś aplikację, która może być złożona z kilku komponentów, z wielkiej ilości kodu, z różnych rzeczy i to można zamknąć w taką jedną poręczną rzecz, taki obraz, który ma wszystko, co tej aplikacji potrzeba). Docker ma wszystko co potrzeba, aby taki obraz uruchomić — to duże uproszczenie.

Okej, i teraz co ten Kubernetes robi z tym Dockerem? No więc, mamy ileś tam tych serwerów, załóżmy 5 tysięcy serwerów. Kubernetes nam to zamyka w ten sposób, że mamy jeden wielki serwer, który zasoby tych wszystkich małych serwerów łączy i zestawia w jedną całość. A Docker działa na każdym z tych małych serwerów, właśnie po to, aby te aplikacje uruchamiać. W jaki sposób Kubernetes jest w stanie aplikacje, które często są właśnie rozbudowane, uruchomić na różnych serwerach?

Właśnie m.in. dzięki mocy Dockera, dzięki jego możliwościom zamknięcia serwerów w magicznych pudełkach, które wszystko mają. Te aplikacje działają i Kubernetes nie musi martwić się o to, jak je uruchomić, bo o to martwi się Docker. Docker wie jak te pudełka rozpakować i jak je uruchomić. Zestawiając takie warstwy, które zajmują się różnymi rzeczami, Docker byłby nieco poniżej, a Kubernetes byłby trochę powyżej. Istotna rzecz jest taka, że Docker ma w swojej ofercie produkt, który jest podobny do Kubernetesa – nazywa się Docker Datacenter. Jest to coś, co robi podobne rzeczy jak Kubernetes. Ciężko zatem porównać Dockera z Kubernetes, dlatego że jeżeli mówimy o Dockerze, w kontekście, o który zapytałeś, założyłem, że mówimy o tym narzędziu, którym możesz uruchomić we własnym laptopie i możesz robić te kontenery. Można tez uruchomić Dockera w podobny sposób, jak Kubernetesa z podobnymi możliwościami.

Oferty pracy z

A teraz anegdota, miałem rekrutację z Dockerem i ją przeszedłem. Dostałem ofertę pracy w San Francisco. Bardzo fajny zespół, świetni ludzie i super firma. Ale VMware dał mi lepszą ofertę, a ten nowy team, do którego przeszedłem wydawał mi się ciekawszy. Dyrektor z Dockera nie poddawał się i napisał do mnie maila, że CEO chciałby ze mną porozmawiać. Założyłem, że rozmowy z CEO się nie odmawia, pierwszy raz mi się coś takiego przytrafiło. Zadzwonił do mnie i zadałem mu dwa pytania: 1. Co powiedzieli Twoi ludzie o mnie, że chciałeś ze mną porozmawiać. 2. Co powiedziałeś swoim pracownikom, że wszyscy Cię tak chwalili. Bo jak byłem na rozmowie rekrutacyjnej, to wszyscy się o nim wypowiadali w samych superlatywach.

Jak usłyszał to drugie pytanie, gdzie mógł mówić o sobie, to skupił się na tym. O pierwszym pytaniu zapomniał. Nie przekonał mnie jakoś specjalnie. Miłą rozmowę odbyliśmy. Jak zadzwonił do mnie dyrektor z pytaniem „No i jak?”, to odpowiedziałem, że po tej rozmowie z CEO będziecie musieli mi jeszcze więcej zapłacić, żebym do Was przyszedł. Jak to powiedziałem, to zrozumiał, że nic z tego nie będzie.

MM: Co sądzisz o studiach i bootcampach? Prowadzę bloga i przygotowuję się do napisania tekstu na ten temat, Twoja wypowiedź może być bardzo ciekawa. Teraz jest mnóstwo osób, które przychodzi bez studiów albo ze studiami, ale nietechnicznymi. Rozszerzmy temat o bootcampy, które przygotowują od zera do programisty w dwa miesiące.

KS: Jasne, to bardzo fajny temat. Dzięki, że go poruszyłeś. Maciek Aniserowicz porusza go w swojej książce dość mocno. Studia jako całość to moim zdaniem trochę strata czasu, dlatego że w dzisiejszych czasach można by to robić tak, żeby kursy dobierać do potrzeb. Niektóre przedmioty są bardziej potrzebne, a inne mniej. Wydaje mi się, że studia powinny bardziej na bieżąco tych rzeczy uczyć. Dają jednak jakieś podstawy. Maciek Aniserowicz pisał, że dla niego wyższa matematyka jest niepotrzebna. Może i do podstawowego programowania nie jest potrzebna, ale w trudniejszych case’ach, czy grach komputerowych, czy machine learningu, matematyka jest wymagana. Machine learning to właściwie sama matematyka. Wszystko inne za Ciebie robią frameworki, nawet część tej matematyki za Ciebie robią, ale jeżeli nie rozumiesz, co tam się pod spodem dzieje, to będziesz poszkodowany.

Na politechnice było tak, że chodziło się na dane przedmioty, ze względu na punkty ECTS, a to jest dla mnie bezsensu. Mam parę takich przedmiotów ze studiów, które uważam, że się przydały, ale niestety większość były stratą czasu. Może nie był dla mnie stratą czasu, bo ja na te przedmioty nie chodziłem. Generalnie studiowałem dwa kierunki jednocześnie i do tego pracowałem, więc musiałem sobie radzić. Dwa kierunki dzienne i praca to było wyzwanie. Starałem się nie chodzić na zajęcia, które był niepotrzebne i starałem się nie dublować przedmiotów. Poniekąd moje kierunki pokrywały się, więc część przedmiotów przepisałem, część starałem się robić tylko raz.

W studiowaniu jest też coś takiego, że część przedmiotów jest potrzebna – matematyka, computer science, algorytmy. Prawda jest jednak taka, że tych rzeczy można się nauczyć samemu. Kiedyś nie można było, kiedyś ten dostęp do wiedzy był nieco gorszy. Dzisiaj wchodzisz na coursera.org i większość tych rzeczy możesz się nauczyć online. Jeżeli jesteś na tyle zmotywowany, by usiąść, przerobić kurs i nauczyć się danego zagadnienia, to uważam, że studia nie są potrzebne. Studia mogą Ci pomóc w aspektach komunikacyjnych, w organizacji pracy, w takich rzeczach, których siedząc sam w domu bez kontaktu z ludźmi i bez interakcji, np. umiejętności komunikacyjnych nie jesteś w stanie samemu wyćwiczyć.

Poza tym dla umiejętności technicznych, to takie studia nie są potrzebne. Chyba, że chcesz wyjechać do USA i chcesz mieć wizę, no to jeżeli masz papierek z uczelni to +10 do sukcesu. Inaczej trzeba mieć listy polecające z różnych firm, a to jest już problem. Mając studia jest łatwiej. Studia dają też taki wyznacznik, że jednak ktoś tam coś wie i skoro te studia skończył, to w jego głowie zostało. Chociaż też nie do końca, znam masę ludzi, którzy studiów nie skończyli, a znam tez parę osób, które studia pokończyły, a w głowie niewiele zostało. Jakby na dwoje babka wróżyła. Taka jest moja perspektywa.

PN: Powiedz jak uważasz, być może to się już pojawiało mniej więcej w tym co mówiłeś, ale w razie czego to jeszcze raz się do tego odnieśmy. W jaki sposób uważasz, że powinno się sprawdzić lub dać też wykazać się swoimi umiejętnościami programowania?

KS: Mówimy tutaj o rozmowach rekrutacyjnych? Taki był kontekst? Ok. Miałem przedwczoraj kandydata do naszego zespołu, któremu robiłem interview. Nie przyjęliśmy go. Gość miał świetne umiejętności komunikacyjne, bardzo dobrze się z nim rozmawiało, zero stresu, był dosyć swobodny, mówił ciekawie, itd. Niestety zabrakło tych umiejętności technicznych. Wydaje mi się, że skupił się za bardzo na rozmawianiu, a za mało na dostarczaniu wartości. Jeżeli chodzi o pokazywanie swoich umiejętności technicznych – zdecydowanie polecam, podeśle link do wywiadu z autorką książki „Cracking the coding interview”. Książka opisuje jak radzić sobie z technicznymi rozmowami o pracę. Myślę, że autorka mówi o rzeczach, które generalnie są znane ludziom.

Przede wszystkim swój własny projekt, jeżeli masz do tego skłonności, pisanie własnych projektów, tworzenie ich i wysyłanie w świat, to jest świetna droga. Nigdy nie miałem takich umiejętności pisania projektów od zera, zarządzania nimi i wysyłania w świat. Zawsze potrzebowałem projektu, z którego ktoś inny będzie korzystał, bo od razu wiedziałem, że komuś będzie potrzebny. Dla siebie nigdy nie potrafiłem czegoś takiego zrobić, ale jeżeli ktoś ma takie umiejętności, to jest świetna ścieżka dostępu do różnych firm. Po pierwsze pokazujesz, że masz umiejętności techniczne, a po drugie, że masz umiejętność zarządzania projektem — potrafisz wyprodukować, wypchnąć i utrzymać przy życiu.

Druga rzecz, którą mogę polecić to codewars.com — proste zadania w przystępnej formie, koduje się w przeglądarce, strona ma bardzo fajny interfejs. Zdarzyło mi się parę razy na rozmowach rekrutacyjnych linka do tego udostępnić i ludzie mogli sobie mój profil oglądać, i byli pod wrażeniem tego, co tam zrobiłem.

Podczas rozmów o pracę cenię sobie jedną rzecz. Mam pytanie, które zadaję prawie każdej osobie, z którą rozmawiam, chyba, że wymagania są inne. Pytanie/zadanie brzmi: zaprojektuj funkcję, która będzie sprawdzać złożoność hasła. I właściwie mówię tyle. Daję mało informacji, ale właśnie tak wygląda ta praca na co dzień. Takie jest moje odczucie – mało masz informacji na dzień dobry. Trzeba pokazać swoje skillsy, żeby zebrać więcej informacji, pokazać, że wiesz z doświadczenia o co trzeba się zapytać, co jest istotne, dopytać o szczegóły. Trzeba mieć też swoje sensowne założenia, bądźmy szczerzy, niektórzy nasi klienci nie do końca wiedzą czego chcą.

Trzeba pokazać, że umie się dać sensowne założenia do rozwiązania jakiegoś problemu. To są rzeczy, na które zwracam uwagę. Nie do końca algorytmy, to osobna historia, bo z algorytmami jest trochę łatwiej. Myślę, że Ci co dają takie zadania sticte algorytmiczne, to idą na łatwiznę, bo albo ktoś coś umie, albo nie. Wiadomo, że w pewnym sensie jest to łatwiej później zweryfikować, jak ktoś jest dobry, wiadomo że takie pytania też się muszą pojawić, ale pytanie otwarte pozwala zobaczyć, czy ten człowiek faktycznie myśli analitycznie, a to jest potrzebne w pracy programisty. To są rzeczy, na które zwracam uwagę. Michał powiedz jak to wygląda z Twojej strony.

MM: Odnosząc się do oryginalnego pytania, to ja bym postawił na 3 rzeczy – na GitHuba, na LinkedIn’a i na pojawianie się na różnych meetup’ach, żeby wyrobić sobie sieć kontaktów. Myślę, że to będzie bardzo dobry start. Nie wiem jak u Ciebie, ale u mnie w pracy przy rekrutacji bazujemy na sieci poleceń przez inne osoby. Najpierw dostajemy aplikacje z polecenia, a dopiero później sprawdzamy umiejętności techniczne.

KS: Tak, polecenia bardzo ułatwiają proces rekrutacji, bo zwykle oznaczają, że dana osoba jest sprawdzona. Pewne rzeczy, których nie wiesz i nie możesz sprawdzić, możesz w ten sposób ominąć. Na pewno daje się większy kredyt zaufania takiej osobie. To, że jestem w USA jest zasługą LinkedIna, wszystkie moje rekrutacje są zasługą LinkedIna. Umiejętność stworzenia odpowiedniego profilu jest ważna i pewnie są osoby, które zarabiają na tym, jak stworzyć dobry profil.

PN: Pytanie zarówno do Ciebie Karolu, jak i do Ciebie Michale: jak jest w takiej dużej firmie z projektami? Jakie wymagania macie na starcie, kiedy co macie robić i na kiedy to ma być skończone? Karol już mniej więcej o tym powiedziałeś, ale jakbyś mógł powiedzieć nieco więcej jak wygląda Twoja codzienna praca nad nowym tematem.

KS: Projekty są długoterminowe. Można powiedzieć, że w pewnym sensie są to podprojekty, jakieś tam mniejsze rzeczy, które robi się w ramach dużego projektu. To zwykle produkty, zresztą VMware jest nastawiony na tworzenie produktów oprogramowania, które potem sprzedaje w modelu licencyjnym. Teraz bardziej przechodzą na SaaS, czyli Software as a Service. Ale w dużej mierze jest to wciąż software, który użytkownik ściąga, instaluje licencję i go używa. Trochę jak Windows.

Takie projekty długo żyją i firmy raczej nastawiają się na to, że jeżeli już inwestują w jakieś planowanie, to chcą żeby ten support trwał długo. Mój dzień wygląda zwykle tak, że zaczynam go od stand upu, na którym mówimy, co robiliśmy wczoraj, co będziemy robić dzisiaj, i to co będę robił dzisiaj jest w dużej mierze zależne ode mnie. Są ustalone rzeczy, które musimy zrobić, ale nie ma czegoś takiego, że coś jest absolutnie przypisane do mnie. Mogę pójść do kolegi i powiedzieć, że to zadanie pasuje bardziej do Ciebie. Ważna jest komunikacja, wiadomo, że trzeba trochę się lubić, żeby tak wymieniać się zadaniami. Pewne priorytety są ustalone przez naszego managera, to jest ustalone, co kto robi. Natomiast w dużej mierze jest to zależne od nas.

Już jakiś czas pracuję w tej firmie i mam kredyt zaufania od innych osób, toteż mogę sobie pozwolić na wybór tego, co robię. Inne osoby wiedzą, że wiem, co jest ważne, a jeśli nie będę wiedział, to zapytam. Zaufanie jest bardzo ważne. To pozwala na to, że mogę zaplanować pracę po swojemu. Jest taki fajny program w VMwarze, większość firm już tak robi, że masz możliwość podjęcia innego projektu (u nas to się nazywa take three) – bierzesz sobie trze miesiące, gdzie pracujesz nad innym projektem i możesz to zrobić raz do roku. Możesz w ten sposób nauczyć się czegoś nowego, zebrać siły, zmienić temat, itd.

MM: Ja też coś dorzucę. Niektórych to śmieszy, ale ja swój dzień kończę od stand upu, w USa z ludźmi, z którymi współpracuję, bo oni dopiero wstają, kiedy ja kończę pracę. Ciekawostka odnośnie pracy u nas: wymagania spływają z góry od klientów, i bardzo często jest problem z przepływem informacji między pracownikami. Im więcej nas pracuje, a już pracuje nas całkiem sporo, to fajnie jeżeli wiemy, jak najwięcej o produkcie, bo w razie jak gdyby ktoś się zwolnił albo zachorował, to ktoś inny musi przejąć jego zadania. O ile nas jakiś termin bardzo nie goni, to mamy taką zasadę, że dajmy na to w zespole jest 5 osób, to naraz jakby in progress mogą być tylko 4 zadania. Jedna osoba zostaje bez zadania. I co z tą osobą? Musi się z kimś sparować, zrobić pair programming i w ten sposób wymuszamy przekazywanie wiedzy. Im dłużej to stosujemy, tym bardziej to doceniam. Nauczyłem się bardzo dużo o produktach, z którymi wcześniej nie miałem styczności. Jeżeli ktoś ma taką możliwość, polecam tak robić.

KS: To mi się bardzo podoba z tego względu, pamiętam z jakiegoś szkolenia praktykę, że taka osoba też jest desygnowana do wszelkich przerwań. W sensie, jest jakaś awaria i jeżeli jest taka potrzeba, to osoba, która jest „nieprzypisana” w danym tygodniu do zadania, zajmuje się awarią. Bardzo mi się to podoba, choć nigdy mi się to nie zdarzyło.

PN: Bardzo fajne porównanie. Będę przechodził do pytań od widzów, bo pojawiło się ich trochę. Padło pytanie, jak wygląda u Was codereview.

KS: Michał, może Ty zacznij.

MM: Jasne, bardzo chętnie, bo codereviw to jest trochę mój konik. W każdej firmie, do której trafiam staram się wymuszać, żebyśmy robili sonie codereview. Szczęśliwie w firmie, w której obecnie pracuję jest codereview. Mamy taką zasadę, że co najmniej dwie osoby muszą przejrzeć kod, który tafia do repozytorium, więc każda zmiana trafia tam po przejrzeniu. Tak u nas wygląda codereview i to się sprawdza.

KS: Czego używacie do review?

MM: GitHuba.

KS: Jasne. U mnie to wygląda tak, że w pierwszym projekcie openstackowym używaliśmy Gerrita i na początku byłem przerażony, bo narzędzie wyglądało, jak z poprzedniego wieku, ale po czasie bardzo je chwalę. Teraz używamy GitLaba, przez chwilę używaliśmy GitHuba i generalnie to jednak nie jest ten sam poziom tego, co można osiągnąć w Gerricie. Każda zmiana musi przejść zatwierdzenie od CI, czyli musi dostać +1 od testów, czyli odpalamy różnorakie testy i te testy muszą przejść, żeby zmiana weszła do projektu. Oczywiście ktoś musi to przejrzeć.

Zwykle było tak, że był jakieś core reviewers dla danego komponentu i minimalnie jeden albo dwa głosy od nich były wymagane, żeby zatwierdzić zmianę, plus inni mogli dawać +2. 2 razy + 2 od tych osób oraz dodatkowo każdy mógł swoje komentarze zgłosić +1/-1, w zależności od tego, czy ktoś się bardziej znał czy mniej. Zwykle tych głosów było więcej. Gerrit zdecydowanie polecam.

---

Trzecią część tego livestreamu opublikujemy w przyszłym tygodniu, ale już teraz możecie obejrzeć całość w poniższym materiale.