Jak powinien wyglądać dobry staż?

1

Cześć,
Moja firma planuje zorganizować program stażowy dla kilu osób na kilka miesięcy. Wiadomo, że wygląda to czasami nieciekawie, w związku z tym pytanie do potencjalnych zainteresowanych jakie warunki musiałby spełniać taki program, żebyście chcieli w nim wziąć udział i uznali że było warto?

3

jeżeli stażysta po odbytym stażu wie jak zrobić kawę lub herbatę dla starszych kolegów z zespołu to taki staż jest 10/10.

3

Z tego co ludzie piszą nieustannie na forum, to obecnie jest strasznie ciężko się wbić na rynek, a dostanie się na Juniora to takie samo szczęście, jak przynajmniej piątka w totolotka. Dlatego chyba cokolwiek dasz w warunkach tego stażu, chętni i tak się pojawią, żeby zyskać jakąkolwiek namiastkę doświadczenia komercyjnego i mieć chociaż kilka tygodni/miesięcy do wpisania w CV. Nawet, jakbyś zrobił to w wersji odpłatnej (nie Ty płacisz stażystom, ale oni Tobie za możliwość uczestnictwa) to i tak chętnych by było mega dużo.

Tylko zastanów się, kogo szukasz i na jaki poziom się nastawiasz. I jaki jest cel tego stażu - czy chodzi o "przemielenie" jakiejś grupki ludzików, czy szukasz sobie pracowników na dłuższą współpracę?

1
cerrato napisał(a):

Z tego co ludzie piszą nieustannie na forum, to obecnie jest strasznie ciężko się wbić na rynek, a dostanie się na Juniora to takie samo szczęście, jak przynajmniej piątka w totolotka.

A żebyś wiedział. Się nagle tyle osób przebranżawia i najlepiej na starcie być kompletnym pracownikiem.

6

Tak z moich lepszych i gorszych doświadczeń ze stażami, z obu stron:

  • przeklikanie się przez aplikację i "obejrzyj sobie drzewko katalogów z kodem" to nie jest wdrożenie w projekt.
  • proste bugfixy wcale nie są proste, jeśli zupełnie nie znasz projektu, a co gorsza jesteś świeżakiem. Danie stażyście taska, którego junior znający jako-tako projekt rozpykałby w 10 minut nie znaczy, że można zostawić nowo przyjętego stażystę samemu sobie i liczyć na to, że rozpyka to w 20 minut.
  • code review powinno być rzeczowe, koledze mogę powiedzieć "a coś ty tu od***ł, WTF" i po chwili pewnie sam strzeli facepalma i poprawi, ale stażysta będzie się na mnie patrzył jak na zjawę i zastanawiał, czy wolno mu spytać, co zrobił źle i jak to poprawić.
  • jak jednak uda się zrealizować "wdrożenie w projekt" z prawdziwego zdarzenia, to łatanie drobnych bugów i inne takie bzdety nudzą się baaaardzo szybko.
  • za pierwszym i drugim razem lepiej na wszelki wypadek powiedzieć, co i jak trzeba zrobić jeśli chodzi o np. workflow i skąd się to wzięło. Np. dlaczego ma używać rebase zamiast merge, albo odwrotnie, albo skąd się wziął zwyczaj robienia XYZ w waszym projekcie.
  • stażyście, który startował do X może nie być do śmiechu, jak pierwszego dnia dowie się, że trafił do Y. Jest spora szansa, że X jest jego (prawie) całym światem, a przejście do Y brzmi jak wyprawa przez Atlantyk kajakiem, a nie lot biznesklasą ;)
5

Dobry staż to taki który Cię przeora tak, że po tygodniu bedziesz chciał odejść z tej branży. Kiedy każdego dnia bedziesz po przyjsciu do biura zadawał sobie podstawowe pytanie "Chyba kogoś pojebao". Codziennie będziesz miał uczucie że się topisz ale nie utoniesz tylko dlatego że w ostatniej chwili ktoś wyciągnię Ci głowę lekko ponad tafle tylko po to byś na nowo zaczął taniec o życie. Dobry staż to taki kiedy pracujesz na prawdziwym produkcie komercyjnym z cały tym cyrkiem z klientem zarządzaniem, nerwówką i kolejnymi wpadkami jedna za drugą. Im więcej nieprzyjemnych sytuacji dośwadczysz tym lepiej, szybciej bedziesz ogarniał czego nie robić i kiedy g**no zbliża się w Twoją stronę. Dobry staż to taki kiedy stwierdzisz że przez 3 miesiące bardziej zrozumiałeś czym jest wytwarzanie oprogramowania niż przez ostatnie 2 lata klepania tutoriali i czytania książek.

5

Większość firm nie ogarnia jak seniora do projektu wprowadzić, a co dopiero kogoś, kto nigdy nie wchodził w żaden projekt :D Tak więc szacun za inicjatywę ;)

