Rekrutacyjne WTF jakie Was spotkały

WTF jest dodawanie przez rekruterów uśmieszka do informacji o braku live codingu na rozmowie tylko po to, żeby później zostać zasypanym dupoteoretycznymi pytaniami jakby to było lepsze. Chyba dla vibe coderów którzy wkuwają się regułek na pamięć i udają speców.

Rok 2012. Dwoch programistow w nowej firmie opowiada, jak to dostali po 3-4 latach od wyslania CV zaproszenie do wyslania CV do firmy. (Chodzilo oczywiscie o inne firmy.) Widocznie firmy odczekaly 3-4 lata, zeby programisci nabrali odpowiednio duzego doswiadczenia. Po paru miesiacach dostaje telefon. Dzwoni z "januszsoft" mikro firmy ze wsi 1500 mieszkancow i mowi, ze "dwa lata temu wyslal nam Pan swoje CV. Moze Pan to jeszcze raz zrobic?" W skrzynce patrze i rzeczywiscie minelo 1 rok i 9 miesiecy od wyslania tej mikro firmie CV. W tej mikro firmie zreszta praca byla tylko na jednoosobowa dzialalnosc gospodarcza, co w tamtych czasach bylo rzadkoscia.

Może nie WTF bo w sumie to już standard. Wysłałem CV w połowie września, kontakt był szybki, bo już tego samego dnia umówiłem się na rozmowę z HR. Rozmowa była dwa dni później, wszystko sprawnie szło, bo niedługo później był pierwszy etap techniczny, który przeszedłem. Wtedy też pojawił się pierwszy red flag, rekruter na rozmowie mówił, że czekają mnie jeszcze dwa dodatkowe etapy, a HRówka mówiła tylko o jeszcze jednym. Jeszcze rekruter mnie chyba próbował nastraszyć, bo mówił, że tego następnego etapu jeszcze nikt nie przeszedł xD 3 etapy techniczne trochę dużo, ale uznałem, że jak już jestem w trakcie, to spróbuję.

Po kilku dniach przychodzi mail, że mam do zrobienia zadanie domowe. Rzeczywiście HRówka mówiła, że będzie live coding albo zadanie. Tylko że w mailu ani słowa o tym rzekomo bardzo ciężkim kolejnym etapie technicznym z hamerykanami. OK niech będzie, zrobię to zadanie. I to był błąd. Poświęciłem na nie jeden weekend, przyłożyłem się, zrobiłem wszystkie dodatkowe punkty. Spokojnie mogę powiedzieć, że było to zrobione dobrze, gdybym miał więcej czasu, to poprawiłbym kilka rzeczy, ale szanujmy się. To nie praca zarobkowa a zadanie domowe na rekrutację, na które miałem max tydzień i robiłem je w czasie wolnym. Uznałem, że wszelkie uwagi omówimy na następnym etapie. Błąd xD

Napisali do mnie, że nie mogą odpalić tego zadania u siebie lokalnie. Dziwne, bo u mnie działa. Stawiam, że różnice Windows vs MacOS. Odpisałem, co może być przyczyną. Był jeszcze jeden problem z Dockerem, który szybko naprawiłem i puściłem fixa. Głupi błąd, migracja bazodanowa się niepoprawnie odpalała przy tworzeniu bazy. Lokalnie bazę miałem utworzoną, więc tego nie zauważyłem. No trudno, pomyślałem, wytłumaczę przyczynę błędu na rozmowie.

Następnie była cisza z ich strony na prawie 3 tygodnie, mimo że obiecywali, że cała rekrutacja potrwa max 4-5 tygodni (trwała 6 ostatecznie). Przyszedł tylko mail z odmową napisany w sposób pasywno-agresywny z zarzutem, że nie przetestowałem tego u siebie, co było nieprawdą. Nie zaprosili mnie na jakąkolwiek następną rozmowę. Uważam to za brak szacunku do kandydata. Poświęciłem na to kilkanaście godzin, zrobiłem wszystko łącznie z punktami dodatkowymi, wszystko działało poza problemami u nich lokalnie na Windowsie, a i tak mnie zlali i nawet nie dali tych 30-40 minut na omówienie. Rozumiem, gdyby mnie odrzucili po kolejnej rozmowie. Może był ktoś lepszy, kogoś rozwiązanie było lepsze od mojego. Ale nie, kompletna olewka. Żal czasu poświęconego na zadanie. Nie mówiąc już o tym, że tego typu zadania mogą być zrobione przez LLMy, więc decydowanie o zatrudnieniu/odrzuceniu kandydata bez rozmowy z nim o tym zadaniu nie wydaje mi się zbyt rozsądne. No cóż, szukam dalej.

