Mitologia rekrutacji programistów

Mainpage_Slider_Greek_Mythology_GodsChoć jest przynajmniej kilka znanych i całkiem dobrych tekstów nt. rekrutacji programistów (kilka linków podałem niżej), postanowiłem podzielić się swoim – bardzo subiektywnym – doświadczeniem w tej dziedzinie. Niniejszy tekst piszę z perspektywy osoby, która rekrutuje programistów, jednak spostrzeżenia i porady pomocne mogą być zarówno dla innych rekruterów jak i kandydatów do pracy. Swoje przemyślenia zebrałem w formie kilku “mitów”, które udało mi się gdzieś usłyszeć lub przeczytać. Nazywam się je mitami głównie dlatego, że w całości lub przynajmniej częściowo się z nimi nie zgadzam… i staram się niżej wyjaśnić dlaczego. Dodatkowo chciałbym uprzedzić – tekst dotyczy weryfikacji zdolności, umiejętności i wiedzy technicznej – a nie całokształtu znajdowania idealnych pracowników do danego zespołu. Nie aspiruję do tego aby być ekspertem od psychologii, HR czy zaawansowanego managementu. Interesuje mnie głównie to, aby ludzie techniczni – programiści i architekci, mieli możliwość dobierania sobie współpracowników poprzez udział w rekrutacji i żeby robili to kierując się sensownymi kryteriami.

Mit 1: nie liczy się wykształcenie, kursy, certyfikaty… tylko i wyłącznie doświadczenie i praktyka

Sporo osób uważa, że najważniejsza jest praktyka. Widać to wyraźnie po liczbie młodych ludzi, którzy na 2 czy 3 roku studiów zaczynają pracować w branży – bo uwierzyli, że ważniejsze od tego co mówią im podręczniki i wykładowcy, jest to co zrobią w firmie do której trafią. Zdecydowanie coś w tym jest – wytwarzanie oprogramowania wymaga wielu praktycznych zdolności i praktycznego podejścia do problemów. ALE… w czasie swojej kariery “rekrutera” spotkałem sporo osób z wieloletnim doświadczeniem w wytwarzaniu słabych systemów IT. Paradoksalnie – lepiej dla nich, żeby tego doświadczenia nie mieli. W kontraście do tego – spotkałem kilku młodych ludzi, którzy nie mieli w ogóle doświadczenia w prawdziwych projektach, ale ich wiedza, wyobraźnia i zaangażowanie pozwoliły im bardzo szybko włączyć się aktywnie w prace zespołu i przynosić konkretną wartość w projekcie.

Co to pokazuje? Aby skorzystać z doświadczeń – pozytywnych bądź negatywnych – trzeba mieć wiedzę. Osoba, która wie odpowiednio dużo – nawet trafiając do “słabego” zespołu, zobaczy co jest złe i zrozumie czego nie robić w przyszłości. Osoba, która wie za mało – zamiast zdobywać cenne doświadczenie, nasiąka tym co widzi w koło. Dlatego w rekrutacji, bardziej od doświadczenia, szukam zrozumienia tego doświadczenie. Czyli nie tylko “co robiłeś w poprzednim projekcie”, ale bardziej “co o tym sądzisz, dlaczego to robiłeś, dlaczego uważasz, że powinno być inaczej” itd. Konkretniej – sporo ludzi z łatwości wymieni technologie i narzędzia, które były używane w poprzedniej (lub jeszcze obecnej pracy). Dużo trudniej jednak celnie odpowiedzieć na pytanie “w jakim celu używany był Guice, jakie korzyści chcieliście osiągnąć używając wstrzykiwania zależności, jaki jest tego koszt, czy rzeczywiście się opłaciło, czy robiąc nowy projekt poszedłbyś tą samą drogą…”. Zauważyłem również, że dobrym miernikiem jakości doświadczenia, jest to w jaki sposób kandydaci mówią o wadach narzędzi i technologii, które używają. Czy w ogóle mają coś do powiedzienia na ten temat. Dobrym przykładem są narzędzia ORM. W naturalny sposób większość kandydatów wymienia jak litanię, plusy czy też obietnice tej koncepcji. O dziwo sporo osób nie jest w stanie sensownie wyjaśnić przypadków, kiedy ORM to nie jest dobre podejście, albo przynajmniej kosztów, na które musimy się godzić, jeśli używamy ORM.

