Krzysztof:
To jest 318 odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Solid.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.

Łukasz:
Cześć Krzysztofie.

Krzysztof:
To nasze kolejne spotkanie w ramach cyklu podcastów dla kandydata. W wcześniejszych odcinkach było trochę o tym, jak się do rozmowy przygotować, jak podejść do wysyłania CV, czy te wszystkie kroki, które miejmy nadzieję macie już za sobą. Jeśli 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 właśnie tej rozmowy czy tych rozmów jest sprawdzenie waszych kompetencji technicznych, waszych skilli, 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 sentyment, można by powiedzieć, związany właśnie z 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.

Łukasz:
Ja osobiście uważam, że nie da się kogoś zatrudnić, nie oglądając go w pracy, w tym naturalnym środowisku. Jaką mamy w ogóle alternatywę do takiego live codingu? Alternatywa to jest coś, co ja nazywam zgaduj z gadula. Czyli przepytywanie kandydata z jakichś losowych funkcji losowych, czy może mniej losowych jakichś 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 no to też nie jest moim osobistym zdaniem dobra droga jakie jeszcze mamy alternatywy możemy od kandydata. Oczekiwać, że zrobi jakieś tak zwane zadanie domowe czyli też coś w rodzaju, takiej sesji codingu, ale offline, czyli, może zyskujemy to że ten kandydat ten poziom jego stresu będzie trochę mniejszy, no bo ktoś mu nie patrzy na ręce, No ale za to jest tutaj też duży opór z rynku, od kandydatów. Ludzie po prostu nie chcą robić takich zadań offline, no 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 zadanie umieszczają, bo często to jest tak, że to jest jakiś pierwszy etap, który ma za zadanie odsiać tych kandydatów. Nikt jeszcze z tobą nawet nie porozmawiał, tak face to face, a już ci każą robić jakieś zadanie no i potem często to jest tak, że ci ludzie robią te zadania, a nikt się nawet do nich już nie odezwie i nie dostaną żadnego feedbacku, także 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?

Krzysztof:
Gdy w skiller czy coś takiego pewnie, tak?

Łukasz:
Tak, tak, tak, tak. Właśnie gdzie robi się zadania na przykład algorytmiczne. No ale to znowu co sprawdza? No sprawdza, czy ktoś na pamięć zna jakiegoś quicksorta, czy tam hipsorta, 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 quicksort’a napisze, bez problemu, ale no 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.

Krzysztof:
No tak, jeśli jesteś Googlem, to możesz właśnie tego typu egzaminy robić 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 nietuźnikowych problemów, ale dla większości firm gdzieś tam z takiego rynku, można 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ć QuickSorta, BubbleSorta, czy tam cokolwiek, bo nikt tego w rzeczywistości w realnej pracy nie będzie robił, skorzystasz po prostu z metody, z jakiejś tam biblioteki i tyle, więc tak jak tutaj zaznaczyłeś, myślę, ż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 jakimś tam przybliżeniem, jest jakimś przybliżeniem, jakąś heurustyką, jakąś próbą, no nie wiem, zrozumienia, jakie ty tak naprawdę masz skille. Ja myślę sobie, że dużo lepsza byłaby, aczkolwiek dużo jest też problemu 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 stworzenia, jak programista się w naturze sprawdza. Natomiast wiadomo, że to jest oczywiście jakaś forma już inwestycji ze strony firmy i nie zawsze możliwa, ale life coding jest pewnie taką opcją, żeby zobaczyć jak to wygląda

Krzysztof:
W miniaturze w tej godzinie czy 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 spotykane na co dzień. No i myślę, że tutaj też wypracowaliśmy właśnie taki sposób, żeby to weryfikować bazując na live codingu. Ale pewnie też się ze mną zgodzisz, że wiele osób zarzuca w tej metodzie jakiś niepotrzebny stres, który wywołuje.

Łukasz:
Tak, natomiast wydaje mi się, że programowanie dla nas programistów to jest ten chleb powszedni, to nasz, bread and butter, to co umiemy robić, to co lubimy robić przede wszystkim. No to to jakby powinna być przyjemność, że możemy tutaj programować jeszcze używając swojego komputera, swojego środowiska, swojego ID, 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 o pracę, ona powinna rzeczywiście symulować to realne jakieś zadanie, realny 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ą.

Krzysztof:
No okej, a co z tam 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, jakąś tam presję. Chodzi mi o to,

Łukasz:
Że… Zasada tak, nieoznaczoności, że sama obserwacja wpływa na obiekt obserwowany. Myślę, że to musimy wziąć pod uwagę, i po prostu na to mieć taki, wewnętrzny, jak to ładnie powiedzieć, no to powie mnie ładnie, shift, ż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, no 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 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 no to nie chcę żeby ktoś po tym stringu jechał 4Eachem po każdym, karze i porównywał, szukał, gdzie jest średnik czy tam przecinek. Jak widzę, że ktoś po prostu w ten sposób podchodzi do zadania, to już widać, że to nie jest ten mindset programisty.