Rok 2019. Rozmowa z technicznym kolesiem z firmy, ktory mowi mi, zebym mu wyslal jakis swoj kod, obojetnie jaki, ma byc moj kod. Wyslam mu wiec kod z testami. To byl task, ktory robilem 2-3h na jakas inna rozmowe pare dni wczesniej. Koles dzwoni po paru dniach i pyta sie mnie: "co to za kod?" Ja mu mowie, ze to jest moj kod z innej rozmowy rekrutacyjnej. Koles mi mowi, zebym mu wyslal inny kod.
(Dalem sobie spokoj z ta firma i zdanego innego kodu nie wyslalem.)

dzis dostalem ten dokladnie problem na livecodingu, co jest ze male SH daja zadania jak w faang xD
https://leetcode.com/problems/n-queens/
gg ;_;

kimikini napisał(a):

dzis dostalem ten dokladnie problem na livecodingu, co jest ze male SH daja zadania jak w faang xD
https://leetcode.com/problems/n-queens/
gg ;_;

Problemem takich zadań jest, to, że średnio ogarnięty programista napisze jakiegoś bruteforca który zadziała dla małych przypadków, ale do poprawnego rozwiązania które rekruter oczekuje to już trzeba znać pewien sposób rozwiązania takich problemów. I teraz zrobienie tego może sygnalizować a) jesteś geniuszem który to wymyślił na poczekaniu b) znasz rozwiązanie przy czym opcja b zachodzi w 99% przypadków. Analogia do szkoły podstawowej, to, że jakieś dziecko umie rozwiązać równanie kwadratowe zanim nauczyciel je wprowadził nie znaczy, że jest geniuszem, tylko, że wcześniej niż inni przeczytało wzór. Więc zadawanie takich pytań (o ile to nie była rekrutacja do portalu który tworzy rozgrywkę w szachy) nie ma żadnego sensu.

kimikini napisał(a):

dzis dostalem ten dokladnie problem na livecodingu, co jest ze male SH daja zadania jak w faang xD
https://leetcode.com/problems/n-queens/
gg ;_;

Pamiętam to gówienko akurat ze studiów, ale nikt normalny takich rzeczy nie pamięta. Jest to zwykły bruteforce backtracking, ale still jak ktoś nie jest FAANG-iem to bez sensu o coś takiego pytać. Ktoś wie czemu w polskim IT przyszła nagle moda na LeetCody? Nie było tego od wielu lat. Myślałem, że polscy programiści, którzy siedzą tylko w PL tego nie rozwiązują.

Ja do dziś wspominam historię programisty, którą wyczytałem chyba gdzieś na Quora. Akcja działa się na początku lat 2000 w UK, więc naturalnie rozmowy odbywały się onsite. Gość pisał, że jechał 400km na rozmowę na stanowisko programisty. Na dzień dobry dostał do rozwiązania sudoku. Gość mówi, że nigdy w życiu sudoku nie rozwiązywał. A rekrutujący niby menago niby też programista, albo po prostu miłośnik sudoku powiada "przecież to logiczne, jak można być programistą i nie umieć rozwiązać sudoku".

Kurtyna xD

Ja właśnie zabieram się do szukania nowej roboty, CV odświeżone. Zobaczymy co mnie czeka.
Jedno jest pewne. Zadań domowych nie robię, nawet płatnych.

tefu napisał(a):

Zadań domowych nie robię, nawet płatnych.

Takich ludzi się szanuje i takich ludzi potrzebujemy w IT.

still.still napisał(a):

tefu napisał(a):

Zadań domowych nie robię, nawet płatnych.

Takich ludzi się szanuje i takich ludzi potrzebujemy w IT.

Jeśli mam do wyboru robić zadania albo zmienić branżę to ja zmieniam branżę. Do IT trafiłem w zasadzie z przypadku.
Po prostu miałem na pewnym etapie do wyboru dwie oferty za te same pieniądze. Jedna IT druga nie IT.

Robiłem w życiu różne rzeczy ale jak mam z siebie robić debila to wolę iść do jakiejkolwiek innej pracy niż zakuwać jakieś dziwactwa i poświęcać mój własny czas na obiecanki macanki.
Za stary na to jestem (40stka tuż tuż) a mam jeszcze trochę innych umiejętności niż programowanie.
Może na początek będzie trzeba zejść trochę z kasy ale jeśli średnia krajowa to 9k brutto to myślę, że jestem w stanie znaleźć jakąkolwiek robotę za 9-12k brutto na UoP na początek w innej branży. Może nie będzie zdalnie, może nie będzie tak wygodnie, ale na rachunki na początek wystarczy.

