Rekrutacja techniczna dla DevOps-a

Transkrypcja

Dziś moim gościem jest Wojciech Lepczyński. Wojtek, opowie nam o rekrutacji technicznej na stanowisko DevOps-a. Wojtku, dziękuję, że przyjechałeś w moje zaproszenie na rozmowę.

Cześć, witam wszystkich, słuchajcie bardzo serdecznie i dziękuję za kolejne zaproszenie. Super, że możemy sobie znowu pogadać.

Jak dobrze liczę to już nasz trzeci odcinek. Jest pewnie spora część osób, która Cię zna, ale zacznijmy standardowo. Proszę, powiedz nam coś więcej o sobie i co łączy Cię z branżą IT?

Witam wszystkich jeszcze raz bardzo serdecznie, ja nazywam się Wojciech Lepczyński, cały czas pracuję jako DevOps w GFT. Pomagam tam tworzyć cyfrowy bank w chmurze dla klienta z Azji. Taki bank bez fizycznych biur, budynków, który funkcjonuje w 100% w przestrzeni cyfrowej. Bank już powstał jakiś czas temu, teraz zajmujemy się jego udoskonalaniem i dodawaniem kolejnych funkcji.

W IT pracuję już ponad 12 lat. Byłem już administratorem, trochę architektem i konsultantem chmurowym, teraz głównie jestem DevOps-em. Najbardziej lubię pracować z chmurą, z którą mam bliższą znajomość od jakichś 7 lat. Można powiedzieć, że jestem pasjonatem chmury, mam kilka certyfikatów potwierdzających wiedzę w różnych chmurach. Aktualnie najwięcej pracuję z chmurą od AWS. Dzielę się swoją wiedzą dotyczącą chmury, prowadzę swój blog i kanał na YouTube z różnymi tutorialami i poradami. Zainteresowanych zapraszam do odwiedzenia.

No dobrze, czas powiedzieć: kim jest DevOps i czym zajmuje się na co dzień?

OK, ja jestem DevOps-em, ale nie każdy DevOps zajmuje się tym samym. Słowo DevOps powstało od połączenia angielskich słów development i operations. Mówi o współpracy pomiędzy działami wytwarzania oprogramowania (development) i zarządzania systemami (operations), ale to dotyczy bardziej metodologii i filozofii podejścia.

Zazwyczaj ludzie mówiąc DevOps, nie mają na myśli filozofii, a tylko właśnie konkretną rolę DevOps inżyniera. Kiedyś było się developerem albo administratorem, dzisiaj można być kimś pomiędzy, osobą łączącą te dwa obszary. Ja głównie zajmuję się automatyzacją, infrastrukturą jako kodem. Daleko mi do programisty, ale z kodem też mam trochę do czynienia. Większość mojego czasu zajmuję się infrastrukturą i automatyzacją. 

Często zajmuję się rozmową z ludźmi i rozwiązywaniem problemów. Zazwyczaj nikt nie mówi mi, jak ma być coś zrobione. Jest do rozwiązania problem, albo jakaś nowa funkcjonalność do zbudowania, ja wybieram najlepszy sposób realizacji. Czasem sam, czasem z zespołem.

Lubiłem pytać dlaczego ma coś być zrobione i potem wybierać najlepszy sposób na wykonanie tego. Nie wiem, czy każdy tak ma, ale ja tak mam i miałem tak jeszcze zanim zacząłem być DevOps-em. Często jest tak, że ludzie mówią o jednym, a chcą dostać zupełnie coś innego. Dlatego ważna jest rozmowa z ludźmi i zrozumienie tego, czego oni potrzebują.

Kto może startować na DevOps-a? Powiedziałeś, że jest to coś pomiędzy programistą a administratorem, czy trzeba wywodzić się z którejś z tych grup? Czy może to być osoba, która chce się przebranżowić lub świeżo po studiach, nie mająca doświadczenia w tych dziedzinach?

Wg mnie jak najbardziej. Fajnie, jak masz jakieś doświadczenie albo od strony administracyjnej, albo od programistycznej. Na pewno taka osoba nie może się bać zmian. Musi lubić cały czas się uczyć i poznawać nowe rzeczy, ale w naszej branży to chyba każdy musi. Bardzo często jest tak, że DevOps-ami stają się ludzie, którzy byli wcześniej adminami, tak jak ja, albo developerami, jak duża część moich kolegów.

