@piotrpo: a bo zajmuję się m.in. rekrutacją techniczną od jakiś 7-8 lat. I nigdzie nie pisałem o latach doświadczenia, bo ten wskaźnik zazwyczaj rozbija się przy pierwszym kliencie z USA czy UK (gdzie seniorzy to się zaczynają od 10-12 lat doświadczenia). Chodzi o zakres obowiązków. Firmy mogą różnie mówić o latach doświadczenia, ale zakres obowiązków na danym poziomie jest bardzo zbliżony i często różni się tylko nazewnictwem pewnych elementów.
0
1
Koziołek napisał(a):
łapiesz się słówek.
Łapię, bo jak dyskutować o czymś co raz nazywasz wymaganiem, raz obowiązkiem, raz może odpowiedzialnością.
Tutaj piję do Ciebie, bo bronisz osobnika, któremu jak brakuje argumentów to zaczyna prowokować wyzywając od dzieci, buractwa itd.
Pokażę Ci dlaczego.
Od dłuższego czasu na tych stanowiskach są dość jasno opisane nie tyle wymagania ile obowiązki i odpowiedzialności
Wymagania na dane stanowisko to minimalne kompetencje jakie trzeba posiadać by dostać dane stanowisko i się na nim swobodnie utrzymywać.
np. 3 lata doświadczenia, znajomość java docker html
Więc jak sam dalej napisałeś nie ma wymagań (to ciekawe, raczej w ogłoszeniu to głównie wymagania są, obowiązki są rozmyte, Ty to mylisz o czym dalej)
Obowiązki to naprawianie bugów, implementacja nowych funkcjonalności, analiza systemu, doradzanie i tworzenie architektury.
Odpowiedzialności to oddawanie działającego kodu, reagowanie w przypadku ryzyka typu niedowiezienie na czas, czuwanie nad działaniem systemu, zapewnienie ciągłości działania aplikacji.
I teraz przechodzimy do miejsca, gdzie mylisz obowiązki z wymaganiami:
Od mida nikt nie będzie wymagał np. wprowadzania nowych technologi czy technik, ale senior to już powinien ogarniać (a tech lead aktywnie wspierać).
I dalej
Pomijam już temat zakresu wymagań na danym stanowisku, bo zazwyczaj są one opisane w stylu „spełnij zachcianki klienta”.
Przejdźmy więc do treści:
OP mówi wyłącznie o nazywaniu go seniorem. Nigdzie nie napisał o tym, że wczoraj fixował rozjeżdżającego się diva, a dzisiaj nagle przychodzi kierownik i każe mu analizować architekturę systemu.
Czyli wymagania nie są opisane. Załóżmy, że OP nie ma opisane iż jako mid ma mieć lata 3 lata doświadczenia i znać wzorce architektoniczne, ale ma opisane w obowiązkach iż odpowiada za naprawianie prostych rzeczy i regularny development, nie interesuje go architektura
Od mida nikt nie będzie wymagał np. wprowadzania nowych technologi czy technik, ale senior to już powinien ogarniać (a tech lead aktywnie wspierać).
Więc ma to wpisane co napisałem jako mid, dzisiaj jest seniorem i powinien ogarniać inne rzeczy, ale dalej nikt go o coś takiego nie zapytał.
Jeśli istnieje ta wyimaginowana tabelka to podpisaną ma ją na linii on -> pośrednik, a nie on -> klient.
Więc tak długo jak go klient nazywa "specjalistą wysokich napięć", ale nie wymaga od niego pracy przy wysokich napięciach bo nie posiada kompetencji (tutaj certyfikatu do wysokich napięć) tak długo doszukujesz się problemu gdzie go nie ma. Dalej, może być tak, że u kontraktora na stanowisku seniora oczekuje się
wprowadzania nowych technologi czy technik
a u klienta oczekuje się tego od tech leada
I co wtedy? Przeczytaj co napisałem. Czy pośrednik z klientem posiadają cerfytikacje kompetencji potwierdzoną papierkiem, że mid u kontraktora = mid u klienta?
Osobiście od juniora do seniora w obowiązkach zawsze miałem wpisane to samo jak gdzieś wspomniałeś ('programuj"), oczekiwania były także różne, pracownicy na różnych stanowiskach robili różne rzeczy. Fajnie jak macie tabelki w pracy, ja ich nie mam i zarówno dobry junior potrafi orientować się minimalnie w architekturze jak i słaby senior potrafi mieć problemy z podstawową konfiguracją ORM'a. Nazywanie kogoś juniorem/midem/seniorem jest pomocnicze i jak zapytałem, odpowiem - wolę być midem z 20k niż seniorem z 15k.
Edit. Jak rekrutujesz 7-8 lat, to dziwi mnie, że nie rekrutowałeś "seniora" bez znaczenia jakiego, byleby spełnić warunki np. dofinansowania UE czy czegoś w tym rodzaju.
1
Łapię, bo jak dyskutować o czymś co raz nazywasz wymaganiem, raz obowiązkiem, raz może odpowiedzialnością.
@froziu: bo to są trzy różne pojęcia, które odnoszą się do różnych momentów w czasie twojej pracy i rekrutacji.
Wymagania
To są rzeczy, które są zapisane np. w ogłoszeniu o pracę. To są też najczęściej zmieniające się elementy. Za pomocą samych wymagań ciężko zdefiniować stanowisko. I tu wracamy do problemu z latami doświadczenia. Stosunkowo młody rynek, jakim jest Polska, będzie stawiał inne wymagania niż dojrzały rynek amerykański. Dobrze ten problem obrazują rekrutacje na stanowiska związane z młodymi technologiami, gdzie wymagane lata doświadczenia w danej technologii przekraczają jej wiek.
Więc tak długo jak go klient nazywa "specjalistą wysokich napięć", ale nie wymaga od niego pracy przy wysokich napięciach bo nie posiada kompetencji (tutaj certyfikatu do wysokich napięć) tak długo doszukujesz się problemu gdzie go nie ma.
Tu podałeś przykład formalnych wymagań. I choć w IT nie spotyka się tego zbyt często, to czasami takie bardzo formalne wymagania pojawiają się w ogłoszeniach np. certyfikaty, czy ukończenie konkretnych studiów.
Obowiązki
Czyli to, co rzeczywiście powinieneś robić na danym stanowisku pracy. Klepanie kodu, zarządzanie k8s, tzw. technical writing, czy szeroko rozumiane projektowanie architektury, to wszystko może być twoim obowiązkiem. Oczywiście pewne zadania nie trafiają zazwyczaj do juniorów, ale też nie oznacza to, że na stanowisku juniorkim nie masz wpisanych obowiązków kojarzących się z seniorami. Przykładowo są zespoły, gdzie wszyscy członkowie, niezależnie od poziomu doświadczenia, uczestniczą w procesie rekrutacji. I mają takie samo prawo odrzucić kandydata jak starsi pracownicy.
Odpowiedzialności
Wszystkie dodatkowe rzeczy, które nie są ściśle ujęte w procesach, albo to ty definiujesz te procesy. I jak od juniora oczekujemy, że będzie tworzył kod zgodnie z przyjętymi standardami, tak odpowiedzialnością starszych stażem jest zadbać, by „młody” był odpowiednio przeszkolony i żeby rozumiał co i dlaczego robi. I właśnie tutaj leży główna osi podziału na poszczególne „poziomy”. Nie zarobki, nie lata doświadczenia, a właśnie odpowiedzialności i umiejętność ich przyjęcia.
I tu wchodzi typowa alfonsiarnia – cała na biało
Która jeszcze chce szybko zarobić duży hajs. Typowy pośrednik będzie patrzył jedynie na pierwszy punkt. Jest zapotrzebowanie, są formalne wymagania i jest budżet. Zatem pisze się ofertę, tak by zmieścić się w budżecie. Klient czasami chce zweryfikować ogłoszenie, a czasami przychodzi z własnym, które należy jedynie przenieść do szablonu.
Jak znajdzie się kogoś, kto pasuje na dane stanowisko i przejdzie przez rekrutację techniczną, to wysyła się go na rozmowę do klienta i to on decyduje czy daną osobę chce, czy nie. Przy czym klienci zazwyczaj weryfikują tylko umiejętności opisane w wymaganiach. Jak wszystko pyknie, to podpisuje się z delikwentem umowę.
W tym miejscu pojawiają się obowiązki, które w umowach z pośrednikami są zazwyczaj bardzo ogólnie zdefiniowane np.:
Zleceniobiorca zobowiązuje się stale świadczyć:
a. na rzecz Zleceniodawcy lub
b. w imieniu Zleceniodawcy - na rzecz klientów Zleceniodawcy (zwanych dalej łącznie „Klientami”) jako podwykonawca Zleceniodawcy, usługi informatyczne (zwane dalej “Usługami”), a w zamian za świadczenie Usług Zleceniodawca zobowiązuje się wypłacać Zleceniobiorcy wynagrodzenie, na warunkach i zasadach określonych w Umowie.
Czasami taki zapis dodatkowo odsyła do załącznika, gdzie wyszczególnia się „obowiązki”, a tak naprawdę zamienia się treść wymagań, na „będziesz programował z wykorzystaniem”.
Delikwent trafia do klienta, z którym nic go nie łączy, ale to klient ma dla naszego bohatera gotowy zakres odpowiedzialności. Oczywiście nie wszystkie od razu, ale po okresie wdrożenia zakłada, że podejmiesz się pewnych zadań.
Problem polega na tym, że w ogromnej większości przypadków, pośrednik obiecuje, że dostarczy np. seniora, czyli kogoś, kto będzie miał określone odpowiedzialności i bierze za to określoną stawkę, po czym szuka „mida”, bo może mu zapłacić mniej. Koniec końców jak mija „gwarancja”, to delikwenta przerzuca się do innego klienta, a na jego miejsce wysyła kolejnego „seniora”.
1
Dobrze, że powtórzyłeś sobie czym są odpowiedzialności, obowiązki i wymagania. Możemy więc zacząć dyskutować o tym samym :)
Do tego momentu jesteśmy w tym samym miejscu:
Typowy pośrednik będzie patrzył jedynie na pierwszy punkt. Jest zapotrzebowanie, są formalne wymagania i jest budżet.
Określiłeś, że są formalne wymagania. Dajmy na to - szukamy seniora. Czy Twoi klienci szukają seniorów? Czy szukają osoby mogące pochwalić się 10 letnim doświadczeniem w programowaniu i twierdzące, że potrafią biegle posługiwać się językiem Java, Dockerem i mają przynajmniej X lat doświadczenia przy pracy z tymi i tymi technologiami. Nazywają ich seniorami, bo ich jakoś klasyfikują, ale tak długo jak nie powiedzą Ci kim jest ten senior, to dajesz im losowego gościa z portfolio zwanym seniorem przez Ciebie? Czy jednak zwracasz uwagę na resztę moim zdaniem najważniejszych wymagań czyli doświadczenia i kompetencji a nie nazwy. Bo jeśli rekrutujesz ludzi, którzy potrafią odpowiedzieć klientowi "Tyś senior?" "Ta, ja senior" to okej, możliwe że to popularne w USA, może Hiszpanii, nie rekrutowałem się tam :)
Jak znajdzie się kogoś, kto pasuje na dane stanowisko i przejdzie przez rekrutację techniczną, to wysyła się go na rozmowę do klienta i to on decyduje czy daną osobę chce, czy nie.
Jesteśmy już na etapie dalszym. Klient chciał seniora z 10 letnim doświadczeniem i X lat w Java/Docker. Ty masz mida z 10 latami doświadczenia i X lat w Java/Docker. Dasz mu go na rozmowę, czy powiesz "mam gościa, ale na pytanie "Ty senior?" on odpowiada "Nie, ja mid", chcecie?"".
Okej, dalej, bez znaczenia jak go nazwałeś. Gość przychodzi i klient weryfikuje jego umiejętności. Dostał to co chciał, sprawdził po swojemu. Tutaj podpisuje się swoim imieniem i nazwiskiem "sprawdziliśmy gościa, nadaje się, bierzemy". I tutaj pojawiają się dwie kwestie. Z jednej strony masz potwierdzenie, że klient dostał kogo chciał z drugiej, być może powinien poinformować kandydata czym będzie zajmował się w firmie? Zakładam, że formalnie niczego nie podpisuje i tutaj mamy kość niezgody. Ja jestem nauczony by pytać klienta, a nawet klient nic nie wie i pytam developera po co ja im jestem potrzebny i co ja tam będę robił. Tutaj moglibyśmy skręcać w wątki "robie coś innego niż mi obiecywali" i "jak znaleźć dobrą pracę, o co pytać pracodawcę a najlepiej team leadera docelowego projektu"
Przy czym klienci zazwyczaj weryfikują tylko umiejętności opisane w wymaganiach.
Jak wyżej. Klient akceptuje gościa. Nie dostaje kota w worku. Sam sprawdził gościa, zwyczajowo dużo lepiej niż wstępna weryfikacja przez kontraktornię. Jedyne co pozostaje niedogadane, że będzie miał seniora (w głowie mida), który mu odpowie "ja architektury nie ruszam, bo mówili, że nie muszę, umiem, ale nie muszę".
Poza absurdalnością powyższego zdania wypowiedzianego przez mida (nie chce się rozwijać?) może mieć w głowie znaki zapytania pt. "A co jeśli nie umiem tego robić, co jeśli zawalę i mnie pociągną do odpowiedzialności".
I tutaj wracamy do punktu wyjścia
Jak wszystko pyknie, to podpisuje się z delikwentem umowę.
Jak wszystko jest sprawdzone i dwie strony sobie ufają to przechodzimy do umowy. Tak długo jak nie ma tabelki odpowiedzialności typu "mid nie rusza architektury" "mid odpowiada do 10k za zepsuty kod, senior do 100k" tak długo gadamy o jakiejś wyimaginowanej sytuacji nie mającej nigdzie miejsca. Sam wspominasz, że umowa brzmi "programuj klientowi" i tyle.
Problem polega na tym, że w ogromnej większości przypadków, pośrednik obiecuje, że dostarczy np. seniora, czyli kogoś, kto będzie miał określone odpowiedzialności i bierze za to określoną stawkę, po czym szuka „mida”, bo może mu zapłacić mniej. Koniec końców jak mija „gwarancja”, to delikwenta przerzuca się do innego klienta, a na jego miejsce wysyła kolejnego „seniora”.
Odpowiedziałem Ci wyżej. Klient weryfikuje tego seniora, dostał mida ale przeszedł weryfikacje na seniora. To kto tutaj zawalił proces, pośrednik, który znalazł kandydata i go wstępnie przetestował, czy klient który słabo weryfikuje zasoby przekazywane do swojej firmy? Dalej nie wiem co w tej sytuacji zmienia "mid" "senior", bo równie dobrze może dostać tego rzeczowego seniora odpowiadającego twierdząco na w/w śmieszne pytanie, dalej może mieć kompetencje i w zasadzie nigdy nie masz gwarancji, że jak to piszesz po okresie wdrożenia będzie zdolny coś sensownego tworzyć jeśli klient sam tego nie zweryfikuje.
Po coś ta weryfikacja powstała. Jeśli sprzedajesz zasoby jednocześnie oferując usługę weryfikacji technicznej kandydatów, to jeśli robisz to dobrze to firma dalej z Tobą współpracuję, a jeśli regularnie dajesz juniorów na stanowiska seniorów, to powiedz mi jak to się wszystko kręci?
rekrutacją techniczną od jakiś 7-8 lat
To powiedz mi teraz, nie czujesz się winny, że przepuszczasz do swojej firmy midów, gdy przełożony chciał seniorów? Bo jeśli robisz to dobrze i na 10 seniorów stwierdzasz, że 9 to midów, to zakładam że macie uzasadnione pretensje do kontraktorni i zmieniacie na lepsze? Czy sami psujecie rynek i przymykacie oko na takie sytuacje? OP nie napisał czy w docelowej firmie ktoś go weryfikował, ciężko więc wyrokować czy firma kupiła kota w worku, czy zweryfikowała mida kłamiącego w żywe oczy "ja senior" :P
3
Moim zdaniem to nie jest fair.
Umawiasz się na kasę X za stanowisko mida.
I teraz jeżeli klient wymaga żebyś robił robotę seniora to kontraktornia nie jest fair.
Ja bym negocjował, ale z mojego przykładu często nic nie uzyskasz.
Ja 10 lat temu miałem podobnie. 2 lata doświadczenia. Dostałem mida za kasę której byłem zadowolony. Po 3 miesiącach klient się wysypał więc poszedłem do dużego szwajcarskiego banku, wypadłem nieźle na rozmowach i dostaje ofertę na seniora. Pytam się ile więcej dostanę a kontraktornia że nie no nic i zdziwieni, że narzekam. Powiedziałem, że ok ale na mida. W sensie mają klientowi powiedzieć, że jestem midem. Oczywiście wyśmiano mnie, że nie ma szans. Senior albo wcale i dostałem 5% teraz i obietnice dużej podwyżki po 9m bo teraz właśnie zacząłem i się nic nie da zrobić.
Przyjąłem a po 9 miesiącach dostałem info że 3% podwyżki bo ciężkie czasy i więcej się nie da. Miesiąc później przy wypowiedzeniu okazało się ze i 15% się znajdzie a gdy powiedziałem nie to i 25% się znalazło.
Ofertę odrzuciłem mimo że szedłem do firmy za mniejsze pieniądze niż ta oferta +25% i nie żałuje ani trochę.
Wniosek, jeżeli firmy tak postępują, bo biznes to biznes to Ty/my też tak powinniśmy postępować.
3
@Kubuś Puchatek: Tak to się nazywa "hej załatwiliśmy wam Seniora za 120netto/h :)"
Praktyka dość popularna ostatnio przez inflację, wołam sobie np 160 co jest takie górne na mida, mówią mi, że mid stanowisko, a na interview technicznym z klientem okazuje się, że zestaw pytań na seniora, detale dosyc mocne z GC/Memory management, Kafka internals, kubernetes internals podchodzace pod devopsing ze szczegolami jak co dziala cały ELK stack przewalkowany. I akceptacja z propozycja jako senior java dev do tego klient opowiada, że jako senior muszę być proactive, brac inicjatywe, gadac z biznesem, opisywac i motywowac midów i juniorów/ pilnowac, zeby dowozili itp XD
ofc powiedzialem, ze jak senior to juz nie 160 tylko gadamy o 185 netto/h oczywiscie odmowa i płacz, że w trakcie interview jak jest na stole propozycja nie zmienia sie stawek bo to nie fair.
Moje rozwiązanie? albo szukamy do skutku mid role albo już jak jesteś mocnym midem co sobie rzuca 140netto/h+ to lepiej juz wolac 180 i isc na senior role przynajmniej nikt cie nie wydyma na stanowisko, a kasa się będzie zgadzać :)
1
Moim zdaniem na pierwszym callu z klientem należy się grzecznie przywitać, przedstawić i powiedzieć kilka słów o sobie.
Jak jesteśmy juniorem, to przedstawiamy się jako junior, jak midem, to jako mid :)
A jak widzimy, że w systemie klienta błędnie widniejemy jako senior, to należy tę pomyłkę jak najszybciej sprostować.
Można wysłać maila do klienta lub poruszyć ten temat na grupowym callu z klientem i grzecznie zapytać, do kogo się zwrócić w tej sprawie :D
1
tmk3 napisał(a):
Wtf, co z wami nie tak? Firma was wali w dupala, płaci wam za gorsze stanowisko niż was sprzedaje dalej, dodaje wam pod spodem nowe obowiązki, odpowiedzialności, a wy machacie ręką, że to normalne? Odpowiadacie całym majątkiem przy tej umowie, i myślicie, że was później kontraktoria uratuje i się przyzna, że powinniście być midami jak coś odwalicie? xD
W tej sytuacji chyba można próbować ratować się ustaleniem istnienia stosunku pracy, jeżeli są ku temu podstawy.
6
Mały update, mieliście rację zmieniłem robotę i dostałem prawie 2x tą kasę co miałem :]
0
To teraz sprawdz czy nie jests Staff, Principal albo CTO :P
0
W przypadku jak widniejesz w systemie jako "Software Enginieer/Developer" to de facto firma może Ci kazać robić wszystko, a Twój zakres obowiązków nie jest sprecyzowany i zazwyczaj kończy się to tym, że robisz jako one-man-army i pod stołem są coraz częściej dodawane Ci dodawane nowe obowiązki.
Spróbuj tak zrobić z biznes analitykiem czy scrum masterem :) Oni akurat bardzo dobrze znają swój zakres obowiązków.