Ale zanim ucieknę z IT to powalczę trochę o jakieś przebranżowienie w ramach tej samej branży. Coś tam dłubałem z Openshiftem, Dockerem i Jenkinsem to będę szukał czegoś w obszarze DevOps'owym. Przypomnę sobie jakieś Linuxowe tematy, ogarnę podstawy popularnych narzędzi DevOps'owych i zobaczymy.
Nawet za mniejszą kasę na początek byleby experience leciał.

Na początku 2025 skontaktował się ze mną rekruter ze Szwajcarii z ofertą pracy (programowanie PLC). Wyraziłem zainteresowanie. Kilka dni później odbyłem pierwszą rozmowę online z kierownikiem działu. W miarę luźna rozmowa. Poszła dobrze. Po dwóch tygodniach ciszy zaproszenie na następną rozmowę online z tym samym kierownikiem oraz teamleadem. Byli zadowoleni i zaprosili na wizytę w firmie. Moje pytanie: czy zapłacą za podróż (800+km)? Odpowiedź: nie, nie zapłacą, takiej praktyki w Szwajcarii nie ma. Cóż - zgodziłem się i 10 dni później pojawiłem się na miejscu. Ludzie okazali się bardzo sympatyczni. Już na wstępie przeszliśmy z kierownikiem i teamleadem na ty, przedstawili mnie wszystkim obecnym w biurze, zaprosili na obiad. Na samym końcu wizyty kierownik wspomniał tylko, że moje wymagania finansowe są trochę za wysokie. Ja na to: możemy coś wynegocjować. On, że księgowa jest akurat na urlopie ale wróci za kilka dni to się zgłoszą.

Wróciłem nocnym pociągiem i z marszu poszedłem do pracy. Wczesnym popołudniem dzwoni telefon ze Szwajcarii. Nie mam jak odebrać (praca w biurze, nie ma się gdzie skryć). Po jakimś kwadransie oddzwaniam ale nikt nie odbiera. Sprawdzam skrzynkę pocztową. Jest wiadomość: sformułowana oficjalnym tonem per "pan" odmowa - moje kwalifikacje nie odpowiadają oczekiwaniom.

Na tym historia się kończy. Mam tylko nadzieję, że to taka ich szablonowa odpowiedź, bo różnych rzeczy mogli się byli czepiać ale nie tego że ich technologii nie znam - robię w niej od ośmiu lat. Tajemnice HR-u. Nigdy się nie dowiem co spowodowało taki obrót o 180 stopni w 12 godzin.

"jak rozwijasz sie w czasie wolnym? weekendy?"

po odpowiedzi, żę weekedy poświęcam rodzinie skrzywiona mina xD

reszta rozmowy spoko ale cos czuje ze i tak dostalem za to sporego minusa

kimikini napisał(a):

"jak rozwijasz sie w czasie wolnym? weekendy?"

po odpowiedzi, żę weekedy poświęcam rodzinie skrzywiona mina xD

reszta rozmowy spoko ale cos czuje ze i tak dostalem za to sporego minusa

Trzeba było powiedzieć to co chcieli usłyszeć. Ludzie uwielbiają być oszukiwani. Tobie powiedzą, że mają pełne pokrycie w testach, dobre praktyki, code review, szkolenia, ciekawe projekty itp. I nawet im brewka nie tyknie

Jak wchodzi temat security i JWT w kontekście tego na co należy zwracac uwage projektujac system...
Rekruterzy robią wielkie oczy jak powiesz im, że Access tokenu nie da sie tak łatwo revokować... (Więskzosć systemów na to albo wprost nie pozwala, lub wymaga znajomosci tokenu, którego zazwyczaj nie masz prawa znać jako szarak developer)

Jeden mnie wyśmiał i powiedział "wystarczy z bazki recznie usunąć lol XD"

Skąd się tacy marzyciele biorą? Wymagania dla człowieka-orkiestry znającego niszowe oraz przestarzałe technologie, ale stawka na mida/juniora.
Soft-skille opisane w wersji typowo polskiej, sugerujące problemy z toksycznym szefem nieradzącym sobie w aspergerowym świecie programistów.

SALARY
12 000 - 18 000 PLN
Net per month - B2B

Twój zakres obowiązków
Będziesz odpowiedzialny za utrzymanie i rozwój systemów Faktura.pl.
Powierzymy Ci zadanie projektowania i implementacji funkcjonalności w naszym systemie w porozumieniu z zespołem IT.
Do Twoich obowiązków będzie też należało priorytetowe rozwiązywanie problemów zgłoszonych przez klientów.

