Rekrutacja: Live coding. Gość: Łukasz Drynkowski - POIT 318

Witam w trzysta osiemnastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów dla kandydata jest live coding podczas rekrutacji.

Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.

Główne myśli o live coding z tego odcinka to:

• sens i cele stosowania live codingu w rekrutacji
• symulacja codziennej pracy zamiast egzaminu z wiedzy
• wpływ stresu i presji czasu na ocenę kandydata
• rozmowa o sposobie rozwiązywania problemów zamiast samego kodu
• ograniczenia oceny jakości programowania w krótkiej sesji
• algorytmy kontra zadania odzwierciedlające realny biznes
• różnice w podejściu do juniorów i seniorów
• oczekiwania firm produktowych i software house’ów
• pair programming, zadania domowe i code review jako alternatywy
• korzystanie z IDE, bibliotek, wyszukiwarek i AI podczas rekrutacji
• bezpieczeństwo pracy z obcym kodem i środowiskiem kandydata
• candidate experience, transparentność procesu i wartość feedbacku

Subskrypcja podcastu:

• zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
• poproszę Cię też o polubienie fanpage na Facebooku

Linki:

• Profil SOLID.Jobs na LinkedIn – https://www.linkedin.com/showcase/solid.jobs/
• SOLID.Jobs – https://solid.jobs/

Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/318

Transcript

Wprowadzenie Do Live Codingu\n

SPEAKER_01 0:00

To jest 318 odcinek podcast Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Stolid Jobs, który ma przyjemność współtworzyć, dyskutujemy o tematach związanych z rekrutacją z perspektywy kandydata. Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania odpalamy. Cześć Łukasz.

SPEAKER_00 0:23

Cześć Chrzytofa.

SPEAKER_01 0:24

Nasze kolejne spotkanie w ramach cyklu podcastów dla kandydata. Wcześniejszych odcinkach było trochę o tym, jak się do rozmowy przygotować, jak podejść do wysyłania cicli, czy te wszystkie kroki, które miejmy nadzieję, że macie już ze sobą mieści się, wam poszczęściło, to zostaliście zaproszeni na którąś z rozmów właśnie w ramach już procesu rekrutacyjnego. I na pewno jakimś tam etapem tej rozmowy, czy tych rozmów jest sprawdzenie waszej kompetencji technicznych, waszych skili, waszych umiejętności. Jedną z takich metod, jednym z takich sposobów, jak to zrobić jest kodowanie na żywo, czy taka sesja live codingu robiona bądź to stacjonarnie, bądź to online'owo, o tym jeszcze dzisiaj będzie mowa. No i oczywiście zależy kogoś zapytać, to różne jest podejście, różny jest centyment, można było powiedzieć, związany właśnie live codingiem. Jedni preferują, inni niekoniecznie, o tym też dzisiaj będzie mowa, ale żeby sobie gdzieś tam jakiś wspólny grunt, myślę pod rozmowę zbudować, to Łukasz może przejdźmy na początku przez to, żeby opisać i powiedzieć, po co właściwie live coding, jaki jest sens, jaki jest cel w ogóle korzystania z tej metody.

SPEAKER_00 1:46

Ja osobiście uważam, że nie da się kogoś zatrudnić, nie oglądając go jakby w pracy, w tym naturalnym środowisku. Jaką mamy w ogóle alternatywę do takiego live codingu? To alternatywa to jest coś, co ja nazywam zgadów Zgadula,

Po Co Sprawdzanie W Praktyce\n

SPEAKER_00 2:05

