Rynek pracy w Warszawie - dlaczego rekrutacje są takie debilne?

4

Minimum 70% systemów to kupo kod. I nie ma znaczenia kto je pisał. Powstawały w pośpiechu, zmieniały się koncepcje, zespoły projektowe itp.
Na rynku brakuje też mentorow, dlatego wielu ludzi tak jak ja sam do wszystkiego doszedłem, ucząc się na własnych błędach. A studia dają tylko ogólny pogląd na technologie i narzędzia, na mało których zwraca się uwagę na jakość kodu.

2

Mnie się wydaje, że każdy miał tutaj swoje własne przejścia, doświadczenia, pracował w różnych technologiach i przy różnego rodzaju projektach, nie wiem więc jak mielibyście dojść do porozumienia. U mnie specyfika pracy w jednym dziale w dwóch zespołach była zupełnie inna, a co dopiero tutaj, gdzie dwie osoby mogą zajmować się czymś zupełnie innym i zupełnie różne typy osobowości mogą być do danych rodzajów zadań potrzebne ;)

1
Troll anty OOP napisał(a):

W ogóle określenie "mruk" jest trochę określeniem negatywnym, ale weźmy ten typowy przypadek o którym mówimy: introwertyzm, plus opcjonalnie jakiś stopień fobii społecznej. Żadna z tych cech nie wyklucza normalnego porozumiewania się w zespole,

Ale ja o innych mrukach mówiłem.
Np. jak ktoś jest zatopiony w kodzie, i nigdy nie można się doprosić, żeby pomógł, a jak już pomaga, to i tak robi to albo od niechcenia ("szybko mów, bo mam tylko 5 minut, bo potem kolejnego pomidora walę"), albo nieudolnie (czyli tłumaczy tak, że i tak ciężko zrozumieć), albo z nutą wyższości, żeby pokazać ci, że jesteś od niego słabszy w programowaniu, jeśli czegoś nie wiesz.

I w czasie rekrutacji podobnie. Np. zdarzyło mi się kiedyś, że programista, który prowadził rekrutację, nie nawiązywał żadnego kontaktu ze mną, tylko zadawał kolejne pytania, których nawet nie do końca słuchał. Wyglądał, jakby siedział tam za karę.

Albo goście, którzy zadawali pytania, ale od razu dawali odczuć, że czują się ode mnie lepsi z jakichś powodów i się zachowywali w chamski sposób. Takie buractwo.

Czyli tak ujęta mrukowatość to nie jest introwertyzm czy fobia społeczna (bo inaczej sam musiałbym się określić mrukiem), tylko:

  • brak kultury osobistej
  • ego wywalone w kosmos, pokazywanie, że się jest lepszym od kogoś, a tamten jest gorszy
  • myślenie tylko o sobie, a nie o to, żeby poświęcić komuś pełną uwagę i wysłuchać kogoś i się jakoś próbować skomunikować, nawet choćby miało to potrwać dłużej niż 5 minut.
4

@LukeJL: no to się kompletnie nie zrozumieliśmy. To co opisujesz to nie mruk, tylko po prostu buc :)

7
piotrpo napisał(a):

Ponieważ w życiu już widziałem kilka takich systemów pisanych przez produktywnych introwertyków, pozwolę sobie nie drżeć z podniecenia na myśl o kolejnym.
To czy ktoś potrafi w komputery, nie ma żadnego związku z tym, jak rozwinięte są jego umiejętności społeczne. Jest to taki mit na bazie Rain Mana i przekonanie, że upośledzenie na jednym polu przekłada się automatycznie na zwiększone umiejętności na innym.

Introwersja to nie jest upośledzenie, a introwertyk to ktoś, kto nie traci po prostu czasu na bezproduktywne dyskusje. Tak więc introwertycy są produktywni niemalże z definicji.

No chyba, że wy tu każdego introwertyka nazywacie mrukiem, ale jak dla mnie, to mrukiem nazwałbym gościa z rodzaju: "ja chcę kodzić, nie chcę żadnych ustaleń, żadnych rozmów z QA ani BA, tylko kod". No to jest z definicji nieproduktywne, i z takimi ludźmi współpraca jest bardzo ciężka. (Tak jak z ekstrawertykami z ich bezustanną potrzebą ględzenia i dyskutowania zamiast wzięcia się do roboty.)

2
LukeJL napisał(a):

z nutą wyższości, żeby pokazać ci, że jesteś od niego słabszy w programowaniu, jeśli czegoś nie wiesz.