Nasze wymagania
minumum 3 lata doświadczenia w IT jako programista back-endowy lub full-stack,
doświadczenie w tworzenie produktów klasy enterprise,
wykształcenie techniczne (zakończone lub rozpoczęte studia Informatyczne),
znajomość tematów związanych z księgowością (zarówno od strony technicznej jak i merytorycznej)
bardzo dobra znajomość Java 8+, Hibernate, NativeQuery, Java EE/Jakarta EE, EJB
bardzo dobra znajomość standardowych bibliotek Java,
bardzo dobra znajomość systemów kolejkowych (ActiveMQ, Apache Kafka itp.),
praktyczne umiejętności poprawnego zarządzania transakcjami w wielostopniowych procesach,
praktyczna znajomość zagadnień związanych z kryptografią w procesach integracji z usługami rządowymi MF/ZUS,
praktyczna znanomość zagadnień związanych z podpisami cyfrowymi typu Xades,
znajomość JavaFX,
znajomość narzędzi do budowania aplikacji: maven, launch4j, wix, a także obfuskatorów,
REST API, SOAP API, integracje z zewnętrznymi API,
bardzo dobra znajomość SQL (szczególnie PostgresSQL),
znajomość pakietu Office, a w szczególności narzędzia Excel,
dobra znajomość Dockera na potrzeby developmentu,
znajomość Jenkins i GIT na poziomie umożliwiającym modyfikację pipeline'ów CI/CD,
umiejętności zarządzania serwerami testowymi, stawianie nowych środowisk,
znajomość JIRA, - znajomość wzorców projektowych,
umiejętność bezpiecznej refaktoryzacji kodu,
praktyczna zmajomość SOLID, KISS, DRY,
pisanie kodu wysokiej jakości,
umiejętność pracy w grupie (konsultowanie newralgicznch zmian w kodzie),
wysoko rozwinięte umiejętności analityczne, umowżliwiające samodzielne werfikowanie wymagań biznesowych oraz poprawne interpetowanie intencji zleconych zadań,
rozwinięte zdolności komunikacyjne (o problemach rozmawiamy od razu gdy wystąpią i staramy się rozwiązać je razem),
umiejętność praktycznego korzystania z BPMN, draw.io itp.,
znajomość języka polskiego minimum C1

Mile widziane
znajomość Java (17+)
znajomość i doświadczenie w pracy z R2DBC,
znajomość Spring/Spring Boot w tym Security, WebFlux
rozumienie protokołu oAuth 2.0
doświadczenie w migracji kodu
doświadczenie w pracy z Kafka

Ogólnie mam wrażenie, że w najgorzej płacących firmach wymagania są najwyższe, a mimo to znajdują jakichś ludzi.

Mam doświadczenie w rekrutacjach po obu stronach. Zdarzało mi się widzieć wczorajszych kandydatów. Ale pierwszy raz się zetnkąłem ze skacowaną rekruterką. Spóźniona, zaspana, w trakcie rozmowy musiała przerwać "bo kurier". No i miałem okazję pierwszy raz w życiu podejść (i polać kompletnie) test codility. Jeżeli faktycznie ktoś zatrudnia programistów w oparciu o to, że pamiętają jak otworzyć plik w Javie, to trochę chyba nie chcę tam pracować.

Jakieś może 2 lata temu jak współuczestniczyłam w rekrutacjach, to miałam dwie rekrutacje ustawione w tym samym dniu z krótką (chyba 30 minut) przerwą pomiędzy.
Efekt - 1 godzina na rekrutację, to mało, rozmowa ucięta trochę na siłę, bo trzeba przerwę i następna rozmowa umówiona. Po rekrutacjach tego samego dnia przyszło mi pisać podsumowanie i ocenę obu kandydatów i już mi się obie rekrutacje mieszały, który kandydat co powiedział.

Później gdy już prowadziłam rekrutacje, nie ustawiałam nigdy 2 rozmów w ten sam dzień i zawsze mam margines by zostać ciut dłużej po rozmowie.
Jak masz rekrutację za rekrutacją, to trudno mieć entuzjastyczne podejście (nawet jak normalnie nie mam entuzjazmu, to nakładam maskę trochę bo wiem, że rekrutacja działa w obie strony). Jestem przekonana, ze druga strona czuje jak się do rekrutacyjni podchodzi bardziej otwarcie aniżeli rekrutacja za rekrutacją i nawet nie pamiętasz cv kandydata jako rekruter.
Oczywiście w przypadku HR, to jest to wpisane w specyfikę ich pracy (masowa obsługa), ale już dalsze etapy czy rozmowa techniczna, no to dobrze jakby nie było poczucia obsługi taśmowej kandydatów.