czyli przepytywanie kandydata z jakiejś losowych funkcji losowych, czy może mniej losowych jakiś ogólnych zasad. No ale to czy ktoś zna tą zasadę, czy jakby daną część frameworka, czy nie zna, czy to w jakiś sposób determinuje jego umiejętność tutaj w tym przypadku programowania jest to pewnie dyskusyjne. Żaden z nas nie jest encyklopedią. Czasami też bywa tak, że też wiemy, albo znamy pewne pojęcia pod trochę innymi nazwami, albo nie potrafimy skojarzyć, o co akurat rekruter pyta, także to też nie jest moim osobistym zdaniem dobra droga. Jakie jeszcze mamy alternatywy? Możemy od kandydata oczekiwać, że robi jakieś tak zwane zadanie domowe, czyli też coś w rodzaju takiej sesji kodingu, ale offline, czyli może zyskujemy to, że ten kandydat ten poziom jego stresu będzie trochę mniejszy, bo ktoś mu nie patrzy na ręce. No ale za to jest tutaj też duży opór z rynku, tak, od kandydatów. Ludzie po prostu nie chcą robić takich zadań offline, bo czują, że to jest jakaś strata czasu. Za długo to trwa. Też wydaje mi się, że firmy w złym miejscu procesu tego typu zadania umieszczają, bo często to jest tak, że to jest jakiś pierwszy etap, który ma za zadanie odciać tych kandydatów. Nikt jeszcze z tobą nawet nie porozmawiał tak face to face, a już si każą robić jakieś zadanie, no i potem często to jest tak, że ci ludzie robią te zadania, a niech się nawet do nich już nie odezwie i nie dostaną żadnego feedbacku. Także w ten sposób też już jest spalony, nazwijmy to na rynku pracy. No i tak, moim zdaniem nie ma dobrej alternatywy. Są jeszcze zadania typu, już zapomniałem, jak się nazywają takie strony? Tak, tak, tak. Właśnie, gdzie robi się zadania na przykład algorytmiczne. Ale to znowu, co sprawdzą? Sprawdza, czy ktoś na pamięć zna jakiegoś Quicksorta, czy tam Hip Sorta, czy inne jakieś tam algorytmy. No i też chyba nie na tym polega praca programisty, żeby to gdzieś tam zdać na pamięć. Pewnie fajnie jest, akurat wiadomo, że każdy z nas Quicksorta napisze bez problemu. Ale nie o to chodzi tak bardziej chodzi o to, żeby wiedzieć, kiedy zastosować, który rodzaj na przykład tego przysłowiowego sortowania, jakie są silne, czy słabe strony danego podejścia w danym kontekście. To jest to, co byśmy chcieli na tej rozmowie od programisty wydobyć, a nie to, czy on akurat na pamięć zna ten czy tamten algorytm.

SPEAKER_01 5:25

No tak, jeśli jesteś Googlem, to możesz właśnie tego typu egzaminy, że tak powiem, robić tak z algorytmiki, ponieważ na przykład zależy ci na tym, żeby ściągnąć osoby, które z tych algorytmów są bardzo dobre, które będą wymyślać jakieś tam sposoby rozwiązywania niebanalnych i nietóźnikowych problemów. Ale dla większości firm, gdzieś tam z takiego, nie wiem, rynku, może powiedzieć, tworzącego w miarę powtarzalny soft, no to nie do końca to będzie miało znaczenie, tak samo jak i tutaj, jak zaznaczyłeś to, czy potrafisz zaimplementować quick sorta, Bubble sorta, czy tam cokolwiek, bo nikt tego w rzeczywistości w realnej pracy nie będzie robił. Sorzystasz po prostu z metody, z jakiejś tam biblioteki i tyle. Więc tak jak tutaj zaznaczyłeś, myślisz, że to ma duży sens, żeby dobrać tę metodę weryfikacji kompetencji do tego, jak będzie wyglądała później praca na co dzień. No i tak też się zgodzę z tym, że nie ma pewnie idealnego sposobu. Każdy jest jakąś tam przybliżeniem, jest jakimś przybliżeniem, jakąś heurustyką, jakąś próbą, no nie wiem, zrozumienia, jakie ty tak naprawdę masz skile. Ja myślę sobie, że dużo lepsza byłaby, aczkolwiek dużo jest też problemów z taką logistyką tej metody, lepsza byłaby metoda polegająca na tym, że ty powiedzmy tam tydzień, dwa, trzy pracujesz, oczywiście tam za jakieś ustalone wynagrodzenie, i tak dalej. Wtedy można zobaczyć, jak takie stworzenie, jak programista się w naturze sprawdza. Natomiast wiadomo, że to jest oczywiście jakaś tam forma już inwestycji ze strony firmy i nie zawsze możliwa. Live coding jest pewnie taką opcją, żeby zobaczyć, jak to wygląda w miniaturze w tej godzinie czy tam 45 minutach, żeby zobaczyć, jak taka osoba faktycznie podchodzi do rozwiązywania problemu. I myślę, że tutaj taki jest cel. Zresztą nasza branża wcale nie jest jakoś tutaj specyficzna. De facto, gdyby spojrzeć na jakieś inne branże, tam też się po prostu testuje pracownika, sprawdza, jak wykonuje dane zadania, takie codzienne zadania

