Jak wygląda rekrutacja na kogoś wyżej niż junior?

@Krzywy Krawiec cieszę się, że miałeś udane rekrutacje, na których miałeś taski do zakodowania (ja osobiście niestety miałem w takich przypadkach mniej szczęścia jeżeli chodzi o firmy, które były na ogół januszsoftami), ale ja piszę o czymś zupełnie innym. Wiem, że nie jesteś zdesperowany, pytanie tylko, czy rekruterzy też to wiedzą. Pamiętaj, że nie tylko ważne jest to jak Ty siebie oceniasz, ale również to jak inni Ciebie oceniają. A będą (to tak w nawiązaniu do desperacji).

Spinaczer napisał(a):

@Krzywy Krawiec cieszę się, że miałeś udane rekrutacje, na których miałeś taski do zakodowania (ja osobiście niestety miałem w takich przypadkach mniej szczęścia jeżeli chodzi o firmy, które były na ogół januszsoftami), ale ja piszę o czymś zupełnie innym. Wiem, że nie jesteś zdesperowany, pytanie tylko, czy rekruterzy też to wiedzą. Pamiętaj, że nie tylko ważne jest to jak Ty siebie oceniasz, ale również to jak inni Ciebie oceniają. A będą (to tak w nawiązaniu do desperacji).

Nie wiem dlaczego ktoś miałby tak kogoś oceniać jeśli tak po prostu wygląda proces rekrutacyjny.
Inna sprawa, jakby okazało się, że 'zadanie' jest dużo większe i faktycznie januszsoft próbowałby zrobic na mnie pracę za darmo.
Ale coś takiego wyczułbym w momencie przesłania zadania i po zapoznaniu pewnie odmówił.

Ja staram się być sobą, jeśli coś nie wychodzi na rekrutacji to znaczy, że pewnie bym tam nie pasował i dobrze, że się ostatecznie nie dostałem ;)
W moim przypadku raczej aspekt nietechniczny o tym decyduje. Albo rozmowa z rekruterem płynie... lub kompletnie się nie układa.

(Sorry za chaotyczny wpis i odpowiadanie nie po kolei, chyba powinienem założyć bloga)

Co do pytań logistycznych: w większości przypadków odpowiedź brzmi "to zależy". Przede wszystkim musisz sam wszystko poustawiać tak, żeby być w dobrej formie (fizycznej i psychicznej) na rozmowie i nie wzbudzić podejrzeń w obecnej firmie - jeśli na co dzień nie chodzisz w koszuli, to przyjście w garniturze i urwanie się wcześniej będzie podejrzane i może wpłynąć na traktowanie cię przez przełożonych. Najlepiej wziąć urlop i „pojechać” na Kanary, gdy już wszystko będziesz miał poustawiane.

Bardzo ważne: zawsze sprawdzaj temat podatków/urlopów/chorobowego/odpowiedzialności za fuck-upy konkretnego modelu współpracy. Wszystko jest w necie, ale wiele rzeczy nie jest oczywistych.

Co do przebiegu rekrutacji - znowu, "to zależy". Najlepszym podejściem jest po prostu zapytanie rekrutera na samym początku i przygotowanie się wg odpowiedzi. Jej brak lub odpowiedź niejasna, zbyt ogólnikowa lub (później) niepokrywająca się z rzeczywistością - to duży znak ostrzegawczy. Mówi to tyle, że firma nie ma jasno zdefiniowanych zasad pozyskiwania ludzi. A więc pewnie większości innych: nagradzania i awansowania pracowników, testowania nowych technologii, podejmowania decyzji dotyczących akceptowania/rozpoczynania/ubijania projektów, otrzymywania hajsu na rozwój itd. Nie chcesz pracować w firmie, gdzie nie wiesz czego się spodziewać i nigdy nie wiesz jak coś załatwić.