A z WTF, to ostatnio miałam rekrutację wraz z managerem. I ten manager nawija jak my nie dyskryminujemy ludzi itp, dla mnie to byłby od razu red flag, jeśli na rozmowie rekrutacyjnej manager tłumaczy się, że nie dyskryminują ludzi. Nie jestem pewna czy on to tłumaczył kandydatowi czy mi, ale rynek jest na tyle zły, że kandydat przyjął ofertę mimo tej niezręcznej sytuacji.

Skoro skręcamy trochę na drugą perspektywę to nie cierpię rekrutacji z pozycji rekrutera. Firma najczęściej narzuca mi jak ma wyglądać rozmowa/proces, czy mogę tylko zadawać pytania, pokazać kod, wymagać live codingu itd. To wszystko jest zwykle narzucone. Jeśli chodzi o feeback to różnie czasami pisałem swoje odczucia w 3-4 zdania. Czasami dawali mi jakieś templatki do wypełniania gdzie miałem ocenić skille. Dla mnie ocena skilli na fullstacka gdzie muszę zobaczyć czy kandydat umie coś z frontu, coś z backendu, czy ogarnia CI/CD a nie daj boże jeszcze chmurę i zrobić to rzetelnie w 1h to jakiś dramat. Łatwo odsiać ludzi którzy są z przypadku i nic nie umieją, ale znaleźć w ten sposób kogoś dobrego to też nie można. Czasami miałem rekrutacje że klepie pytania top 50 interview jako wstęp a jeśli kandydat przebrał w miarę ok to potem kilka własnych o szczegóły (starałem się bez kruczków, raczej rzeczy na logikę), jeśli firma tak ułoży proces, że mam tylko zadawać pytania to co lepszego mogę zrobić? Z drugiej strony obok powstała cała branża która sprzedaje kursy "jak zdobyć pracę w IT" co samo w sobie jest patologią, ludzie na pamięć zakuwają letcody i system designy gdzie rozwiązania są wszędzie takie same (żeby rekruter był zadowolony) tylko inne nazwy i rodzaje systemów. Oczywiście to też nie jest dobry sposób na sprawdzenie kandydata, bo weryfikuje jedynie jego determinację a nie realne umiejętności i wiedzę. Kiedyś ktoś wymyślił zadania domowe, może to miało sens w 2010 gdzie kandydat mógł się popisać swoją wiedzą, potem podyskutować o kodzie, teraz w dobie LLMów i ludzi którzy próbują się dostać do branży bocznymi drzwiami (niech ktoś mi napiszę projekt) nie ma to żadnego sensu. Pomijając już zupełnie aspekt bezpłatnej pracy. I tak kręcimy się w kółko: pytania teoretyczne można wykuć, zadania domowe można zlecić, live coding stresuje i nie oddaje realnej pracy, a na dogłębną rozmowę techniczną brakuje czasu. Jak ktoś ma jakieś pomysły które faktycznie są w stanie zweryfikować rzetelnie kandydata w 1-1,5h to czekam :). Nie lubię tego robić też dlatego, że czasami można odrzucić naprawdę niezłą osobę (a wziąć kogoś gorszego bo on akurat się wstrzelił), bo akurat nie wstrzeliła się w to, o co pytamy. Ktoś może być świetnym programistą, ale nie pamiętać na zawołanie różnicy między call a apply, albo zablokować się na głupim pytaniu przez stres. I co – odpalam go, bo nie trafił w moje 10 pytań z listy? Świat IT jest jeszcze mały – za pół roku to on może rekrutować mnie :)

TTA120 napisał(a):