Mit 2: rozmowa na tematy teoretyczne jest bez sensu – przecież w pracy i tak wszystko można znaleźć na StackOverflow i Google

Część osób uważa, że w dzisiejszych czasach programista nie musi pamiętać prawie nic. Zawsze można przecież wyszukać w sieci. W zasadzie zgadzam się z tym. Wielu szczegółów nie trzeba pamiętać, wobec czego nigdy nie zadałbym pytania typu: “jaki typ ma 3 parametr metody Y w klasie Z odpowiedzialnej za X?”. Niestety jednak u wielu osób “nie trzeba pamiętać” przekształciło się magicznie w “nie trzeba rozumieć”. Moim zdaniem nie trzeba wiedzieć jaką metodą można posortować kolekcję napisów zgodnie z porządkiem leksykalnym, ale trzeba wiedzieć i rozumieć, że w zależności od wybranej kolekcji złożoność takiej operacji będzie różna. Nie trzeba pamiętać jakim przełącznikiem JVM ustawić agresywne porządkowanie sterty w Garbage Collectorze, ale na pewnym poziomie trzeba dokładnie rozumieć co to jest Garbage Collector, sterta, porządkowanie sterty, po co to zostało wprowadzone, jakie może mieć pozytywne i negatywne efekty w systemie i jak ogólnie można diagnozować potencjalne problemy. I tak dalej, i tak dalej…

Faktem jest, że w Google można znaleźć wszystko. Problem w tym, że wszyscy programiści świata mają dostęp do tego samego Google i mimo wszystko część z nich radzi sobie dużo lepiej niż pozostali. Pewnie dlatego, że dobry programista rozumie co się dzieje i wie czego ma szukać.

Mit 3: zadania praktyczne, gdzie trzeba na szybko napisać prosty kawałek kodu, są bez sensu

Wiem, że sporo ludzi uważa, że krótkie zadanie programistyczne, gdzie do napisania jest kilka pętli for i operacji na tabelce nic nie sprawdza. Nie szkodzi. Ja stosuję (i będę stosować) zadania dotyczące fundamentalnych algorytmów i struktur danych i w większości przypadków będą rozwiązywane na kartce i tablicy. Dlaczego? Powodów jest bardzo wiele, ale tak naprawdę tylko jeden do mnie przemawia – statystyka. Odbyłem już na tyle dużo rozmów, że wiem że dane zadanie ma kilka typowych strategii rozwiązania. Ludzie albo wybierają jedną z nich, albo myślą kreatywnie, albo nie potrafią sobie poradzić, albo mają problem ze szczegółami, albo nie widzą potrzeby testowania, albo czują się niepewnie kiedy muszą przeanalizować abstrakcyjny problem, albo nie wiedzą co to jest złożoność. Pozornie błahy kawałek kodu zaczyna mówić bardzo wiele, jeśli widzisz jak ktoś próbuje go napisać po raz 20, 30, … 50 itd.

Niestety spotkałem w swojej karierze kandydatów, którzy mieli kilka ładnych lat doświadczenia w projektach IT, a nie potrafili policzyć elementów w liście jednokierunkowej. I choć zdaje sobie doskonale sprawę, że w codziennej pracy nikt tego sam nie implementuje, to naprawdę… nie chciałbym oglądać bardziej rozbudowanego kodu pisanego przez takie osoby.

Mit 4: programista nie musi umieć pięknie mówić, musi umieć programować