Krzysztof:
Nie wróży, tak. No właśnie, tutaj myślę sobie, że jednak ta osoba obserwatora w postaci prowadzącego, czy jakkolwiek go 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 gdzieś towarzyszy, która być może naprowadza, która jakoś ten stres gdzieś tam rozładowuje.

Łukasz:
To tutaj pierwszy taki hint bym chciał podać. Po pierwsze potraktujmy to jako sesję per programingu, czyli jest nas załóżmy dwóch, ten rekrutujący i rekrutowany i potraktujmy to po prostu jako sesję takiego per programingu i, razem twórzmy to coś, co jest do zrobienia. Natomiast może warto zacząć od tego, żeby odwrócić rolę i 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 zredukować i zacząć w tą stronę, a potem po 10 minutach odwrócić rolę.

Krzysztof:
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? Są ekstrawertykami bardziej niż introwertykami, bo na przykład takie osoby będą w stanie się o coś dopytać, otworzyć, niejako uzyskać podpowiedź, pomoc ze strony prowadzącego?

Łukasz:
Ciekawe pytanie, Krzysztofie, jak to mówią w telewizji. Dziękuję za to pytanie.

Krzysztof:
Bożyłeś o niej pewnie cały dzień.

Łukasz:
Z jednej strony wydaje mi się, że masz rację, tak, to była twoja teza, masz rację, że ta osoba ekstrawertyczna by miała trochę łatwiej, a z drugiej strony jednak to jest pisanie kodu, więc może jednak to nie ma aż takiego znaczenia i jeśli chcesz się jednak trochę bardziej zamknąć w tej swojej skrupie, no to po prostu rób swoje. Też jakby zatrudniamy programistę, a nie UX designera to też jakby inaczej to o czym mówimy pewnie też ma sens dla tak jak mówiłem UX designerów, testerów. Analityków 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ż jakby to są takie, może pułapkę to jest złe słowo, ale jakby oczekuję, że ktoś zapyta, zada jakieś konkretne pytania, tak, tak samo jak jeśli to jest kod do napisania, no to oczekuję, że ktoś oprócz tego, że napisze kod, który coś zrobi, to napisze też jakieś testy, które sprawdzą, czy to.

Łukasz:
Co jakby jest tworzone, czy 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ę ten ciąg, o narzędziach może porozmawiajmy.

Krzysztof:
Ja bym może dorzucił jeszcze jedną myśl do tego wątku, żeby nie uciekła. 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, 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 nam Hello World’a na ekranie wyświetla.

Łukasz:
A powiem Ci nawet więcej. Nawet jakbym dostał taki kod, który jest kompletnie dobani i wygląda za kiepsko, robi co miało robić, ale teraz by ten ktoś powiedział, że to zrobiłem źle, to zrobiłem źle, to zrobiłem, jestem super niezadowolony za mało czasu, to bym wolał ten kod.

Krzysztof:
Który jest źle zrobiony,

Łukasz:
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.

Krzysztof:
Tak i powiem Ci, że uczestniczyłem kiedyś w takiej rekrutacji właśnie. Startup amerykański, więc jakby 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, że w 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. Myślę sobie, że to 45 minut, godzina, zależy jak ta sesja live codingu trwa. Tutaj bardzo trudno byłoby oczekiwać, że na koniec ma być coś, co jest 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. I domyślnie, jako programista, uczestniczący takiej rekrutacji, ty wybierzasz sobie i chcesz coś dostarczyć, bo tak wygląda twoja praca, i skupiasz się na tym, żeby to faktycznie coś tam było, co jeszcze bardziej gdzieś tam napędza taką spiralę stresu, 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. Chodzi mi o to, żeby jasno też postawić oczekiwania, co jest oczekiwane z takiej rozmowy, podczas takiej rozmowy, a co nie jest, bo myślę, że to dużo bardziej pozwoli rozładować ten stres i napięcie.

Łukasz:
Tak, 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ść, zdebugować, wdrożyć poprawkę, czy spanikuje i będzie bezradny. Praca to też jest stres. To nie jest tak, że, Wszyscy pracujemy sobie wesoło w tych korpo i tam nikt za nic nie odpowiada. Nie? Wszyscy odpowiadają, czyli nikt.

Krzysztof:
Pan odpowiada, pani odpowiada. Jasne, jasne. No dobra, skoro wiemy już mniej więcej, jak to może wyglądać, to co według ciebie powinno być treścią takiego zadania albo takiego problemu postawionego kandydatowi? Czy bardziej właśnie napisz mi tam quicksorta, czy bardziej rozwiąż jakiś

Łukasz:
Problem 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ś, coś co kiedyś spotkałem po prostu na swojej drodze programistycznej i z tego, właśnie robię takie zadania, takie fragmenty, smaczki na rozmowę kwalifikacyjną. Właśnie o to chodzi, żeby w jak największym stopniu zasymulować 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 szeroki, dostęp do internetu, do dokumentacji, tak jakbyś po prostu miał dostarczyć funkcję normalnej pracy. W normalnej pracy korzystać ze stag overflow, no to czemu na tej rozmowie kwalifikacyjnej byś miał nie skorzystać z tego stag overflow? Nie czyni to ciebie gorszym, tak? Wszyscy korzystamy ze stag overflow, albo dopóki AI nie nadeszło.