Skoro skręcamy trochę na drugą perspektywę to nie cierpię rekrutacji z pozycji rekrutera. Firma najczęściej narzuca mi jak ma wyglądać rozmowa/proces, czy mogę tylko zadawać pytania, pokazać kod, wymagać live codingu itd. To wszystko jest zwykle narzucone. Jeśli chodzi o feeback to różnie czasami pisałem swoje odczucia w 3-4 zdania. Czasami dawali mi jakieś templatki do wypełniania gdzie miałem ocenić skille. Dla mnie ocena skilli na fullstacka gdzie muszę zobaczyć czy kandydat umie coś z frontu, coś z backendu, czy ogarnia CI/CD a nie daj boże jeszcze chmurę i zrobić to rzetelnie w 1h to jakiś dramat. Łatwo odsiać ludzi którzy są z przypadku i nic nie umieją, ale znaleźć w ten sposób kogoś dobrego to też nie można. Czasami miałem rekrutacje że klepie pytania top 50 interview jako wstęp a jeśli kandydat przebrał w miarę ok to potem kilka własnych o szczegóły (starałem się bez kruczków, raczej rzeczy na logikę), jeśli firma tak ułoży proces, że mam tylko zadawać pytania to co lepszego mogę zrobić? Z drugiej strony obok powstała cała branża która sprzedaje kursy "jak zdobyć pracę w IT" co samo w sobie jest patologią, ludzie na pamięć zakuwają letcody i system designy gdzie rozwiązania są wszędzie takie same (żeby rekruter był zadowolony) tylko inne nazwy i rodzaje systemów. Oczywiście to też nie jest dobry sposób na sprawdzenie kandydata, bo weryfikuje jedynie jego determinację a nie realne umiejętności i wiedzę. Kiedyś ktoś wymyślił zadania domowe, może to miało sens w 2010 gdzie kandydat mógł się popisać swoją wiedzą, potem podyskutować o kodzie, teraz w dobie LLMów i ludzi którzy próbują się dostać do branży bocznymi drzwiami (niech ktoś mi napiszę projekt) nie ma to żadnego sensu. Pomijając już zupełnie aspekt bezpłatnej pracy. I tak kręcimy się w kółko: pytania teoretyczne można wykuć, zadania domowe można zlecić, live coding stresuje i nie oddaje realnej pracy, a na dogłębną rozmowę techniczną brakuje czasu. Jak ktoś ma jakieś pomysły które faktycznie są w stanie zweryfikować rzetelnie kandydata w 1-1,5h to czekam :). Nie lubię tego robić też dlatego, że czasami można odrzucić naprawdę niezłą osobę (a wziąć kogoś gorszego bo on akurat się wstrzelił), bo akurat nie wstrzeliła się w to, o co pytamy. Ktoś może być świetnym programistą, ale nie pamiętać na zawołanie różnicy między call a apply, albo zablokować się na głupim pytaniu przez stres. I co – odpalam go, bo nie trafił w moje 10 pytań z listy? Świat IT jest jeszcze mały – za pół roku to on może rekrutować mnie :)

Bardzi celne uwagi. Ja kiedyś na takiej pogadance odpowiedziałem na bardziej złożone pytania z Javy i Springa a gdy rekruter mnie zapytał "czym się różni klasa abstrakcyjna od interfejsu" to miałem pustkę w głowie.

Żadna metoda rekrutowania nie jest dobra. Ja to sprowadzam do tego na co firma chce wydać pieniądze i ile chce ich wydać. Albo wydajesz na rekrutowanie i szukanie kandydatów, albo robisz prosty szybki check i idziesz trochę w ciemno zatrudniając kandydata i płacisz mu wynagrodzenie/fakturę. Po krótkim czasie widzisz czy się nadaje i czy nie.

Więc albo kasa idzie na żmudne procesy rekrutacyjne albo na zatrudnianie ludzi po krótkiej weryfikacji i sprawdzasz ich w boju. Ja się skłaniam ku tej drugiej metodzie w myśl zasady skills can be taught, but attitude can't. To czy ktoś zna wszystkie regułki, czy umie leet code czy odwali darmowe zadanie domowe nie ma znaczenia. Jak ktoś nawet wszystko technicznie umie ale jest chamem to nie chcesz go w zespole. Jak ktoś ma braki ale jest ich świadomy i można się z nim dogadać to nauczy się tego co jest wymagane w projekcie i będzie robił robotę. A na rozmowie jesteś w stanie wyczuć czy ktoś jest perdolniety czy nie.

PS. 10 lat temu wystarczyło znać obiektowość z Javy by dostać robotę. Dziś technologii przybylo perdylion. Nikt nie wie wszystkiego o wszystkim, zwyczajnie się nie da. Trzeba znać ogólny koncept i umieć szukać rozwiązań, szczegóły wygooglować, dopytać jakiś model językowy, poprosić w zespole o pomoc. Tak działa zdrowa organizacja.

tefu napisał(a):

Bardzi celne uwagi. Ja kiedyś na takiej pogadance odpowiedziałem na bardziej złożone pytania z Javy i Springa a gdy rekruter mnie zapytał "czym się różni klasa abstrakcyjna od interfejsu" to miałem pustkę w głowie.

To pytanie to smutny żart rekrutacji z Javy. Chociaż na ileś tam rozmów technicznych w ostatnim czasie nikt go mi nie zadał. Patrząc z jakiejś perspektywy, to jest nawet ciekawe, bo można się wykazać pewną znajomością zasad kompozycji aplikacji, wzorców projektowych itd. Ale w większości przypadków pytającym chodziło o odpytanie z jakichś pierdół typu konstruktory, pola klasy i podobne bzdety.

Z takich błahostek, to poległem na pytaniu o kolejność wykonywania się konstruktorów w Javie, bo jednak wolno, ale się uczę i od chyba 10 lat nie wpadłem na to, żeby zrobić sobie krzywdę i używać dziedziczenia.

