Załóżmy, że podchodzicie do rekrutacji do danej firmy, macie dobry opis stanowiska, a sama rozmowa rekrutacyjna to tak naprawdę ustalenie warunków i wytłumaczenie na czym konkretnie polega projekt i co będziecie w nim robić. Zero rozmowy technicznej, zadań, czy sprawdzania wiedzy na łamigłówkach z algorytmiki.
Jak postrzegalibyście takiego potencjalnego pracodawcę?
Zależy od umowy i od pracodawcy.
W jednej firmie nie miałem zadań. Umówiliśmy się, że po tygodniu tygodniu współpracy siadamy i zastanawiamy się, czy dalsza współpraca ma sens.
Zadania z algorytmiki nie oddają tych skilli jakie są potrzebne w projekcie. Jeśli pracodawca szuka kogoś z doświadczeniem, kogoś kto już ma konkretną wiedzę to powinien na tej wiedzy się się skupić, a nie algorytmach. Natomiast algorytmika to nie zbrodnia, ale rzecz jaka warto rozpatrzeć jak mamy juniora, w ten sposób idzie ocenić potencjał do chłonięcia wiedzy.
Ja z rozmowami mam pecha. Na rozmowach dostaje ciekawsze zadania niż te jakie pojawiają się w projekcie.
Dominik Olszewski napisał(a):
Zero (...) sprawdzania wiedzy na łamigłówkach z algorytmiki.
Łamigłowki nie sprawdzają wiedzy tylko umiejętność rozwiązywania łamigłówek. Jak mnie pytają o łamigłówki to są skresleni. Jak pytają o wiedze to znaczy że jest szansa na ciekawą pracę
Ja to nie wyobrażam sobie, jak można kogoś zatrudnić na stanowisko techniczne bez sprawdzenia jego kompetencji choćby w minimalnym stopniu. Nie mówię o algorytmach czy zadaniach na czas, ale o zwykłej rozmowie z zagadnień technicznych. Po świecie chodzi zbyt dużo cwaniaczków którzy to potrafią pięknie opowiadać o mikroserwisach, chmurach, DDD, TDD, architekturze, a jak przychodzi do praktyki to nagle okazuje się, że ledwo co umie. A zatrudniać ludzi jak leci na jakieś okresy próbne i sprawdzać jak sobie radzą w faktycznej robocie też jest bez sensu bo są różne projekty o różnym stopniu złożoności. Do jednego ktoś się wdroży w 2 tygodnie bo prosta domena i w zasadzie crud, a do drugiego ta sama osoba będzie się wdrażać 2 miesiące bo domena złożona i 8 warstwowy monolit.
Pracodawcę jak i pracownika można ocenić tak naprawdę podczas okresu próbnego (który, przypominam, jest dla obu stron). Na rekrutacji obie strony mogą opowiadać bajki (chociaż potencjalnego pracodawcę trudniej przyłapać na kłamstwie) więc tak naprawdę dobra (czyli np. przypadek, gdzie wytknęliśmy błąd rekruterowi i z tego powodu nie przeszliśmy dalej to nie jest dobra rekrutacja) rekrutacja odsiewa (a przynajmniej powinna) nieogarów i ludzi bez wiedzy (nie mylić z doświadczeniem).
Także jeśli mamy kandydata z udowodnionym doświadczeniem x lat w danej technologii w której ma pracować u nas to wszelkie testy typu "jakie znasz wzorce" czy "napisz fizz-buzz w 37 językach" to jak dla mnie strata czasu. W tym przypadku dużo ważniejsze jest jak nowy człowiek wpasuje się w zespół, jak szybko ogarnie domenę biznesową i jak będą wyglądały jego taski. A to można sprawdzić dopiero w prawdziwym "boju". Oczywiście luźna rozmowa o projektach w jakich się uczestniczyło (po stronie kandydata) oraz omówienie projektu w którym kandydat ma pracować jest jak najbardziej potrzebne.
Powyższe dotyczy zatrudniania co najmniej "mocnego" mida a nie juniorów bo to trochę inna bajka i inne oczekiwania po obu stronach.
Taki jest moje zdanie.
markone_dev napisał(a):
Ja to nie wyobrażam sobie, jak można kogoś zatrudnić na stanowisko techniczne bez sprawdzenia jego kompetencji choćby w minimalnym stopniu.
Po świecie chodzi zbyt dużo cwaniaczków którzy to potrafią pięknie opowiadać o mikroserwisach, chmurach, DDD, TDD, architekturze, a jak przychodzi do praktyki to nagle okazuje się, że ledwo co umie.
W zasadzie nie sprawdzisz tego na rozmowie rekrutacyjnej, co najwyżej trafnymi pytaniami, które i tak nie do końca dadzą Ci obraz sytuacji. Jak zadasz pytania ogólne, to masz te "piękne opowiadania o mikroserwisach", a jak chcesz w praktyce sprawdzać "przyjście do praktyki" to nikt nie będzie tracił 2h na rekrutację z zadaniem testowym, bo potem i tak finalnie okazuje się jak wyżej, że to zadanie było ściemą, bo w praktyce w firmie masz pseudo mikroserwisy. Ewentualnie zadanie do domu może zrobić z tutoriala, więc potem i tak musisz poświęcić kolejną godzinę żeby kogoś z tego przepytać. Jak ktoś ma nieskończone zasoby na prowadzenie rekrutacji i czas, why not.
A zatrudniać ludzi jak leci na jakieś okresy próbne i sprawdzać jak sobie radzą w faktycznej robocie też jest bez sensu bo są różne projekty o różnym stopniu złożoności.
Do jednego ktoś się wdroży w 2 tygodnie bo prosta domena i w zasadzie crud, a do drugiego ta sama osoba będzie się wdrażać 2 miesiące bo domena złożona i 8 warstwowy monolit.
Czyli do prostego cruda i w zasadzie do 8 warstwowego monolitu też sprawdzasz czy ktoś umie w DDD, architekturę, chmury i mikroserwisy?
Byłem zarówno na rekrutacjach gdzie lecieli podstawowymi pytaniami technicznymi i były projekty sensowne jak i legacy kupa, jak i tam gdzie sobie gadaliśmy o doświadczeniu, jakiś projektach górnolotnie i podobnie trafiałem na sensowne projekty jak i legacy kupę. Ciężko o idealny środek.
Najlepiej wspominam rekrutacje, gdzie przepytywał mnie gościu, który jest liderem projektu i do niego rekrutuje sobie odpowiednich ludzi. Wie kogo szuka, wie co jest w projekcie i czego wymaga od człowieka, nie wali ściemy i najbardziej zależy mu aby znaleźć odpowiednie dopasowanie projekt-człowiek.
W zasadzie nie sprawdzisz tego na rozmowie rekrutacyjnej, co najwyżej trafnymi pytaniami, które i tak nie do końca dadzą Ci obraz sytuacji. Jak zadasz pytania ogólne, to masz te "piękne opowiadania o mikroserwisach",
Tak myślałem, że z tą częścią mojej wypowiedzi może być problem :D Generalnie da się to sprawdzić. Przykładowo, jeżeli szukasz do projektu kogoś z AWSem i przychodzi na rekrutację gość ze znajomością AWS potwierdzoną 5 certyfikatami, to zadając dwa, trzy konkretne pytania z życia wzięte, jesteś już w stanie odróżnić człowieka, który robi certyfikaty dla certyfikatów od człowieka, który ma certyfikaty i wiedzę, albo nie ma certyfikatów, a ma wiedzę bo spędził miesiące na konfigurowaniu różnych typów load balancerów w AWS na dziesiątki sposobów.
Czyli do prostego cruda i w zasadzie do 8 warstwowego monolitu też sprawdzasz czy ktoś umie w DDD, architekturę, chmury i mikroserwisy?
Nie. Chodzi mi o to, że w zależności od projektu proces wdrażania może trwać od tygodni do miesięcy. I nie da się obiektywnie ocenić czy ktoś się nadaje do roboty czy nie, po przykładowo 2 tygodniach pracy bo zależy to od wielu czynników.
Nie mówiąc o tym, że proces przyjmowania/zwalniania pracowników jest w wielu firmach złożony, zwłaszcza jeżeli mówimy o UOP. Więc nie dziwne że management nie chce przyjmować ludzi jak leci i zwalniać ich po tygodniu lub dwóch bo ktoś nie sprawdził na rekrutacji że typ ma 5 certów z AWS a nie odróżnia NLB od ALB.
Jeżeli to rekrutacja na juniora/mida to by mi się lampka zapaliła.
Moim zdaniem techniczne rozmowy mało sprawdzają, zwłaszcza jak ktoś ma już kilka lat doświadczenia. Jak np w przypadku juniora ma to jakiś sens to jak ktoś ma 5 - 10 lat doświadczenia to już średnio.
Dominik Olszewski napisał(a):
... a sama rozmowa rekrutacyjna to tak naprawdę ustalenie warunków i wytłumaczenie na czym konkretnie polega projekt i co będziecie w nim robić.
Ja mam właśnie na tapecie taki przypadek:
Tylko dwie uwagi: człowiek ma ponad 20 lat doświadczenia w IT i pierwsza umowa jest próbna na 3 m-c.
miałem 2 takie rekrutacje w życiu
obydwie spalone
pytań technicznych całe zero
były pytania, co robiłem, z czego jestem dumny, czego używałem, jakie projekty, jak wyglądał zespół itp
najbliższe techniczności pytania to były takie
a używałeś SQL-a?
a używałeś NoSQL-a?
a w czym kod pisałeś (w sensie edytora)?
a Git był?
itp
tylko tyle - bez wchodzenia w szczegóły
z tej drugiej rozmowy to mnie rozdupczył tzw. feedback - kolo dorobił sobie ideologię
żeby to zobrazować
to jakbym spytał czy masz prawo jazdy, tylko o to i nic więcej - odpowiedź na zasadzie TAK|NIE
w odpowiedzi usłyszał TAK
a potem opisał, że niestety nie bo owszem prawo jazdy jest, ale za mało jeździsz, nie lubisz ruchu lewostronnego(a będą wymagane wyjazdy do UK), nie lubisz nowych tras i jazdy po autostradach itp.
trochę to inaczej wygląda, jakbym się spytał o kategorię prawa jazdy, bym usłyszał że jest B, a ja w odpowiedzi powiedział, że dziękuję bo szukamy C+D
Dlatego dla mnie tego typu rekrutacje są dziwne, bo to nie wiadomo o co w nich chodzi
jakubek napisał(a):
tylko tyle - bez wchodzenia w szczegóły
z tej drugiej rozmowy to mnie rozdupczył tzw. feedback - kolo dorobił sobie ideologię
Dla wielu ludzi ważniejsze jest czy będzie dało się z tobą współpracować po ludzku niż to, że umiesz napisać zaje... kod do wyliczania ciągu Fibonacciego. Zwłaszcza w dużych firmach jak człowieka można nauczyć wielu aspektów technicznych - z miękkimi jest gorzej.
Dominik Olszewski napisał(a):
Załóżmy, że podchodzicie do rekrutacji do danej firmy, macie dobry opis stanowiska, a sama rozmowa rekrutacyjna to tak naprawdę ustalenie warunków i wytłumaczenie na czym konkretnie polega projekt i co będziecie w nim robić. Zero rozmowy technicznej, zadań, czy sprawdzania wiedzy na łamigłówkach z algorytmiki.
Jak postrzegalibyście takiego potencjalnego pracodawcę?
Myślę, że pozytywnie, jeśli byłaby krótka umowa próbna (np. miesiąc). Wtedy można byłoby sprawdzić w praktyce, jak wygląda tam praca. Powiedzmy sobie szczerze, że rozmowy techniczne zwykle nic programiście nie powiedzą o tym, jak faktycznie wygląda tam kod czy styl pracy. Na rozmowie będą ciekawe algorytmiczne wyzwania, a w pracy klepanie. Na rozmowie gadki o czystym kodzie, a w pracy spaghetti. Na rozmowie pieprzenie o Scrum i samoorganizujących się zespołach, a w pracy po prostu jeden wielki chaos i brak metodyki.
Ogólnie jakbym był pracodawcą, to chciałbym sprawdzić kandydata, żeby nie zatrudniać byle kogo, jednak jako kandydat czuję asymetrię informacyjną (firma więcej się dowiaduje o mnie i moich umiejętnościach niż ja o tym, jak faktycznie wygląda praca w danej firmie. Więc w efekcie firma ma jakieś podstawy do decyzji, czy wchodzić ze mną we współpracę, ja takich podstaw nie mam, mogę co najwyżej zachowywać ostrożny pesymizm i zakładać już na wstępie, że będzie brzydki kod, a projekt będzie nieudolnie zarządzany).
Natomiast zbyt duży nacisk na sprawdzanie wiedzy technicznej i zbyt wiele etapów rekrutacji to dla mnie tylko strata czasu. Wolałbym już pójść do firmy na jakiś jednodniowy demoday, mógłby być darmowy nawet i sprawdzić mięsko (i ja mógłbym zobaczyć, jak się tam pracuje i firma mogłaby zobaczyć, jak sobie radzę), a nie być odpytywanym jak na egzaminie, nie dowiadując się praktycznie niczego.
Sprawdzanie techniczne nie ma większego sensu. Najlepsi pracodawcy jacy mi się trafili byli właśnie z grupy rekrutacja w godzinę.
Tak powinno być. Jak ktoś chce pracować na danym stanowisku (a firma ma otwarte etaty), to powinien mieć taką możliwość od razu, a nie jakieś tam rozmowy techniczne. Po co to komu.
Najlepszy programista, z którym do tej pory pracowałem uważa, że nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy, wszystko dopiero w praniu wyjdzie. Im dłużej siedzę w IT, tym bliżej mi do tego poglądu. Jakiś czas temu pracowałem z gościem, naprawdę słabym + cwaniaczek + leniwiec + ma wyrąbane na to co robi, chyba najgorsze możliwe połączenie. Wiem, że przeszedł wcale niełatwą rekrutację. Szanuję gościa, który go rekrutował i się zastanawiam do dzisiaj, czy to biznesowo-modelowy look zmylił rektutera. Gość wygląda jak Adonis (trochę fizycznie podobny do rekrutera), czy jeszcze o coś innego chodzi. Ciekawy przypadek...
Kiko88 napisał(a):
Najlepszy programista, z którym do tej pory pracowałem uważa, że nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy, wszystko dopiero w praniu wyjdzie.
Bo się nie da. I to są nowe szaty cesarza. Każdy udaje, że się da, a wiadomo, że to w dużej mierze mrzonki.
No chyba, że weźmiesz kogoś, o kim wiadomo, że zna się na danej działce. Jak masz do zrobienia system operacyjny, to możesz Linusa Torvaldsa brać i masz gwarancję, że będzie umiał taki system operacyjny zrobić.
Tylko, że przeciętna rekrutacja to nie jest szukanie rock starów programowania, a łowienie anonimów i sprawdzanie, czy kumają czaczę. Więc jak można anonima sprawdzić w 2 godziny?
LukeJL napisał(a):
Tylko, że przeciętna rekrutacja to nie jest szukanie rock starów programowania, a łowienie anonimów i sprawdzanie, czy kumają czaczę. Więc jak można anonima sprawdzić w 2 godziny?
Jeśli progiem wejścia jest kuma / nie kuma to podstawowa rozmowa techniczna rozwieje te wątpliwości a godzina zupełnie na to wystarczy.
W przypadku poszukiwania Juniora na front-end kilka pytań załatwia sprawę.
W przypadku poszukiwania specjalisty oczywiście tak ławo nie będzie bo ryzyko podatności rekrutera na ściemę znacznie wzrasta i faktycznie dopiero w praniu wyjdzie.
Kiko88 napisał(a):
Najlepszy programista, z którym do tej pory pracowałem uważa, że nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy, wszystko dopiero w praniu wyjdzie.
Programiści nie są od rekrutowania ludzi zatem nawet najlepszy na świcie programista może nie dać rady poprawnie ocenić kandydata bo nie taka jest jego rola.
Jakoś nie mogę pojąć jakim cudem z założenia, że "nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy" przechodzimy do wniosku "nie warto sprawdzać w ogóle". W ciągu paru minut już czasami widać, że ma się do czynienia z dzbanem, wiadomo, że niektórym mało korona z głowy nie spadnie jak mają zrobić jakiegoś trywialnego taska w stylu FizzBuzz. Nawet jeśli taka rekrutacja przepuści ludzi, których nie powinna przepuścić to na pewno nie jest niekorzystna dla ludzi, którzy potrafią programować - nie przekonuje mnie, że dobry programista nie jest w stanie przejść normalnej technicznej rozmowy.
Saalin napisał(a):
Jakoś nie mogę pojąć jakim cudem z założenia, że "nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy" przechodzimy do wniosku "nie warto sprawdzać w ogóle". W ciągu paru minut już czasami widać, że ma się do czynienia z dzbanem, wiadomo, że niektórym mało korona z głowy nie spadnie jak mają zrobić jakiegoś trywialnego taska w stylu FizzBuzz. Nawet jeśli taka rekrutacja przepuści ludzi, których nie powinna przepuścić to na pewno nie jest niekorzystna dla ludzi, którzy potrafią programować - nie przekonuje mnie, że dobry programista nie jest w stanie przejść normalnej technicznej rozmowy.
+1 i normalna rekrutacja techniczna może nas ochronić przed pracą z kompletnymi nieogarami
+1 i normalna rekrutacja techniczna może nas ochronić przed pracą z kompletnymi nieogarami
W jaki sposób?
S4t napisał(a):
randomize111 napisał(a):
Saalin napisał(a):
Jakoś nie mogę pojąć jakim cudem z założenia, że "nie da rady sprawdzić dobrze gościa podczas godzinnej, dwugodzinnej rozmowy" przechodzimy do wniosku "nie warto sprawdzać w ogóle". W ciągu paru minut już czasami widać, że ma się do czynienia z dzbanem, wiadomo, że niektórym mało korona z głowy nie spadnie jak mają zrobić jakiegoś trywialnego taska w stylu FizzBuzz. Nawet jeśli taka rekrutacja przepuści ludzi, których nie powinna przepuścić to na pewno nie jest niekorzystna dla ludzi, którzy potrafią programować - nie przekonuje mnie, że dobry programista nie jest w stanie przejść normalnej technicznej rozmowy.
+1 i normalna rekrutacja techniczna może nas ochronić przed pracą z kompletnymi nieogarami
W jaki sposób?
Np u mnie był jeden kandydat (kilka lat doświadczenia) który miał dobrze gadane i zrobił bardzo dobre wrażenie na pierwszy etapie, ale jak był etap techniczny to nie dość że jego kod był bardzo słaby (jak początkujący junior) to jeszcze nie umiał wytłumaczyć dlaczego wybrał dane podejście itd. - jak coś takiego byś wyłapał bez rozmowy technicznej (oprócz tego że pewnie poleciałby po jakimś czasie)?
Rozmowa techniczna pozwala też ustrzec się przed ludźmi z drugiej strony, na przykład aza każdym razem przy pytaniu o testy widać czy ktoś jest mocksturbatorem ("wszystkie zależności muszą być mockowane") czy integratorem ("wszystko mamy na testcontainers, tylko w ten sposob wiadomo czy dziala"). To nawet nie kwestia czy to dobrze czy to źle, ale ma znaczenie w kontekście tego czy będzie pasować nam sposób w jaki pisze się tam kod. No i na rozmowie technicznej widać czy osoba z którą rozmawiamy jest na wyższym poziomie od naszego, ja bardzo dobrze wspominam rozmowy na których uczyłem się jakiś nowych rzeczy, za to źle wspominam takie na których była lista pytań i zero/minimalny feedback.
Nie do końca. Jeżeli ktoś 3 lata siedział np. w jakieś kontraktowni, utrzymał się, to nie ogarem raczej nie jest. Ja bardziej sprawdzam czy ktoś jest dobrym team playerem, czy jest w miarę pozytywny, ciekawy świata, easygoing (resztę mam w CV). Czytałem gdzieś na forum, ze ludzie pracujący w FAANGu latami nie mogą odejść np. z takiego Amazona w USA, bo np. nie są w stanie przejść po latach whiteboarding interview. I teraz pytania, czy jeżeli gościu 5 lat dał radę się utrzymać w Google, to takie interview ma jakikolwiek sens? JA prywatnie jak widzę, że rekruter sprawdza live coding to osobiście uważam, albo nie jest zbyt bystry, albo nie ma jeszcze za dużo doświadczenia i nie wie że to nie działa.. Nie musicie się tutaj ze mną zgadzać tym temacie :)
Jakby mi jakaś firma dała moją oczekiwaną stawkę bez żadnej weryfikacji, to ideolo :D co nie zmienia faktu, że nie darzyłbym tej firmy szacunkiem.
Brak rozmów technicznych jest normą np. w Japonii, co do samych rozmów technicznych i ich sensowności to pomimo iż na 100% nigdy się danej osoby nie sprawdzi to jednak da się odsiać bajkopisarzy. Brak rozmowy technicznej ocenił bym obojętnie, po prostu pracodawca bardzo wierzy że to co wrzuciłeś w CV to prawda
Czyli na 4p mamy tyle samo ludzi technicznych, co nietechnicznych. Gratulacje!
Zauważyłem że im więcej expa mam tym mniej weryfikacji technicznych mam a tylko takie pogawędki o projekcie i te rekrutacje kończą się sukcesem więc w sumie nie wiem, zależy od sytuacji czasem może faktycznie odpuściłbym weryfikacje techniczną czasem przeciwnie. Więc w sumie nie zaznaczam żadnej opcji.
EDIT:
Ale ja nie jestem tak ufny w stosunku do ludzi i jednak bym był za tym żeby jakąś weryfikacje techniczną robić.
Ja dostałem od google zaproszenie do rekrutacji, zrobiłem większość zadań, ale mnie depresja dopadła i się zatrzymałem, ale chyba zrobię resztę od następnego tygodnia.
Potrzebuję tej pracy boję się, że odpadnę przy białej tablicy, nie mam sił już ciągłych niepowodzeń przeżywać, a w sumie to oni mnie zaprosili, a z tego co czytałem mimo zewnętrznego zaproszenia można odpaść.
Miałem taki przypadek kilka lat temu w małej firmie. W firmie nie było innych programistów zajmujących się technologią w której pracowałem.
Do dzisiaj wspominam to miejsce pracy jako jedno z najlepszych, jeśli nie najlepsze w całej dotychczasowej karierze.