Witam wszystkich, moi drodzy czytelnicy!
Dziś chciałbym podzielić się swoimi przemyśleniami na temat od dawna palącej kwestii i być może omówić ją w komentarzach.
Często natrafiam na artykuły dotyczące złych praktyk przeprowadzania rozmów kwalifikacyjnych na stanowisko programisty, które moim zdaniem są dosyć aktualne i mam nadzieję, że będą czytane przez działy HR w dużych i małych firmach.
W naszych stronach, o ile mogę ocenić, istnieje zapotrzebowanie na takie interesujące profesje, jak inżynier DevOps. Jestem osobą, która nie do końca pojmuje to sformułowanie (tak, tak, metodologia DevOps itd.), dlatego dostrzegam pewne różnice w ścieżkach rozwoju tej grupy specjalistów.
Przede wszystkim jestem przekonany, że każdy człowiek ma swoje własne zainteresowania, nawet w obszarze zawodowym, to znaczy dla jednych odpowiednie są chmury, inni wolą głębokie wnikanie w serwery aplikacji, konfigurowanie Java na głębokim poziomie, a niektórzy pisanie kodu w Pythonie lub, nie daj Boże, YAML. Więc pojawiają się tzw. inżynierowie infrastruktury, inżynierowie budowy, starsi deweloperzy YAML 🙂
Wszystko to pozwala z jednej strony znaleźć osobę maksymalnie odpowiednią do twojego zestawu zadań, a z drugiej strony tworzy nieporozumienia podczas rozmów kwalifikacyjnych.
Na podstawie własnego doświadczenia, przeszedłem przez kilkadziesiąt rozmów kwalifikacyjnych, a także uczestniczyłem w różnych rolach jako odpowiedź udzielająca, chciałbym podzielić się swoim spojrzeniem na to, co się dzieje.
Pierwszym, a chyba moim ulubionym antywzorem, jest pragnienie, aby ktoś robił wszystko, lub niezrozumienie, kto dokładnie jest potrzebny, zerkamy na wielu kandydatów, a potem to zrozumiemy. Prawdopodobnie ma to zastosowanie w każdej dziedzinie, ale tutaj są swoje szczególne cechy.
Jak zauważyłem, ludzie są bardziej zainteresowani ofertami pracy zawierającymi słowo DevOps niż Administratorem Systemu, chociaż moim zdaniem na poziomie seniora zakres zadań w tych dwóch obszarach znacznie się różni.
Każdy pracodawca, któremu naprawdę zależy na adminie, pisze w tytule oferty DevOps, wymieniając w treści prośby absolutnie wszystko, K8S/Java/gradle/oracleDB itd. w kolejności, chociaż osobiście osoba ma zająć się wsparciem klastra K8S i wsparciem stosu OracleDB z dala od zespołu.
A więc jakie jest tutaj współdziałanie w formacie Deweloperzy/Operacje?
Dalej okazuje się, że nie ma ustanowionego procesu współpracy z zespołem, a w ogóle nie ma działu operacyjnego, więc będziesz musiał także konfigurować komputery deweloperów.
Taki wariant w rzeczywistości pasuje części kandydatów, ale bądźmy szczerzy, to jest Senior System Administrator, więc dlaczego nie chcą tak pisać i co w tym wstydliwego? Różnica w wynagrodzeniu między różnymi nazwami zawodów? Budżet firmy jest jeden, a jak nazwiesz statek, tak popłynie on na swoim budżecie.
Słyszałem też, że teraz kandydaci szybko automatyzują wszystko i wlewają się w rozwój produktu w Pythonie, jaka różnica, wszędzie Python jest ten sam. Różnice w światopoglądzie i podejściu nie są brane pod uwagę.
Zwykle na tym etapie różnicuję poziom specjalistów, którzy przychodzą, i dla każdego widzę swoje problemy.
Junior — dla mnie osobiście Junior DevOps to osoba, która na średnim poziomie opanowała administrację / programowanie. Przyjemnie jest różnicować solidnych Linuxowców, którzy chcą rozwijać się w nowej dziedzinie, lub programistów, którym zależy na dobrymi rozwiązaniach dla innych programistów. Solidnych, z jakimiś umiejętnościami debugowania, szukania logów lub z jakimś zapasem kodowanych projektów.
Spotkałem zarówno administratorów, którzy spróbowali czegoś i chcą spróbować pracy w chmurze, jak i tych, którzy próbowali front-endu, back-endu i z jakichś powodów znaleźli interes w procesach DevOps.
Na tym poziomie zawsze niepokoi mnie, gdy zaczynają wymieniać ogromny stos technologii, Puppet, Ansible — dlaczego nie próbowałeś wszystkiego? K8S, K3S — czym się różnią? Ile rodzajów baz danych znasz? Dlaczego tak mało? Jak działa szyfrowanie w Javie? Szczególnie tych, którzy come z programowania, chociaż to bardzo cenne kadry, zawsze jest dla nich praca w tej dziedzinie.
Zawsze wprawia mnie w osłupienie, gdy się tak dzieje, pierwsze, co chcę zapytać — dlaczego??? Drugie, co przychodzi mi do głowy — czy sam interviewer jest gotowy odpowiedzieć na pytania dotyczące tak różnorodnego stosu? Czy naprawdę chcą wziąć juniora i obarczyć go wszystkim?
Często zdarza się to w różnego rodzaju bodyszopach, gdy trzeba sprzedać osobę do jakiegoś projektu i potrzebne są bardziej „fajerwerkowe” słowa do CV, albo firma nikogo nie chce zatrudniać, ale po prostu przegląda, jakie są dostępne juniory.
Poziom Middle
Moim zdaniem istnieją tutaj dwie skrajności. Po pierwsze, trudno określić, kiedy człowiek zbliża się do poziomu mid, ponieważ albo próbuje się go zredukować do poziomu juniora, albo zaczyna się nim bawić jak seniorem, próbując wydobyć seniora w cenie mid (tak, rynek decyduje, nic osobistego).
Najbardziej zaskakujące, co widziałem, to głębokie zanurzenie w kodowanie, programowanie w Pythonie, dręczenie Java GC, czyli poruszanie się w bardziej specyficznych tematach, lub wręcz przeciwnie, odkrywanie luk w dawno nieużywanych umiejętnościach, poruszanie się po sieciach, rodzajach sterowników systemu operacyjnego, z uśmiechem, myśląc jak ktoś mógł to zapomnieć. I tu wydarza się coś naprawdę interesującego!
Moim zdaniem na poziomie mid, specjalista kształtuje krąg swoich zainteresowań i osobisty punkt widzenia dotyczący tego, z czym chce pracować - podążać za najnowszym trendem technologicznym, wpędzając się w trudne projekty, lub rozwijać się w kierunku wymagających rozwiązań dla ogromnych przedsiębiorstw, zagłębiając się w wydajność kodu.
Myślę, że warto już teraz zapytać o procesy, którymi osoba się zajmowała, co było dla niej najbardziej interesujące, a co nie, i na podstawie tych informacji zbudować zestaw pytań, obowiązkowo mapując pytania na swój stak. W przeciwnym razie, prowadząc fascynującą rozmowę przez godzinę lub dwie na temat konfiguracji klastra OpenShift, zatrudniamy osobę, a następnie każe jej budować monitoring. Prawdopodobnie spodoba się to obu stronom.
Poziom Senior
O, mój ulubiony poziom.
Przed tobą doświadczony specjalista, który rozwijał się w różnorodnych projektach, człowiek, który już wie, czego chce, a czego tak bardzo nie lubi.
I tu zaczyna się show:
— trudne pytania dotyczące administracji systemami (patrz pierwszy antywzorzec)
— trudne pytania dotyczące Linuksa w ogóle, z obszaru teorii dalekiej od praktycznych umiejętności (Topowe pytanie o poziomy OSI)
— akademickie pytania dotyczące kodowania (bo sam interviewer nie zna się na obszarze, po prostu poproszono go o przeprowadzenie rozmowy z dziwnym devopsem)
Chciałbym tu dodać małą uwagę. Pewnego razu, na rozmowie kwalifikacyjnej poproszono mnie o napisanie jakiegoś kawałka kodu. Na kartce. Tak jak wszyscy lubią, piszą codziennie - kartka to wszystko.
Po zrealizowaniu zadania, po obejrzeniu mojego arkusza i rozwiązaniu, wydano werdykt, że algorytm będzie nieoptymalny. Zaproponowałem, żeby interviewer napisał swój algorytm, na co otrzymałem odpowiedź: „To nie wchodzi w ramy rozmowy kwalifikacyjnej”. Poprosiłem o chwilę, poprawiłem trochę kod i pokazałem, pytając, czy tak będzie szybciej czy wolniej? Na co otrzymałem odpowiedź, przejdźmy do następnego pytania. Różnica była w pracy kodu w pętli i bez pętli, a ja miałem przygotowaną odpowiedź, dlaczego lepiej zrobić to tak, a nie inaczej. No, po tym nie miałem już ochoty odpowiadać na pytania i pracować z tą osobą.
Należy uwzględnić, że wszyscy jesteśmy różni, a każda rzecz, która dla was jest nieistotna, może odstraszyć kandydata.
— zazwyczaj specjaliści na poziomie Senior mają dokładnie opisany stos technologiczny, ale nie, trzeba zacząć jeździć po podobnych. Na przykład, macie napisane Ansible, świetnie, a u nas Puppet, po prostu was zaprosiliśmy, więc opowiedzcie o Puppecie. Doskonale! Pracowaliście z OpenShift? U nas K8s, nie znamy różnic, ale wasze doświadczenie jest nieistotne. Wspaniale!
Jest jeszcze taki podklasa — osobiście biorę stażystów, aby wyrosnąć w juniorów.
Chciałbym, aby wszyscy rozumieli, że stażysta to jeszcze w ogóle niekształtna jednostka. Strasznie mnie przeraża, gdy stażystów zaczynają traktować jak solidnych juniorów, a potem, z zadowoloną miną, proponują staż (czasami nieopłacany, koszmar!)
Nie rób tak.
Stażysta, moim zdaniem, to albo student starszych lat, albo ktoś, kto bardzo chce „wejść do IT”.
Ze studentami wszystko jest proste — świetnie dowiedzieć się, czym zajmuje się na uniwersytecie, co robił sam, zobaczyć, na jakich pytaniach zapalą się oczy — jeśli się zapalą, zapytać, dlaczego akurat w DevOps i co o tym wiedzą. Poczuj człowieka i zrozum, czy będzie przyjemnie z nim dalej pracować, czy chce się uczyć czegokolwiek właśnie tej osoby.
Z tymi, którzy chcą „wejść do IT”, wszystko jest trochę surowsze — zobaczyć, jak bardzo osoba uczy się sama, co zrobiła przed tym, jak trafiła na rozmowę kwalifikacyjną, tu już dobrym rozwiązaniem będzie przejrzenie GitHub, jeśli jest, oczywiście, gęstość commitów i jakie były zrealizowane ćwiczenia. Zapytać także, dlaczego akurat DevOps, wszak w frontendzie jest weselej i bardziej pomysłowo?
Na koniec chciałbym ponownie doradzić, określcie, kto jest wam naprawdę potrzebny, a natychmiast znajdziecie właściwą osobę. Zidentyfikujcie potrzeby, spójrzcie na specjalistę jak na specjalistę, znajdźcie jego mocne strony i skutecznie wykorzystajcie je w swojej pracy. Bądźcie uważni na rozmówcę, przyszedł do was na rozmowę, a nie na zawody, kto kogo obleje lub nie obleje.
Źródło: habr.com