Żadna metoda rekrutowania nie jest dobra. Ja to sprowadzam do tego na co firma chce wydać pieniądze i ile chce ich wydać. Albo wydajesz na rekrutowanie i szukanie kandydatów, albo robisz prosty szybki check i idziesz trochę w ciemno zatrudniając kandydata i płacisz mu wynagrodzenie/fakturę. Po krótkim czasie widzisz czy się nadaje i czy nie.

Żadna metoda nie jest idealna. Umiejętności techniczne jeszcze jakoś da się sprawdzić, ale tego czy z konkretną osobą da się pracować już nie bardzo. Ostatecznie osoby o toksycznych osobowościach potrafią całkiem nieźle udawać przez tę godzinę normalnych.

PS. 10 lat temu wystarczyło znać obiektowość z Javy by dostać robotę. Dziś technologii przybylo perdylion. Nikt nie wie wszystkiego o wszystkim, zwyczajnie się nie da. Trzeba znać ogólny koncept i umieć szukać rozwiązań, szczegóły wygooglować, dopytać jakiś model językowy, poprosić w zespole o pomoc. Tak działa zdrowa organizacja.

Jeżeli komuś się przyda, to główne wątki z jakimi się zetknąłem, to raczej jakieś poboczne technologie, bazy, kolejki. Co zaskakujące często pytano mnie o wielowątkowość.

piotrpo napisał(a):

Żadna metoda nie jest idealna. Umiejętności techniczne jeszcze jakoś da się sprawdzić, ale tego czy z konkretną osobą da się pracować już nie bardzo. Ostatecznie osoby o toksycznych osobowościach potrafią całkiem nieźle udawać przez tę godzinę normalnych.

Też prawda, że ktoś może chwile dobrze poudawać.

Ja uważam, że lepiej przepalać kasę zatrudniając kogoś szybko, bo wtedy przynajmniej masz pewność czy nadaje się do pracy czy nie.

A robiąc 20 etapów, testów coś tam weryfikujesz, mniej lub więcej a ostateczny sprawdzian i tak przyjdzie w pracy. Więc przy długim procesie rekrutacyjnym płacisz dwa razy, za proces i potem za zatrudnienie. Po wielu testach możesz mieć jakąś większą pewność, że ktoś ma taką czy inną wiedzę. Natomiast po tym wszystkim i tak może się okazać, że człowiek jednak nie pasuje. A długie rekrutacje zniechęcają wielu kandydatów. Ci szczególnie dobrzy raczej nie chcą się babrać w coś takiego. Jak masz 20 lat doświadczenia i jesteś już po 40stce czy bliżej 50tki to nie chce Ci się siedzieć jak na egzaminie na studia będąc odpytywanym przez kogoś 20 lat młodszego.

Jestem zwolennikiem podejścia fail fast.

W firmie której pracuje mamy 3 etapu rekrutacji (tak było od zawsze)

1. rozmowa z HR
2. Rozmowa z Kierownikiem (przyszłym w sumie),
3. Rozmowa techniczna 2.5h z przyszłymi kolegami z pracy (3 z różnych zespołów). + live coding ale... live coding gdzie masz totalną dowolność, zależy nam na sprawdzeniu jak dochodzisz do rozwiązania i z jakich narzędzi korzystasz (napisanej prostej appki 20-30 linikowej) Możesz użyć AI, możesz u żyć Google wszystkiego. Ważny jest efekt końcowy i sposób wypracowania wyniku. Jeśli użyłeś AI ważne żebyś potrafił opowiedzieć co to AI zrobiło itp...

Mnie też tak rekrutowali i stwierdzam że to była jedna z lepszych rekrutacji na jakich byłem. Fakt, faktem byłem wykończony po tej rozmowie. Ale była na prawde rzeczowa i techniczna, a nie pytanie o klasy abstrakcyjne itp...

Szkoda że tak mało firm robi w podobny sposób. Marnują swoje pieniądze i innych i swoją reputacje. Nigdy tego nie rozumiałem.

No to jestem po pierwszym od chyba 10 miesięcy interview. Gość mnie odpytywał z adnotacji Spring i Hibernate xD
Coś tam wiedziałem coś tam nie wiedziałem.
Pierwsze interview po długiej przerwie zawsze jest najgorsze bo sobie trzeba przypomnieć te wszystkie duperele. Notatki zrobione, doczytam i jedziemy dalej xD
Żeby było śmieszniej w kontekście mojego wcześniejszego posta, już drugie pytanie jakie padło na rozmowie było o różnice między interfejsem a klasą abstrakcynją ;-)

