[Marek Czuma]

Bardzo przydatne, praktyczne info ze środka, dzięki Mateusz! Btw – na początku myślałem że to ty się rekrutowałeś i dziwiły mnie trochę te różne „babole” :D.

Z mojej strony pozwolę nie zgodzić się z jedną rzeczą: punktem dot. live codingu. Moim zdaniem jeśli pada pytanie „czy jestem OK z live codingiem”, to jest tu pozostawiona przestrzeń do dezaprobaty. Z naszej strony dezaprobatra może być delikatna, np „osobiście nie jestem fanem, ale chętnie zmierzę się z każdym rodzajem wyzwania – naprawdę zależy mi na tej robocie”. Niemniej moje zdanie od lat jest bardzo krytyczne wobec live codingu. Być może nabiera to więcej sensu dziś, w dobie generowania odpowiedzi przez AI. Natomiast pomijając ten aspekt, znacząco zwiększa to poziom stresu którego nie będzie potem w pracy, a znacznie mniej sprawdza realne umiejętności.

Z kolei ZGODZĘ SIĘ AS FUCK z koncówką – naprawdę, solidnie przerobione podstawy to 80% roboty. Może przesadzam, a może nie. Ale to jest wniosek z mojej drogi zawodowej – i dlatego zawsze każdemu polecam sposób nauki „Od ogółu do szczegółu”. Sam również – jak może zauważyliście – stosuję to w kursach. I ja i inni nasi zacni autorzy:-). Ja sam prowadziłem zbyt wiele rozmów, na których „sparkowiec z 2 latami doświadczenia w pracy z tą technologią” nie umiał odpowiedzieć na pytanie „Co to jest Spark?”. Naprawdę, najpierw zrozummy ogół, podstawy, a potem stopniowo zagłębiajmy się w coraz większy detal.

[Mateusz Wąsalski]

Racja, trochę źle zacząłem ten post 😀

Jesli chodzi o live coding, to jest to 100% to, co robimy na co dzień:

masz kod, który pobiera dane z Jiry, dwa endpointy: taski i projekty.

Dla tasków i projektów są dwie osobne komórki, dużo powtórzeń, żadnych funkcji nic.

Przepisz mi to na klasę.

Informuje o tym badzo wyraźnie i jest to właśnie po to, żeby oddzielić vibe coderów od ludzi, którzy nie skończą pracy, jak im się limit tokenów skończy. Miałem ludzi, którzy byli data architektami i nie potrafili tego dobrze zrobić. Jeśli firma, do której aplikują, ma dosyć duże wymagania, jeśli chodzi o security, to pewnie będzie duże ograniczenie, jeśli chodzi o kodzenie z AI, więc muszą sobie radzić.

Co do stresu – jeśli rozmowa rekrutacyjna Cię stresuje, to moim zdaniem będzie Ci bardzo ciężko wspiąć się wyżej, bo wtedy masz co chwilę mikro rozmowy rekrutacyjne z senior managerami, C-levelem, zarządem albo przedstawicielem klienta, którzy Cię oceniają na każdym kroku, bo jak tego dobrze nie ugrasz, to będziesz postrzegany jako koszt, a nie inwestycja (tutaj się ciągle odnoszę do tego, że jest to stanowisko seniorskie).

Zresztą, seniorska rola to nie jest klepanie kodu 8 godzin dziennie 😉

[Marek Czuma]

Odnośnie stresu – stres pisania kodu w notatniku, gdy ktoś patrzy Ci na ręce (i zależy od tego czy przejdziesz dalej) to zupełnie inny rodzaj stresu niż np. „muszę sprawnie skończyć to zadanie”, albo „muszę porozmawiać z klientem”. Po prostu – nawet jeśli rodzaj zadań jest podobny – moim zdaniem nie odwzorowuje to prawdziwego „dnia pracy”. To bardziej przypomina egzamin na prawo jazdy, który niby ma sprawdzać czy potrafimy jeździć, ale wiadomo że realnie potem, nawet w stresowych sytuacjach, jesteśmy w zupełnie innych warunkach.

[Marcin Parzy]

Jak moja szefowa rekrutowała i brała mnie na rozmowy, to na stanowiska seniorskie interesowało nas, co kandydat robił i czy wiedział, co robił. To bardzo szybko wychodzi jak się wejdzie w szczegóły, ale nie na zasadzie przepytywanie z jakiegoś kawałka kodu, co on robi.

Nas interesowało rozwiązywanie problemów i ownership. I chcieliśmy ludzi, którzy ogarną temat.

Natomiast jak ja wchodziłem w rolę senior data engineera ze świata etl i programowania baz danych, to trafiłem na okres, gdzie moja szefowa i jej szef szukali do specyficznych technologii. Najlepsze było, że jak zmieniłem wewnętrznie zespół, to narzędzia się zmieniły i trzeba było kod przepisać z tego, co był.

Tak więc uczyłem się on the job. Miałem problem i go rozwiązywałem. Teraz interesuje mnie Databrics i dodanie tego do moich umiejętności. Dlatego się uczę i liczę na wewnętrzny projekt u siebie.

[Marek Czuma]

Ja powiem szczerze, że najfajniejsza rozmowa rekrutacyjna w której brałem udział (jako osoba rekrutowana) wyglądała tak, że… w ogóle nie byłem przepytywany.

Rozmawiliśmy bazująz na moich projektach, od których wychodziliśmy i potem dyskutowaliśmy nad rozwiązaniem, nad alternatywami itd.

Mega fajnie się gadało, chłopaki super poprowadzili. Natomiast to też trzeba umieć, żeby wyczuć czy ktoś ma gadane czy naprawde się zna. Jak ja to raz spróbowałem wprowadzić to mało nas nie nakierowałem na minę, bo ziomek nieźle odpowiadał, ale jak potem mój kolega go przepytał z technikaliów, okazało się, że prawie nic nie ogarnia :D.

[Marcin Parzy]

Myśmy zaczynali od tego, co kandydat robił i schodzili do szczegółów. I wiedzieliśmy czy kandydat to robił czy nie. Ale do tego trzeba było wiedzieć z czego się kandydata pyta.

Mieliśmy kilka pytań na zasadzie, co robił i co poszło nie tak i jak to naprawił. Albo co robił i drążyliśmy do szczegółu. Potem wiedzieliśmy na ile, to były ogólniki a na ile nie.

[Marek Czuma]

Bardzo spoko. Mi osobiscie dużo swobodniej rozmawia się o moim warsztacie, niż o abstrakcyjnych tehnikaliach wyjętych z kontekstu. I wydaje mi się że dużo lepiej to pokazuje realną wiedzę, bo jest osadzona w kontekście, sprawdza research który został przy tej okazji zrobiony (a więc i umiejętność jego przeprowadzania!) itd.