Stres Obserwacji I Jego Sens\n

SPEAKER_01 7:40

spotykane na co dzień. No i myślę, że tutaj też wypracowaliśmy właśnie w taki sposób, żeby to weryfikować bazując na live codingu. Ale pewnie też się ze mną zgodzisz, że wiele osób zarzuca tej metodzie jakiś niepotrzebny stres, który wywołuje, prawda?

SPEAKER_00 8:01

Tak, natomiast wydaje mi się, że programowanie dla nas, programistów, to jest ten chleb powszedni, ten nasz bread and butter, to, co umiemy robić, to, co lubimy robić przede wszystkim, to powinna być przyjemność, że możemy tutaj programować, jeszcze używając swojego komputera, swojego środowiska, swojego ide. Bibliotek, narzędzi wspomagających programowanie, o czym też jeszcze za chwilę. Fajnie, że robimy to i robimy to na komputerze, a nie na kartce albo na whiteboardzie. Bo ta rozmowa pracy, ona powinna rzeczywiście symulować realne jakieś zadanie, realną wycinek jakiś model tego, co normalnie byśmy robili w pracy. Gdybym zatrudniał pilota, to bym chciał zobaczyć jak lata. Jakbym zatrudniał osobę od marketingu, to bym chciał zobaczyć, czy umie stworzyć jakąś sztukę, nie wiem, broszury, postu na social media, czy tam nie wiem, co osoby od marketingu robią.

SPEAKER_01 9:14

Nokej, a co są według ciebie presją czasu, albo czymś takim, że widzisz, że ktoś patrzy, jak ty rozwiązujesz jakieś zadanie. Tak. I samo to rodzi jakiś tam stres, W jakąś tam presję.

SPEAKER_00 9:28

To jest zasada takta nieoznaczności, tak, że sama obserwacja w kwaś zmienia. Obieg obserwowany, tak. Myślę, że to musimy wziąć pod uwagę i po prostu na to mieć taki wewnętrzny, jak to ładnie powiedzieć, no to powiem nieładnie shift, także po prostu mieć to w głowie, że to nie będzie to samo, gdzieś tu są jakieś uproszczenia, właśnie też ten czas robi swoje. I też ja nie oczekuję jako osoba, która jest po drugiej stronie akurat stolika, to nie oczekuję, że. Albo inaczej, to, czy ktoś, rzeczywiście w te 45 minut przysłowiowe wykona to zadanie, czy nie, to jest gdzieś drugorzędne. Bardziej to, co mnie interesuje, to właśnie jak ta osoba podchodzi do problemu, jak korzysta z tych wszystkich narzędzi, czy dalej znowu tą anegdotę opowiem, którą już pewnie wszyscy słyszeli, którzy są tutaj naszymi słuchaczami stałymi, no to jeśli daje komuś CSV do sparsowania, to nie chcę, żeby ktoś po tym stringu jechał foryczem po każdym karze, i porównywał, szukał, gdzie jest średnik czy tam przecinek, tak. Jak widzę, że ktoś po prostu w ten sposób podchodzi do zadania, to już widać, że to jakby to nie jest ten mindset programisty.

SPEAKER_01 11:07

Nie wróży, tak. No właśnie, tutaj myślę sobie, że jednak ta osoba obserwatora w postaci prowadzącego, czy jakolwiek tam nazwać rekrutera, no jednak może mieć znaczenie, w sensie to zbudowanie atmosfery może wpłynąć na nasz rezultat jako kandydata, i tutaj myślę sobie, że jest też jakaś odpowiedzialność po stronie prowadzącego, żeby nie stawiał się w roli jakiegoś egzaminatora czy kogoś takiego. Tylko raczej właśnie osoby, która

Pair Programming Zamiast Egzaminu\n

SPEAKER_01 11:40

gdzieś towarzyszy, która być może naprowadza, która, nie wiem, jakoś ten stres gdzieś tam rozładowuje.

SPEAKER_00 11:47