Następnym razem odpowiedz

Klasa abstrakcyjna i interfejs w Javie pełnią podobną rolę – pomagają budować wspólną strukturę dla wielu klas – ale ich znaczenie i możliwości zmieniały się na przestrzeni lat, dlatego dziś różnice między nimi nie są już tak ostre jak kiedyś.

Na początku istnienia Javy interfejs był pomyślany jako czysty kontrakt. Określał jedynie, co dana klasa powinna udostępniać, bez narzucania jak ma to być zrobione. Klasa abstrakcyjna z kolei od początku służyła jako częściowo zaimplementowana klasa bazowa, pozwalająca dzielić wspólną logikę i stan pomiędzy klasami potomnymi. Ta różnica była kiedyś bardzo wyraźna.

Z biegiem lat Java ewoluowała i interfejsy zaczęły przejmować część cech klas abstrakcyjnych. Najpierw pojawiła się możliwość dodawania metod z implementacją, później metod statycznych i prywatnych. Sprawiło to, że interfejs przestał być wyłącznie zbiorem deklaracji, a zaczął zawierać także pewne elementy zachowania. Mimo tego nadal nie stał się pełnoprawną klasą – nie przechowuje stanu obiektu i nie posiada konstruktorów.

Klasy abstrakcyjne w tym czasie zachowały swój pierwotny charakter. Nadal mogą mieć pola, konstruktory i pełną kontrolę nad dziedziczeniem, ale są ograniczone do pojedynczej hierarchii klas. Interfejsy natomiast od zawsze były projektowane tak, aby umożliwiać implementację wielu kontraktów jednocześnie, co z czasem okazało się bardzo przydatne przy projektowaniu elastycznych API.

Współczesna Java sprawia więc, że wybór między klasą abstrakcyjną a interfejsem nie wynika już tylko z różnic technicznych, ale raczej z intencji projektowej. Klasa abstrakcyjna sugeruje bliską relację i wspólne wnętrze obiektów, natomiast interfejs – pewną rolę lub zdolność, którą klasa może przyjąć. To, że oba te mechanizmy zmieniały się i rozwijały na przestrzeni kolejnych wersji Javy, pokazuje, że ich granice są płynne, a decyzja o użyciu jednego z nich zależy dziś bardziej od koncepcji niż od sztywnych ograniczeń języka.

Ziomek po odpowiedzi zapomni to co mówiłeś na początku i stwierdzi że umiesz

szok napisał(a):

1. Rozmowa techniczna 2.5h z przyszłymi kolegami z pracy (3 z różnych zespołów). + live coding ale... live coding gdzie masz totalną dowolność, zależy nam na sprawdzeniu jak dochodzisz do rozwiązania i z jakich narzędzi korzystasz (napisanej prostej appki 20-30 linikowej) Możesz użyć AI, możesz u żyć Google wszystkiego. Ważny jest efekt końcowy i sposób wypracowania wyniku. Jeśli użyłeś AI ważne żebyś potrafił opowiedzieć co to AI zrobiło itp...

Takie coś to rozumiem. Dużo czasu, możesz korzystać ze wszystkiego tak jak na codzień w pracy. Jest w tym sens. Bo odpytywanie ze znajomości na pamięć adnotacji ze Springa, czy robienie codility na czas, czy darmowych zadań domowych, które nie wiadomo czy ktoś w ogóle sprawdza to jest absurdalne. A tak jak u Ciebie jest live coding, live, czyli oboje siedzicie razem i pracujecie. Jest zaangażowanie ze strony kandydata ale też ze strony rekrutujących. Widać, że poważnie podchodzą do sprawy.

tefu napisał(a):

No to jestem po pierwszym od chyba 10 miesięcy interview. Gość mnie odpytywał z adnotacji Spring i Hibernate xD
Coś tam wiedziałem coś tam nie wiedziałem.

Szok, jeden dzień po tej rozmowie i jest oferta.
Moment później dzwoni pani z firmy numer dwa i umawia kolejne rozmowy. Dziś kolejne dwie rozmowy z firmy numer już odhaczone, na razie feedback pozytywny, opcjonalna trzecia rozmowa z menago.
Po tych dwóch dzisiejszych rozmowach, znowu telefon, dzowni firma numer trzy. Kolejna rozmowa po świętach.

Największym szokiem dla mnie jest ta pierwsza rozmowa, która uważam, że poszła bardzo średnio. A ze szczątków informacji jakie udało mi się wyciągnąć (bo projekt nowy i nikt nic nie wie) to zanosi się na bagno, więc pewnie dlatego szybko oferta, bo jest ktokolwiek kogo można upchnąć butem do projektu.