Zdarzają się też ludzie z innych branż, jak wspomniałeś, albo po prostu po studiach. Czeka ich trochę więcej pracy, bo pewien background wiedzy technicznej jest wymagany.

Czy zanim przejdziemy do etapu rozmowy technicznej, dostajemy jakieś zadanie do wykonania w domu, jak często bywa przy rekrutacji na programistę? Sam wspomniałeś, każdy może przyjść z innym backgroundem, więc jak taką osobę sprawdzić?

Wg mnie raczej rzadko się to zdarza. Tutaj mogę mówić bardziej o sobie, jak ja przeprowadzam rozmowy techniczne albo ludzie, z którymi ja miałem kontakt. Nie zapewnię Cię, że nigdy tak się nie stanie, ale z mojego punktu widzenia, zwłaszcza w czasach chat GPT, dawanie ludziom zadań do zrobienia w domu byłoby bezcelowe.

No dobrze, to powiedz nam w takim razie, kto najczęściej przeprowadza rozmowy techniczną na DevOps-a?

Zapewne Cię nie zaskoczę, bo zazwyczaj jest to inny DevOps albo dwóch, takich z większym doświadczeniem. Na wysokie stanowiska zazwyczaj bierze udział w rekrutacji więcej niż jedna osoba, odpowiednia liczba to dwie, może trzy. Dużo zależy tutaj od firmy i od jej podejścia. Zazwyczaj taka rozmowa to nic strasznego, nikt tam na nikogo kogo nie krzyczy i nie wymaga nie wiadomo czego. Zacznijmy od tego, że jest to przede wszystkim rozmowa.

Czy rozmowa techniczna online i offline znacząco się od siebie różnią?

Ja pracuję zdalnie i od kilku lat przeprowadzam tylko rozmowy online. Przeprowadzałem rozmowy kwalifikacyjne z ludźmi z różnych krajów, nie tylko z Polski. Zazwyczaj ludzie chcą pracować zdalnie, nawet jeśli mieszkają w tym samym mieście, w którym jest siedziba firmy, nie wspominając już o pracy z innego kraju.

Wydaje mi się, że dużo tutaj zależy od stanowiska, ale wg mnie DevOps może pracować z dowolnego miejsca na Ziemi, jeśli ma odpowiedni sprzęt, dobry internet i jeśli firma na to pozwoli. Czy jest to dobre czy nie? No to już temat chyba na inną rozmowę.

Może jeszcze do tego dojdziemy następnym razem. A teraz chciałbym się ciebie zapytać, co warto sobie przygotować, by rozmowa online przebiegała sprawnie?

Przyda się dobre łącze internetowe, porządne słuchawki z mikrofonem, kamerka, wystarczy taka z laptopa i ciche miejsce, tak żeby można było spokojnie, swobodnie porozmawiać. Dobrym pomysłem będzie szklanka wody albo coś do picia. Jak się dużo mówi, to czasem zaschnie w gardle, więc fajnie jest mieć coś do picia. No i taki mały trik jeszcze, jak chcesz się dłużej zastanowić nad odpowiedzią, to możesz to zrobić właśnie podczas picia wody. 

To może jeszcze taka szklanka ze słomką, żeby to dłużej trwało.

Jak już tak mamy takie rzeczy mniej techniczne za sobą, to czas na pytanie: o co pyta się DevOps-a podczas rekrutacji technicznej? Jakie zadania otrzymuje?

Tutaj dużo zależy od tego, czy ktoś chce być juniorem, midem czy seniorem. Podstawy każdy powinien znać, jednak dla mnie rozmowa kwalifikacyjna o pracę to przede wszystkim rozmowa, a nie test.

Ja na początku zaczynam jakimś small talk-iem, ja mówię kilka słów o sobie i proszę kandydata, żeby też powiedział coś o sobie. Gdzie pracował wcześniej, nad jakimi projektami, czym się zajmował, jak duże ma doświadczenie itp. Potem przechodzę do konkretów, czyli do tego, po co tu przyszliście.

Zazwyczaj rekruterzy techniczni zadają dwa typy pytań. Pierwszy, w którym Ty o czymś opowiadasz, np.: powiedz, co to jest Container Registry, a Ty opowiadasz: to miejsce do przechowywania obrazów, kontenerów itd.