Popularnie uważa się, że ludzie z IT to często zamknięte w sobie mruki, które potrafią z trudem składać 4 wyrazowe zdania, ale to jest OK… bo to, co się liczy, to klepanie kodu. To oczywista nieprawda – co widać chociażby na tym blogu :) Zdania są dłuższe. Problem w tym, że często mamy do czynienia z kandydatami, którzy nie potrafią nic powiedzieć o tym co robili, co jest dla nich ważne, co by chcieli robić, co ich pasjonuje itd. Choć to może być krzywdzące i bardzo nieobiektywne – to z pełną determinacją staram się sugerować niezatrudnianie osób, które mają bardzo wyraźny problem z komunikacją słowną. Dlaczego? Z dwóch powodów. Po pierwsze wytwarzanie oprogramowania to gra zespołowa. Cokolwiek by się nie działo – zespół musi być w stałym kontakcie, umieć ze sobą rozmawiać. Nawet największy geniusz, jeśli będzie siedział cicho w kącie finalnie będzie opóźniać, a nie przyśpieszać prace. Szczególnie na stanowiskach senior – należy oczekiwać od ludzi, że będą potrafili dzielić się wiedzą, rozpoczynać dyskusje merytoryczne, bronić swoich racji itd. Po drugie – od pewnego momentu kariery trzeba rozmawiać z “biznesem” – z ludźmi nietechnicznymi, którzy zamawiają lub użytkują nasz software. Nie ma wyjścia i to jest bardzo dobre! Żeby się rozwijać trzeba budować relacje z klientem, poznawać lepiej jego potrzeby itd. Nie jest to tylko zadanie analityków, PM-ów, product ownerów czy innych agile coachów. Wobec tego pytanie “jakie jest twoje hobby” albo “co robisz w wolnym czasie” jest równie ważne jak “po co używamy wstrzykiwania zależności i co to nam ma dać”.

Mit 5: jedynym kryterium zatrudniania do zespołu powinny być techniczne “skille” – zatrudniamy tylko A-players

Próbując zebrać (realtywnie szybko) zespołu programistów, możemy wpaść w pułapkę. Chcemy mieć możliwie silny zespół – wszechstronny, doświadczony, wyedukowany, mądry, zdolny, z potencjałem, zmotywowany itd. Wobec czego przeprowadzamy staranną rekrutację i wybieramy samych asów. Najlepszy z najlepszych. Dream team. Sadzamy ich razem i po kilku miesiącach okazuje się, że coś jest źle. Przeżyliście to? Ja tak. To trochę tak jakby pomyśleć: “Batman super rozwala przestępców – to zatrudnimy 10 Batmanów i wygramy z każdym”. Niestety zespół 10 Batmanów, to z reguły nie jest dobry zespół. Problem jest taki, że ci ludzie mogą wcale nie chcieć ze sobą pracować. Z różnych powodów. Różnice poglądów (w tematach merytorycznych). Różnice temperamentów. Różnice oczekiwań i przyzwyczajeń. Różne wizje i aspiracje… Idąc dalej porównaniem do Batmana – w zespole potrzebujesz mieć Batmana, Robina… ale też różnych ich pomocników, współpracowników itd.

Są firmy, które zbyt mocno w rekrutacji skręcają w stronę miekką i zamiast patrzeć na faktyczne możliwości techniczne, wybierają ludzi, którzy z jakichś subiektywnych powodów się spodobali. To oczywiście błąd. Ale… równie złym, a może nawet jeszcze gorszym, jest zignorowanie aspektu “miękkiego”. Nie można bać się odrzucać ludzi, którzy mają dużą wiedzę, doświadczenie i są inteligentni – ale nie pasują do zespołu i to widać od razu. Co więcej… czasem tego nie widać i tu ponownie – nie można bać się reagować, przenosząc (jeśli się da) lub zwalniając ludzi, którzy nie zgrali się dobrze z zespołem. Wszystkim finalnie wychodzi to na dobre.

Mit 6: “wymyśl 20 zastosowań do gwoździa” to super pytanie rekrutacyjne