To tutaj ja pierwszy taki hit bym chciał podać. Po pierwsze, potraktujmy to jako sesję per programmingu, czyli jest nas załóżmy dwóch, ten rekrutujący i rekrutowany, i potraktujmy to po prostu jako sesję takiego per programmingu, i razem twórzmy to coś, co jest do zrobienia. Natomiast może warto zacząć od tego, żeby odwrócić rolę, może to ten rekruter może na początku pisać trochę kodu i czekać na jakby on przejmuje klawiaturę, a osoba rekrutowana jest tą osobą, która w tym momencie jest podającym tutaj pomysły, czy mówiący co dodać, od czego zacząć. Więc to też myślę, że jest ciekawy pomysł, który by pozwolił też ten stres jakby zredukować i zacząć w tą stronę, a potem po tam 10 minutach odwrócić rolę.

SPEAKER_01 12:48

Ciekawe, ciekawe. Zupełnie może pytanie z innej beczki, ale z racji na to, że tutaj mamy do czynienia z jakąś taką relacją, przynajmniej dwóch osób, to czy według Ciebie live-coding w jakiś sposób można powiedzieć, faworyzuje albo daje lepsze rezultaty dla osób, które są bardziej gdzieś na skali ekstrawertycznej, powiedziałbym, tak, są ekstrawertykami bardziej niż introwertykami, bo na przykład, nie wiem, takie osoby będą w stanie się o coś dopytać, otworzyć, niejako uzyskać podpowiedź, pomoc ze strony prowadzącego.

SPEAKER_00 13:20

Ciekawe pytanie, Krzysztof. Jak to mówią w telewizji, dziękuję za to pytanie. Zarzyłeś o nie pewnie cały dzień tak. Z jednej strony wydaje mi się, że masz rację. Tak, to była twoja teze. Masz rację, że ta osoba ekstrawertyczna bym ja trochę łatwiej. A z drugiej strony jednak to jest pisanie kodu, więc może jednak to nie ma aż takiego znaczenia. Jeśli chcesz się jednak trochę bardziej zamknąć w tej swojej

Introwertyk Na Live Codingu\n

SPEAKER_00 13:55

skorupie, to po prostu rób swoje. Też jakby zatrudniamy programistę, tak, a nie wiem designera, to też to, co znaczy inaczej, to o czym mówimy, pewnie też ma sens dla, tak jak mówiłem, już designerów, testerów, analityków, tak, też jakby chcę zobaczyć sztukę jakiegoś artefaktu na koniec takiej rozmowy praktycznej. Natomiast jeśli mówimy tutaj w tym przypadku o programiście, no to też ja mam tutaj odpowiednią skalę do tego, co usłyszę i co tu się stanie. Też często w tych zadaniach są. Specjalnie pewne niejasności, czy pewne warunki brzegowe nie są do końca określone i też to są takie, może łapkę to jest złe słowo, ale oczekuję, że ktoś zapyta, zada jakieś konkretne pytania. Tak samo jak, jeśli to jest kod do napisania, to oczekuje, że ktoś, oprócz tego, że napisze kod, który coś zrobi, to napisze też jakieś testy, które sprawdzą czy to, co jest tworzone, działa tak. To są takie rzeczy, które są gdzieś tam niedopowiedziane, ale na które się zwraca uwagę. Też może zmieniając jeszcze trochę jakby ten ciąg, o narzędziach, może porozmawiaj.

SPEAKER_01 15:37

Ja bym może dorzucił to jeszcze jedną myśl do tego wątku, żeby nie uciekła. Wiesz, bo ja w mojej opinii live coding jest bardziej o badaniu potencjału niż jakimś konkretnym artefakcie, który powinien powstać w wyniku takiego live codingu. Bo dużo rzeczy może tam pójść. Nie to, że nie tak, ale w różnych kierunkach. Natomiast to właśnie o co kandydat dopytuje, nie wiem, w jaki sposób myśli, jakie tam ścieżki obiera, jakie rozwiązania odrzuca, myślę, że to jest nawet istotniejsze niż to, żeby na końcu powstał jakiś kawałek kodu, który mniej lub bardziej się kompiluje i coś tam Hello World na ekranie wyświetla.

SPEAKER_00 16:17

Powiem Ci nawet więcej, nawet jakbym dostał taki kod, który jest kompletnie do banii i wygląda kiepsko robi co prawda to, co miało robić, ale teraz, by ten ktoś powiedział, że no, to zrobiłem źle, to zrobiłem źle, to zrobiłem. Jestem super niezadowolony za mało czasu, to bym wolał ten kod, który źle zrobiony, ale ktoś mi powiedział 20 rzeczy, które by chciał poprawić, i on wie, że to trzeba poprawić, niż kogoś, kto jest z siebie zadowolony, bo działa.