Krzysztof:
Tak, zwykliśmy byliśmy.

Łukasz:
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.

Krzysztof:
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 byłaby trochę głupota, gdybyśmy oczekiwali, że podczas live codingu, który to ma nas przybliżyć do realnej pracy, my takich narzędzi gdzieś tam zabraniamy. Natomiast pewnie ważne by było, 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 i jak promptujemy, to już jest sztuka sama w sobie, która może być badana właśnie, czy sprawdzana podczas live codingu. Jeśli ty, wiesz, przepiszesz zadanie do chat-a GPT i rozwiąż ten problem, to niekoniecznie świadczy o tobie, ale jeśli zapytasz, żeby ten problem został przeanalizowany dla ciebie, o co powinieneś zapytać, o co może dopytać, jakie są jakieś luki bezpieczeństwa itd., to według mnie to tym bardziej świadczy, że ty wiesz w ogóle jak wygląda taki cykl wytwarzania, oprogramowania. 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 codiku.

Łukasz:
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 w 5, a potem się spytać, no i co robimy dalej, to może też byłoby okej. 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łbym rower, a dostałbym rakietę i… Czy testy, jakieś inne cuda niewidy, może zrobiłoby to wrażenie.

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

Łukasz:
Przede wszystkim powinien swoje decyzje uzasadniać i nazwijmy to dokumentować wszystkie trade-offy i wszystkie takie, miejsca, które byłyby jeszcze do poprawy, czyli jeśli gdzieś tam robi rzeczy trochę gorzej z tego właśnie powodu, że, mamy tego czasu mniej. Czy tak, no pewnie głównym ograniczeniem jest czas. No to chciałbym, żeby tego typu decyzje były jasno komunikowane lub też w kodzie odpowiednio oznaczone. Tak, jeśli nie lubisz mówić i w trakcie kodowania się to rozprasza, no to zrób tutaj komentarz to do, coś tam, coś tam.

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

Łukasz:
Po pierwsze, ja bym tu dał taki negatywny punkcik, malutki, że malutki, ale jednak bym dał, jeśli ktoś… Od razu by usiadł i zaczął klepać. To oczekiwałbym jednak, że ktoś spróbuje przeczytać to zadanie, 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 zeszyt do kamerki, czy tam jeśli jesteśmy na miejscu, to wiadomo, nie ma problemu. Jakby nie zacznie robić YOLO, tylko całość jakby podejdzie do tego kompleksowo, czyli właśnie tak, jakbym oczekiwał, że ktoś podchodzi do zadania, które gdzieś tam mu zlecono w pracy.

Krzysztof:
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 jak gdyby 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óle tworzymy 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 czas, który poświęcimy na rozwiązanie zadania, to rozpocząłbym od czegoś w miarę prostego, jakiegoś takiego MVP, który nie jest idealnie architektonicznie według najnowszych standardów i od razu rozbity na mikroserwisy, ale coś prostego, coś łatwego, coś namacalnego.

Łukasz:
Tak, ale to też to samo z drugiej strony, to zadanie też nie powinno być na, 20 kartek a 4, tylko dajmy jakieś, takie 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 się to 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, tam zapytań na sekundę. Tego typu po prostu ciekawe pytania, które niekoniecznie, oczekujesz, że teraz będziemy to implementować.

Krzysztof:
Tak, no i tu się pojawia dosyć istotna rola rekrutera, bo może się okazać, że nieraz jakaś drobna podpowiedź, jakaś wskazówka, jakieś wskazanie kilku opcji będzie czymś, co otworzy drogę kandydatowi do tego, żeby się lepiej pokazać, ż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 kandydat experience i pomaga właśnie ten stres nam rozładować.

Łukasz:
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 wszystkiego zbierać, tylko od razu też kandydat ma bieżąco informację zwrotną.

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

Łukasz:
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óżnicę między interfejsem a klasą abstrakcyjną, bo one naprawdę nic nie wnoszą, a starajmy się po prostu przedstawić, pokazać, 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ć te informacje, bo 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 w wodzie korzysta ze swojego sprzętu. Może jeszcze taki hint 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ć, i żeby czuć się też bezpiecznie, bo też słyszałem o takich historiach, że ktoś czekautował kod, który niby rozmowa kwalifikacyjna, a chcieli cię zhakować, także uwaga też na takie rzeczy.

Krzysztof:
Tak. Wszelkie przygotowania, które sobie gdzieś tam poczynimy wcześniej, pozwolą nam 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 nam pomoże. Dobrze, Łukasz. Myślę, że dobyliśmy tutaj do końca. No właśnie, mam nadzieję, że staraliśmy 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 kandydatom, tylko zbadać to, jak poruszamy się w realnym środowisku pracy. Myślę, że to jest jedna z alternatyw, z możliwości właśnie badania kompetencji. Nie wykluczone, ż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, no 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 on 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ń.

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

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

Łukasz:
Dzięki bardzo. Cześć.