��ѻ��ý

Karolina Prasałek
Cześć! Nazywam się Karolina i witajcie w podcaście Let’s Get Your Hired – podcast ��ѻ��ý, który przybliży Wam trochę świata rekrutacji i jest ze mną dzisiaj Michał. Witaj Michale, cześć. Mam do Ciebie takie pierwsze pytanie: Jak często uczestniczysz w rozmowach rekrutacyjnych jako ekspert?

Michał Pietrzak
To zależy. Zależy od ilości. Zależy od liczby rekrutacji, które mają miejsce w danym okresie. Liczba moich uczestnictw może się różnić. Czasami nie ma ich w ogóle. Natomiast są tygodnie, w których uczestniczę nawet do trzech takich sesji w ciągu jednego tygodnia.

Karolina Prasałek
Czyli dzisiejszy temat Tak naprawdę to są rozmowy i zadania techniczne i za chwilę sobie zgłębimy bardziej ten temat. 

INTRO
Let’s get you hired.
Rozmawiamy o procesie rekrutacyjnym w ��ѻ��ý.
Odkryj swoją przyszłość. Razem z nami.

Karolina Prasałek
Wracając do głównego tematu naszego odcinka. Jak wygląda rozmowa i rozwiązywanie zadania technicznego podczas rozmowy rekrutacyjnej w ��ѻ��ý?

Michał Pietrzak
Wyróżniłbym w sumie kilka etapów, ale jest jeden właściwy etap. Natomiast zacznę może od początku, że w zależności od działu proces ten może się nieznacznie różnić. W jednym z nich z tych działów może mieć miejsce taki rekruterski screening z kandydatem, podczas którego mogą paść pytania sprawdzające znajomość języka obcego. Albo ten etap może być przesunięty na tą rozmowę właściwą, czyli ten etap, nazwijmy go etapem drugim. Etap właściwy trwa około dwie godziny. Jest to rozmowa, w której uczestniczą dwie osoby zarówno SME, Subject Matter Expert, w danej dziedzinie, jak i osoba pełniąca rolę managera. Jako, że jest to ograniczona w czasie do 2 godzin rozmowa, jest ona również podzielona na pewnego rodzaju etapy. W pierwszej kolejności mamy do czynienia z prezentacją firmy, zaprezentowaniem projektów z jakimi mamy do czynienia, klientów, benefitów. Następnie przechodzimy do kolejnego etapu, który mniej więcej również trwa 15 minut. Są to pytania do CV, czyli pytania tak zwane miękkie, które pozwolą nam zapoznać się z kandydatem, z kandydatką. Jakie ma doświadczenie z jakich technologii korzystała, z jakich metodologii wytwarzania oprogramowania również z jakimi miała do czynienia.


Michał Pietrzak
Następnie przejdziemy płynnie na takiej rozmowie do tej części technicznej, która trwa około półtorej godziny. I tutaj mogą pojawić się oczywiście pytania teoretyczne, jak i ta część live codingowa. Można też ją troszeczkę nazwać pair programmingiem. Ale to myślę, że później wyjaśnię dlaczego. I po takiej rozmowie oczywiście udostępniamy, przekazujemy feedback, Niezależnie od tego, czy rozmowa przebiegła pozytywnie, czy negatywnie, feedback ten jest przekazywany w zależności od działu, ale przeważnie w ciągu dwóch tygodni. Oczywiście zdarza się, że jest to znacznie szybciej i może też wskazałbym, że przed naszymi rozmowami nie mamy zwyczaju przekazywania prośby o wykonanie jakichś dodatkowych zadań, czy czy wypełnienia jakiejś dodatkowej pracy. Czyli tutaj nie ma nakładu pracy przed rozmową rekrutacyjną. Całość dzieje się w ciągu tych dwóch godzin, kiedy musimy się zapoznać z kandydatem i kiedy mamy dla siebie czas.

Karolina Prasałek
Okej, czyli przechodząc do takiego pogłębiającego pytania: Jakie techniki mogą pomóc w radzeniu sobie z pytaniami właśnie w trakcie takiej technicznej rozmowy? Na co rekruterzy zwracają tak naprawdę uwagę?

Michał Pietrzak
Powiedziałbym: chłodna głowa.

Karolina Prasałek
Okej.

Michał Pietrzak
I rozbicie zadania na mniejsze części, czyli taka praca iteracyjna. W pierwszej kolejności może dostarczyć działający kod, ale spełniający minimalne wymagania, jakie zostały postawione, a dopiero w kolejnej fazie przejść do optymalizacji tego kodu, o ile jest na to czas. Mogą też pomóc przypadki czy obsługa przypadków brzegowych, tak żeby przemyśleć to, z czym mamy do czynienia, jakie są wymagania, Czy ja wiem wszystko? A czy może trzeba zadać jakieś dodatkowe, uzupełniające pytania rekruterowi, czy mnie jako SME na takiej rozmowie, aby wyjaśnić konkretnie co tutaj autor tego pytania ma na myśli.

