renderme napisał(a):
Ostatecznie doszedłem do tego, że najlepszym sposobem weryfikacji, który nie wycina zestresowanych, ale dobrze sprawdza jest prośba o przyniesienie ze sobą/ przesłanie jakiegoś projektu, w którym się uczestniczyło i rozmowa o nim.
Czyli "proszę opowiedzieć o swoim doświadczeniu komercyjnym a najlepiej gdyby to było 10+ lat doświadczenia".
Bo w Warszawie nie ma pracy dla ludzi z moimi aspiracjami, doświadczeniem i wykształceniem
Ferdynand Kiepski, a raczej Ferdynand Wspaniały
Co ma powiedzieć 96% populacji tego kraju nie mieszkająca w Warszawie, kiedy w Warszawie programista przez głupie haery i " tympych humanistuff" nie może znaleźć pracy? Co ciekawe, Nie-Warszawa żyje, pracuje, nie lamentuje.
Zasada trzech osób
Jeśli jedna osoba mówi ci że jesteś koniem, wyśmiej ją.
Jeśli druga osoba mówi ci że jesteś koniem, olej ją.
Ale jeśli trzecia osoba mówi ci że jesteś koniem, to zacznij zbierać na siodło.
BraVolt napisał(a):
Co ma powiedzieć 96% populacji tego kraju kiedy w Warszawie programista przez głupie haery i " tympych humanistuff" nie może znaleźć pracy?
"Nie ma miejsca w tramwaju, pojadę innym"
Kiedyś byłem na rozmowie w takiej firmie, gdzie dostałem pytanie w którym był zacytowany błąd i miałem opowiedzieć jak go poprawić. Powiedziałem że musiałbym zobaczyć kod i być może zajrzeć do dokumentacji. Na co JRiN(Janusz Rekrutacji i Negocjacji) odpowiedzial:"U tego nie wiesz, to było najważniejsze pytanie. Ale wiesz możemy Ci dać połowę stawki której oczekujesz i nauczymy cię tego." Podziekowalem, a dwa dni później dostałem telefon, czy jednak się nie zdecyduje przyjąć tej oferty. 
Myślę że większość firm ma określony budżet na przykład max 7000 zł. Inna kwestia jest to że obecnie programowanie to rozległa wiedza i nigdy się nie będzie wiedziało wszystkiego. Nawet to co już umielismy, potrafi wylecieć z głowy jeśli w obecnej firmie z wiedzy tej nie korzystamy. Na rozmowach najczęściej padają pytania dość szczegółowe i pół biedy jeśli faktycznie firma szuka pod siebie i są związane z profilem kandydata. Ale problem jest wtedy kiedy zestaw pytań rekrutacyjnych jest od czapy. Na przykład firma szuka programisty znajacego jakiś framework X, reazujacy niemal wszystko od połączeń db po mvc. A na rozmowie dostajesz zadanie zeby zaprojektować i napisać od począku modul połączeń i odbierania danych z db w danym języku. Jeśli przez ostatnie lata korzystałes z frameworka, możesz porostu nie pamiętać nazw metod. Dodatkowo dochodzą przemyślenia architektoniczne w stylu jak to fajnie podzielić na klasy z jakich wzorców projektowych warto skorzystać. Podczas kiedy myślisz sobie kiedy to było, kiedy ostatnio pisałeś tak niskopoziomowo w danym języku próbując sobie przypomnieć nazwy tych metod. Patrzysz na zegarek minęło już 7 minut z 15 przewidzianych na to zadanie. Dochodzi stres i szanse maleją. A przecież wystarczyłby Ci jeden wieczór, zeby sobie wszystko przypomnieć.
Ale w innej firmie możesz trafić na coś czym zajmowałes się całkiem niedawno. Więc masz już za sobą projektowanie, pamiętasz nazwy funkcji roztrzaskujesz zadanie. I słyszysz wow jesteś pierwszym kandydatem który je wykonał.
Więc podsumowując moim zdaniem trzeba się nie poddawać i chodzić na rozmowy w końcu zaskoczy i stawka i zadania i branża i itp. Bo powody bywają różne.
Co oni chcą sprawdzić u kandydata dając mu zadania i pytania na poziomie II roku studiów?"
Też się zdziwiłem że trzeba czasem osoby z kilkuletnim doświadczenime pytać, aż do ostaniej rozmowy na stanowisko "seniora" - kandydat z 8 lenim doświadczeniem nie umiał wyjaśnić czym jest klasa abstakcyjna, ani czym się różni stos od sterty. Miała być rozgrzewka i potem luźna gadka o architekturze aplikacji, podjeściu do pracy, w formie luźnej rozmowy itd. ,ale odpuściliśmy, nie było sensu. Niestey przekonało mnie ze trzeba - pro forma.
Na podstawie lektury niektórych wypowiedzi w tym temacie, można odnieść wrażenie że mit braku programistów na rynku osiągnął poziom niefalsyfikowanej wiary religijnej u niektórych osób. W obliczu licznych przykładów przesadnego wybrzydzania przez firmy, oporów przed podnoszeniem stawek do poziomu zachodniego (gdzie brak programistów jest rzekomo jeszcze większy) itd osoby te uczepiły się tezy iż rzekomo "pracy jest więcej niż specjalistów, tylko mało kto się nadaje". A tak sformułowanego sofizmatu można by bronić nawet w sytuacji gdyby panowało 50% bezrobocie i ludzie umierali z głodu na ulicach.
To taki fun fact z mojej strony w kwestii szukania pracy.
Ze wszystkich ofert które mi złożono po rozmowach ani razu moje kompetencje i umiejętności techniczne nie były decydujące i nie miały praktycznie wpływu na zatrudnienie. Ani tani, ani dobry nie jestem ;]
renderme napisał(a):
Dodam jeszcze, że takie pytania "o definicje" są absolutnie bezwartościowe. Zdarzyło mi się mocno naciąć na kandydatach, którzy formułki mieli wykute na blachę i przerobione te wszystkie standardowe pytania, a później przez tydzień bezskutecznie walczyli z obsługą formularza, albo pisali weryfikacje numeru telefonu (najbanalniejszą z banalnych, usunięcie nie-liczb i policzenie znaków) przez parę dni w taki sposób, że waliła błędami przy usunięciu środkowej liczby itp. Ogólnie typy niezdolne do twórczego i logicznego myślenia, ale obkute z definicji.
15 minutowe zadanka w stylu fizzbuzz są też bez sensu, bo nie pokazują umiejętności pracy, ale znajomość składni i podstaw programowania. Znowu zadanie na 4 godziny odstrasza profesjonalistów, a bez tego trudno sprawdzić postawę danej osoby.
Najgorsza u kandydatów jest też postawa, pt. wypuszczanie gó... kodu po 10 razy do PR i za każdym razem oznaczanie taska jako wykonanego - byle jak, ale wypchnięte.Wiele juniorów ma też postawę: "oto ja! nic nie umiem, ale uczcie mnie, bo poszukam sobie wtedy lepszej pracy".
Ostatecznie doszedłem do tego, że najlepszym sposobem weryfikacji, który nie wycina zestresowanych, ale dobrze sprawdza jest prośba o przyniesienie ze sobą/ przesłanie jakiegoś projektu, w którym się uczestniczyło i rozmowa o nim.
Nie każdy ma taki projekt, a komercyjnych nie można wynieść z pracy. To kryterium usuwa wartościowych kandydatów
Co do pytania o błąd to się nie zgadzam z autorem. Ja lubię zadawać otwarte pytania bo pokazują jak kandydat myśli.
Gdy zapytam seniora "Co zrobisz jak zobaczysz OOM na produkcji" to oczekuje dojrzałego podejścia, chcę zobaczyć jak dochodzi do rozwiązania, komu da znać, czy zrobi hotfixa na produkcji np poprzez zwiększenie pamięci, jakie zna toole i tak dalej.
W mojej ocenie, taka analityczna odpowiedź jest dużo więcej warta niż to, jak mi powie jaką złożoność obliczeniową mają operacje w kolekcjach czy rozwiąże jakiś prosty problem z każdej stronki "top 100 java interview questions".
Najgorsze są dwa rodzaje pytań:
Dzisiaj mamy internet na wyciągnięcie dłoni i trzeba wziąć pod uwagę ten czynnik przy rekrutacji. Również w dziedzinie tego, że nie wszystko trzeba znać na pamięć skoro można to znaleźć w 2 minuty.
Na stażu, zanim dostałem możliwość wejścia na open space, dowiedziałem się razem z innymi, że z firmy jak już przyjęto, to raczej nie da się wylecieć, chyba, że ktoś wyniesie / udostępni, zrobi fotki, itp kod albo inne dane.
Zatem kiedy czytam o rekrutacji na zasadzie pokaż goithuba albo chociaż kawałek githuba to dochodzę do wniosku, że to chyba jakiś alternatywny świat. Może w nim pokazuje się na lewo i prawo githuba w firmowymi projektami a brak sensownych ludzi do pracy w IT to rzeczywiście mit i propaganda mediów.
BraVolt napisał(a):
Zatem kiedy czytam o rekrutacji na zasadzie pokaż goithuba albo chociaż kawałek githuba to dochodzę do wniosku, że to chyba jakiś alternatywny świat. Może w nim pokazuje się na lewo i prawo githuba w firmowymi projektami a brak sensownych ludzi do pracy w IT to rzeczywiście mit i propaganda mediów.
WTF??? Przecież repo firmowe to repo firmowe, a tu mówi się o projektach prywatnych lub zleceniach które wykonuje się samemu ze swoim klientem, nigdy o takich projektach nie słyszałeś? Czy może nie wiesz, że możesz mieć więcej kont niż tylko firmowe, w dodatku - wow - na swojego prywatnego maila?
Nie każdy robi zlecenia.
Nie każdy, ale każdy rozwija się po pracy, a przynajmniej każdy kto nie chce być juniorem całe życie.
Ani jak ani nikt z kolegów nie rozwija się przez hodowanie githuba.
Nawet tech-lead mają żony, dzieci, prywatne życie, spłacone albo spłacane mieszkania. Żaden nie ma jednak prywatnego githuba.
W pokazywaniu kodu na githubie, który piszesz w pracy nie ma nic nadzwyczajnego. Masa projektów rozwijanych komercyjnie ma kod na github czy innych serwisach z repozytoriami - Linux, Apache, warianty BSD, FreeRTOS itd.
@BraVolt: nie czepiłem się ciebie do braku prywatnego githuba, bo sam nie mam, a wszystkie moje projekty prywatny czy zleceniowe mają zamknięty kod. Czepiłem się dlatego, że napisałeś o pokazywaniu githuba firmowego, tak jakby prywatny nie mógł istnieć. A co do trendu to wśród moich znajomych jest całkiem, inny 90% osób roi po godzinach dużo nie ważne czy mają rodziny czy nie, a najwięcej robią ci co mają kredyty dlatego że wtedy szybciej je spłacają ;)
@mr_jaro: Weź pod uwagę, że korpo może nie używać githuba jako VCS. Serio.
@BraVolt: Boże widzisz i nie grzmisz... a co ma piernik do wiatraka? Potocznie mówi się github ale może to być dowolne repo nawet jakieś self-hosted.
Podpisane zobowiązanie pod karą "sześć zer" za wyciek danych. Zaliczone szkolenia z bezpieczeństwa obiegu informacji.
Tu wszyscy wiedzą, od koderów po haery i reruterów jakie są zasady i nikt się w pokazywanie githubów z poprzedniej firmy nie bawi.
@BraVolt: pokaż mi gdzie pisałem o pokazywaniu kodu z poprzedniej firmy, gdzie ktokolwiek o tym pisał, właśnie ja to wyśmiałem u ciebie.
BraVolt napisał(a):
Zasada trzech osób
Jeśli jedna osoba mówi ci że jesteś koniem, wyśmiej ją.
Jeśli druga osoba mówi ci że jesteś koniem, olej ją.
Ale jeśli trzecia osoba mówi ci że jesteś koniem, to zacznij zbierać na siodło.
A na cholerę koniowi siodło? Siodło jest potrzebne jeźdźcy.
@mr_jaro: Nie piję do ciebie, tylko ogólnie ludzie piszą o pokazywaniu przy rekrutacji różnych projektów na githubie
somekind napisał(a):
Ale jeśli trzecia osoba mówi ci że jesteś koniem, to zacznij zbierać na siodło.*
A na cholerę koniowi siodło? Siodło jest potrzebne jeźdźcy.
Jest jeszcze wersja "to zacznij szukać sobie weterynarza".
@BraVolt: ty widzę nadal nie kumasz co ja napisałem, to przeczytaj jeszcze raz, a zrozumiesz, że nikt ale to nikt nie mówi o pokazywaniu kodu z poprzednich firm na rekrutacjach. Wszyscy mówią o pokazywaniu prywatnego kodu. Przetraw to, prześpij się. Jak zaczniesz takie rzeczy kumać od ręki to bedziesz aspirował na regulara, na razie to z tym twoim zrozumieniem to taki typowy junior, aż mi się przypomniało jak musiałem takich niańczyć rok temu, uh, dobrze, że już nie muszę.
Kiedy się jutro obudzę to tu tak jak dzisiaj nikt nie będzie podczas rekrutacji pytać o prywatnego githuba.
Nawet 27 października jak już każdy wyśpi się dłużej tu nie będzie się pytać o prywatnego githuba.
Nikt nigdy nie chciał oglądać kodu moich projektów. Mam je wymienione w CV więc były do nich pytania, ale kodu nikt nigdy nie chciał. Jedyny kod jaki oglądano to ten z rozwiązywania zadań jakie mi dawano.
Jak ja uderzam do firm do od większości dostaje pytanie "czy mogę pokazać jakiś kod swojej aplikacji, czy w razie co mają podesłać zadanie rekrutacyjne", i każdy normlany człowiek z branży wie, że nikt nie może pokazać kodu z poprzedniej firmy, nawet często mówić o projektach nie może bardziej niż ogólnikami, za to z prywatnymi często może wszystko i o takie się rozchodzi.
Moja, a raczej nasza. Nasza bo zespół to 10, 20, 60 osób. Dobrze jak tylko w Europie i nie ma dzikich różnic czasowych.
renderme napisał(a):
Ech, tak trochę zbyt powierzchownie na to patrzycie. Firmy nie mają dyscypliny jak pruska armia. Czasami ktoś chce prowadzić rekrutacje, a ktoś inny chce ją sabotować. Powodów może być wiele, np. ma już kolegę-kandydata na to miejsce, nie chce wdrażać nowej osoby do zespołu itp.
Programiści czasem sabotują rekrutację. Spotkałem się już z sytuacjami, w których już od pierwszych chwil rozmowy wiedziałem, że oni tak naprawdę nie chcą, żebym z nimi pracował. Czyli przeprowadzali rekrutację tylko dlatego, że im kazano, ale widać było od razu, że mają na twarzy wypisane "wypieprzaj stąd, nikt cię tu nie chce".
Nie wiem, dlaczego tak się dzieje. Ale może w takich sytuacjach firmy mają już wybranego kandydata, a przeprowadzają kolejne rozmowy tylko dla formalności? Więc wtedy nawet jeśli testy techniczne wyszły mi dobrze, to wiadomo, że nie zatrudnią, skoro mają już kogoś innego wybranego, a cała "rekrutacja" to tylko pic na wodę (a delegowani to sprawdzania wiedzy technicznej programiści to wiedzą, więc od razu są "na nie", bo mają świadomość, że to nie ma sensu?)?
Ale może odpowiedź jest bardziej prosta i może po prostu niektórzy programiści to mruki, którzy w ogóle są niechętni do ludzi i wzdrygają się na samą myśl, że dojdzie do zespołu nowy kolega? A już nie daj boże, jeśli jest od nich lepszy technicznie, to wtedy w ogóle trzeba go zgnoić i pokazać, że tak nie jest (czyli taka typowa walka o ego).
LukeJL napisał(a):
Ale może odpowiedź jest bardziej prosta i może po prostu niektórzy programiści to mruki, którzy w ogóle są niechętni do ludzi i wzdrygają się na samą myśl, że dojdzie do zespołu nowy kolega? A już nie daj boże, jeśli jest od nich lepszy technicznie, to wtedy w ogóle trzeba go zgnoić i pokazać, że tak nie jest (czyli taka typowa walka o ego).
W takim wypadku to trzeba im dziękować, że się ujawnili już na samym początku. Gorsze byłoby to gdybyś dołączył do zespołu mruków, a oni sabotowaliby Twoją pracę czy awans zawodowy. Miałem nieprzyjemność pracować w zespołach gdzie wiele osób nie chciało się dzielić wiedzą, do niektórych trzeba było się umawiać na 5 minutową konsultację. Zdarzyło się, że zablokowali mi możliwość pracy w nowym projekcie, a kierowniczka poradziła mi żebym może się z nimi zaprzyjaźnił. W przypadku gdy pracujesz z jakimś legacy kodem pomoc innych jest nieoceniona i można dużo szybciej wdrożyć się w projekt. Niestety są ludzie, którzy nie chcą współpracować i na tym budują swoją pozycję zawodową, ponieważ wydają się kierownictwu być nie do zastąpienia.