SPEAKER_01 16:44

Tak, i powiem ci, że uczestniczyłem kiedyś w takiej rekrutacji właśnie startup amerykański, więc gdyby bardzo im bliskie było właśnie takie podejście do badania kompetencji w postaci live codingu. Wiadomo, że oni tam dużo przy tym gadają, i tak dalej, jak to Amerykanie. Zupełnie na koniec nie uzyskałem działającego niczego. W sensie to, że ten sposób ani się nie kompilowało, ani nic nie generowało, i tak dalej. A rekruter, który gdzieś tam miał ze mną tą sesję, nazwijmy to w ten sposób godzinną, był mega zadowolony, ponieważ chodziło mu dużo bardziej o to, żeby właśnie wyłapać te sposoby myślenia, odrzucania, jakichś tam rozwiązań, skupiania się na najistotniejszych elementach, tak. I myślę sobie, że to 45 minut godzina, zależy, jak ta sesja lekwidingu trwa, no tutaj bardzo trudno byłoby oczekiwać, że na koniec mam być coś, co jest, nie wiem, właśnie możliwe do wdrożenia na produkcji. To raczej chodzi o zbadanie sposobu myślenia według mnie. Ale też kilka razy spotkałem się z czymś takim, że nie ma jasno powiedziane, jakie jest oczekiwanie, tak? I domyślnie, jako programista uczestniczący takiej rekrutacji, ty wyobraszasz sobie i chcesz coś dostarczyć, bo tak wygląda Twoja Twoja praca i skupiasz się na tym, żeby to faktycznie coś tam było, co jeszcze bardziej gdzieś tam napędza taką spiralę stresu. No bo wiadomo, że godzina to jest mało, to jest mega mało. Widzisz, że zegar tyka, ty nie masz niczego, co by cię tam przybliżało do tego działającego rozwiązania. Stresujesz się i Twoje logiczne myślenie się wyłącza. Więc chodzi mi o to, żeby jasno też postawić oczekiwania, co jest oczekiwane z takiej rozmowy, podczas tej rozmowy, a co nie jest. Bo myślę, że to dużo bardziej pozwoli rozładować ten stres i napięcie.

SPEAKER_00 18:40

Tak, no natomiast powiedzmy sobie szczerze, że też to, jak ktoś sobie radzi pod wpływem stresu, to też jest cenną informacją, też bywają błędy na produkcji, krytyczna funkcja nie działa. I teraz pytanie, czy ktoś będzie umiał teraz chłodno podejść, zdebagować, wdrożyć poprawkę, czy spanikuje i będzie bezradny, tak. Też jakby praca to też jest

Jakie Zadania Mają Sens\n

SPEAKER_00 19:10

stres. To nie jest tak, że wszyscy pracujemy sobie wesoło w tych korpo, i tam nikt za nic nie odpowiada. Albo tak, tak, wszyscy odpowiadają, czyli nikt. Tak, tak.

SPEAKER_01 19:23

Pan odpowiada, pani odpowiada tak. Jasne, jasne. No dobra, no to skoro wiemy już więcej, jak to może wyglądać, to co według Ciebie powinno być treścią takiego zadania, bo takiego problemu postawionemu postawionego kandydatowi, tak? Czy bardziej właśnie napisz mi tam Quick Sta, czy bardziej, no nie wiem, rozwiązasz jakiś problem biznesowy.

SPEAKER_00 19:46

To musi być coś. Ja ogólnie też jako ciekawostkę, to u mnie zawsze te zadania to są takie real life, coś, co kiedyś albo poszło nie tak, albo coś. Spotkałem po prostu na swojej drodze programistycznej. I z tego właśnie robię takie zadania, takie fragmenty smaczki na rozmowę kwalifikacyjną. I właśnie o to chodzi, żeby w jak największym stopniu zesymulować to prawdziwe życie. Też może próbuję tak skierować tą rozmowę na narzędzia, to może trochę teraz w tym kierunku, no to też uważam, że zakres narzędzi powinien być jak najbardziej dostęp do internetu, do dokumentacji tak, jakbyś po prostu miał dostarczyć funkcję w normalnej pracy. Jeśli w normalnej pracy korzystasz ze Stack Overflow, no to czemu na tej rozmowie kwalifikacyjnej byś miał nie skorzystać z tego zoverflow? Nie czynij to ciebie gorszym, tak, no wszyscy korzystamy ze Stack Overflow, albo dopóki AI nie nadeszło. Zwykliśmy, byliśmy. Tak. No to jeśli już doszliśmy tutaj do tego słonia w składzie porcelany, to Krzysztofie, a jakie jest Twoje zdanie na temat narzędzi AI i ich użycia w trakcie właśnie takiej sesji live codingu?