Karolina Prasałek
Czyli można tak naprawdę tutaj podpytywać?

Michał Pietrzak
Jest to wręcz wymagane, bo nawet w rzeczywistych projektach nigdy nie dostajemy wszystkich wymagań na tacy. One pojawiają się dopiero jak będziemy o to pytać, czyli kiedy zwrócimy się czy to do stakeholdera, czy do klienta, czy do osoby, która te wymagania nam szczątkowe w pierwszej fazie szczątkowe wymagania przedstawi. Następnie my jako osoby techniczne. Musimy spojrzeć na to z punktu widzenia technicznego i dopytać o te szczegóły, których zazwyczaj brakuje. I to samo ma miejsce na rozmowie rekrutacyjnej. Pytania, które zadajemy, przeważnie są pytaniami ogólnymi, tak aby zachęcić i też sprawdzić, w jaki sposób kandydat bądź kandydatka podchodzą do rozwiązania takiego ogólnego zadania, które jest niepełne w pierwszej fazie.

Karolina Prasałek
Oczywiście jasne. A jeszcze jakieś dodatkowe rzeczy, na które zwracacie uwagę podczas właśnie takiej rozmowy?

Michał Pietrzak
Na pewno jest to styl kodowania, czyli to, w jaki sposób zwracamy uwagę na dobre praktyki. No właśnie, wcześniej wymienioną obsługę przypadków brzegowych błędów, walidację danych wejściowych, na to, czy w ogóle Zwróćmy uwagę na przykład na napisanie nie tyle co unit testów testów jednostkowych, co na przykład pokrycie wejścia i wyjścia, żeby przedstawić to symbolicznie czy słownie. Czy wiemy czy w ogóle zakładamy, że na wejściu oczekujemy, że coś nam wejdzie i czy wiemy co ma być na wyjściu. Czyli co dana funkcja, klasa, cokolwiek ma poprzez przetworzenie tych danych, jak ma zareagować. Także myślę, że to są kluczowe aspekty związane z tym, co my jako rekruterzy oczekujemy, że się pojawi. Ale tak jak wspomniałem, te pytania…

Karolina Prasałek
A po takiej rozmowie rekrutacyjnej czy my jako rekruterzy zadajecie sobie pytanie?

Michał Pietrzak
Tak, pada jedno kluczowe pytanie które, które zawsze padnie z naszych ust już po rozmowie, czy już kiedy podejmujemy pewną decyzję na temat tego, czy rozmowa przebiegła pozytywnie, czy negatywnie. Podsumowując, zadajemy pytanie następujące: czy chcemy z tą osobą pracować w jednym projekcie. Czy ten vibe, który złapaliśmy jest na tyle pozytywny, ma pozytywny wydźwięk, że decyzja na szali, na wadze przeważy, że mimo jakiś możliwych nieścisłości, niedopowiedzeń czy braku wiedzy w jakimś mniejszym aspekcie, obszarze, rozmowa koniec końców jej wynik jest pozytywny i że my faktycznie z tą osobą widzimy się w jednym projekcie. Więc tak, to jest to pytanie kluczowe…

Karolina Prasałek
Czyli ten vibe, aspekt właśnie tej atmosfery też i i samej komunikacji, i tego, w jaki sposób osoba się prezentuje, jest tutaj niezwykle ważne.

Michał Pietrzak
Tak, mamy tylko i wyłącznie dwie godziny na zapoznanie się z kandydatem. To jest nasza zawsze pierwsza możliwość porozmawiania nie tyle co face to face. Niestety, ale rozmowy przeważnie do ��ѻ��ý mają miejsce online, ale jest to ten moment, kiedy jesteśmy w stanie z kandydatem porozmawiać i musimy zarówno my tak poprowadzić tę rozmowę, żeby kandydat się czuł swobodnie i pewnie. Ale też w sumie od kandydata oczekujemy dziś tego złapania, tego wspólnego stylu, toku rozumowania i rozmowy.

Karolina Prasałek
Okej, a jeżeli chodzi też jeszcze dalej o rozmowę rekrutacyjną. Jakie najczęstsze błędy pojawiają się albo zauważyłeś podczas właśnie live codingu?