Jest pewna grupa rekruterów, która uważa, że dobrze jest zadawać różnorakie logiczne, abstrakcyjne, fabularyzowane lub jeszcze bardziej zwariowane zagadki. Spotkałem się z przypadkiem, gdy na rekrutacji IT zadawane było zadanie z matematyki z podręcznika do podstawówki czy gimnazjum (i sporo ludzi nie umiało go rozwiązać). Z początku brzmi to super – sprawdzamy jak abstrakcyjnie, nieszablonowo i efektywnie nasz kandydat rozwiązuje problemy. Super. Co więcej przecież sam chwilę wyżej pisałem, że warto zadawać zadania. Świetnie. Problemy w tym, że zadawanie pytania o treści: “a teraz zadam ci zadanie z matematyki, które znalazłem w książce mojego młodszego dziecka” nie jest sprytne i ciekawe, tylko uwłaczające. W jednym z pierwszych zespołów w których pracowałem, był człowiek, który umiał rozwiązywać wszystkie łamigłówki tego typu i rozkładać je na elementy pierwsze. Był to też człowiek, który chyba jako jedyny wyleciał z pracy. Umiejętność odpowiedzi na pytanie, która z 9 kulek jest cięższa, nie wyznacza grupy “dobrzy programiści”. Znam sporo bardzo zdolnych i inteligentnych ludzi, którzy padają przy jakiejkolwiek zagadce logicznej – ale potrafią rozwiązywać prawdziwe, duże problemy. Dla kontrastu zbadanie umiejętności “posortowania listy” moim zdaniem skutecznie eliminuje ludzi, którzy nie mają pojęcia o programowaniu.

Fakt jest taki – zadajmy dużo szczegółowych i ogólnych pytań o informatykę, programowanie, technologie etc. Zadajemy zadania w tym obszarze. Pytajmy też o rzeczy “miękkie” i próbujemy normalnie rozmawiać. Ale nie każmy ludziom oszacować z powietrza “ile waży boeing 777 ze wszystkimi miejscami zajętymi” (a to akurat jest realny przykład “super” pytania rekrutacyjnego, którego nigdy nie zadam, ale słyszałem je od kogoś kto był z niego dumny).

Mit 7: trzeba sprawdzić jak kandydat radzi sobie ze stresem

Atmosfera na rozmowie rekrutacyjnej mówi bardzo dużo… ale nie o kandydacie, tylko o osobach, które ją prowadzą. Znam ludzi, którzy celowo chcą wprowadzić atmosferę nerwową i napiętą – żeby sprawdzić jak kandydat sobie z tym poradzi. Niestety w ten sposób co najwyżej sprawdzają, czy kandydat umie pracować w patologicznym środowisku pracy – a taki skillset niekoniecznie jest potrzebny. Prawda jest taka, że cokolwiek byśmy zrobili i tak rozmowa rekrutacyjna rodzi stres. Naszym zadaniem jest zminimalizowanie go. Kandydat po wyjściu z rozmowy powinien czuć, że potraktowano go z szacunkiem i godnością – niezależnie od prezentowanej wiedzy i umiejętności.

Jak w takim razie sprawdzić umiejętność radzenia sobie ze stresem? Pytanie zasadnicze – czy na pewno musimy to sprawdzać wprost? Jeśli mimo naszych najlepszych starań, kandydat “trzęsie się jak galareta”, to zapewne coś jest nie tak. Poza tym… moim zdaniem, nie sprawdzimy tego dobrze w ciągu 1, 2 czy 3 godzinnego spotkania, a z reguły tyle maksymalnie czasu jest do dyspozycji.

Mit 8: nie dawaj po sobie poznać jak mu idzie

Temat jest bardzo drażliwy i delikatny. Bardzo uzasadnione jest to, żeby nie doprowadzić kandydata do świadomości, że idzie mu świetnie i jest najlepszy na świecie. Z tego powodu część osób przybiera postać bezemocjonalnego słuchacza, który na dowolną głupotę odpowie “bardzo dziękuję za odpowiedź”.

Musimy jednak pamiętać, że rekrutacja to bezpośrednie spotkanie z potencjalnym pracownikiem, ale również w przyszłości być może partnerem, klientem, współpracownikiem, albo znajomym kogoś takiego. Co więcej – rekrutacja w moim rozumieniu, niezależnie od końcowego wyniku powinna coś dać obu stronom. Dlatego ja staram się od jakiegoś czasu, zawsze wyjaśniać poprawną odpowiedź na pytanie/zagadnienie w przypadku gdy kandydat uczciwie deklaruje, że nie zna odpowiedzi lub, że nie jest jej pewien. Kto wie – być może dzięki temu, ktoś kiedyś zrozumie jakiś ważny element, który będzie dla niego przełomem i nawet jak nie dostanie pracy, to w przyszłości rozwinie swojej karierę. A być może opowie swoim kolegom, że miał fajną rozmowę. Tak czy inaczej plus na przyszłość.