SPEAKER_01 21:31

Tak, wiesz, ja myślę, że programiści dzielą się na dwie grupy. Ci, którzy za zgodą pracodawcy korzystają z AI i ci, którzy korzystają z AI bez wiedzy, pracodawcy, tym niemniej praktycznie każdy w jakiś sposób z tego korzysta, więc to chyba byłaby trochę głupota, gdybyśmy oczekiwali, że podczas live codingu, które to ma nas przybliżyć do realnej

Internet Stack Overflow I AI\n

SPEAKER_01 21:55

pracy, my takich narzędzi gdzieś tam zabraniamy. Natomiast pewnie ważne by Był albo warto byłoby spojrzeć, w jaki sposób ta osoba korzysta na przykład z narzędzi AI. Myślę, że to tutaj jest kwestia do rozegrania i do ustalenia, a nie to, czy te narzędzia są dostępne, czy nie. Bo to, jakie doświadczenie my mamy, o co pytamy, jak promtujemy, to już jest sztuka sama w sobie, która może być badana właśnie, czy sprawdzana podczas live-codingu, a jeśli ty, przepisz zadanie, tak do Chata GPT i piszesz, tak, rozwiąz ten problem, no to niekoniecznie świadczy o tobie, ale jeśli zapytasz o żeby ten problem został, nie wiem, przeanalizowany dla ciebie, o co powinieneś zapytać, o co może dopytać, jakie są, jakieś luki bezpieczeństwa, itd, i tak dalej, no to według mnie to tym bardziej świadczy, że ty wiesz w ogóle, jak wygląda taki cykl wytwarzania, oprogramowania i jest jak najbardziej na plus, więc ja absolutnie uważam, że wszystko to, co normalnie jest dostępne dla Ciebie jako programisty na co dzień, powinno być też dostępne podczas sesji Live-Codingu.

SPEAKER_00 23:10

I tu się kompletnie zgadzamy. Też uważam, że wszelkie narzędzia, w tym AI powinny być częścią tej rozmowy rekrutacyjnej i ja nie widzę żadnego powodu, żeby coś sztucznie ograniczać. No i też, jeśli ktoś by miał mi dostarczyć to zadanie, które normalnie trwa 45 minut 5, a potem się spytać, no i co robimy dalej, to może też byłoby OK. Ty tak powiedziałeś, że całego zadania nie wrzucić. No to pewnie nie, ale jakby ktoś tak zrobił, i potem nie wiem, dostarczył mi jeszcze do tego, chciałem rower, a dostałbym rakietę. Testy, jakieś inne, cudanie widy, może zrobiłoby to wrażenie.

SPEAKER_01 23:58

Myślę, że jesteśmy bardzo blisko takiego tematu z drugiej strony. To wobec tego ten biedny, tak w cudzysłowie kandydat, o czym on powinien wiedzieć, o czym on powinien, nie wiem, pomyśleć, o co zadbać właśnie podczas takiej sesji live-codingu, aby wypaść dobrze.

SPEAKER_00 24:17

Przede wszystkim powinien swoje decyzje uzasadniać i nazwijmy to dokumentować wszystkie trade-offy i wszystkie takie to ładnie powiedzieć, miejsca, które byłyby jeszcze do poprawy, tak? Czyli jeśli gdzieś tam robi rzeczy trochę gorzej z tego właśnie powodu, że mamy tego czasu mniej tak, pewnie głównym ograniczeniem jest czas, to chciałbym, aby tego typu decyzje były jasno komunikowane lub też

Jak Kandydat Może Wypaść Dobrze\n

SPEAKER_00 24:55

w kodzie odpowiednio oznaczone. Tak, jeśli nie lubisz mówić i w trakcie kodowania się to rozpraszam, to zrób tutaj komentarz tu, coś tam, coś tam.

SPEAKER_01 25:06