Generalnie tak, ale zdarzają się też sytuacje gdzie nie da się inaczej, bo... bo nie.
Przykład - analiza wycieku pamięci aplikacji. Szukamy we dwójkę przyczyny, przeglądamy dumpa i sprawdzamy co siedzi w poszczególnych generacjach (.net).

Podchodzi znajomy - 3 lata dupogodzin (w c#) - i pyta: "A co to są te generacje?"

Tak więc odnosząc się do cytatu: jeśli to pytania o coś niekoniecznie oczywistego a specyficzną rzecz, pytania o architekturę rozwiązania i jakieś sprawy powiązane z dziedziną to tak - to jest słabe.
Natomiast jeśli ktoś pytając o podstawowe rzeczy pokazuje kompletny brak kompetencji (i co najlepsze uważa się równocześnie za kozaka) to normalnemu człowiekowi może być ciężko zachować stoicki spokój :D

2
Czulu napisał(a):

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.

Tak jest ze wszystkim w tym kraju, bo pracodawcy przyzwyczaili się przez wiele lat do pracowników dobrych i tanich, toteż zmiana tego zajmie jeszcze sporo czasu.

2

Mam całkowite odmienne doświadczenia z rekrutacji w Warszawie.
Pytania otwarte w stylu "Co zrobisz jak wywali error?" wcale nie są takie złe, bo potrafią lepiej zobrazować podejście kandydata, niż jakieś ze zbioru 100 pytań na rozmowie o pracę.
To jakie pytania zadają to ich problem i mają, albo powinni mieć ku temu jakieś powody. Ty masz odpowiedzieć i tyle. Jak się kandydat zapyta o wynagrodzenie na początku rozmowy to nie powinien być dopuszczony do rozmowy, bo ktoś uważa że takie pytania są głupie, bez sensu i nie na miejscu?
Jak pytają o proste rzeczy, to albo próbują odsiać, albo nie mają wielkich wymagań co do umiejętności technicznych. Jak pytają trudne, albo zbyt konkretne rzeczy to może szukają eksperta, albo chcą potem błędną odpowiedź użyć jak argument przy negocjacji wynagrodzenia.
Nie wiem jak tam ze pieniędzmi w .net, ale ja na przykład w Pythonie dostaje oferty ze wyższym wynagrodzeniem niż to co wspomniałeś, pomimo mniejszego doświadczenia. Myślę że tu ma znaczenie to że nie aplikuję na oferty, tylko czekam aż ktoś się do mnie odezwie na LI, więc też ich oferty są trochę wyższe żeby zachęcić kandydata.

Pewnie miałeś pecha i źle trafiłeś, albo ja miałem wyjątkowe szczęście.

0
bootcamp_z_czarnej_listy napisał(a):

Pytania otwarte w stylu "Co zrobisz jak wywali error?" wcale nie są takie złe, bo potrafią lepiej zobrazować podejście kandydata, niż jakieś ze zbioru 100 pytań na rozmowie o pracę.

Miałem takie pytanie na rekrutacji. Po drążeniu tematu moje pytanie o testy spotkało się z odpowiedzią: Nie piszemy testów i ty nie będziesz pisać testów bo to czasochłonne i jakbyśmy je pisali i klient się dowiedział to musielibyśmy je udostępnić klientowi, a on by je przekazał drugiej firmie która pracuje też nad częścią tego systemu.

Rekrutacja to nie jest konkurs Miss Stolicy, nie masz się wykazać, że jesteś Rambo, Jobs, kandydat do nobla w jednej osobie.
Przy takich rekrutacjach na udowodnienie kandydatowi jaki jest cienki zawsze kasa jest słaba albo i kasa słaba i JanuszBiznes.

Jak się kandydat zapyta o wynagrodzenie na początku rozmowy to nie powinien być dopuszczony do rozmowy

Jak nie ma sensownych widełek w ofercie to się nie traci prywatnego czasu na rozmowy.

0

Głupie rozmowy z HR i menadżerami, gdzie zadawane są mi pytania typu "a jak pan zobaczy błąd w aplikacji, to co pan zrobi?". Czasami mam ochotę odpowiedzieć "zesram się i ucieknę".

Mnie raz zapytano "Co pan zrobi jeżeli kolega obok się zadławi i zacznie się dusić?" No kurde, wezmę popcorn i będę patrzył jak kona. Byłem zbyt skupiony żeby się zdziwić, więc z miejsca zacząłem bajerować coś o klepaniu w plecy i manewrach Heimlicha (nie żebym w praktyce wiedział jak się go poprawnie robi, ale ciiiii).

0

To nie takie proste z tymi błędami, bo miałem do czynienia z jednym portalem opartym na Wordpressie, który czasem się wywalał bo nie dawał rady z ogromną ilością danych. Czyli w takich przypadkach to wcale by mnie nie zdziwiło, kiedy to na takiej rekrutacji mogłyby być propozycje czy nie zaorać systemu i napisać od nowa a to wiadomo koszty. A te testy to jak widać w realiach nie wszędzie są stosowane czyli znowu jest problem, starcie z programistą który by chciał takie pisać a tu jak widać w rekrutacji, np. nie piszemy testów. Czyli przychodzi drugi który mógłby się z powodzeniem w tym babrać, podobnie jak nie rzucałby propozycjami zaorania systemu. Który lepszy? Zresztą już w jednej z rekrutacji, od razu z technicznymi rozmawiałem trochę na ten temat ale u nich to te testy były stosowane, więc wydaje mi się że w takich przypadkach to nawet nie jest kwestia tego czy coś się umie, tylko czy się pasuje czy nie, w zależności od swoich upodobań i tego jak się w praktyce realizowało projekty.

1
drorat1 napisał(a):

To nie takie proste z tymi błędami, bo miałem do czynienia z jednym portalem opartym na Wordpressie, który czasem się wywalał bo nie dawał rady z ogromną ilością danych.

Nie piszemy testów jednostkowych bo nasz kod od razu działa.
Nie robimy testów wydajnościowych bo na początku obsługuje tylu klientów, że na starym laptopie wszystko śmiga.
Pokazujemy system, kasujemy klienta, zachęcamy do rozwijania i dodawania funkcjonalności.

Dopiero przy rozwoju i utrzymaniu zaczyna się problem, bo śmieciowo napisany projekt łatany śmieciami staje się nieużywalny i nienaprawialny.
Nie ma testów, nie ma dokumentacji, cool młoda ekipa wymiataczy co go napisała w 2 miesiące znudziła się i poszła w miasto do nowych hipsterskich projektów.

5
  1. Głupie rozmowy z HR i menadżerami, gdzie zadawane są mi pytania typu "a jak pan zobaczy błąd w aplikacji, to co pan zrobi?". Czasami mam ochotę odpowiedzieć "zesram się i ucieknę".

przeciez to bardzo sensowne pytanie, sprawdzajace zarowno soft jak i hard skille.

  1. Lwia część ludzi przeprowadzających te rozmowy nie powinna być na nie w ogóle dopuszczona. I nie chodzi o to że są ubrani jak lumpy pod monopolem, bo to nie jest dla mnie problem. Większym problemem jest to, że te rozmowy nie wiadomo do czego prowadzą. Ostatnio byłem na jednej, gdzie przeszedłem test z podstaw programowania, gdzie pytania były typu "czym się różni interfejs od klasy abstrakcyjnej (klasyk na rozmowach)",. Co oni chcą sprawdzić u kandydata dając mu zadania i pytania na poziomie II roku studiów?

kolejne dobre pytanie, po odpowiedzi od razu widac czy kandydat jest glabem vs czy jest sens dalej powaznie rozmawiac. jak kandydat zaczyna sensownie mowic to mozna zaczac drazyc temat i dojsc do czegos ciekawego.

  1. No i best part, czyli hajs. Mieszkam i pracuję w Warszawie, od kilku lat pracuję w .net, ostatnio w net core, znajomość front, angular, ef itd, na rozmowie odpowiadam na przynajmniej 80% głupich pytań, a jak mówię że chcę zarabiać 14lk netto na fakturę, to robią czasami oczy. Ostatnio mnie odrzucili z jednej firmy i po uzyskaniu feedbacku dowiedziałem się że chodzi o wymagania finansowe. To dlaczego firmy nie negocjują? Ja zawsze mówię stawkę 10-15% wyższą niż chcę, mogą zadzwonić i ponegocjować, jeżeli praca mi się podoba to mogę zejść z wymagań.

odpowiadasz na 80% glupich pytan i chcesz zarabiac 14k netto... masz swoja odpowiedz. powinienes odpowiadac na 100% glupich pytan i pewnie 95% madrych. po prostu nie umiesz na kwote ktora sobie zyczysz i tyle.

moja rada od serca - daj sobie siana z roszczeniowa postawa i po prostu nabierz doswiadczenia i doucz sie.

1

Jedna fajna senior haerka, powiedziała kiedyś, że na rozmowie po pięciu minutach już wie, że ktoś się nie nadaje i ciągnie te 20 minut pogawędki bo musi wypełnić papier. Ludzie bardzo dobrzy technicznie na rozmowie z hr i kadrą nietechniczną odpadają. Ich (humanistów, socjologów, psychologów) rolą jest nie dopuszczenie do zatrudnienia ludzi nie nadających się pod względem nie-technicznym.

Gdy się nadajesz do pracy zdaniem hr i masz jakąś sensowną wiedzę to witamy na pokładzie nową parę rąk.
Jak się nie nadajesz to nie ważny twój skill i projekty. Rekrutacje w Warszawie i innych korpo są debilne bo wszędzie ci sami ludzie od hr w mig rozpoznają, że nie nadajesz się.

Inżynier w firmie A, B i C potrafi bez spiny zakodzić prostego taska. Te [piiiip] po socjologiach i wredne [autocenzura - które nie wiadomo po co tam są] znają się za to na ludziach.

Dziewczyna mnie nie chce, pies mnie rzucił, w Warszawie same głupie haerki i debilni managerowie. Tylko ja jestem coool, mam skill i nawet znam frontendowe frameworki.

3

Ja się jeszcze odniosę do kwestii definicji pojęcia "mruk", którego to mruka miałby eliminować dobrze przeprowadzony proces rekrutacji. Dla mnie i niektórych dyskutantów "mruk" to generalnie człowiek introwertyczny i z jakimś tam poziomem fobii społecznej. I tak zdefiniowanego mruka oczywiście uda się odsiać podczas rekrutacji, bo mając fobię społeczną, trudno jest udawać jej nie posiadanie.

Część dyskutantów jednak pod pojęciem "mruk" rozumie człowieka, który nie tylko mało mówi, ale swoją postawą wręcz sabotuje pracę zespołu, bo wynik pracy ma w dupie. Tylko w jaki sposób rekrutacja miałaby wykryć, że dany człowiek ma tendencję do praktykowania takiej postawy w pracy? Przecież nie jest aż tak głupi, by zademonstrować taką postawę w trakcie rekrutacji. To nie jest wielka sztuka być na co dzień chamskim, a przez godzinę dla pozoru grać na rekrutacji człowieka uprzejmego oraz twierdzić, że na co dzień jest się takim, jak przez tę godzinę.

0
Troll anty OOP napisał(a):

Ja się jeszcze odniosę do kwestii definicji pojęcia "mruk"

Nie inżynier decyduje o miękkim etapie rekrutacji. Nie inżynier definiuje i stosuje definicje społeczne.
Nie socjolożka sprawdza testy jednostkowe i czystość kodu.

Eliminowanie pewnych "osobników" z określonymi cechami osobowości, które akurat wśród programistów są nieproporcjonalnie częściej spotykane, jest faktem.

Programista może popracować nad sobą.
Świat się zmienia. Nadążasz albo nie.
To wszystko.

EdiT
Nie znam się na rekrutacji od strony hr, to nie moja osobista opinia: Zadziwiająco łatwo przy odpowiednim doświadczeniu sprowokować bucowatego, aspołecznego typka do odkrycia się.

Przy rekrutacji do IT zdarzają się nawet takie kwiatki jak aplikacja przez grupy na fejsie gości z wpisami, memami o głupich c..pach z rekrutacji.
Świat postapokaliptyczny, to znaczy post-bootcampowy, zna niejeden taki przypadek aplikującego gościa. (na włąsne oczy widziałem zebrane "kwiatki", to się dzieje naprawdę)

2
BraVolt napisał(a):

Nie znam się na rekrutacji od strony hr, to nie moja osobista opinia: Zadziwiająco łatwo przy odpowiednim doświadczeniu sprowokować bucowatego, aspołecznego typka do odkrycia się.

W odpowiedzi na to, ja napiszę swoją osobistą: nie jest to ani odrobinę zadziwiające, ale wybitnie ciężko rozpoznać kłamcę, który ma świetne "umiejętności miękkie", a później swoją bezczelnością, tylko że ukrytą za grzecznymi słówkami, udawaniem że o czymś nie został poinformowany, powoduje że w ogóle w całym zespole pracuje się tragicznie, nie tylko w interakcjach z nim samym.

Z kolei pracowałem też z człowiekiem często używającym niecenzuralnych zwrotów, niekiedy odzywającym się po prostu chamsko. Ale pracowało się z nim bardzo dobrze, bo chamsko się jedynie odzywał, nigdy chamsko nie postępował (a przynajmniej ja nie zauważyłem), nigdy nie próbował czegoś osiągnąć podstępem. Oczywiście ten przypadek to też żaden ideał, ale ideałów nie ma. To już moja osobista preferencja, że wolę kogoś odzywającego się niekiedy chamsko, niż manipulanta. Manipulant niejako z definicji posiada znakomicie rozwinięte "umiejętności miękkie".

0
Troll anty OOP napisał(a):
BraVolt napisał(a):

Nie znam się na rekrutacji od strony hr, to nie moja osobista opinia: Zadziwiająco łatwo przy odpowiednim doświadczeniu sprowokować bucowatego, aspołecznego typka do odkrycia się.

W odpowiedzi na to, ja napiszę swoją osobistą: nie jest to ani odrobinę zadziwiające, ale wybitnie ciężko rozpoznać kłamcę, który ma świetne "umiejętności miękkie", a później

A później jest trzymiesięczny okres próbny. :)
Socjalni-humaniści to nie wróżki ani agenci CIA żeby rozpoznać każdy przypadek.