Drugi typ pytań, to taki w którym rekruter pyta się, jak rozwiązać jakiś problem, czyli przedstawia pewną w historię, sytuację i prosi, żebyś powiedział: co byś zrobił, żeby rozwiązać ten problem? Tutaj chodzi o sposób myślenia. Na takie pytanie może być wiele prawidłowych odpowiedzi.

To może tu zapytam o te prawidłowe odpowiedzi. Wiadomo, że w Twojej branży jest tak, że rozwiązując zadanie, czasem trafimy na miejsce, w którym musimy się cofnąć. Czy od razu oceniasz, że ktoś źle odpowiedział, kiedy się tak „zapętlił”, czy go podpytujesz o kolejne rzeczy i dajesz mu możliwość wybrnięcia z tej złej odpowiedzi, a może uznajesz, że taka osoba już powinna na tym etapie to wiedzieć?

Dla mnie liczy się sposób myślenia. Jeśli ktoś dobrze kombinuje, to jest OK. Nie chodzi tutaj o to, by znać odpowiedzi na wszystkie pytania. Ja podczas rozmowy staram się nakierować kandydata na prawidłową odpowiedź. Przez to pytam: a co jeszcze można by zrobić? Czasem można czegoś zapomnieć. Dla mnie nie jest to taki zero-jedynkowy proces, lubię pytać: a co się stanie, jeśli? Często, żeby odpowiedzieć na takie pytanie, potrzebne jest doświadczenie. 

Nie musisz znać wszystkich technologii i wszystkich aplikacji, bo nikt przecież nie wie wszystkiego. Np. jeśli kandydat zna Jenkinsa, to nie będę się upierał, żeby powiedział, jak używać GitLab'a. Jeśli umie rozwiązać problem za pomocą narzędzi, które zna, to dla mnie jest super wiadomość, nowych zawsze można się nauczyć. Przestawienie się na inny system nie jest takie trudne. Ważne, żeby znać zasadę działania. 

Możesz spodziewać się pytań z kilku kategorii. Jest kilka obszarów technicznych, z których ja chcę poznać wiedzę kandydata. Na pewno system kontroli wersji (dużo się z nim pracuje), konteneryzacja, automatyzacja (całe CI/CD), wiedza ze znajomości serwerów, sieci oraz mój ulubiony temat: chmura i infrastruktura jako kod. Tak jak mówiłem, nikt nie wie wszystkiego. Z jednego obszaru jesteś silniejszy, z innego jesteś słabszy. 

Muszę jeszcze dodać, że rozmowy są zazwyczaj prowadzone w języku angielskim, więc kandydat powinien rozumieć zadawane pytania i umieć na nie odpowiedzieć w zrozumiały sposób. Nawet jeśli nie będzie miał kontaktu z klientem, to i tak będzie codziennie kontaktował się z zespołem. Zespoły w dzisiejszych czasach często składają się z ludzi z różnych krajów, a sprawna komunikacja i zrozumienie, co trzeba zrobić, jest bardzo ważne.

Jak opowiadałeś te wszystkie rzeczy, przyszło mi do głowy takie pytanie: czy zdarzyło Ci się brać udział albo słyszałeś o takiej rekrutacji, gdzie ktoś od razu został zdyskwalifikowany, bo czegoś nie wiedział albo tak popłynął, że nie było dla niego miejsca? Czy przypominają Ci się takie sytuacje?

Od razu to może nie, bo zazwyczaj daje się kilka szans, jak nie z tego obszaru to może z innego. Zdarzyło się kilku takich kandydatów, którzy zaczęli mówić takie troszkę dziwne rzeczy. Nie powiem, że od razu zostali zdyskwalifikowani, bo tak nie było, ale są takie punkty, do których warto się przygotować. Potem wychodzi, czy wiesz, czy nie wiesz i jeśli nie wiesz, to lepiej tak powiedzieć niż zmyślać.

OK, a możesz nam podać konkretny przykład? Żeby wiedzieć, z czego na pewno powinniśmy się przygotować.

Podam przykłady, kilku takich pytań, żebyśmy wiedzieli, o czym mówimy. Czy wiesz, jak działa site-to-site VPN, czy możesz coś o tym opowiedzieć? Czy możesz podzielić się nam swoim doświadczeniem dotyczącym technologii konteneryzacji, takich jak Docker czy Kubernetes? Albo wracając do systemu kontroli wersji, to często pojawia się pytanie: jakiego narzędzia używałeś? A potem następuje rozmowa dotycząca właśnie tego narzędzia.