1

Szukamy ludzi ogarniętych. Wiadomo, że jest to adresowane do pre-juniorów i cudów nie ma się co spodziewać, ale zdecydowanie nie chcemy nikomu tłumaczyć czym jest pętla. Projektów i technologii mamy od groma zaczynając od C, Matlabów, na chmurowych Big Data kończąc. Rozwijane projekty są na różnym poziomie, ale akurat tych słynnych CRUD'ów chyba się u nas nie robi. Specjalizacje jakie się pokazują na horyzoncie to programiści (w tym test automation), DevOps (też spory wachlarz rozwiązań). Celem zdecydowanie nie jest nauka robienia kawy i obsługa ksero. Nie oczekujemy jakiegoś wielkiego wkładu w rozwijane produkty, raczej o zainwestowanie czasu w potencjalnie przyszłych pracowników, zbudowanie sobie wizerunku ciekawego pracodawcy dla ludzi umiejących w komputery.

6

Z perspektywy stażysty doradzałbym przede wszystkim właściwy dobór opiekunów stażu. Pominę kwestie merytoryczne, bo to raczej oczywiste, ale chodzi mi raczej o jakąkolwiek cierpliwość czy zwykłą życzliwość. Myślę, że taki opiekun chociaż w jakimkolwiek stopniu musi "chcieć" brać w tym wszystkim udział, wiedzieć, że będzie musiał poświęcić trochę czasu stażyście i wykazać chociaż minimum zaangażowania.

Sam byłem na stażu w firmie, gdzie miało być "super" - ten Software House kreuje się na bardzo przyjazny pracownikom, jedną wielką rodzinę - a przez półtora miesiąca w projekcie, do którego mnie przydzielono po pierwszym miesiącu wdrożenia, mój "opiekun" tylko na mnie warczał, a gdy zadawałem pytanie był tak niezadowolony z faktu, że będzie musiał odpowiedzieć, że odechciewało mi się pytać. Było też kilka sytuacji, w których ewidentnie robił mi "pod górę" - np. pokazałem mu jakieś miejsce w kodzie i mowie, że to chyba trzeba by poprawić, on popatrzył, pomyślał i mówi, że mam to teraz tak zostawić i dorobić po prostu swojego taska w okół tego. Zrobiłem tak, po 3 godzinach skończyłem, wystawiam PR'a, a tam miliard konfliktów. Sprawdzam co się zmieniło, a tam w ciągu tych 3 godzin on poprawił kod, który mu pokazywałem. Zmian tyle, że swoje rozwiązanie muszę praktycznie "od nowa" ogarnąć. Cały czas siedział obok mnie, oczywiście nie powiedział nawet słowa o zmianach, które robi :-) Raz nawet uratowałem mu dupę przed prezentacją dla Klienta - naprawiłem komponent z którym walczył od rana, a na godzinę przed prezentacją nie miał gotowego działającego - to i tak nie był zadowolony, bo "to będzie trzeba jeszcze trochę przepisać, ale wrzuć". Miesiąc później mój komponent oczywiście dalej działał na produkcji. Jestem pewien, że na koniec "opiekun" wystawił mi negatywną ocenę, bo po tych 3 miesiącach nie zaproponowali mi pracy i to byłą chyba najfajniejsza rzecz jaka się zdarzyła na tym stażu. Gdyby zaproponowali mi pracę raczej na pewno bym ją przyjął, bo zależało mi na doświadczeniu jako dev :-)

Druga sprawa, wydawałoby się oczywista, to zapewnienie odpowiedniego sprzętu stażystom. Ja na mój staż dostałem się wygrywając hackaton, który zorganizowali. Uczestników było kilkunastu, mieliśmy przyjść z własnymi kompami, co przy takiej liczbie uczestników jest rozsądne. Na koniec dnia staż zaproponowali 2 osobom, warunki: 1500 netto UZ, zaczynamy za tydzień na własnych kompach "na razie", a oni się "zorganizują". Jak to wyglądało w praktyce? Kodowałem 3 miesiące na swoim 13" Macbooku - przez 2 miesiące bez żadnego monitora zewnętrznego (organizowały się), a przez miesiąc praktycznie bez miejsca przy biurku (siedziałem zwykle na pufie, z laptopem na kolanach). Gdy dołączyłem do projektu, który właśnie wystartował, miałem już biurko, ale nie miałem fotela (też się organizował), więc codziennie rano jak przychodziłem sprawdzałem na slacku kogo ma nie być i brałem jego fotel, a jak byli wszyscy to brałem krzesło z salki konferencyjnej :-)