Im chodzi o to, żeby wyłapać za wczasu co się wyłapać da. Pamiętam dyskusję w której przedstawicielka jednej z dużych firm mówiła o rekrutacji z punktu widzenia hr.
Ocenia kandydata który musi w pracy często spotykać się z ludźmi. Nie bardzo idzie rozmowa, ona niby przypadkiem sięga do papierów, wyjmuje kartę, mówi

  • O, przepraszam, przez przypadek zawieruszyła mi się notatka z inną ofertą pracy, ale to chyba pana nie zainteresuje, bo mamy tu takie stanowisko, na którym siedziałby pan w pokoju na końcu korytarza, nikt by do pana nie zaglądał...
    Tu kandydat się ożywia.
  • Chciałby pan porozmawiać o tym stanowisku?, pyta niby zdziwiona rekruterka.

Jak mówiła na spotkaniu, nawet takie proste tricki działają.
Bo nie chodzi na tym etapie o wybranie najlepszych kandydatów ale o odrzucenie już teraz kompletnie się do tej roli nie nadających.

3

To chyba zostało już udowodnione naukowo, co prawda nieładnie przeklinać ale to powinna być oznaka szczerości i uczciwości. Przychodzi ktoś taki na rozmowę i co? Od razu pewnie będzie skreślony. Co do samych testów na umiejętności miękkie, staranie się o pracę na rozmowie to niewątpliwie jest sprzedaż. Przychodzi więc gość słaby technicznie ale za to bardzo dobry w negocjacjach, potrafiący nawijać makaron na uszy a w rozmowach mówiący to co ci po drugiej stronie chcieliby usłyszeć. A z drugiej strony jako kolejny kandydat będzie to ten który jest szczery i mówi także o swoich wadach ale jednocześnie kiepski w negocjacjach i z kiepskimi umiejętnościami handlowymi ale za to dobry technicznie. I tu się tylko zastanawiam kto ma większe szanse, bo co do uczciwości to już na bazie doświadczeń też można wygrać i już tak raz przekonałem nawet do siebie firmę która się zawiodła na poprzednim wykonawcy projektu. Tylko że wszystko się odbywało bezpośrednio z kimś kto był w zarządzie firmy a nie z HR-ami a to chyba jednak różnica.

1
drorat1 napisał(a):

Przychodzi więc gość słaby technicznie ale za to bardzo dobry w negocjacjach

Pożądany pracownik. Jak jeszcze technicznie się podciągnie będzie bardzo dobrze. ;)

Im większe i dłuższe w cycku życia projekty tym mniejsze zapotrzebowanie na specjalistów w rodzaju (parafrazując Ś.P. Klasyka)
"Jakbyśmy dwóch takich programistów mieli to byśmy sami ten Windows napisali".

0

Zabawny ten temat bo pokazuje jak wyobrażenia odbiegają od rzeczywistości. Zakładając że nie startujesz do Googla by pisać ich innowacyjne algorytmy to Twój poziom nie jest tak ważny jak Ci się wydaje. Pracodawca woli kogoś kto łatwo wkomponuke się w zespół i nie będzie zawalal roboty. Jak do tego jest wymiataczem to super. Jak idziesz na rozmowę odpowiadasz na 80% pytań i do tego przy tych łatwych sprawiasz wrażenie jakby Ci przeszkadzano to nie dziw się że nie chcą Ci sporo płacić. Ja dopiero zaczynam karierę zawodową w programowaniu. Pierwsza pracę dostałem mimo że nie miałem do niej podstaw. Druga dostałem już z pensja 5 cyfrową mając rok doświadczenia komercyjnego, a żeby było śmiesznie to PHP i nie w Warszawie. Byłem w trakcie swojej "kariery" na 4 rozmowach i na 3 dostałem propozycję pracy. Ostatnia rekrutacja wyglądała tak że po godzinnej rozmowie technicznej powiedziane że mnie na 100% biorą i jutro odezwie się ktoś w sprawie negocjacji stawki.
Moja strategia jeśli tak to można nazwać to pokazanie, że mimo braków technicznych jestem zainteresowany nauka i łatwo się że mną dogadać. Na proste pytania zawsze odpowiadam szerzej - przykładowo na pytanie interfejs vs abstrakt bym napomknal o kilku wzórcach typu metoda szablonów czy o zasadzie separacji interfejsow z SOLID. Pokaże w ten sposób na banalny pytaniu że nie nauczyłem się tego z książki tylko umiem zastosować w praktyce i jestem podjarany tematem OOP.
Nie wiem jak w Warszawie ale na prowincji działa dobrze. Fakt że ja po prostu mam taką osobowość że zawsze myślę w kategoriach miękkich i lubię sobie pogadać o programowaniu. Tak więc nie jest to jakieś udawanie z mojej strony. Nawet jednak nie mając takiej osobowości pewnie można się w czasie rozmowy na coś takiego zdobyć.

2
Troll anty OOP napisał(a):

Ja się jeszcze odniosę do kwestii definicji pojęcia "mruk", którego to mruka miałby eliminować dobrze przeprowadzony proces rekrutacji. Dla mnie i niektórych dyskutantów "mruk" to generalnie człowiek introwertyczny i z jakimś tam poziomem fobii społecznej. I tak zdefiniowanego mruka oczywiście uda się odsiać podczas rekrutacji, bo mając fobię społeczną, trudno jest udawać jej nie posiadanie.

Wtedy jest większy problem, bo taka osoba może się bać np. rozmawiać przez telefon. A ponieważ rekrutacje są często prowadzone przez telefon (niezależnie czy jest taka potrzeba czy nie), to taka osoba będzie mieć problem z przejściem większości rekrutacji.

Część dyskutantów jednak pod pojęciem "mruk" rozumie człowieka, który nie tylko mało mówi, ale swoją postawą wręcz sabotuje pracę zespołu, bo wynik pracy ma w dupie. Tylko w jaki sposób rekrutacja miałaby wykryć, że dany człowiek ma tendencję do praktykowania takiej postawy w pracy? Przecież nie jest aż tak głupi, by zademonstrować taką postawę w trakcie rekrutacji.

No nie wiem jak jest od drugiej strony, ale jako kandydat zdarzało mi się spotkać z rekrutującymi mnie chamami. Więc jeśli osoby zajmujące się rekrutacją są "tak głupie, by demonstrować taką postawę w trakcie rekrutacji", to mogę przypuszczać, że i odwrotnie bywa.

1

Myślę, że tutaj paru ludzi próbuję potwierdzić swoją teorię o wyższości umiejętności miękkich wykorzystując pewno oczywistość - CRUD developer albo klepacz stronek nie potrzebuje jakiejś ogromnej wiedzy technicznej. W przypadku takiej pracy wszystkie umiejętności techniczne ponad pewien poziom są bezużyteczne (a wręcz szkodliwe, bo taki ktoś może być zbyt ambitny na daną posadę). Jeżeli wielu kandydatów osiąga ten poziom, to rzeczywiście można ich odsiać po umiejętnościach miękkich.

Niestety, jeżeli pracujesz przy czymś ambitniejszym, to okazuje się, że ogarniętych ludzi jest za mało i nie można wybrzydzać. Na pewno nie po tym, że nie udało mu się oczarować HR-ki.

0

Raczej chcą wytłumaczyć że miękki skill podnosi wynagrodzenie tak samo jak każdy inny atut. Już w latach 20tych ubiegłego wieku robiono badania na temat miękkich skilli i okazało się że w zawodach technicznych maja większy wpływ na wynagrodzenie niż w średniej dla populacji. W programowaniu zepewne tak jest również bo to sport drużynowy a przy okazji jest sporo osób które tego skilla nie mają.

1
part napisał(a):

Myślę, że tutaj paru ludzi próbuję potwierdzić swoją teorię o wyższości umiejętności miękkich wykorzystując pewno oczywistość - CRUD developer albo klepacz stronek nie potrzebuje jakiejś ogromnej wiedzy technicznej. W przypadku takiej pracy wszystkie umiejętności techniczne ponad pewien poziom są bezużyteczne (a wręcz szkodliwe, bo taki ktoś może być zbyt ambitny na daną posadę). Jeżeli wielu kandydatów osiąga ten poziom, to rzeczywiście można ich odsiać po umiejętnościach miękkich.

Technologia jest łatwa, to wszystko inne jest trudne. Oczywiście testy techniczne są potrzebne (żeby odsiać kompletnych ignorantów), ale nie przesadzajmy. W większości projektów pewnie większe znaczenie ma komunikacja w zespole niż poziom techniczny indywidualnego pracownika.