Tak naprawdę takie pytania często wymyśla się na bieżąco i dostosowuje się do każdego kandydata w zależności od jego poprzedniej odpowiedzi. Podam Ci przykład. Gdy usłyszę, że kandydat miał do czynienia z Gitem, to mogę zadać pytanie: co się stanie, jeśli dwie osoby równocześnie edytują ten sam plik i próbują wypchnąć swoje zmiany? Odpowiedź: Git zasygnalizuje konflikt podczas próby wypchnięcia. No i teraz może być kolejne pytanie: jak można rozwiązać taki konflikt? Czy tacy ludzie umawiają się na pojedynek i ten kto wygra, tego zmiany są przepchnięte, czy jak to wygląda?

Pytania można tworzyć na bieżąco pod każdego kandydata. Ja staram się nie być tutaj sztywnym i prowadzić rozmowę na luzie, czasem zażartować, każdy ma swój styl. Ja wiem, że takie rozmowy bywają dość stresujące, same w sobie, więc staram się, by kandydat poczuł się jak najbardziej swobodnie.

Gdy widzisz, że ktoś ma spore pojęcie o czymś, to mu o tym po prostu mówisz i przechodzisz do kolejnej kategorii. Zazwyczaj czas bardzo szybko mija podczas takiej rozmowy, a sporo rzeczy jest do sprawdzenia, sporo tematów do poruszenia. Czasem, gdy ktoś ma sporą wiedzę i startuje np. na juniora, to zadaje trudniejsze pytania, bo może się okaże, że on tak naprawdę nadaje się na mida. Prawdę mówiąc, z juniorami to dawno nie rozmawiałem. Zazwyczaj to prowadzę techniczną część rozmowy o pracę z ludźmi, którzy szukają pracy jako senior DevOps.

Pytania mogą być naprawdę różne i różnie skonstruowane. Teraz w czasach chat GPT staram się zadawać mniej pytań typu: powiedz, co to jest? A więcej bardziej takich rozbudowanych: masz Kubernetesa z kontenerami, jeden z kontenerów po aktualizacji przestał działać. Jakie kroki podjąłbyś, aby znaleźć przyczynę tego problemu? Oczekiwałbym tutaj odpowiedzi: sprawdziłbym najpierw logi, aby znaleźć ewentualne błędy podczas uruchamiania, potem np. że użyłbym polecenia kubectl, describe itd.

Jak już wspomniałem nie spotkałem się z tym, żeby kandydat dostawał jakieś zadania do rozwiązania w domu. Moim zdaniem w czasach chata GPT byłoby to bez sensu. Rekruter by sobie robił niepotrzebnie robotę, a wiedzy kandydata i tak by w ten sposób nie sprawdził, bo mogłaby mu pomóc sztuczna inteligencja albo jakiś inny znajomy.

Już parę razy padły słowa: chat GPT. Uważasz, że chat GPT jest pomocny w Twojej pracy? Czy on faktycznie usprawnia proces, daje pomysły do rozwiązania problemu? Czy może do prostszych tak, ale do bardziej skomplikowanych rozwiązań raczej nie a wręcz utrudnia i sugeruje błędy tam, gdzie ich nie ma?

To jest narzędzie jak każde inne i wg mnie trzeba umieć z tego korzystać i robić to świadomie. W prostych rzeczach wydaje mi się, że jak najbardziej.

Czytałem kilka artykułów o tym, że ludzie uczą się razem z chatem GPT, że np. on tworzy im zadania do rozwiązania i w ten sposób nabywają wiedzę szybciej.

A czy spotkałeś się z tym, że firmy nie pozwalają korzystać z chata GPT, bo boją się, że jakieś dane wrażliwe wyciekną poza firmę?

Wydaje mi się, że tutaj chodzi bardziej o sposób używania narzędzi. Musisz być świadomy tego, jak ich używać i jaki wpływ mogą mieć Twoje działania na inne rzeczy.

OK, no dobra, to kontynuuj, bo Ci przerwałem myśl.