Mit 9: dobre pierwsze wrażenie to podstawa / ubiór, wygląd, prezentacja są bardzo ważne LUB ubiór, wygląd, prezencja w ogóle nie są ważne

Większość poradników dla osób szukających pracy rozpisuje się o tym, jak to trzeba pięknie się ubrać, wypucować i wymalować przed spotkaniem rekrutacyjnym. Znaną prawdą jest to, że takie rady raczej średnio dotyczą IT. Ale niektórzy przesadzają! W swojej kilkuletniej karierze rekrutera, spotkałem chyba wszystkie konfiguracje ubioru i wyglądu kandydatów – od top-class garnituru, po klapki i szorty (tak!!!).

Jak dla mnie wszystko (no może poza klapkami i szortami) jest dopuszczalne, o ile weźmiemy pod uwagę jedną ważną rzecz. Ubiór i ogólnie wygląd, sposób siedzenia, mówienia… to część wiadomości jaką wysyłamy o sobie w świat. W rekrutacji jak najbardziej nie można tej informacji zignorować! ALE – nie można również odczytywać jej w oderwaniu od reszty przekazu. Wobec tego – warto szukać ludzi, których przekaz werbalny i poza-werbalny jest spójny i podkreśla rzeczywiste mocne strony danej kandydatury.

Przykład – kandydat przyszedł w t-shirt’cie z napisem “I don’t care” i trampkach… ok! Jeśli swoją wiedzą i poziomem odpowiedzi potwierdza, że rzeczywiście może pozwolić sobie na to, że “nie obchodzi go…” – bo wie, że jego wartość leży gdzie indziej i wręcz stara się ją w ten sposób podkreślić. Człowiek ubrany tak samo, ale prezentujących przeciętny poziom kompetencji wygląda śmiesznie i groteskowo – udając kogoś kim nie jest. Podobnie osoba pięknie ubrana, w wyprasowanej koszuli, krawacie i garniturze – jeśli w czasie rozwiązywania zadań i udzielania odpowiedzi okazuje się niechlujna i nieuporządkowana, zaczyna budzić wielkie podejrzenia – może ubiorem próbuje przykryć jakiś problem?! Ubierając się zbyt ładnie, w pewien sposób stawia sobie wygórowane wymagania. Tak samo ubrany kandydat, który płynnie i wyraźnie tłumaczy podstawowe, ważne rzeczy – nawet jeśli nie jest idealny merytorycznie, daje jasny przekaz: jeśli będzie trzeba, wyślesz mnie na spotkanie z biznesem / klientem i zrobię super wrażenie – a to często jest duży plus.

I ostatnia sprawa – wiele osób zapomina, że w rekrutacji chodzi o to, że obie strony mają szanse, żeby się zaprezentować – z dobrej albo złej strony. Rekrutując, powinniśmy okazywać szacunek ludziom, których spotykamy – od samego początku. Rekruter w szortach, klapkach i pomiętolonym t-shirt’cie to przeciętnie śmieszny dowcip, nawet jeśli atmosfera w firmie jest bardzo luźna.

Mit 10: rekrutacja to zadanie jedynie dla team leadera i HR