Teraz, z perspektywy czasu (prawie 2 lata), jak o tym wszystkim myślę to wydaje mi się absurdalne, że zgadzałem się na takie warunki :-) Ale musiałem najpierw trafić do fajnej firmy i trochę w niej popracować, żeby zobaczyć jak powinno to wszystko wyglądać. Co lepsze, to ten staż to wcale nie była moja pierwsza praca po studiach (mam kilka lat doświadczenia przy administracji i wdrożeniach systemów ERP), ale poprzednia firma też nie była dobrym porównaniem :-)

2

Ja byłam na bardzo fajnym stażu. Z doświadczeń moich i zasłyszanych:

  1. Mój opiekun na stażu to był anioł cierpliwości i spokoju, do tego starał się odpowiedzieć mi na każde pytanie, a jeśli nie on, to kto inny z zespołu. W sumie wszyscy w zespole się bardziej lub mniej angażowali w "trenowanie" stażysty, w pozytywnym tego słowa znaczeniu :D. Plus świadomość zespołu i PO/leada/szefostwa/kogokolwiek, że opiekun stażysty szczególnie przez pierwsze tygodnie będzie faktycznie musiał w jakieś części zajmować się tym stażystą - będzie miał trochę mniejsze przebiegi ;).
  2. Rzeczowe i dość dokładne CR świeżaka. Z tego i oglądania dobrego kodu wyciąga się najwięcej.
  3. Tego na moim stażu mi zabrakło. Wprowadzenie na początku w workflow i jakieś wewnętrzne ustalenia, typu jakieś specyficzne formatowanie, nazywanie czy nazwy branchy, a czasem nawet przydatne skróty ;).
  4. Nie kazać stażystom tworzyć gunwoprojektu, który zaraz po stażu zostanie wyrzucony do kosza.
  5. Im szybciej przechodzi się do normalnej pracy, kontaktu z klientem etc (oczywiście w zakresie dostosowanym do skilla i znajomości projektu), tym lepiej.

I jedna fajna, zasłyszana rzecz: przed rozpoczęciem stażu firma dla przyjętych świeżaków kupiła kilka fajnych szkoleń z udemy czy innej platformy nt. technologii, z którymi mogli się zetknąć i clean code. Według mnie bardzo fajny pomysł, relatywnie niewielkim kosztem uzupełnienie/poszerzenie wiedzy przyjętych ;-).

3

Po pierwsze, bardzo fajna inicjatywa, a za to, że pytasz potencjalnych stażystów jak do sprawy podejść to już w ogóle szacun :D

Kilka spostrzeżeń, na przykładzie stażu, z którego byłam całkiem zadowolona:

  1. Tak jak poprzednicy podkreślam, że warto zadbać o fajnego opiekuna stażu lub przynajmniej o wrzucenie stażysty do zespołu z cierpliwymi ludźmi. Mojemu stażowi bliżej było do stanowiska juniorskiego, więc nie miałam określonego opiekuna, ale prawie nigdy nie było problemu z tym, żeby ktoś poświęcił czas na pomaganie mi.
  2. Zapoznanie z firmą, panującymi zasadami, oprowadzenie po budynku - warto poświęcić na to parę chwil, żeby stażyście łatwiej było się odnaleźć.
  3. Lepiej w miarę możliwości jak najszybciej wdrożyć stażystę w rzeczywisty projekt, zamiast kazać mu pisać projekt do szuflady. Pierwszy ticket, który ostatecznie trafił do klienta dostałam drugiego dnia stażu - wtedy byłam trochę przerażona, ale z perspektywy czasu uważam, że takie szybkie wdrożenie dużo dobrego mi dało.
  4. Sprawne ogarnięcie dostępów - być może w mniejszych firmach sprawa jest prostsza, w korpo było z tym trochę problemów. Samo pierwsze zalogowanie do Windows wymagało zadzwonienia do supportu w Indiach. Nie idźcie tą drogą :D
  5. Porządne Code Review, rozmowy ze stażystą na temat wykorzystanych przez niego rozwiązań, rzeczowo i z naciskiem na rozwój i przekazanie nowej wiedzy, ale bez nadmiernego "znęcania się" i zniechęcania.

Ogólnie im bardziej dacie szansę stażyście na rozwój i wykazanie się, tym chętniej z Wami zostanie na dłużej, a przy okazji macie szansę, że zrobi coś pożytecznego dla projektu.

3

Dziękuję wszystkim za odzew, był bardzo pomocny i udało się odrzucić kilka jak się okazało niezbyt trafionych pomysłów. Włączyliśmy do planu trochę szkoleń, przydzielanie każdemu komunikatywnego opiekuna, włączenie ich w zespoły pracujące nad realnymi projektami ze wszystkimi tego konsekwencjami. Pewnych rzeczy oczywiście się nie obejdzie w firmie zatrudniającej 150k ludzi i niestety na dostępy chwilę zaczekają, ale planujemy interesujący program rozrywkowy w tym czasie. Jak tylko pojawią się ogłoszenia wrzucę tutaj trochę szczegółów.

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