Temat drażliwy, bo każdy wycenia dopisek "Senior" na różną liczbę lat doświadczenia aczkolwiek niezmienne pozostaje że aby na ten przedrostek zasłużyć należy pracować na etacie. Istnieją jednak języki gdzie nie ma ofert pracy niżej niż Senior - jak wtedy liczy się dokonania aplikanta? Co powinno znaleźć się w CV aby przejść pomyślnie rekrutację? Czy jedyną drogą dostania się jest wówczas zaczęcie w innej firmie jako powiedzmy Junior Java Dev, potem przejść na Senior Golang Dev i dopiero wtedy ma się jakieś szanse?
0
0
Z juniora na seniora nie skoczysz, ale tak, generalnie trzeba skoczyć z podobnego ekosystemu z podobnym poziomem doświadczenia którego ktoś szuka.
1
Są takie stanowiska fakt. Myślę, że to od szczęścia zależy niestety. Tak, że pracujesz w jednej firmie i to wewnątrz niej się przebranzawiasz np na devopsa. U nas jak był tworzony taki team to się pytali nas czy byśmy nie chcieli do niego przejść zwyczajnie. Jednej kolega sobie z tego skorzystał i tak nabijasz sobie expa.
1
Albo awansujesz/zmieniasz stanowisko wewnatrz firmy, albo po prostu aplikuejsz na cos nowego i wykazujesz sie na rozmowie.
0
Pracuję w branży IT już 6 lat i to jest dziki zachód z tymi tytułami, one nic nie mówią. Widziałem 2 letnich Midow co zarabiali mniej niż zasiedziani, wypaleni Seniorzy, gdzie stawki mieli mniejsze średnio o 10k. I co to niby ma znaczyć?
2
MarioBros33 napisał(a):
Pracuję w branży IT już 6 lat i to jest dziki zachód z tymi tytułami, one nic nie mówią. Widziałem 2 letnich Midow co zarabiali mniej niż zasiedziani, wypaleni Seniorzy, gdzie stawki mieli mniejsze średnio o 10k. I co to niby ma znaczyć?
No właśnie to jest dobre pytanie, też nie wiem :) Spodziewałem się, że w tym wątku ktoś odpowie, że aby nazwać się Seniorem powinno móc się pochwalić co najmniej jedną poważniejszą zasługą typu:
- brałem udział aktywnie w projekcie od początku developmentu do pomyślnego wdrożenia na produkcję
- wydobyłem projekt z zapaści
- napisałem i wdrożyłem samodzielnie aplikację na rynek
A tu c****, wszyscy piszą że masz się wystarać awansami, ew. liczyć na cudowne utworzenie zespołu w AKURAT takiej technologii do jakiej aspirujesz i wtedy łapać okazję. Może nie jestem jednak taki szalony widząc jak ta branża jest zjebana.
1
No jakbyś chciał zostać Seniorem w innym języku to na pewno nie znasz go biegle więc trudno się dziwić takiemu podejściu ale każda firma ma inne
1
Półtora roku temu, jak byłem na kontrakcie (BE Java), to devopsi rzucili, że mają +1 devopsowy etat, czy ktoś od nas nie chciałby przejść. Tak to najczęściej wygląda.
6
Trzeba trafić mieć szczeście i być w firmie gdy ogłaszają przejście z języka A na język B. Ewentualnie szukać firmy która ma A i B jednocześnie i próbować przeskoczyć wewnątrz firmy. Opcja trzecia to kuć język docelowy i liczyć, że dostanie się seniora za ogólny staż w IT, ale to się raczej zdarza jak firmę naprawde przyciśnie i nie ma wyboru
4
Jak chcesz więcej kasy to mów że jesteś seniorem, jak nie chcesz - to że midem / juniorem.
4
To pytanie należałoby kierować do osoby, która będzie czytała twoje CV, bo jak sam zauważyłeś zdania są różne. Moje podejście jest takie, że mam kompletnie wywalone na to jakich tytułów/zaimków używał kandydat w poprzedniej pracy. Przecież nie ma centralnej komisji przyznawania tytułów zawodowych, skoro każdy ten "poziom" inaczej rozumie, to nie znaczy on dokładnie nic. Z mojego punktu widzenia, nawet te mityczne "lata doświadczenia" znaczą tyle co nic, bo tempo poszerzania wiedzy u różnych ludzi, w różnych projektach bywa kompletnie różne.
Dzisiejszy, typowy system informatyczny, to jakiś tam niewielki (i coraz mniejszy) kawałek kodu, który rozwiązuje problem biznesowy (znajomość domeny), łącząc się z innymi kawałkami kodu wewnątrz i na zewnątrz systemu (REST, SOAP, GQL....), odbiera/wysyła jakieś wiadomości przez kolejki, ma warstwę persystencji (SQL, NoSQL, Blob Storage.....). Wszystko to jest uruchomione na jakimś server(less), zwykle wirtualizowanym rozwiązanu, korzysta z powalonych metod uwierzytelniania itd. Do tego sporą część pracy programisty zajmuje komunikacja z biznesem, wyciąganie i doprecyzowywanie wymagań (te zbędne soft skille). Natomiast wciąż pokutuje przekonanie, że ktoś, kto przez 10 lat pisał pętle i ify w Javie jest seniorem i ta wiedza jest podstawowa i nie ma żadnego przełożenia na pisanie pętli i ifów w GO, czy dowolnym innym języku turing complete. Nie wiedzieć czemu, doświadczenie w tych banalnych czynnościach uważane jest za coś wielce wartościowego.
Tutaj następuje zderzenie z rynkiem pracy na którym biznes szuka Java dev, więc vendor szuka Java dev, ma być "senior", więc wpisują wymaganie x lat doświadczenia, jak firma ma "proces talent acquisition" to jeszcze dostaniesz formularz do wpisania, ile lat tego doświadczenia masz i jak wybierzesz złą odpowiedź z listy, to nikt nawet nie przeczyta twojego CV.
Plusem twojej sytuacji jest, że szukasz roboty w niszowym języku, a to oznacza, że są spore szanse na to, że firma, która szuka programisty jest nieco bardziej ogarnięta (nie dlatego, że GO to jakieś super rozwiązanie dla firmy, ale firma była zdolna do przejścia na ten język.
Moim zdaniem (i z mojego doświadczenia), mając trochę wiedzy ogólnej o programowaniu zmiana języka programowania z zachowaniem kasy nie jest niemożliwa. Napisz CV, jak masz "jakieś" doświadczenie w technologii docelowej, to wpisz je w CV, nawet jeżeli nie jest "komercyjne" (to jest kolejna bzdura) i uderzaj.
0
Ja zostałem seniorem z poniżej 3 lat FTE expa jeszcze w trakcie studiów i niewiele to znaczy.
Uważam, że nie ma jak dobrze porównywać się rangami*. Przykładowo, niektóre kontraktownie mogą pompować kogoś latami na seniora/leada, po czym te same osoby przychodzą do mojej kontraktowni na mida. Albo w drugą stronę przykład: tutaj mogę być seniorem, ale do seniora w faangu brakuje mi w najlepszym możliwym przypadku co najmniej 2 lat jakbym się dobrze sprzedał.
Dla mnie senior to scope twojej pracy, a nie cyferki expa. Natomiast mocno uogólniając uważam też, że ktoś kto szybko rośnie może dobrze rokować, a zastój przez lata to czerwona flaga (lub mocna seria niefartów).
*Wyjątkiem od tego byłby FAANG, gdzie trzymają się podobnego standardu rang.
2
phantom_wizard napisał(a):
Co powinno znaleźć się w CV aby przejść pomyślnie rekrutację?
CV nie ma aż takiego znaczenia jak sposób zaprezentowania się na rozmowie i pokazania, że jesteś osobą kompetentną, która sobie poradzi i że nie ma żadnych żółtych flag (bo żółte będą traktowane jak czerwone - więc też trzeba uważać na to, co się mówi).
Chodzi o zyskanie zaufania, że podołasz zadaniom, do których firma szuka człowieka. Jeśli firma cię nie chce na seniora, to znaczy, że nie ma zaufania do ciebie, do tego, że faktycznie masz odpowiednie kompetencje. Więc trzeba umieć to zaufanie zbudować.
ten przedrostek zasłużyć należy pracować na etacie.
Nie chodzi po prostu o pracę na etacie, tylko w rekrutacji seniorskiej mogą paść pytania o to czy np. brałeś odpowiedzialność za zespół / dowodziłeś kimś, albo czy pracowałeś w jakiś konkretny sposób tj. w taki, w jaki pracują w tej konkretnie firmie (co jest śmieszne, bo zakłada się, że programiści nie są elastyczni i nie nauczą się innego sposobu pracy, ale co zrobić). Albo właśnie czy brałeś udział aktywnie w projekcie od początku developmentu do pomyślnego wdrożenia na produkcję.
1
Jak mówi księga ulicy:
Seniorem może być ten, kto zaczynał w piwnicy.
Lata doświadczenia nie mają znaczenia,
bo nie trudno znaleźć takiego lenia,
który dekade przesiedzał w korpo
i umie tylko kłapać mordą.
Ma jednak poziom regulara,
bo rozwijać się wcale nie stara
i zamiast poznawać technologie,
to siedzi tam, gdzie mu jest wygodnie.
Co do samego tytułu seniora,
to wcale nie jest rzecz taka spora.
Jak oczekują wyzszych kompetencji
to tę nazwę dodają dla atencji.
to takie hasło, że czujesz się pewnie
i swoją pracę robisz zwiewnie.
Nie prosisz nikogo specjalnie o pomoc
i bardzo rzadko czujesz niemoc.
1
piotrpo napisał(a):
Do tego sporą część pracy programisty zajmuje komunikacja z biznesem, wyciąganie i doprecyzowywanie wymagań
No tutaj z tą sporą częścią to już pojechałeś ... :-D Trochę mi to Januszem podchodzi. Jest tyle innych osób, które to powinny ogarnąć - nie macie analityków, czy jakichś chociaż Product Ownerów, Scrum Master od biedy też by mógł. Nawet w ich braku to Architekt powinien to ogarniać.
Do OP - o ile ilość technologii się ciągle rozrasta, o tyle ich znajomość robi się coraz bardziej pobieżna. Są natomiast firmy, które mają nadal zdroworozsądkowe podejście i nie wymagają, żeby jeden człowiek był od wszystkiego. Jak jest zgrany zespół, to się fajnie podzieli technologiami i każdy będzie robił taski, jakie mu bardziej pasują. Natomiast plus jest taki, że w zasadzie jak ktoś lubi się rozwijać, to na pewno się nudził nie będzie w tych czasach.
2
PaulGilbert napisał(a):
piotrpo napisał(a):
Do tego sporą część pracy programisty zajmuje komunikacja z biznesem, wyciąganie i doprecyzowywanie wymagań
No tutaj z tą sporą częścią to już pojechałeś ... :-D Trochę mi to Januszem podchodzi. Jest tyle innych osób, które to powinny ogarnąć - nie macie analityków, czy jakichś chociaż Product Ownerów, Scrum Master od biedy też by mógł. Nawet w ich braku to Architekt powinien to ogarniać.
Ile to razy widziałem jak programista ślepo klepał to co było podane w jirze, potem się okazywało że że wszystko idzie do kosza albo wymaga wielu poprawek i czas wszystkich jest zmarnowany.
Analitykom/Architektom też się błędy zdarzają i ktoś powinien robić im review dokumentacji.
To według mnie powinno wyglądać tak, analityk/architekt/team leader tworzy taska w jirze(a najlepiej to zrobić przed stworzeniem taska, podczas omawiania wymagań), programista go analizuje i jak są niejasności/pytania to odbija piłeczkę od razu po otrzymaniu taska a nie po miesiącu komunikujemy że tego nie da się zrobić.
Najgorsi są tacy co po tym miesiącu narzekają że są błędne wymagania.
Do tego w każdej firmie jakiej pracowałem to zawsze było spotkanie zespołowe, omawianie wymagań, analitycy i architekci dopytują programistę co jego opinie.
No i czy senior nie powinien iść właśnie bardziej w stronę tworzenia architektury, omawiania wymagań, sprawdzać czego brakuje w projekcie, samemu tworzyć taski i komunikować zespołowi że wdrażamy daną funkcjonalność?
Dzięki temu poszerzasz swoją wiedzę w pracy przy prawdziwych projektach i masz większą szansę rozwinąć się w coś więcej niż programista CRUDÓW i być spokojny o swoją pracę w branży.
1
PaulGilbert napisał(a):
piotrpo napisał(a):
Do tego sporą część pracy programisty zajmuje komunikacja z biznesem, wyciąganie i doprecyzowywanie wymagań
No tutaj z tą sporą częścią to już pojechałeś ... :-D Trochę mi to Januszem podchodzi. Jest tyle innych osób, które to powinny ogarnąć - nie macie analityków, czy jakichś chociaż Product Ownerów, Scrum Master od biedy też by mógł. Nawet w ich braku to Architekt powinien to ogarniać.
Do OP - o ile ilość technologii się ciągle rozrasta, o tyle ich znajomość robi się coraz bardziej pobieżna. Są natomiast firmy, które mają nadal zdroworozsądkowe podejście i nie wymagają, żeby jeden człowiek był od wszystkiego. Jak jest zgrany zespół, to się fajnie podzieli technologiami i każdy będzie robił taski, jakie mu bardziej pasują. Natomiast plus jest taki, że w zasadzie jak ktoś lubi się rozwijać, to na pewno się nudził nie będzie w tych czasach.
Tak jasne. Biznes kazał podzielić przez 0, to dzielimy przez 0, bo programista to jest zbyt drogi specjalista, żeby oczekiwać od niego czegoś innego niż pisanie return a/b.
Mamy od +10 lat hype na agile, które właściwie opiera się na częstej i efektywnej komunikacji z klientem, jak świętość traktuje się DDD, które sprowadza się znalezienia wspólnego języka pomiędzy biznesem i programistami, ale nie, w zespole musi być specjalista od rozmawiania, żeby reszta nie musiała.
2
piotrpo napisał(a):
Mamy od +10 lat hype na agile, które właściwie opiera się na częstej i efektywnej komunikacji z klientem, jak świętość traktuje się DDD, które sprowadza się znalezienia wspólnego języka pomiędzy biznesem i programistami, ale nie, w zespole musi być specjalista od rozmawiania, żeby reszta nie musiała.
Mylisz grywalizację (które polega na wymyślaniu nowych reguł i nazw żeby nie umrzeć z nudów w świecie post-scarcity) z rzeczywistością - bo w wspólny język między biznesem a programistami istnieje od samego początku i jest to język pieniądza.
1
Generalnie te tytuły mało co oznaczają, nawet pod kątem płacy. Są firmy, gdzie Senior zarabia 20k a są takie, gdzie to entry point dla mida. Pod kątem wiedzy działa to podobnie, sam z resztą tego doświadczyłem pracując z nieudolnymi Seniorami/architektami :P
4
Senior to ktos kto przedewszytkim popelnil sporo bledow w danej technologii :), exprety to ktos kto popelnij juz prawie wszystkie :D
Generalnie seniority to duze doswiadczenie, ktore zdobywa sie nie iloscia lat ale raczej skomplikowaniem i iloscia projektow. mozna siedziec w jednej korpo 10 lat i nie miec poziomu seniora, a mozna po 5 latach zasuwania miec poziom seniorski i uwazac ze ciagle sie jeszcze trzeba duzo uczyc.
2
wadus napisał(a):
Senior to ktos kto przedewszytkim popelnil sporo bledow w danej technologii :), exprety to ktos kto popelnij juz prawie wszystkie :D
Generalnie seniority to duze doswiadczenie, ktore zdobywa sie nie iloscia lat ale raczej skomplikowaniem i iloscia projektow. mozna siedziec w jednej korpo 10 lat i nie miec poziomu seniora, a mozna po 5 latach zasuwania miec poziom seniorski i uwazac ze ciagle sie jeszcze trzeba duzo uczyc.
Czyli spokojnie można powiedzieć że u nas w branży liczy się tylko rozpoznanie bojem?
2
loza_prowizoryczna napisał(a):
Czyli spokojnie można powiedzieć że u nas w branży liczy się tylko rozpoznanie bojem?
Może nie tylko, bo jakaś tam wiedza się przydaje, ale jako branża nie mamy wypracowanych sposobów działania zapewniających w miarę wysokie prawdopodobieństwo sukcesu i prawie wszystko opiera się na indywidualnych doświadczeniach pojedynczych osób.
0
No to tak konsekwentnie idąc to kluczowym zasobem stosowanym przy rozpoznaniu bojem jest głównie masa (ludzka). A tutaj ludzie się naśmiewają że Indie nie mają szans zdominować IT. Nie wiem czy to jakiś mechanizm obronny czy brak umiejętności wnioskowania.
1
wadus napisał(a):
Generalnie seniority to duze doswiadczenie, ktore zdobywa sie nie iloscia lat ale raczej skomplikowaniem i iloscia projektow. mozna siedziec w jednej korpo 10 lat i nie miec poziomu seniora, a mozna po 5 latach zasuwania miec poziom seniorski i uwazac ze ciagle sie jeszcze trzeba duzo uczyc.
Zamiast "skomplikowaniem" napisałbym "złożonością". Projekty są często skomplikowane nie dlatego, że są jakieś specjalnie złożone pod kątem tego, co mają robić, ale dlatego, że jest tam zły kod i słaba architektura (często jest to pomieszanie przeinżynierowania z big ball of mud i elementami kodu spaghetti).
Myślę, że ktoś, kto był tylko w takich sztucznie skomplikowanych projektach, prędzej będzie midem, który może się odnaleźć w skomplikowanym projekcie i zaklepać szybko i sprawnie kolejną warstwę spaghetti. Komplikować każdy umie, a senior powinien umieć upraszczać.