Są firmy w których jedynymi osobami decydującymi o zatrudnianiu nowych pracowników, są kierownicy / zarządcy / managerowie. Oczywiście – finalna decyzja musi płynąć od osoby decyzyjnej, ALE – pominięcie w procesie rekrutacji udziału osób stricte technicznych – praktyków, którzy obecnie biorą aktywny udział w projektach IT, to zdecydowanie zła praktyka. I to z wielu powodów! Z własnego doświadczenia wiem, że dla doświadczonego developer czy architekta możliwość udziału w rekrutacji i siłą rzeczy w procesie decyzyjnym, to ciekawa odskocznia od codziennych obowiązków – taki bonus (oczywiście nie dla wszystkich). Sam nauczyłem się wiele rekrutującą. O ludziach i technologii. Co więcej – finalnie nowo zatrudniona osoba ma stać się częścią zespołu i pracować z zespołem, a nie tylko raportować do managera. Jeśli chcemy okazać szacunek zespołowi, musimy dać jasny przekaz – nowi członkowie zespołu przechodzą konkretną selekcję i mają postawione jasne wymagania.

Na koniec małe kwiatki…

Kilkanaście razy spotkałem się z odpowiedzią: “no właśnie niedawno nawet o tym czytałem, tylko… no jakoś nie pamiętam dokładnie co”. Moja interpretacja: kandydat nie zna odpowiedzi, co więcej mówi o tym, że ma problemy z przyswajaniem wiedzy i nauką. A najprawdopodobniej również ściemnia, czyli kłamie. Współczuję i dziękuję za poświęcony czas, życząc szczęścia.

Lubię pytania o testy. Wiele ludzi niestety nie ma o tym pojęcia. Niezliczoną ilość razy słyszałem już odpowiedź: “no chcieliśmy robić testy jednostkowe, ale jakoś nie było na to czasu”, albo “nie mieliśmy czasu na testy, bo musieliśmy bardzo szybko dostarczać nowe funkcjonalności”. Innymi słowy: “tak szybko pracowałem, że aż nie miałem czasu patrzeć na to co robię. Tak szybko zachrzanialiśmy z taczkami, że nie było czasu na patrzenie czy są one załadowane”. Rozumiem, że jest sporo środowisk, które generują takie myślenie. Ale przerażające jest, jak bezrefleksyjnie ludzie do tego podchodzą.

Podsumowanie

Rekrutacja IT to trudny i ważny temat. Obecnie wiele firm jest w podobnej sytuacji – potrzeba dużo nowych ludzi do pracy (co jest super!). Oznacza to, że jeszcze uważniej trzeba przyłożyć się do dobrego wyboru tych ludzi. Niestety praktyka pokazuje, że popularny żart: “Nie stać Cię na zatrudnienie specjalistów? Nie wiesz jeszcze, ile kosztuje zatrudnienie amatorów!” jest bardzo prawdziwy. Wszystkim rekrutującym i rekrutowanym dużo powodzenia i sił!

Warto przeczytać

Joel Spolsky – The Guerrilla Guide to Interviewing 3.0 – klasyczny tekst, do którego prawie wszyscy nawiązują
http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

Laurie Voss – You suck at technical interviews – całkiem nowy tekst, który dość sprytnie neguje część tez Joel’a
http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews

Matt Youell – The art of recruiting a software developer – spojrzenie z nieco innej strony – kilka rad nie tylko dla rekruterów technicznych, ale ogólnie dla ludzi poszukujących kandydatów
http://qz.com/70905/the-art-of-recruiting-a-software-developer/