Zadania domowe, testy "whiteboard", pytania na temat singletonów i zasad SOLID czy Codility etc. - wszystko to może się pojawić i nie jest do końca złe, jednak wg mnie powinno się pojawić na początku rekrutacji w celu odsiania ewidentnych niewypałów, a nie jako główne decydujące kryterium. Osobiście zachowuję dystans do firm, które podejmują decyzję o zatrudnieniu wyłącznie lub głównie na podstawie umiejętności technicznych (sprawdzanych w jakikolwiek sposób – właściwie każdy nie daje specjalnych informacji o przydatności pracownika). Jeśli decydują tylko kryteria techniczne, to prawdopodobnie wylądujesz w grupie antyspołecznych freaków, bez kompetencji i woli do współpracy z kimkolwiek. Masz takich wielu na tym forum.

Fajnie jeśli firma próbuje sprawdzić umiejętności działania w sytuacjach analogicznych do tych, które pojawiają podczas normalnej pracy. Czyli nie implementowanie QuickSorta. Zrobienie tego jest trudne (bo wymaga świadomości, co naprawdę – a nie w teorii - robią ludzie w firmie), ale jeśli zauważysz, że rekrutujący cię ludzie próbują to zrobić – to dobry znak. Przykłady to: zadanie na rozmowie, który jest prawdziwym zadaniem, nad którym ktoś właśnie pracuje. Najlepiej: task, nad którym właśnie pracuje osoba zadająca pytanie. Z punktu widzenia osoby rekrutującej nie ma nic bardziej stymulującego (i zostającego w głowie!) niż dyskusja z kandydatem, która przydaje się w dalszej pracy po wyjściu z rozmowy. Jeśli na rozmowie rozwiążesz buga, nad którym męczy się rekrutujący, to nie masz lepszego sposobu pokazania, że nadajesz się do tej pracy.

Ale też nie warto przesadzać ze staraniem się za bardzo: robotę na pozycji ~regulara (średnio-doświadczonego), która zdefiniowała mi dalszą karierę, dostałem po nieprzespanej nocy, bo robiłem zadanie do innej firmy, na której bardzo mi zależało. Niewyspanie i dystans do oferty/firmy sprawiły, że byłem bardziej wyluzowany i otwarty niż zazwyczaj, co okazało się dość dobrze przyjęte. Na pytanie jaką bibliotekę/technologię/framework uważam za najbardziej wartościowy w swoim toolboxie odpowiedziałem, że java.util.collections i opisałem jak wielu programistów nie jest świadomych wielu właściwości i możliwości. Inne osoby chwaliły się najnowszymi frameworkami, o których było wiadome, że nie będą specjalnie przydatne. Pragmatyzm, świadomość konsekwencji własnych decyzji i doświadczenie „w boju” odróżnia juniora od seniora.

Co do angielskiego – sprawdzana (na ogół) jest swoboda wypowiedzi i łatwość komunikacji, nie jakieś wyszukane konstrukcje gramatyczne czy słownictwo, nawet techniczne, bo zwykle robi to ktoś z kadr.Jak się przygotować? Wg mnie najlepszą opcją jest przez kilka dni przed rozmowami starać się mówić z współlokatorami/dziewczyną/rodzeństwem/kumplami tylko po angielsku. Potraktują tę propozycję jak delikatne wariactwo, ale szybko nauczysz się przekazywać informacje bez myślenia o gramatyce czy słówkach. Po tygodniu pracy w firmie, w której „urzędowym” był angielski zacząłem odruchowo odpowiadać ludziom zwrotami angielskimi. A tylko to się liczy, jeśli w pracy masz używać angielskiego – z kolegami czy klientami. Dokumentację i StackOverflow ostatecznie przetłumaczysz sobie translatorem. Jeśli możesz sobie na to pozwolić, przed rozmowami jedź na weekend czy tydzień do jakiegoś Londynu czy Edynburga.

Szukanie ofert jest obecnie tak proste i jest ich tyle wszędzie, że zwykłe zaaktualizowanie Linkedina i przejrzenie losowych portali da ci więcej niż dość. Ale, najlepszą metodą zmiany pracy jest rekomendacja przez jakiegoś znajomego, najlepiej takiego, z którym pracowałeś, jeszcze lepiej: w jednym zespole. On wie jak się z Tobą współpracuje i co właściwie potrafisz, ty masz wiedzę z pierwszej ręki jak się w danej firmie pracuje. Najczęściej jeszcze macie parę tysięcy bonusu za polecenie.

