"FENOMEN" pracy w IT 🤔

PanamaJoe napisał(a):

Tylko ile tak naprawdę poświęca się juniorom REALNIE? Bo ja się założę, że jest to może raz czy dwa dziennie po 5 minut jak się rozłoży na to, że junior pyta różnych osób to może z 10 minut w tygodniu taki junior wam zabierze. I co znaczy, że nie będzie przynosił zysku.

A robienie review? Jak nie chcesz mieć syfu w kodzie to każdy kod napisany przez juniora musi zostać zaakceptowany przez seniora, najlepiej dwóch. Jeśli samodzielnie masz 4 juniorów pod sobą do bywają sprinty że sam o programowaniu możesz zapomnieć :(

mstl napisał(a):

Dodam jeszcze co ciekawsze spostrzeżenia z dyskusji pod ogłoszeniami:

dwa lata doświadczenia to już mid
na kasie w biedronce płacą więcej
oferowanie zlecenia zamiast etatu - janusze (gdy oferta ewidentnie kierowana dla studentów)

Często skutkuje to tym, że pracodawcy mniej chętnie wystawiają takie oferty i nie raz widzę "strong mid - wymagane 2+ lata doświadczenia".

Tak, to na pewno mocno wpływana ilość ofert pracy dla juniorów.
Widełki doświadczenia w latach IMHO powinny być mniej więcej:

• 0-5 junior
• 5-10 mid
• 10+ senior

A przez to że nikt nie chce być juniorem a wszyscy seniorem to faktycznie są

• 0-1 junior
• 2-5 mid
• 5-10 senior
• 10+ principal czy inny expert

W rezultacie słowo junior określa bardzo krótki okres w karierze z prawie zerowym doświadczeniem

* wszystkie liczby oczywiście podane w przybliżeniu i zależą od indywidualnych prezyspozycji programisty :P

@victordeleco2:

Wychodzi na to, ze pierwsza firma wyszkoliła pracownika tej drugiej konkurencyjnej za darmo.

czemu konkurencyjnej?

Różnica w skillach pomiędzy kimś z expem 0 a 1-2 lata jest większa niż pomiędzy kimś z 1-2 a 4-8lat.

nie zgadzam się z tym, uważam że 4-8 nie tylko ilościowo, a również pod względem złożoności potrzebuje tych skillsów/wiedzy więcej.

uważam że rzeczy 0-2 to są głównie narzędzia, mechanizmy i poznawanie rzeczy które są blisko "oczywistych prawd", gdzie w tym drugim przedziale już częściej się rozważa jakieś kompromisy

Doświadczenie można zdobyć na freelancerskich zleceniach, jak ktoś chce to znajdzie pracę, a jak ktoś woli płakać, że tylko z doświadczeniem przyjmują to trudno.

victordeleco2 napisał(a):

Nie opłaca się firmom. Moje 3 subiektywne czynniki.

1. Biorą kogoś bez expa np. za 4-6k. Pierwsze miesiące to tak naprawdę nauka i taki junior więcej spowalnia (ciągnące się PR bo na review wychodzi dużo rzeczy itd.) niż pomaga. Po 1,5 roku już wdrożony całkiem sprawnie klepie proste taski z clean code. Dostaje podwyżkę 1-3k. Na linkedin piszą do niego rekruterzy ze stawkami dwa razy większymi więc naturalne, że ucieka do drugiej firmy. Wychodzi na to, ze pierwsza firma wyszkoliła pracownika tej drugiej konkurencyjnej za darmo.

Firma X ukradnie pracownika firmie Y, więc firma Y ukradnie pracownika firmie Z i tak się ta ch*jnia kręci odkąd wynaleźli koło.
Jeżeli firma ma ciekawe projekty, jasną ścieżkę rozwoju i kariery, jakieś fajne benefity, oferując odpowiednie wynagrodzenie to mniej osób będzie dawało się ukraść.

KamilAdam napisał(a):

PanamaJoe napisał(a):

Tylko ile tak naprawdę poświęca się juniorom REALNIE? Bo ja się założę, że jest to może raz czy dwa dziennie po 5 minut jak się rozłoży na to, że junior pyta różnych osób to może z 10 minut w tygodniu taki junior wam zabierze. I co znaczy, że nie będzie przynosił zysku.

A robienie review? Jak nie chcesz mieć syfu w kodzie to każdy kod napisany przez juniora musi zostać zaakceptowany przez seniora, najlepiej dwóch. Jeśli samodzielnie masz 4 juniorów pod sobą do bywają sprinty że sam o programowaniu możesz zapomnieć :(

Takiego syfu jaki widziałem stworzonego przez mid-seniorów to najkreatywniejszy junior by nie wymyślił. Głównie opierał się na pracy z "niedorobionymi" obiektami*. To znaczy mającymi jakieś właściwości aczkolwiek ich zestaw się różni od tego jakie metody je stworzyły :D Do tego ładnie owrapowane tu i ówdzie, żeby nie siało błędami, więc nie stwierdzisz czy tam na końcu np. jakiejś wartości nie ma w bazie czy nie została wyciągnieta. "A nie, nie to tak jak chcesz, żeby to miało toto, to tam napisałem pół roku temu taka metodę w innym module jest - no tamtę se weź, bo zapomniałem ci powiedzieć, no tamtą sobie inicjalizuj". I troche zaczynasz rozumieć że @powstrzykiwanie @wszystkiego @do @wszystkiego daje Ci niezbędną elastyczność w tej architekturze :D

*) fachowo nazywa się ten wzorzec projektowy :D "partially initialized entities"

Bo teraz do zawodu nie wchodzi, się przez oferty juniorskie. Jak ktoś nie ma doświadczenia komercyjnego ani open source, to wejścia do zawodu szuka przez staże, które są zazwyczaj płatne. Staże też nie muszą się kończyć na jednym, czasami coś się złapie dalej dopiero za kolejnym razem. Jak ktoś szuka wejścia poprzez normalną ofertę pracy to robi to źle.

Dlatego, że między początkującym a doświadczonym programistą jest coś w rodzaju "wielkiego filtra" (koncepcja znana z kosmologii). Nie wystarczy nauczyć się języka programowania, trzeba go jeszcze umiejętnie używać, a to jest o wiele wiele trudniejsze. Wiele osób między tymi etapami odpada / zostaje odfiltrowanych.

Firmy nie chcą juniorów, których będą musiały uczyć i ryzykować, że ostatecznie okaże się, że dana osoba nie nadaje się na stanowisko programisty, albo osoba ta im ucieknie, jeżeli okaże się dobra, a firma dla tej osoby niewystarczająca.

O wiele wygodniej wziąć kogoś kto już udowodnił co potrafi i negocjować z taką osobą.

Trzeba też pamiętać, że juniora ktoś musi uczyć, ktoś musi nad nim stać i pilnować, to są dodatkowe koszty.

@TomRZ: zgodzę się z tym co napisałeś, jednak to prowadzi do tzw. wyczerpania zasobów. Pracy jest coraz więcej i jeżeli się nie będzie produkować nowych juniorów, to na rynku zabraknie doświadczonych osób, lub ich stawki będą na tyle wysokie, że niektóre firmy nie będą mogły sobie pozwolić na ich ściągnięcie.

@1a2b3c4d5e: Kontraktownie nie mają problemu z klientami tylko z programistami. A więc konkurują o programistów żeby ich przepchnąć do klienta. Te lata 4-8 podałem w przybliżeniu - chciałem zaznaczyć, że programista przez pierwsze 12 miesięcy uczy się bardzo dużo i po tym roku jest kompletnie "innym" pracownikiem.

P.S. Jak odpowiedziałem do jednej z kontraktowni to KAM chciała mnie umówić na rozmowy z góry do 5 klientów - codziennie, a jakby się dało to po dwie rozmowy dziennie. I to tylko jedna KAM, która ma X klientów w jednej kontraktowni. Następnie napisała do mnie z tej samej kontraktowni kolejna KAM, że ma 5-10 klientów i mogę tam wszędzie pójść na rozmowy, jednak mają politykę, że jak zacząłem proces u jednej to u te drugiej już nie mogę do czasu zakończenia.

Piszę tylko ze swojego doświadczenia:
Są stanowiska potencjalnie do obsadzenia przez juniorów. Ostatnio szukaliśmy paru osób do projektu i wiadomo, najlepiej mieć seniorów, ale pojawiło się też trochę midów. Ostatecznie na jedną z kilku pozycji przyjęliśmy juniora, co okazało się dobrą decyzją.

Natomiast nie wystawię ogłoszenia na juniora, bo mam ciekawsze rzeczy do robienia, niż przez tydzień robić selekcję CV. W ogłoszeniach było po prostu podane, że szukamy mid-senior, ale bez oczekiwanego poziomu wykształcenia czy liczby dupogodzin.

Powtórzę po kolegach piszących wcześniej:
Dlaczego firma woli zatrudnić seniora, niż wannabe juniora / dlaczego nie ma ogłoszeń.

• Bo 15 szczypiorków nie napisze systemu, który napisze 2-3 ludzi z doświadczeniem.
• Bo patrzenie na bootcampie/YT jak ktoś pisze program, to nie to samo co napisanie go samodzielnie.
• Bo zatrudniając juniora, trzeba się liczyć z tym, że za chwilę zmieni pracę (kasa to tylko jeden z powodów), czyli posiedzi rok w firmie, coś użytecznego będzie robił przez pół roku, a zabierze czas komuś z doświadczeniem.
• Bo nie mają wystarczającej liczby seniorów, żeby ogarnąć "młodych".
• Bo jak jesteś jednym z 500 aplikujących na jakieś stanowisko, to masz statystycznie 0.2% szans je dostać
• Bo w razie potrzeby zatrudnienia juniora wystarczy powiedzieć do już zatrudnionych "zapytajcie kolegów w szkole".

Dlaczego firmy zatrudniają juniorów:

• Bo nie mogą znaleźć seniorów/midów.
• Bo szukają mida, ale kandydaci na rozmowach pokazują taki poziom, że już lepiej zatrudnić obiecującego juniora, bo jeszcze nie udowodnił, że uczy się wolno.
• Bo nie mają kasy na seniora, albo liczy się wyłącznie obsadzenie jakiegoś stanowiska - im szybciej i im taniej, tym lepiej.
• Bo mają tyle prostej roboty w projekcie, że szkoda dawać ją komuś z doświadczeniem. Albo firma straci kasę, albo pracownika.

Uprzedzając pytania:

• To jak IT ma się rozwijać, jak nie można wejść do branży.
• Ale jak nie ma juniorów, to nie będzie seniorów.
• Co ma zrobić ktoś, kto się uczył/zapłacił, żeby go nauczono.

Nie wiem, nie mój problem. Zatrudniając kogoś patrzę na to, jak przydatny będzie dla projektu, nie na to jak świat będzie wyglądać za 5 lat. Do IT ciągnie teraz tłum ludzi, dostaje się jakiś tam %, ostra selekcja najczęściej skutkuje wybieraniem najlepszych, więc pewnie nie będzie źle. Żeby nie być tym (do końca) złym, ostatnio zacząłem przepychać w firmie program ~stażowy, nie wiem jeszcze czy przejdzie.

Podstawowe pytanie brzmi: "czy ktoś zna ogarniętego juniora z realistycznymi oczekiwaniami płacowymi pozostającego bez pracy?".

Takich osób na rynku po prostu nie ma. Wystarczy zacząć odpowiadać na ogłoszenia na mida, napisać sensowny listy motywacyjny w tonie "brakuje mi doświadczenia komercyjnego, ale mam kilka ciekawy projektów prywatnych i chętnie będę się uczył" i na bank się praca znajdzie.

Niestety pracuję z juniorami pewnej znanej narodowości w teamie + z dwoma seniorami. Niestety praca z juniorami to dramat. Trzeba im tłumaczyć podstawy a czasami zadają tak idiotyczne pytania, że ludzie nie z IT logicznie myślący lepiej i szybciej ogarnęliby temat.
Dla przykładu podam kilka akcji:

1. Junior BI Front end developer nie wie jakiego datasource uzywa i do jakiej bazy jest aktualnie podlaczony.
2. Junior Data Engineer nr1 nie rozumie po pol roku pracy jak dziala left join w SQLu.
3. Junior Data Engineer nr2 po "szkole z Pythona" nie rozumie roznicy miedzy funkcja a modułem.

Normalna firma (nie ta, dla ktorej aktualnie swiadcze usług) woli zatrudnic seniora za konkretna kase niz kilku juniorow bo dowiezienie czegokolwiek z takimi juniorami jakich ostatnio napotykam graniczy z cudem. Nie mozna im zlecic nawet najprostszej pracy bo oni po prostu nie rozumieja co robia i sprawiaja wrazenie urwanych z choinki.

Na szczescie w nieszczesciu w 95% czasu robie rzeczy niezalezne od nich i mam na to wyrąbane. Natomiast jak pomysle o tych 5% czasu gdzie musze z nimi wchodzic w jakiekolwiek interakcje lub nie daj Boże "work closely with him" to mysle powaznie o zmianie kontrahenta...

a jeżeli mowa o kontraktowni to gdzie właściwie się uczy tego juniora? przecież nie kontraktowania tylko klient ?

Generalnie cały temat to jest jeden wielki roast juniorów. A ja się pytam, kto kieruje planningiem w ten sposób, że juniorzy muszą zadawać pytania podczas sprintu?

W jaki sposób ty piszesz taski że nikt nigdy nie ma pytań? Oczekujesz że dokładnie napiszę którą linijkę w którym pliku ktoś ma zmienić? Zawsze zakłada się ze ludzie w zespole w miarę wiedzą co robią a jak nie wiedzą to będą pytać, a likwiduje się tylko większe źródła niepewności. W przeciwnym wypadku napisanie taska zajmie dłużej niż jego zrobienie.

Jakie taski? Mi chodzi o planning pod względem wyceniania zadań. Jak czegoś nie wiem jak zrobić, daje wysoką notę i mam seniorów od tego żeby popatrzyli na mnie z politowaniem i wytłumaczyli, że zadanie jest łatwiejsze bo polega na tym i tamtym. Po tym następuje drugie głosowanie i następnie (jeśli coś nie jest jasne) trzecie. Nigdy żaden Junior od nas (o tyle co wiem) nie musiał nikomu zadawać pytań po planning.

No ok ale to są pytania na wysokim poziomie. Większość czasu przy (zwłaszcza świeżych) juniorach spędza się tłumacząc im coś na niższym poziomie - jak porządnie napisać testy, dlaczego jakieś nazwy nie są OK w danym kontekście, jak odspaghettizować ich kod, jak poprawnie uzyć jakiejś libki, dlaczego warto/nie warto pisać do czegoś osobnej abstrakcji, dlaczego wczytanie całej bazy do pamięci i przefiltrowanie i przesortowanie jej to zły pomysł, jak coś przedebugować, kiedy warto wpiąć sobie jakieś nowe metryki, jak dodać uprawnienia w AWSie i inne tego typu pierdoły. Jakoś nie chce mi się wierzyć że takie pytania nie padają, mogą nie być zaczęte przez was tylko np pojawić się podczas review, ale tego rodzaju robota zajmuje najwięcej czasu i wpada w bardzo nieoczekiwanych chwilach. Przy refinemencie mówi się gdzie będą zmiany i czego można się spodziewać, ale to jest co najwyżej na poziomie modułów albo komponentów, nie niżej.