6 thoughts on “Mitologia rekrutacji programistów

  • 8 października 2014 at 09:21
    Permalink

    Z podsumowania – pracownicy nie mają czasu z gumy a częst pracodawcy / managerowie projektów nie ujmują w cyklu produkcji testów.

    Wykształcenie często okazywało się niekluczowe. Kluczowe były wyuczone metodologie pracy, zarządzania kodem, tworzenia testów czy dokumentacji.

    Zadanie choćby najprostsze oddziela quasiprogramistę od programisty [chciałem być subtelny].

    I nawet jeśli technik dobrze rokuje a nie jest dopasowany w 100% a potrzebni uczciwi PISACZE a nie dizjanerzy systemów to jest okres próbny i

    Reply
  • 8 października 2014 at 09:36
    Permalink

    Ad mit #7

    Z tym stresem to nie jest takie oczywiste… Wielu kandydatów uprawia na rozmowach autokreację – stara się zaprezentować umiejętności czy cechy osobowości, których nie posiadają. W spokojnej, zrównoważonej rozmowie taka autokreacja jest dużo łatwiejsza niż w stresie. Pamiętam, że po jednej z rozmów wyszedłem z poczuciem że zatrudniamy bardzo spokojnego i zrównoważnego kandydata – a potem ta osoba była najbardziej rozrywkowym członkiem zespołu. Co oczywiście nie znaczy, że pracowała źle :)

    Dlatego niektórzy rekruterzy świadomie wprowadzają w rozmowie element stresu – prowadzą ją bardzo dynamicznie, przerywają kandydatowi wypowiedzi, zadają niespodziewanie pytania. W ten sposób bardziej wychodzą naturalne cechy osobowości.

    Natomiast przeprowadzenie takiej rozmowy żeby nie „stłamsić” kandydata i żeby on potem był też zadowolony z tej rozmowy na pewno jest proste.

    Reply
  • 8 października 2014 at 14:39
    Permalink

    Z ta edukacja to jest roznie i wiele zalezy od uczelni. Moje osobiste anegdotyczne obserwacje na przyklad wygladaja tak:

    – Politechnika Gdanska na ktorej studiowalem blisko 4 lata, to glownie zmarnowane 4 lata. Pracujac zawodowo juz od trzeciej klasy liceum wiecej mialem momentow typu „WTF” sluchajac wykladow niz rzeczywistego poczucia ze otrzymuje jakas przydatna wiedze. Rzucilem studia na czwartym roku i do tej pory uwazam ze to byla jedna z lepszych decyzji.

    – Ludzie bez doswiadczenia zawodowego, prosto po PG, z ktorymi pracowalem, w wiekszosci do pracy sie nie nadawali i potrzebowali co najmniej roku zeby byl z nich jakikolwiek pozytek.

    – Ogromnym kontrastem w stosunku do powyzszego byli ludzie np. po Politechnice Warszawskiej – mimo braku doswiadczenia zawodowego, krotko po studiach, byli to jedni z lepszych i bardziej pojetnych – a takze kumajacych a’priori „o co biega” ludzi.

    – Pasjonat natomiast obroni sie sam i wcale nie porzeba uczelni, zeby wiedziec na czym polega dobre OOP, organizacja pracy, co to jest zlozonosc obliczeniowa, jak dzialaja uzyteczne algorytmy itd.

     

    I chyba w tym ostatnim stwiedzeniu lezy rdzen problemu: sa pasjonaci ktorzy instynktownie rozumieja zagadnienia zwiazane z wytwarzaniem oprogramowania (i chetnie rozwijaja swoja wiedze na rozne sposoby – teoretyczne i praktyczne), i sa tacy ktorych zaden projekt i zadne studia tego nie naucza. Wydaje mi sie ze reszta punktow tego eseju dosc dobrze pokazuje jak odroznic jednych od drugich :)

    Reply
  • 9 października 2014 at 11:21
    Permalink

    Niestety, osoby zajmujace sie rekrutacja czesto interpretuja „umiejetnosc formulowania zdan” jako gadatlowosc. Mysle teraz o kontrprzykladzie dla mitu #4. Fantastyczny spec, ktory przez wiekszosc czasu milczy. Czasem powie jedno spokojne wywazone zdanie, ktore natychmiast przechodzi do historii (np. „oooo….. cos sie chyba pali” (w reakcji na mini-pozar stolu) albo „jeszcze trzy malle i do domu”).

    Zawsze chcialabym go miec w swoim zespole bo jest efektywny, konstruktywny i dokladny. Niestety, jest tez mocno niedoceniany, bo swoje poglady wyraza spokojnie albo wcale. Trzeba wykonac wysilek i poprosic go o opinie – a wtedy okaze sie ze wysilek byl tego wart. Nie zatrudnilabym go na speca od relacji z klientem, ale marzylabym zeby w mojej firmie byl taki architekt.

    Jako gadula otrzymalam od tego czlowieka madrosc zyciowa: fakt ze ktos mowi malo nie znaczy ze nie mowi. To znaczy tylko tyle, ze jego pojedyncze zdania sa bardziej cenne.

    Reply
  • 11 października 2014 at 09:29
    Permalink

    Fajne to wszystko i jak bardzo uproszczone. Panie Witoldzie, są różne typy temperamentów i różni ludzie z naprawdę całą gamą doświadczeń życiowych. Każdy z nas jest trochę inny, ale każdy ma swoje plusy i minusy. Dziwi mnie natomiast taki totalny odsiew po bardzo prostych parametrach. Szufladkowanie ludzi jest naprawdę bezproblemowe, ale faktyczne wyłapanie ich zalet i wad jest dużo trudniejsze.

    Jako rekruterzy jesteście prawdopodobnie takimi jasnowidzami, musicie na krótkiej 1-3 godzinnej rozmowie określić kim jest gość, który siedzi na przeciwko was. Bardzo dobrze to rozumiem, ale nie rozumiem tego jak łatwo się dyskwalifikuje ludzi tylko dlatego, że nie ma się umiejętności wyłapywania cech charakteru.

    Znam różnych programistów i często mówi się, że ten jest dobry, a tamten zły. Ja się trochę z tego śmieję, bo często takie opinie wypowiada osoba, która akurat mogłaby przemilczeć krytykę.

    Zauważyłem pewną zależność, są ludzie, którzy są faktycznie introwertykami z którymi rozmawia się po prostu trochę inaczej niż z ekstrowertykami. Taki introwertyk prowadzi bardzo spokojną rozmowę co nie oznacza, że ma ogromną wiedzę na dany temat, po prostu jest to inna format kontaktu z tym człowiekiem. Ekstrowertycy (powiedzmy skrajni) są bardzo energiczni i kontaktowi, szybcy w mowie, w myśleniu i w działaniu, ale to również nie znaczy, że są świetni w tym co robią.

    Czyli, pomijając fakt czy jesteśmy introwertykami czy też ekstrowertykami czy może miksem tych dwóch temperamentów możemy wnieść swoje umiejętności do zespołu, ale zespół powinien być tak stworzony, żebyśmy się nie pozabijali!!! Spędzamy w pracy ze sobą min. 8 godzin dziennie, jeżeli ktoś nas tak dobrał w zespole, że nasze wizje, opinie, charaktery, sposoby bycia, są tak różne, (albo podobne wady), że nie jesteśmy w stanie wypracować konsensusu, to jak mamy tworzyć zgrany zespół? Jak tworzyć świetny produkt, albo jak być zadowolonym i z chęcią wykonywać swój zawód?

    Rekruterzy, prośba do Was. Pisanie, że nie jest się psychologiem jest może i faktem, ale czy na pewno to jest dobre podejście? Przecież rekrutując musisz wiedzieć jaki zespół ludzi składasz, kogo z kim wiążesz na ileś godzin dziennie. Ten aspekt wyboru pracowników jest według mnie pomijany w trakcie rekrutacji, nie mówiąc już o wychwyceniu zalet, prawdziwych umiejętności człowieka.

    Mój pomysł, zrób sobie tabelkę z umiejętnościami jakie znasz, jakie powinien mieć dany pracownik i w trakcie rozmowy z każdą osób wpisuj wartości liczbowe czy słowne w rubrykę w której ten człowiek jest dobry. Przykładem może być analiza wymagań, widzisz, że osoba jest szybko myśląca, szczegółowa, rozwija każdy temat i ma umiejętność gadania przez wiele godzin dziennie na ten sam temat, wyłapuje słabe punkty rozwiązania i zgłasza pomysły na ich ulepszenie, to może być znak, że spotkałeś właśnie świetnego analityka wymagań. I co dalej? Ta osoba wcale, ale to wcale nie musi być dobrym programistą.

    Reply
  • 3 lutego 2017 at 13:11
    Permalink

    #Mit 11 – „Hackathony to tylko towarzyskie spotkania i nie spełniają swojej funkcji rekrutacyjnej”
    Nie piszesz nic o wyłapywaniu zdolnych ludzi podczas konkursów programistycznych. Widzisz ich wtedy w działaniu, podczas pracy, widzisz jak się komunikują i jak pracują.
    Co o tym myślisz?

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *