loza_wykletych napisał(a):
Wprowadźcie w końcu te związki zawodowe/gildie z powrotem i problem z głowy. Każdy kto chce iść wyżej niż codemonkey będzie musiał swoje odcierpieć jako czeladnik a później wystarczy tylko rzut oka na listę pod kim się uczył żeby wiedzieć czego się spodziewać.
A te gildie to nie są teoretycznie uniwersytety?
I znów rozbija się wszystko o to że w Polsce nie ma oficjalnie szkół zawodowych/studiów na klepaczy CRUDów :(
KamilAdam napisał(a):
A te gildie to nie są teoretycznie uniwersytety?
Teoretycznie tak - problem jest taki że pewnie i tutaj znajdzie się wiele osób co stwierdzi że owszem studia świetnie przygotowują teoretycznie a później trafia taka osoba do pracy, awansuje i 10 lat później masz hacking culture à la FB w kodzie.
I znów rozbija się wszystko o to że w Polsce nie ma oficjalnie
szkół zawodowych/studiów na klepaczy CRUDów :(
Można by podciągnąć pod to uczelnie prywatne, ewentualnie z jakichś mniejszych mieścin. Pytanie brzmi - wiedząc że nawet średnich specjalistów ciężko jest wyhaczyć w kadrze dydaktycznej top uczelni w Polsce to jakie miałbyś zdanie o takim człowieku a losowym noname po butkampie?
I tak przecież w praktyce stosuje się nieformalny system gildiowy - referencje mają priorytet nad otwartymi rekrutacjami, wielu ludzi jest zgarnianych do pracy przy okazji konferencji, wspólnych warsztatów. Jakby to sformalizować to przynajmniej zniknęły by pytanie w style Jestem w 3 trymestrze ciążowym.
loza_wykletych napisał(a):
KamilAdam napisał(a):
A te gildie to nie są teoretycznie uniwersytety?
Teoretycznie tak
Uniwersytety trochę działają za granicą, jak ktoś w USA ma dobrą szkołę, to ma większe szanse, ale niestety i tak musi przechodzić przez cyrk rekrutacyjny. Nie ma też raczej certyfikatów, które byłyby szeroko szanowane, większość skupia się na wybranej technologii, co nie ma przełożenia na "ten gość jest dobrym inżynierem oprogramowania". Do tego dochodzi dziwne przeświadczenie, że jak ktoś nie ma X lat w nowym frameworku, to sobie nie poradzi, więc ludzie mający wiele lat doświadczenia wcale nie mają łatwiej (a często mają trudniej, bo dostają na rekrutacji pytanie o sortowanie, albo odpadają ze względu na wstawianie entera przed klamerką). Pewnie wszystkie te problemy znikną z czasem, jak branża dorośnie i zwolni z odkrywaniem koła na nowo co miesiąc.
@Afish - akurat amerykanie raczej wiedza jak rekrutowac.
Startowalem do G, M$ i Amazing i tylko ten ostatni mial jakies dziwne pytania w rodzaju "scenka sytuacyjna". Ale wszystkie ww mialy ciekawe zadanka, rozwijajace, do tego stopnia ze je potem rozwiazywalem z ciekawosci nawet w domu.
Polskie firmy maja kilka poziomow slabsze rekrutacje (bez wyjatkow).
Rozumiem przypadek, że ktoś się przebranżawia i łapie np. Nokia Academy, wtedy każde pytanie to wyzwanie.
Rozumiem przypadek, że ktoś ma ambicję pracować w USA FAANG wtedy każdy etap rekrutacji to emocje.
Ale u nas, we Wrocławiu, w Warszawie albo w Krakowie? Zaproszenie z szablonu na rekrutację, odpowiadasz, jest telefon i pytasz. Firma? Rekruterka nie może ujawnić. Kasa? Informacja nawet w zakresie bardzo szerokich widełek. Gdzie mają biura, bo miasta są duże? :) Nie da rady powiedzieć. Pytanie jaka rotacja w projekcie wywołuje reakcję jak bym zapytał na pierwszej randce o... ;)
Dwie reakcje.
Albo jesteśmy seksoholikami, alkoholikami, rekrutoholikami i musimy gonić za kobietami, pić, szukać nowych projektów bo nas coś zżera od środka.
Abo spuszczamy wodę nad takimi ofertami, wtedy znikają problemy ze złymi rekruterami, haerami, firmami.
*- Co pan wie o naszej firmie i dlaczego chciałby pan u nas pracować?
Afish napisał(a):
Przesłuchiwania nie robię, a przynajmniej jeszcze nikt z kandydatów nie dał mi takiego feedbacku. Ja im nawet wysyłałem pytania przed rozmową, żeby wiedzieli, z czego się przygotować. Może mam skrzywione podejście, bo nie uważam, że napisanie kawałka kodu na tablicy jest jakoś stresujące, ale jeżeli ktoś tak ma, to może lepiej nad tym popracować w wolnym czasie?
Pójście na rozmowę raz w miesiącu nie jest jakoś strasznie wymagające
A może niektóre przypadki, które opisujesz, to tacy, którzy przychodzili poćwiczyć zanim pójdą do swojej wymarzonej firmy?
poza tym raczej wiadomo, że na rekrutacjach trafia się kodowanie na kartce, no i zawsze można zapytać osobę z HR, jak będzie wyglądał proces.
No, tylko nigdy nie ma gwarancji, że odpowiedź będzie miała związek z rzczywistością.
Tak, tylko to zajmuje masę czasu. Dla kandydata jest to problem, szczególnie w przypadku procesu na miejscu, bo trzeba dojechać, klepać jakieś tam crudy, do tego ludzie potem narzekają, że nie mają swojego IDE, klawiatury, skrótów klawiszowych, swojego krzesełka i kubeczka A dla rekruterów też jest to masa czasu, która w większości jest zmarnowana, bo większość kandydatów się nie nadaje.
Nie, to nie jest problem, review można zrobić zdalnie i robi się je tylko tym, którzy wykonają zadanie najlepiej, czyli z góry można założyć, że to będzie kilka osób. Czas spędzony na review kodu kilku osób przez rekrujuącego będzie na pewno krótszy niż rozmowy (z tablicą albo bez) z kilkudziesięcioma kandydatami.
Rekrutacja to proces obustronny, kandydat też ma prawo dowiedzieć się o firmie jak najwięcej. Jeżeli dla Ciebie ważne są spacje przed nawiasami, to mogłeś poprosić o przejrzenie ich kodu.
Tak, tylko dopóki się tego nie zobaczy, to ciężko raczej się spodziewać, że ktoś kiedykolwiek mógł wpaść na pomysł walki ze światowym standardem oraz IDE.
A w kodzie na publicznym GH takich cudów nie mają.
Dla mnie proces rekrutacyjny to za mało, po okresie próbnym powinna być sensowna rozmowa z współpracownikami i potem odstrzał kandydata, jeżeli ten się nie nadaje, a z takim podejściem można zrobić prostszy i krótszy proces.
Jeszcze prostszy i krótszy niż te 2h na review kodu z zadania domowego?
somekind napisał(a):
Afish napisał(a):
popracować w wolnym czasie?
Pójście na rozmowę raz w miesiącu nie jest jakoś strasznie wymagająceA może niektóre przypadki, które opisujesz, to tacy, którzy przychodzili poćwiczyć zanim pójdą do swojej wymarzonej firmy?
Raz na miesiąc wyjechać na weekend we dwoje, pójść do fajnej knajpy na dobry obiad, wybrać się na wspólny wieczór...
To są tematy do zrobienia raz na miesiąc w wolnym czasie.
Nie zalicza się do nich regularne chodzenie na rekrutacje ani tym bardziej przygotowywanie się pod specyfikę takich comiesięcznych rekrutacji.
Chyba, że ktoś jest geekiem spędzającym życie przed monitorem.
Resztę podsumował @somekind
somekind napisał(a):
A może niektóre przypadki, które opisujesz, to tacy, którzy przychodzili poćwiczyć zanim pójdą do swojej wymarzonej firmy?
Może, to nic nie zmienia, bo z mojej strony proces wygląda tak samo.
No, tylko nigdy nie ma gwarancji, że odpowiedź będzie miała związek z rzczywistością.
To się tyczy wszystkich rekrutacji.
Nie, to nie jest problem, review można zrobić zdalnie i robi się je tylko tym, którzy wykonają zadanie najlepiej, czyli z góry można założyć, że to będzie kilka osób. Czas spędzony na review kodu kilku osób przez rekrujuącego będzie na pewno krótszy niż rozmowy (z tablicą albo bez) z kilkudziesięcioma kandydatami.
robi się je tylko tym, którzy wykonają zadanie najlepiej - a jak to ustalisz przed zrobieniem review? Zrobisz automatyczną testerkę? Metryki kodu? Codility?
Tak, tylko dopóki się tego nie zobaczy, to ciężko raczej się spodziewać, że ktoś kiedykolwiek mógł wpaść na pomysł walki ze światowym standardem oraz IDE.
A w kodzie na publicznym GH takich cudów nie mają.
Dlatego trzeba chodzić do różnych firm, dzielić się doświadczeniem z innymi i rozmawiać z ludźmi na konferencjach. To się nazywa doświadczenie.
Jeszcze prostszy i krótszy niż te 2h na review kodu z zadania domowego?
W długiej perspektywie jest prostszy i tańszy, bo jak kandydat jest słaby, to się go odpala po trzech miesiącach, a nie pozwala siedzieć przez lata. To jak z pisaniem testów, spowalnia pisanie kodu teraz, przyspiesza rozwijanie aplikacji później..
Nie zalicza się do nich regularne chodzenie na rekrutacje ani tym bardziej przygotowywanie się pod specyfikę takich comiesięcznych rekrutacji.
Dla mnie to jest inwestycja przynosząca wymierne tysiące złotych miesięcznie. Kwestia gustu, można chodzić na rekrutacje od wielkiego dzwonu, można cały czas obserwować oferty na rynku, rozwijać się w tej grze i łatwiej złapać atrakcyjne oferty, gdy wreszcie się pojawią. Te kilkanaście godzin rekrutacji rocznie można przeliczyć na konkretne pieniądze, trening jak każdy inny.
Afish napisał(a):
robi się je tylko tym, którzy wykonają zadanie najlepiej- a jak to ustalisz przed zrobieniem review? Zrobisz automatyczną testerkę? Metryki kodu? Codility?
Tak jest jak się pisze jednym okiem w pracy, najpierw pisałem o review/pair programming, potem skróciłem to do samego review (w moim domyśle przy udziale kandydata) i stąd zamieszanie, wybacz.
Żeby rozjaśnić, co ja mam na myśli:
W długiej perspektywie jest prostszy i tańszy, bo jak kandydat jest słaby, to się go odpala po trzech miesiącach, a nie pozwala siedzieć przez lata. To jak z pisaniem testów, spowalnia pisanie kodu teraz, przyspiesza rozwijanie aplikacji później..
Aha, to w takim razie Ty chyba piszesz o innym problemie niż ja. Nie spotkałem się z tym, że zatrudnienie kogoś jest wieczne i trzymaniem słabych ludzi latami.
somekind napisał(a):
Żeby rozjaśnić, co ja mam na myśli:
No to osobiście nie chce mi się bawić w tego typu rzeczy, moim zdaniem trwa to długo i nie daje wiele korzyści, chyba, że szukamy typowego gościa do klepania, co weźmie taska z jiry, wyrzeźbi i porobione. Jak już chcemy sprawdzić resztę elementów inżynierii, to i tak trzeba gadać.
Aha, to w takim razie Ty chyba piszesz o innym problemie niż ja. Nie spotkałem się z tym, że zatrudnienie kogoś jest wieczne i trzymaniem słabych ludzi latami.
To ja mam odwrotnie, pewnie na palcach jednej ręki mógłbym policzyć osoby, które zostały zwolnione, bo sobie nie radziły. Można byłoby pomyśleć, że to oznacza, że rekrutacja jest fenomenalna, no ale tak nie jest.