Dlatego firmy nie powinny "zatrudniać pracowników", tylko powinny budować zespół. Rekrutacje powinny wyglądać tak, że rozmawiasz z ludźmi, z którymi będziesz bezpośrednio pracować i sprawdzacie czy jest chemia.

Czasem tak wyglądają, ale nie zawsze. No bo jeśli rekrutacja polega na gadaniu z HRką (z którą nie będziesz pracować!), czy na gadaniu z jakimiś "dyżurnymi programistami" (a nie tymi, z którymi będziesz pracować), to nie można tej chemii zbadać. Kandydat może tylko przypuszczać, jak będzie wyglądać tam praca, a firma może tylko przypuszczać, jak pracownik będzie współgrał z innymi.

Tak samo czemu ma służyć zadanie domowe typu "zakoduj prostą aplikację, która robi rzecz X, Y i Z"? To tylko sprawdzi umiejętności techniczne i czy ktoś się nadaje na samotnego freelancera, który mając z góry ustalone wytyczne, potrafi to zakodować. A nie sprawdzi tego, jak ktoś będzie realnie pracował w danym zespole, kiedy będzie wzmożona potrzeba komunikacji z innymi i synchronizacji swojego kawałka pracy z tym, co robią inni.

Niestety, jeżeli pracujesz przy czymś ambitniejszym, to okazuje się, że ogarniętych ludzi jest za mało i nie można wybrzydzać.

Co masz na myśli poprzez "coś ambitniejszego"? Podaj przykład.

0

Słyszałem, że do Allegro jest całkiem ciekawa rekrutacja, nie każą implementować quicksorta na tablicy i rozmawia się z sensownymi ludźmi, z którymi potem się pracuje w zespole

1
LukeJL napisał(a):
part napisał(a):

Myślę, że tutaj paru ludzi próbuję potwierdzić swoją teorię o wyższości umiejętności miękkich wykorzystując pewno oczywistość - CRUD developer albo klepacz stronek nie potrzebuje jakiejś ogromnej wiedzy technicznej. W przypadku takiej pracy wszystkie umiejętności techniczne ponad pewien poziom są bezużyteczne (a wręcz szkodliwe, bo taki ktoś może być zbyt ambitny na daną posadę). Jeżeli wielu kandydatów osiąga ten poziom, to rzeczywiście można ich odsiać po umiejętnościach miękkich.

Technologia jest łatwa, to wszystko inne jest trudne. Oczywiście testy techniczne są potrzebne (żeby odsiać kompletnych ignorantów), ale nie przesadzajmy. W większości projektów pewnie większe znaczenie ma komunikacja w zespole niż poziom techniczny indywidualnego pracownika.

Po części się zgadzam, a po części nie. Technologia faktycznie jest stosunkowo najprostsza; poznanie składni, podstawowych zasad środowiska, wyjątków, praktyk, rzeczy nie zapisanych w dokumentacji, dobra znajomość dokumentacji itp. To nie jest aż tak trudne, ale WYMAGA CZASU. Z tego powodu często w ogłoszeniach wymagany jest staż pracy, ale nikt znowu nie wymaga stażu pracy 20lat +, bo zwyczajnie znacznie mniej jest potrzebne, żeby płynnie opanować jakąś technologię. Zwykle są to 2-5 lat, w zależności od technologii, przy czym po pół roku ma się jakąś biegłość zależną od wcześniejszego doświadczenia.

Drugą rzeczą są umiejętności miękkie. Te zawsze są potrzebne, ale ich ocena nie jest liniowa. Gość musi się nadawać do pracy w zespole, ale nie musi być charyzmatyczny jak Napoleon, czy Jurek Owsiak:P Musi się umieć komunikować, dogadać i być odpowiedzialny. Pewnie gdyby była zasadnicza służba wojskowa, to nie byłoby to weryfikowane.

To co jest najbardziej istotne, przynajmniej w obszarach, którymi ja się zajmuje, a które zawsze były trudne, to...
Talent i ogólne kompetencje programistyczne.

4 rzeczy najbardziej sprawiają, że programowanie jest jednak niezwykle trudne, przy czym nie występują one w każdym projekcie (vide Crud), a przynajmniej nie występują wszystkie :

  • olbrzymia skala prostych systemów
  • zaawansowane informacyjnie rozwiązanie
  • ciągle zmieniająca się technologia
  • konieczność stworzenia projektu bez żadnego błędu, a zatem takiego który ma mechanikę samowykluczania błędów, np. ściśle opisanego testami, procedury itp.