Okej, a jakbyś podszedł do samego rozwiązywania problemu. No bo wiadomo, mamy często jako programiści taką tendencję, żeby zakładać, że a to nam zajmie pewnie tyle i tyle. Rzeczywistości, gdyby to pomnożyć przez dwa, albo i przez pięć, to i tak pewnie będzie za mało, więc nie doceniamy tego czasu, które jest potrzebne.

SPEAKER_00 25:25

Po pierwsze, ja bym tu dał taki negatywny punkcik malutki, że malutki, ale jednak by dał, jeśli ktoś od razu by usiadł i zaczął klepać. To oczekiwałbym jednak, że ktoś spróbuje przeczytać to zadanie, tak najpierw znaleźć w nim luki, zadać jakieś pytania, rozplanuje coś, może nawet też zależy od tej formy, ale może coś sobie na kartce nawet rozrysuje, pokaże, ten zeszedł do kamerki, czy tam, myślę, jesteśmy na miejscu, to wiadomo, nie ma problemu. I jakby nie zacznie robić jolo, tak, tylko. No, całość jakby podejdzie do tego kompleksowo. Czyli tak właśnie tak, jakbym oczekiwał, że ktoś podchodzi do zadania, które gdzieś tam mu zlecono w pracy.

SPEAKER_01 26:17

No właśnie, to jest pewnie dosyć ważne. Dodałbym, żeby nie zapominać też o testach. Wiadomo, jest na to mało czasu, ale chociażby, no nie wiem, takie podejście TDD w tym sensie, że jakby uproszczone TDD, tak? Czyli że my nawet stworzymy jakieś te testy, w sensie tylko ich nazwy, żeby powiedzieć i pokazać, że my mamy taki styl pracy, tak, że to jest nasz warsztat, że w ogórzymy testy do kodu, który piszemy. Myślę, że o tym bym też gdzieś tam nie zapominał. No i z racji na to, że właśnie przeceniamy często czasy, który poświęcimy na rozwiązanie zadania, to rozpocząłbym od czegoś w miarę prostego, jakiegoś takiego, nie wiem, MVP, który nie jest idealnie architektonicznie według najnowszych standardów i od razu rozbity na mikroserwisy, ale coś prostego, coś łatwego, coś niebało.

SPEAKER_00 27:12

Tak, ale to też to samo z drugiej strony. To zadanie też nie powinno być, na 24, tylko dajmy jakieś taki MVP i potem najwyżej dorzucajmy kolejne wymagania w trakcie. I zadawajmy takie pytania rozszerzające, nazwijmy to, albo nawet jeśli nie miałobyś to się skończyć implementacją, to często jest tak, że można sobie pogadać o czymś. A jakbyś to zrobił, jakby jednak ten system miał mieć, nie wiem, 100 tysięcy zapytań na sekundę, tak? I tego typu po prostu ciekawe pytania, które niekoniecznie oczekujesz, że teraz będziemy to implementować.

SPEAKER_01 27:54

Tak, no i tu się pojawia dosyć istotna rola rekrutera, bo może się okazać, że nieraz jakaś drobna podpowiedź, jakaś wskazówka, jakaś wskazanie kilku opcji będzie czymś, co otworzy drogę kandydatowi do tego, żeby się lepiej pokazać, tak, żeby iść z tym problemem dalej. Więc stroniłbym od tego, żeby taki rekruter był tam tylko, wiesz, taką skałą, która tak siedzi i patrzy, jak kandydat rozwiązuje problem. Raczej to powinna być osoba, która gdzieś tam wspiera, nie wiem, może właśnie pomaga, podpowiada, drąży trochę temat, bo to jest też bliskie codziennej pracy, tak? Kiedy sobie tam, nie wiem, z kolegą rozmawiasz o czymś, albo podpytujesz seniora, jakby to można było rozwiązać, pytasz AI, jak można byłoby to inaczej ugryźć. Myślę sobie, że to też pozostawia dużo lepszy taki kandydet experience, tak? I pomaga właśnie ten stres nam rozładować.

SPEAKER_00 28:55

Tak, no i też jako ten rekruter starajmy się też na bieżąco dawać feedback i gdzieś tam nakierowywać tego kandydata na to, co robi dobrze, co źle. W ten sposób też nie będziemy musieli na koniec tego wszystkie zbierać, tylko od razu też kandydat ma na bieżąco informację zwrotną.

SPEAKER_01 29:18

Myślę, że dobręliśmy do tego punktu programu, gdzie trzeba byłoby podsumować wszystko to, o czym była mowa.

SPEAKER_00 29:25

Uważam, że należy stworzyć właśnie takie zadanie, które jest jak najbardziej jakimś takim real-life scenariuszem. Porzućmy pytania o różnice między interfejsem a klasą abstrakcyjną, bo one naprawdę nic nie wnoszą, a starajmy się po prostu przedstawić, pokazać tak, dać szansę może, żeby kandydat pokazał po prostu się od najlepszej strony w takiej codziennej pracy po prostu. Teraz tak, pamiętajmy, że senior to nie ten, kto napisze najszybciej, ale też ten, kto wie często, czego nie napisać, jakie zadać pytania, umie skorzystać z narzędzi. Jeśli czegoś nie wie, to też umie odpowiednio wyszukać tej informacje. To też jest coś, co powinniśmy jako rekruter oceniać, czyli umiejętność poradzenia sobie właśnie z brakiem wiedzy, czy z brakiem jakby pewnych informacji. Też tutaj można zrobić takim, że to zadanie może być specjalnie jakieś egzotyczne po to, żeby trzeba było poszukać na przykład wiedzy domenowej gdzieś w internecie. No i co tam dalej? No i przede wszystkim moim zdaniem pełny dostęp do idę, narzędzi, bibliotek, internetu, czyli niech ten kandydat czuje się jak ryba

Rola Rekrutera Podsumowanie I Linki

SPEAKER_00 31:00

w wodzie, korzysta ze swojego sprzętu. Może jeszcze taki hit dla kandydatów z kolei jest taki, że warto na taką rozmowę przygotować sobie też jakieś odizolowane środowisko, jakąś wirtualkę. Po prostu nową sztukę środowiska, tak, żeby po prostu nie mieszać, tak? I żeby czuć się też bezpiecznie. Też słyszałem o takich historiach, że ktoś czekartował kod, który niby rozmowa kwalifikacyjna, chcieli cię skakować. Także uwaga też na takie rzeczy.

SPEAKER_01 31:37

Tak, wszelkie przygotowania, które sobie gdzieś tam poczynili wcześniej po prostu nam pozwolą, ten stres gdzieś tam zmniejszyć, więc myślę, że jak najbardziej nie zaszkodzi. Być może da się nawet dopytać o to, co powinno się w takim środowisku znaleźć. Jakieś biblioteki, jakieś tule, które możemy sobie wcześniej już zainstalować, żeby się z tym nie kopać. Wiadomo, że to na pewno na pewno nam pomoże. Dobrze Łukasz, myślę, że dopytnęliśmy tutaj do końca. No właśnie, mam nadzieję, że starmy się tutaj dosyć klarownie pokazać, że live coding wcale nie musi być taki straszny, bo tutaj nie chodzi o to, żeby nam udowodnić naszą niewiedzę jako kandydatą, tylko zbadać to, jak poruszamy się w realnym środowisku pracy. Myślę, że to jest jedna z alternatyw możliwości badania kompetencji niewykluczone, że w dalszych odcinkach tutaj tej serii będziemy jeszcze o innych alternatywach wstępnie wspomnianych mówić. A jeśli mowa o właśnie tych odcinkach to zapraszamy już do nagranych, wcześniej odcinków z tej i też innej serii, które pozwolą się nie tylko dobrze przygotować i wypaść podczas procesu rekrutacyjnego, ale też znacznie wcześniej zadbać o różne aspekty tego naszego rzemiosła programistycznego. Do tych odcinków odsyłamy. Odsyłamy też do Solid Jobs, jeśli niestety live coding w waszym wydaniu nie pójdzie, może najlepiej. Tam możecie znaleźć inne ogłoszenia o pracę zawsze z widełkami wynagrodzeń.

SPEAKER_00 33:16

Tak, zapraszamy też na nasze ścieżki kariery na Solid Jobs, gdzie też znajdziecie ładne, podsumowanie swojej roli. Średnie wynagrodzenia, medialne, także popularne pytania rekrutacyjne, no i dużo, dużo więcej zachęcam zapraszam.

SPEAKER_01 33:39

Zapraszamy. Dzięki za dzisiaj. Cześć.

SPEAKER_00 33:41

Dzięki bardzo, cześć.