@tamtamtu: nie zapominam, raczej traktuje za oczywistosc

A nie jest tak że rekrutacje mają kilka etapów, które są rozłożone na kilka dni? Jak to teraz wygląda w branży IT? Bo chyba dojeżdzać po 300 kilometrów co parę dni, a potem nie mieć pewności że się dostanie pracę to trochę słabe.
Ogólnie znalazłem też coś takiego: cezarywalenciuk[dot]pl/blog/programing/post/cv-programisci-hr-czytany
I tam jest, że jak ktoś mieszka poza województwem to ma mniejsze szanse.
CV w LaTex to serio dużo większe szanse?
Na tym forum też czytałem, żeby nie wpisywać języków programowania, które się słabo zna, ale np programuje w C#, ale w domu uczyłem się Javy i napisałem program w niej. Nie jakiś trudny, ale też niezbyt łatwy i nie taki, który można znaleźć w tutorialach. Też się lepiej tym nie chwalić?

podbijam ostatnie pytania, może ktoś doświadczony się wypowie?

Brunatny Krawiec napisał(a):

DK94 napisał(a):

Haskell napisał(a):

Zadania domowe się zdarzają, ale z mojego doświadczenia wynika, że nie często.

Nie startujesz do Januszy Biznesu to i nie spotykasz się z zadaniami domowymi itp. itd.

Tak bardzo to. Zadania domowe to złoty punkt w liście symptomów świadczącym o januszowatości firmy.

No tak - bo niby czemu ktokolwiek poważny zatrudniając kogokolwiek do pracy chciałby sprawdzać jak pracuje. To tak, jakby wymagać od kandydata na kierowcę umiejętności ruszenia samochodem z miejsca.

Coredump napisał(a):

W ciągu kilku/kilkunastu/kilkudziesięciu minut przedstawienie wizji całego systemu? Przez człowieka, który bardzo często nie rozumie specyfiki problemu, bo wcześniej pracował przy innym? To tylko sprawdzian, jak dobry ktoś jest w popisach retorycznych.

Raczej w rozwiązywaniu problemów, czyli podstawowej umiejętności w naszej branży.

Wybitnie mnie irytuje, że nawet i w programowaniu, gdzie powinno być miejsce dla osób niewprawnych w towarzyskich sytuacjach, ocenia się ich znacznie niżej od tych z lepszymi umiejętnościami prezentacji.

Celem pracy programisty nie jest napisanie iluś linijek kodu lecz wytworzenie produktu. Tego zazwyczaj nie osiągnie się samemu, trzeba współpracować i komunikować się z innymi ludźmi. Niestety także nietechnicznymi.

Spinaczer napisał(a):

@krzywy Krawiec: zgadzam się z tym, że taki sposób rekrutacji może faktycznie pozwolić na dobrą ocenę umiejętności kandydata, ale problem widzę w troszke innej strefie, bardziej HR'owej. Takie zadanie wymaga od kandydata większej inwestycji czasu, często nie wiedząc, czy ta inwestycja może mu się opłacić. A gdy kandydat już inwestuje swój czas w np. 10-godzinne zadanie, to część osób (np. osoba decyzyjna z docelowej firmy) mogłaby stwierdzić, że faktycznie chce są robotę (albo jest zdesperowany i "potrzebuje" tą robotę) i wtedy kandydat jest na gorszej pozycji pod względem negocjacji. Czasem na tyle gorszej, że bardziej może opłacać się iść potem na interview gdzie dostajesz standardowe pytania i dostajesz sensowniejszą ofertę.

Dlatego o kasie dyskutuje się przed przystąpieniem do procesu rekrutacyjnego, wtedy nie ma niespodzianek.
I zła to firma, w której jakiś HR decyduje o zarobkach.