Wracając do mojej opinii, że talent jest najważniejszy, to często programiści, pomimo wiedzy o składni itp. nie potrafią zaprojektować, rozwijać, a także zmieniać dużych systemów, działać w trudnych środowiskach, uczyć się nowych technologii, zapobiegać błędom.
Największy problem jest taki, że niezwykle trudno sprawdzić to na rekrutacji.

0
renderme napisał(a):

Drugą rzeczą są umiejętności miękkie. Te zawsze są potrzebne, ale ich ocena nie jest liniowa. Gość musi się nadawać do pracy w zespole, ale nie musi być charyzmatyczny jak Napoleon, czy Jurek Owsiak:P Musi się umieć komunikować, dogadać i być odpowiedzialny.

Ale znowu. Stawiając na piedestale to, "żeby kandydat miał umiejętności miękkie", to możemy popełnić ten sam błąd, co z technologią. Czyli oceniamy umiejętności kandydata zamiast budować zespół.

A co to są "umiejętności miękkie?". Jak określić czy coś jest umiejętnością, czy przywarą?

Np. ktoś jest perfekcjonistą - i to może być wada (bo "better done than perfect"), ale również zaleta - jeśli taka osoba będzie mogła uprawiać swój perfekcjonizm w obszarach, gdzie to ma sens. Albo np. łagodne usposobienie - może być to zaletą, bo taka osoba nie będzie generować konfliktów czy kłócić się z nikim - ale może być również wadą, bo takiej osobie łatwo wejść na głowę albo ją olać (i wyobraźmy sobie -PMa o łagodnym usposobieniu). Albo introwersja-ekstrawersja. Jak są sami introwertycy w pomieszczeniu to jest grobowa atmosfera. Ale jak jest za dużo ekstrawertyków, to też źle, bo będą hałasować i przeszkadzać innym.

Więc to zależy. Ciężko oceniać człowieka bez kontekstu całego zespołu. Bo powiedzmy, że ktoś ma tendencje przywódcze - to może być zaleta, jeśli szukamy np. seniora, ale jeśli szukamy regularnego programisty do klepania tasków, to niekoniecznie.

Ostatnio czytałem taki artykuł, w którym babka pisała, dlaczego odrzucają kandydatów (właśnie m.in. dlatego, że " WE ARE ASSEMBLING A TEAM, NOT HIRING INDIVIDUALS.")
https://charity.wtf/2019/10/18/the-real-11-reasons-i-dont-hire-you/

Pewnie gdyby była zasadnicza służba wojskowa, to nie byłoby to weryfikowane.

???

2

Wszystko zależy od profilu kandydata, jakiego szuka firma. IMO miękko trzeba również weryfikować (umiejętnie, a to wcale nie jest łatwe, nie wystarczy zapytać "czy masz empatię?"), bo nawet najlepszy hero developer jest wstanie rozsadzić zespół swoim ego. Świat nie jest czarno-biały - albo ktoś jest mocny technicznie, albo ma umiejętności współpracy. Kombinacja obu jest najbardziej pożądana i to są naprawdę rzadkie przypadki.

1

CRUD developer albo klepacz stronek nie potrzebuje jakiejś ogromnej wiedzy technicznej.

I dlatego tyle razy widze "adnotacja na twarz i pchasz", sterowanie flow wyjątkami, łamanie SOLID, biedarchitekture "controller service repository" itd?
Widzisz, jako Java/JVM dev uwazam że potrzebuje znajomośc przynajmniej:
-bardzo dobra znajomośc języka Javy
-znajomośc SOLID, OOP, FP i AOP (to ostatnie  zeby wiedziec jakie problemy może sprawić :D )
-umiejętność stworzenia dobrej architektury. Tutaj wypada znajomość i tej prostej dla CRUDów totalnych i np. Hexagonalnej gdzie masz jakąs logikę biznesową
-umiejętnośc SQL, wiedzenia co to N+1, itd
-umiejętnośc z pogranicza DevOpsowego - bash, docker itd.
-znajomośc narzedzi do budowania
-umiejętnośc pisania testów
-wybrane wzorce projektowe

To jest minimum. Bo później Team Leader (przecież to tylko CRUDy...) mówi "to Java nie Scala" kiedy proponuje żeby użyć Either zamiast wyjątków (gdzie te wyjątki sa w miejscu które się nie nadaje do wyjątków i może to być bardzo kosztowne dla aplikacji)
Bo niby to takie proste a ludzie zapominają jak zrobic JOINa w SQL :D

1 użytkowników online, w tym zalogowanych: 0, gości: 1