Co myślicie o pomyśle, żeby w trakcie postępowania rekrutacyjnego poprosić potencjalnego pracodawcę o próbkę kodu? Byłoby to interesujące dla was? Czy jako pracodawcy bylibyście skłonni pokazać wasz kod?
Pytam, bo odbyłam ostatnio kilka rozmów, i zdarzały się przypadki np. takie: ‘- Jesteśmy świetną firmą, działamy Agile, wdrażamy Rails best practices! - A czego używacie do testowania? - Yyy… Testowania? Testy są niepotrzebne!’
Albo: ‘- Nasz kod jest prototypem i nie ma pokrycia testami. Chcemy żeby był lepszy. 60% kodu jest nieużywane. I mamy mnóstwo kawałków zakomentowanych, może się jeszcze przydadzą.’
Myślę, że w niektórych przypadkach próbki kodu diametralnie zmieniłyby moją chęć/niechęć do pracy w danej firmie.
A może próbki kodu są niepotrzebne, może to kwestia zadania odpowiednich pytań pracodawcy?
Pomyślałbym że byliśmy na interview w tej samej firmie, ale Ty zdaje się operujesz na wyspach, a nie w Warszawie
Co do brania kodu od pracodawcy: ja tego nie potrzebuję (oraz tworzy to jakieś głupie sytuacje z podpisywaniem NDA czy innych umów), dobrze zadane pytania (jak np. powyższe) wystarczają żeby się zorientować czy firma naprawdę uprawia Railsy i Agile, czy tylko udaje że to robi.
Trochę zakładam, że skoro pracodawca czasem spodziewa się próbki kodu (czyli albo pokazuję coś, co zostało napisane w pracy, albo robię własne projekty), to może też pracodawca jest w stanie pokazać jakiś swój fragment, bez zabaw w papierkologię?
@tomash - rzeczywiście obie przykładowe firmy były w UK.
oj, wejdź na Githuba na konto danej organizacji. Popatrz co ma organizacja w publicznych repozytoriach, czy to są forkowane projekty istniejące, czy własne rozwiązania. Spójrz na praw - członkowie organizacji. Przejrzyj ich repozytoria. Powinno mówić wiele.
@squil: Też przyszło mi to do głowy (i też w momencie pracy na Wyspach, zbieg okoliczności czy raczej “na Wyspach prawdopodobieństwo trafienia na gówniany kod jest większe” ? ) Chociaż teraz jak patrzę z perspektywy czasu na wszystkie firmy gdzie pracowałem, to jednak widząc większość ich kodu PRZED podjęciem pracy raczej bym jej nie podjął ( i był bezrobotny, nie zdobył doświadczenia etc. słowem nie wyszłoby mi to na dobre, więc może lepiej nie patrzeć, zrazimy do siebie tylko pracodawcę (szczególnie tego, który myśli że jest taki super edżajl i w ogóle de best ruby rockstar pipol). Lepiej przyjąć ten gówniany kod na klatę w stylu supermana i go zdepatalogizować
Jest też inny wymiar tego problemu: większość kodu nawet tego, który sami pisaliśmy X miesięcy temu wygląda źle po pewnym czasie czy tego chcemy czy nie bo cały czas udoskonalamy nasze umiejętności i inaczej patrzymy na pewne problemy i rozwiązania. Raczej nie liczyłbym na to, że trafimy na firmę, która pokaże nam “Proszę oto nasz super idealny kod do przejrzenia, jest błyszczący i idealny i pieścimy go codziennie i wygładzamy i nie znajdziesz w nim baboli” - może takie firmy istnieją gdzieś w wyidealizowanym świecie, w rzeczywistym raczej o nie ciężko (co nie zawsze znaczy, że firma jest be).
Tzn. wszyscy pracodawcy, którzy nie mają konta na GitHubie są źli ? Poza tym, nie wydaje mi się, żeby większość firm trzymała wewnętrzne projekty (czyt. te na których się spędza większość czasu w firmie i na których przyjdzie nam pracować a nie te 5% czy 10% opensource’owe dla pokazania community jak bardzo ich kochamy) na otwartych kontach na GitHubie. IMHO pierwotne pytanie, które zadała @squil jest przydatne ale nie może być podstawą do jednoznacznego rozstrzygnięcia “dobra/zła firma” czy zaakceptowania/odrzucenia oferty pracy przez nas.
Po roku depatologizowania jakiegokolwiek kodu:
a) wzrasta samoocena
b) bardzo wzrasta szacunek do ładnego kodu i chęć tworzenia takowego
c) zaczyna się rozumieć idee testowania
Przyjąć na klatę to jedno, ale później trzeba pracodawcy tłumaczyć co to jest agile i właściwie to czemu piszę te głupie testy przez większość dnia. Osobiście nie zawsze czuję się na siłach.
Zdecydowanie się zgadzam. To chyba jedyny sposòb sprawdzenia rozwoju
Ale tego czy pracodawca praktykuje agile nie stwierdzisz po kodzie (no chyba że będzie rewelacyjnie przykryty testami), takie rzeczy trzeba wyciągnąć w trakcie rozmowy.
Generalnie mój problem polega na tym, że określenie “agile” jest trochę marketingowe, i każdy rozumie pod tym coś innego. Więc pytanie “czy działacie w agile” ma średnio sens. Widząc paskudny kod wiadomo, że agile i testy to tylko hasła, natomiast rzeczywiście fakt, że kod jest porządny, jeszcze o niczym nie świadczy. Stąd się zastanawiam - ile można się dowiedzieć z próbki kodu, a ile z odpowiednich pytań.
[color=silver][del]Agile może być faktycznie zbyt ogólnym terminem.[/del][/color]
A gdyby tak zapytać: “Czy korzystacie z metodologii SCRUM?”. Możliwe odpowiedzi:
Bo ja wiem? Brak konta na Github nic nie przesądza na niekorzyść pracodawcy.
Jeśli jednak dostaniesz link do Githuba a tam jest kilka projektów firmowych oraz kilku(nastu) członków organizacji, z których każdy ma po kilka(naście) otwartych repozytoriów, z których niemal wszystkie mają zajebiste testy, to wiesz, że chcesz pracować z takimi ludźmi
A już na serio: rekrutacja zaczyna się od oczarowania pracownika. Zobacz jaka zajebista firma, jakie wspaniałe benefity, wszyscy mają iPhone’y (lub HTC Desire HD). Sporo programistów, zwłaszcza niedoświadczonych, na tym poprzestaje. A przecież po tańcu godowym człowieka od HR jest czas dla potencjalnego pracownika. I wtedy trzeba zadać wszystkie pytania:
jak często Wasi pracownicy biorą nadgodziny?
czy często bierzecie projekty z ciasnym deadline?
czy często zdarza się Wam odmawiać klientowi implementacji głupich pomysłów?
jakie techniki agile wykorzystujecie na co dzień?
czy mogę zobaczyć przykłady Waszych testów? (zobaczenie kodu testowego wystarcza a nie zdradza za dużo szczegółów implementacji i nie powinno łamać NDA)
czy mam dużą dowolność wyboru czasu i miejsca pracy (o ile klientowi to nie przeszkadza)?
Takie pytania są na miejscu i świadczą o doświadczeniu kandydata. W dobrej firmie spodziewają się ich i chętnie na nie odpowiedzą.
W ten sposób to przyciągniesz programistów świeżo po maturze. Profesjonalistę z benefitów to przyciągnie raczej forma współpracy i pakiet socjalny (opieka zdrowotna, karnety sportowe itd.), telefon to on już przecież ma w abonamencie za złotówkę (oraz to zaledwie gadżet).
Natomiast lista pytań do zadania firmie – REWELACJA, przyklejcie ten temat
Anegdotka: byłem kiedyś na rozmowie w jednej firmie, która oferowała bardzo fajne warunki (w sensie stawki) i oczywiście na początku rozmowy dwóch prowadzących opowiadało mi jaka to super firma, a jakie fajne projekty robią, a jak świetnie się u nich programuje. Kiedy już skończyli i przyszła pora na moje pytanie, zapytałem “jakiego stosu rozwiązań używacie do testowania”. Usłyszałem w odpowiedzi że nie piszą testów, co lepsze z dorobionym ideolo (bo pisanie testów wydłuża czas pisania projektu, a poza tym “jak kod działa to działa”) i już wiedziałem, że raczej nie istnieją pieniądze gotowe mnie przekonać do pracy w tej firmie