Michał Pietrzak
To myślę, że brak biegłości tak naprawdę w praktycznym użyciu danej technologii czy języka. Czasami kandydat jest mocny w teorii gorzej to wygląda w praktyce, czyli widać, że brakuje mu jeszcze tej biegłości, tego doświadczenia w użyciu, tej konkretnej technologii. Może tutaj występować brak znajomości syntaksu, nawet jeżeli tutaj na przykład kandydat czy kandydatka używają kilku języków, czy to na przykład języka Javy, czy JavaScriptu równolegle jeden po stronie frontendu, drugi po stronie backendu. No, dochodzi czasami do sytuacji, że kandydaci nie są pewni, jak ta składnia powinna wyglądać, mimo że aplikują na stanowisko full stack developera. Oczywiście nie jest to coś, co z automatu przekreśla, natomiast jest pewnego rodzaju wskaźnikiem. Ukazuje nam, że. Że tutaj występuje nieznaczny brak takiej wiedzy praktycznej. Co jeszcze bym wymienił? To jest brak umiejętności doboru struktur, odpowiednich struktur danych czy odpowiedniego algorytmu do zadanego problemu również na wyższych poziomach. Oczekujemy, że kandydat będzie umiał już na przykład tę architekturę aplikacji zaprojektować, tą architekturę, Więc też mogą się pojawić problemy natury wiedzy z danego obszaru, który podlega przetestowaniu.

Karolina Prasałek
A jeszcze jakieś dodatkowe błędy zauważyłeś podczas rozmów rekrutacyjnych, niekoniecznie związanych z live codingiem?

Michał Pietrzak
Tak, wymieniłbym dwa główne takie ogólne błędy, z którymi najczęściej mamy do czynienia podczas rozmów rekrutacyjnych już w tej fazie technicznej. Że kandydaci mówiąc o swoim doświadczeniu, o tym, za co byli odpowiedzialni, wyrażają się w trzeciej osobie. Na przykład dostarczyliśmy, wdrożyliśmy coś, wykorzystywaliśmy taką, a nie inną technologię. Czyli mówimy tak naprawdę o tym, co zespół zrobił i nie do końca jestem w stanie jako rekruter oczywiście będę do tego dążyć, aby wyciągnąć tę informację, ale za co ten kandydat bądź kandydatka była odpowiedzialna? Czyli jaki jest zakres wiedzy i w praktycznym ujęciu danej osoby. Drugim z takich ogólnych błędów powiedziałbym, że dużo osób wybiera konkretną, jedną technologię, nie idąc szerzej, jakby nie nie chcąc poznać albo nie mając takiej możliwości czasami poznania całego procesu wytwarzania oprogramowania z DLC, czyli od procesu zbierania wymagań, gdzie tutaj mamy konieczność kontaktu z klientem, ze stakeholderem poprzez przygotowanie jakiś proof of concept, czyli tutaj projektowanie, faza projektowania designu aplikacji przez jego implementację, testowanie aż po wdrożenie na środowisko produkcyjne. Fajnie, gdyby tutaj kandydat bądź kandydatka mieli do czynienia z każdą z tych faz. Nie mówię być ekspertem zarówno z clouda, backendu, frontendu, testowania czy ogólnie z biznesu jako business analityk, ale być chociaż świadomym, że są pewnego rodzaju etapy i one w każdym projekcie się pojawiają. Troszeczkę inaczej mogą wyglądać. Natomiast nie da rady. Nie ma projektów, które nie będą posiadały każdego z tych etapów, niezależnie od metodologii, jaką projekt, w jakiej pracuje.

Karolina Prasałek
Podsumowując naszą dzisiejszą rozmowę w takim razie, bo powiedziałeś bardzo dużo na temat w ogóle rozmowy technicznej i tak jakbyś na sam koniec mógł powiedzieć, czy można w taki sprawdzony sposób przygotować się do rozmowy rekrutacyjnej. Tak króciutko.

Michał Pietrzak
Myślę, że to znowu zależy. Zależy od tego, jaką wiedzę dana osoba już posiada i czego jej brakuje, w czym się czuje jeszcze słabiej. Istnieje kilka metod, można użyć. Tutaj takich gotowych platform, które służą do przetestowania wiedzy w formie praktycznej, do rozwiązywania zadań technicznych. Code Signal, HackerRank i wiele innych. Myślę, że ten praktyczny aspekt również można ulepszyć poprzez po prostu pisanie własnych projektów, czyli powiększenie czy stworzenie swojego portfolio na GitHubie jest jedną z metod tego, żeby poczuć się pewniej w danej technologii. Również można symulować sobie oczywiście takie rozmowy we własnym zakresie, przeprowadzając ograniczonym w ograniczonym czasie na przykład jakieś zadania live coding owe przez siebie wymyślone. Taka ogólna rada – podejdź do tego jak najbardziej naturalnie, bez presji. Czyli można też hobbystycznie chodzić na rozmowy rekrutacyjne bez tej presji, co daje czasami pozytywny wydźwięk, bo nie ma nie czujemy tej konieczności, żeby poszło dobrze. Jeżeli pójdzie dobrze, to super, jeżeli nie trudno, idę dalej i będę próbować gdzieś indziej. Bądź jeszcze raz w tej samej firmie, po jakimś czasie, do czego zawsze zachęcamy.

Karolina Prasałek
Dziękuję Ci bardzo Michale za dzisiejszą rozmowę, a Wam dziękuję bardzo za słuchanie dzisiejszego odcinka podcastu Let’s Get You Hired.