Na sam koniec, już po rozmowie kwalifikacyjne warto zastanowić się, co sprawiło Ci trudności i zacząć nad tym pracować. Gdy zadzwonią z rekrutacji i otrzymasz propozycję współpracy, to super, ale jeśli nie, no to wyciągnij wnioski. Zapytaj dlaczego, czy Twoja wiedza była niewystarczająca, czy jest konkretny obszar, nad którym powinieneś pracować, czy może był lepszy kandydat, a może był problem w komunikacji, albo nie pasowałbyś do zespołu. Powodów może być wiele. Taka wiedza jest bardzo cenna i może nakierować Cię na rzeczy, nad którymi powinieneś popracować.

Jeśli dopiero zaczynasz swoją przygodę, nie smuć się, jeśli na pierwszych rozmowach nie pójdzie tak, jak zakładałeś i popełniasz dużo błędów. Po prostu zrób to, co powiedział CEO Intela, Andy Grove: Make mistakes faster. Uczymy się na błędach, więc popełniaj ich więcej, zwłaszcza na początku, nie bój się tego.

Podpytam o Twoje doświadczenia albo Twoich znajomych, czy faktycznie firmy, w których brałeś udział w rekrutacji, one Ci odpowiadały? Udzielały konstruktywnego feedbacku, informując, co było nie tak? Czy spotkałeś się z brakiem informacji lub ogólnymi odpowiedziami, które nie przynosiły żadnej wartości? Czy widziałeś, że im większe masz umiejętności i doświadczenie, tym feedback był bardziej przydatny, czy to mocno zależy od firmy i poziom Twojej wiedzy nie jest tutaj istotny?

Myślę, że dużo jest uzależnione od firmy. Tak jak wspomniałeś, im mam większe doświadczenie, tym ten feedback częściej się pojawiał. Nie wiem, czy dlatego, że na wyższe stanowiska ludzie się bardziej przykładają przy rekrutacji, czy to zależy od firmy. Muszę powiedzieć, że ja nie zawsze otrzymywałem feedback, gdy byłem na takiej rozmowie jako kandydat.

OK, to już tak na koniec. Jaką książkę polecasz osobie, która chce skutecznie przejść rozmowę techniczną na stanowisko DevOps?

Może jakąś książkę o rozmowach o pracę? Nie wiem, nie znam takich książek. Wg mnie warto zainwestować w jakieś kursy, w wiedzę i doświadczenie. Tak jak wspomniałem wcześniej, dobrze jest popełniać błędy, żeby szybciej się uczyć. Ja też je popełniam, czasem o czymś zapominam. Wszyscy jesteśmy tylko ludźmi. Dla mnie nie jest istotne, czy znasz regułki i wszystko wiesz, tylko np. wiesz, gdzie możesz to znaleźć. Trzeba być zaradnym i oczywiście cały czas się uczyć. Jeśli nie będziesz wiedział o istnieniu nowych funkcjonalności, to na pewno ich nie użyjesz. Warto być na bieżąco.

No dobrze, to na koniec, gdzie możemy Cię, znaleźć w sieci? Jeżeli ktoś by chciał podpytać: jak zacząć albo jak dobrze wypaść na rekrutacji?

Łatwo mnie znajdziecie w social mediach np. na LinkedInie po wpisaniu: Wojciech Lepczyński, powinienem być na jednej z pierwszych pozycji. Mogę zaprosić na mój kanał na YouTube, tam nazwa kanału to uwaga: Wojciech Lepczynski, bez polskich znaków. Jak ktoś interesuje się chmurą, to zapraszam, wrzucam tam porady, tutoriale dotyczące chmury. Aktualnie skupiam się bardziej na AWS, ale o Azure też coś kiedyś dodawałem.

Zachęcam do odwiedzenia mojego bloga, głównie o chmurach, ale kilka porad o Kubernetesie, Terraformie też powinniście tam znaleźć. No i tu Was zaskoczę, wystarczy pisać tylko: lepczynski.it .Blog jest zarówno w języku polskim, jak i angielskim.

Super, bardzo Ci dziękuję Wojtku za dzisiejszy odcinek i przekazanie nam swojej wiedzy. Zapraszamy do Wojtka, jeżeli jesteście zainteresowani tematem i mam nadzieję, że to nasz nieostatni raz.

Dzięki za zaproszenie i za rozmowę. Pozdrawiam wszystkich słuchaczy, którzy wytrwali do końca. Jeszcze raz dzięki za rozmowę, jeśli będziesz chciał jeszcze kiedyś pogadać, wiesz gdzie mnie znaleźć. Pozdrawiam, pa.

Dzięki, hej.