🥇Pozbywamy się strachu przed pierwszym zatrudnieniem

Kadr z filmu "Harry Potter i więzień Azkabanu"

Problem tego świata polega na tym, że wychowani ludzie są pełni wątpliwości, a idioci pełni pewności siebie
Charles Bukowski

Ostatnio prowadziłem kolejne indywidualne zajęcia z programowania. W przeciwieństwie do zwykłych zajęć, tematem nie była konstrukcja języka ani problem w rozwiązywaniu zadań. Student podzielił się swoim niepokojem dotyczącym przyszłego zatrudnienia. Sam uczeń był dość bystry. To jeden z tych, którzy przychodzą na kursy, kończą program szybciej niż wszyscy inni i wprowadzają oryginalne rozwiązania, ale ciągle szczerze siebie niedoceniają. Moim zdaniem takie wątpliwości pojawiają się tylko z powodu braku informacji. Ten brak starałem się uzupełnić improwizacją podczas zajęć.

Pytania były mniej więcej takie:

Co roku na studia wychodzi mnóstwo studentów i wszyscy idą szukać pracy. To przecież bardzo dużo ludzi. Z pewnością wezmą najlepszych, a mi nie dostanie się miejsca.
A co jeśli popełnię błąd i mnie od razu zwolnią?
A co jeśli w trakcie pracy zrozumieją, że jestem głupi i mnie wyrzucą?

Ten student nie był pierwszą osobą, której odpowiadałem na podobne pytania. Pojawiają się one u wielu ludzi, a zazwyczaj muszę opowiadać bez przygotowania. Tym razem postanowiłem zapisać mój monolog w notatniku. Myślałem, że powstanie kilka akapitów, a uzbierało się na cały artykuł.

W artykule opisany jest punkt widzenia z mojej perspektywy i na podstawie mojego doświadczenia. Nasz świat jest jednak bardzo różnorodny i zdarzają się w nim niesamowite rzeczy. Jeśli się z czymś nie zgadzasz lub twoje doświadczenie jest inne, napisz proszę komentarz.

Artykuł był pisany przez dewelopera dla deweloperów. Jeśli planujesz zajmować się testowaniem, administracją lub czymś innym w IT, część porad również się przyda.

W ogóle nie zatrudnią

Kiedy wyobrażasz sobie, że co roku wiele uczelni wypuszcza setki studentów, robi się niewygodnie. Jak konkurować z tak ogromnym tłumem?

Niestety, nie wszyscy absolwenci mają wystarczające przygotowanie techniczne. Spróbuj zapytać jakiegoś znajomego studenta z uniwersytetu: jak ludzie w jego grupie uzyskują dostęp do egzaminów z przedmiotów takich jak „bazy danych” czy „wprowadzenie do algorytmizacji i programowania”? W grupie z 30 osób w najlepszym przypadku znajdzie się 3-5 „zaawansowanych” chłopaków, którzy naprawdę zrobili wszystko sami. Pozostali po prostu ściągają od nich, wkuwają odpowiedzi na pytania i zdają.

Tak było, gdy sam się uczyłem. Jednak mój doświadczenie mogło być niereprezentatywne. Dlatego zadawałem to pytanie kilku różnym studentom. Odpowiedzi były w przybliżeniu takie same. Odpowiadający byli z różnych uczelni i szkół wyższych. Rozważania na temat przyczyn zostawię poza zakresem tego artykułu. Na pełne badania mnie nie stać, dlatego wyciągnę wnioski z dostępnych faktów.

Spośród setek absolwentów zaledwie kilka dziesiątek stanowi zainteresowanie dla pracodawców.

Nieliczni absolwenci mogą stanowić rzeczywistą konkurencję dla zdolnego studenta z dobrym przygotowaniem. Niemniej jednak, nawet jeśli uczyłeś się rzetelnie, to po pierwszej rozmowie rekrutacyjnej prawdopodobnie nie zostaniesz zatrudniony. Po drugiej, prawdopodobnie również. Wszystko może się dobrze ułożyć, jednak lepiej nastawić się nie na szturm, a na oblężenie. Nieudana próba znalezienia pracy to tylko okazja do przeanalizowania błędów i spróbowania ponownie. O przygotowaniu do rozmów rekrutacyjnych nie będę opowiadać. W internecie na ten temat już napisano sporo. Powiem tylko, że w przechodzeniu rozmów rekrutacyjnych są niuanse, na które w programie twojego kształcenia raczej nie przewidziano czasu. Poszukaj tych informacji samodzielnie, mogą one skrócić liczbę prób.

Szaleństwo to dokładne powtarzanie tego samego działania. Raz za razem, w nadziei na zmianę.
Albert Einstein

Aby przechodzenie rozmów rekrutacyjnych nie zmieniało się w szaleństwo, po każdej nowej próbie należy stawać się lepszym. Zapamiętuj lub zapisuj pytania, które zadawano ci podczas rozmowy. Po powrocie do domu przeglądaj tę listę i sprawdzaj siebie za pomocą internetu. W ten sposób zrozumiesz, gdzie popełniłeś błąd, a gdzie — rekruter. Tak też bywa. Powtórz lub przestudiuj te tematy, w których odpowiedziałeś źle, i spróbuj ponownie.

Ponadto istnieje wyraźna sezonowość na rynku pracy. Zrozumiałe firmy planują zatrudnienia z uwzględnieniem dat ukończenia szkół. Wiosną jest więcej ofert dla nowicjuszy niż w pozostałych okresach. Jednak konkurencja w tym czasie również jest wyższa.

Tchórzliwy — zostanie zwolniony

Kiedy zatrudniają osobę bez doświadczenia, mają wobec niej odpowiednie oczekiwania.

Od nowicjusza w pracy oczekuje się:

Znajomości ogólnej bazy technicznej
Poznania szczegółów dziedziny działalności firmy
Opanowania używanych narzędzi i praktyk

W niektórych organizacjach dla nowicjuszy organizowane są kursy szkoleniowe dotyczące stosowanych technologii, narzędzi i lokalnych zasad. Na przykład zasady dobrego wychowania przy korzystaniu z firmowej poczty, procedury zmiany dokumentów w wikipedii, lokalne szczegóły pracy z VCS i trackerem błędów.

Są również techniczne wprowadzenia, ale ich użyteczność jest wątpliwa. Jeśli doszło do zatrudnienia, oznacza to, że pracodawcy przekonali się, że posiadasz jakiś wystarczający poziom wiedzy. Najlepiej, aby takie kursy po prostu przejść sumiennie, jako małą formalność. Może rzeczywiście znajdzie się w nich coś przydatnego.

Kiedy przystąpisz do pracy, pamiętaj, że nowicjuszowi z pewnością nie zostanie powierzone rozwiązanie pilnego, skomplikowanego i jednocześnie ważnego zadania. Najprawdopodobniej będzie tylko jedno z tych właściwości. Albo proste, ale pilne: poprawienie layoutu, przesłanie komuś jakiegoś pliku, odtworzenie problemu. Albo skomplikowane, ale bez żadnej nadziei na zakończenie — żeby nowicjusz zebrał jak najwięcej doświadczeń. Albo ważne, ale eksperymentalne. Na przykład projekt, na który wszyscy od dawna czekają, ale nie mogą znaleźć czasu na jego realizację.

Zadania związane z opanowaniem narzędzi będą „trudne” i sztuczne. Prawdopodobnie będzie to uproszczona wersja głównego systemu. W takich zadaniach używa się tego samego stosu technologii i tych samych terminów z dziedziny, co w całym projekcie. Przy tym wyniki wykonania nie będą oddawane końcowemu użytkownikowi. To może demotywować, ale lepiej temu nastrojowi się oprzeć. Sztuczne zadanie należy wykonać sumiennie, jakby od niego zależał los projektu.

Wynik rozwiązania twojego pierwszego zadania stworzy pierwsze wrażenie o tobie wśród kolegów, którzy nie byli na rozmowie kwalifikacyjnej.

Inna wersja zadania na opanowanie narzędzi to „uruchomić projekt na lokalnej maszynie/środowisku testowym”. Czasami ten proces jest opisany w instrukcji. Ale zazwyczaj są one stare i miejscami nieaktualne. Można przynieść realną korzyść projektowi, pisząc nową instrukcję z wyjaśnieniami dotyczących napotkanych problemów. Na pewno na uczelni zdarzało się pisać PRG do raportu w różnych dyscyplinach. To prawie to samo. W dokumencie powinny być odzwierciedlone działania, które należy wykonać w celu uruchomienia.

Zazwyczaj działania do uruchomienia produktu w środowisku testowym są mniej więcej takie:

sklonować repozytorium, przełączyć się na jakąś gałąź lub tag
opracować jakiś plik konfiguracyjny
przygotować strukturę bazy danych
wypełnić ją danymi testowymi
wykonać budowę lub kompilację projektu,
uruchomić zestaw skryptów konsolowych w określonej kolejności

Podczas uruchamiania systemu lokalnie nieuniknione będą pojawiały się nieprzewidziane problemy.

Znalezione rozwiązania problemów należy dopisać do instrukcji wdrożeniowej. Wówczas następnym razem przy przestrzeganiu instrukcji te problemy nie będą już występować. Przy wypełnianiu plików konfiguracyjnych i wywoływaniu skryptów trzeba zwracać uwagę, jakie wartości są używane oraz z czym powinny się zgadzać. Na przykład, jeśli projekt jest budowany za pomocą systemu CI i następnie uruchamiany skryptem, ważne jest, aby zrozumieć, gdzie wpisać nazwę gałęzi lub numer commitu. Czasami skrypt wymaga podania adresy IP lub nazwy DNS bazy danych, jej loginu i hasła. W takim przypadku trzeba wiedzieć, jaki dokładnie adres użyć w środowisku testowym, jakie loginy tam są i jakie hasła dla nich należy podać.

Niektóre zadania mogą wydawać się proste dla doświadczonych programistów, a sprawiać trudności stażystom. To normalne zjawisko.

Programiści codziennie muszą rozwiązywać problemy techniczne. Doświadczeni pracownicy napotkali już wiele z tych problemów, podczas gdy nowi dopiero muszą się z nimi zmierzyć. Najlepszą taktyką będzie zapisanie wszystkich napotkanych błędów w dokumencie "rozwiązania problemów z ${nazwanie zadania}". Dla każdego problemu trzeba sformułować hipotezę o przyczynie, znaleźć w Internecie różne rozwiązania i próbować je po kolei. Wynik każdej próby również należy odnotować.

Sformatowanie Twoich badań w postaci dokumentu umożliwi:

uwolnienie się od drobnych szczegółów. Na przykład parametrów konfiguracji, adresów DNS/IP, poleceń konsolowych i zapytań SQL.
przypomnienie sobie "co robiłem wczoraj", gdy zadanie rozciąga się na kilka dni
nie błądzenie w kółko. Zawsze będziesz mógł przeczytać, co robiłeś wcześniej i zrozumieć, że wróciłeś do pierwotnego problemu
jasno odpowiedzieć na pytanie: "co zrobiłeś dzisiaj?", nawet jeśli gotowego rozwiązania jeszcze nie ma.

Musisz umieć informować swoich kolegów o statusie swoich zadań.

Okresowo koledzy będą zainteresowani Twoimi postępami i będą dzielić się swoimi. Na to codziennie lub co tydzień przeznaczają trochę czasu.

Jeśli nie śledzisz napotkanych i rozwiązanych problemów, to opis Twoich postępów będzie wyglądał tak: "Próbowałem wykonać zadanie, ale mi się nie udaje. Na razie szukam rozwiązania". Z takiego opisu nie widać, czy praktykant coś robił, czy po prostu siedział i czytał Habr. Czy potrzebuje pomocy? Czy sytuacja zmieniła się od wczoraj?

Jeśli prowadzisz dokument z poszukiwaniem rozwiązań, będziesz mógł powiedzieć: "Próbuję wykonać to zadanie. Napotkałem takie błędy. Takie rozwiązałem w ten sposób. Z tym jeszcze sobie nie poradziłem. Mam takie hipotezy i propozycje rozwiązań. Aktualnie je weryfikuję."

Jeśli zadanie można jakoś zmierzyć, to w statusie powinny pojawiać się liczby. Na przykład dla zadania "napisać testy jednostkowe dla modułu" można powiedzieć "planuję zrobić 20 testów, teraz napisałem 10".

Im więcej szczegółów przekażesz, tym lepiej Twoi koledzy będą rozumieć, co robiłeś. To stworzy pozytywne nastawienie wśród kolegów i pozwoli im zrozumieć, czy potrzebujesz pomocy, czy nie.

Nie wahaj się prosić o pomoc.

Napisałem wcześniej, że gdy pojawia się problem, należy sformułować hipotezę na temat jego przyczyn i sposób rozwiązania. Jednak zdarza się, że hipotezy nie potwierdzają się, a samodzielnie znalezione rozwiązania problemu nie działają. W takim przypadku lepiej jest poprosić o pomoc. Aby nie nadużywać uwagi współpracowników, należy najpierw spróbować samodzielnie przeanalizować każdy problem. Jeśli po kilku godzinach nie uda się znaleźć rozwiązania, czas zwrócić się o radę do bardziej doświadczonych kolegów.

Najlepiej zacząć od pytania: „czy ktoś wcześniej miał ten problem?” z krótkim opisem tej trudności. Warto załączyć fragment wiadomości o błędzie lub zrzut ekranu. Tę wiadomość warto najpierw wysłać na jakiś wspólny czat roboczy. W ten sposób nie odrywacie od pracy tych, którzy są naprawdę zajęci. Wolni koledzy zobaczą waszą wiadomość i będą mogli pomóc.

Jeśli po wiadomości na wspólnym czacie nikt nie pomógł, spróbuj złapać doświadczonego kolegę podczas przerwy: obiadu, wyjścia po herbatę/kawę, partii tenisa lub palenia. Jeśli to się nie uda, przekaż swoje trudności podczas porannego spotkania lub stand-upu.

W przypadku znanych problemów na tym może się skończyć. Jeśli jednak problem jest nowy, to rozpocznie się śledztwo, które wymagać będzie działania w zależności od okoliczności.

„Ważne” zadania dla nowicjuszy, które są potrzebne dla użytkownika końcowego, będą nudne i małe. Na przykład „dodać dodatkową kolumnę w raporcie” lub „poprawić literówkę w formularzu drukowanym” albo „zrealizować metodę modelu do ładowania atrybutów klienta z DBMS”. Celem takich zadań jest zaznajomienie nowicjusza z tematyką i włączenie się w codzienną pracę.

Ważne jest nie tylko technologicznie rozwiązać zadanie, ale także poszerzyć wiedzę w danej dziedzinie.

W opisie zadania, w czatach i rozmowach będą występować terminy. Mogą wyglądać jak dobrze znane rzeczowniki. Jednak w kontekście systemu informacyjnego mają one szczególny, bardziej precyzyjny sens. Znalezione terminy najlepiej spisywać w specjalnym dokumencie — słowniku terminów. Przy dodawaniu do słownika wystarczy opisać swoje rozumienie słowa, a po autentyczne wyjaśnienie najlepiej zwrócić się do analityka. Jeśli go nie ma, to do weteranów projektu. Prowadzenie słownika terminów to jeden z najprostszych sposobów na wprowadzenie się w przedmiotową dziedzinę projektu.

Gdy tylko znajdziesz wspólny język z kolegami, oni zaczną dostrzegać w Tobie nie stażystę, a partnera specjalistę.

Są szczególne zadania, na przykład "napisać testy jednostkowe dla modułu". Przy tym zadaniu trudno na długo utknąć w poszukiwaniu rozwiązań. Jest to jednak poważne zadanie, które nie jest przeznaczone tylko dla wprowadzenia stażysty. Napisane testy zwiększają stabilność projektu, zmniejszając błędy w aplikacji i ograniczając czas potrzebny na testowanie przez ludzi. W idealnym świecie testy jednostkowe pisze się od razu w trakcie rozwoju, ale rzeczywistość, jak zawsze, bywa inna. Zdarza się, że programista modułu całkowicie trzyma go w głowie i nie widzi potrzeby ich pisania. "Wszystko jest oczywiste, co tu testować?" Czasami moduły pisane są w trybie awaryjnym, a na testy jednostkowe nie ma czasu. Dlatego w rzeczywistym świecie testy jednostkowe mogą być nieobecne. Dlatego zadanie pisania testów jednostkowych zleca się nowicjuszowi. Dzięki temu stażysta może szybciej zaadaptować się do projektu, a projekt może zaoszczędzić czas bardziej wysoko opłacanych specjalistów.

Czasami stażyści i nowicjusze są zatrudniani w roli pełnoprawnych testerów. Zazwyczaj wcześniej trzeba rozwinąć produkt lokalnie i zapoznać się z wymaganiami. Oczekiwania wobec nowego pracownika są następujące:

pytania w stylu "jeśli zrobimy tak, to wyjdzie tak. W wymaganiach tego nie ma. Jak powinno być?"
zadania w bug trackerze "w wymaganiach jest napisane tak, a w rzeczywistości inaczej".

Testowanie to zbyt szeroka dziedzina działalności w ramach tego artykułu. Jeśli otrzymałeś takie zadanie, poszukaj w internecie, jak najlepiej je wykonać.

Nakołujesz — zwolnią

W normalnej organizacji, jeśli nagle stanie się tak, że niedoświadczony pracownik uzyska dostęp do czegoś krytycznego i coś zepsuje, winny będzie ten, kto dopuścił do takiej sytuacji. Ponieważ nowicjusz z założenia nie ma dostępu do krytycznej infrastruktury. Przy odpowiednim kierownictwie nie będą zrzucać winy na niedoświadczonego stażystę.

Jeśli nagle coś się stanie, to nie będą zwalniać z powodu jednego incydentu. Na błędach ludzie się uczą. Stażysta, który popełnił błąd, otrzymał cenną lekcję i bardzo się różni od innych stażystów. Jeśli zwolnią tego, który popełnił błąd, to na jego miejsce przyjdzie inny i popełni ten sam błąd.

Najważniejsze to uczyć się na błędach i więcej ich nie powtarzać.

Jeśli zaś dana osoba nie wyciąga wniosków ze swoich błędów, wtedy postarają się z nią pożegnać. Z drugiej strony świat jest różnorodny. W jakiejś bandyckiej organizacji mogą wyrzucić przez okno za pierwszy błąd. Ale lepiej unikać takich firm, dlatego warto wcześniej zebrać informacje lub dowiedzieć się więcej podczas rozmowy kwalifikacyjnej.

Lepiej nie dopuszczać do incydentów

Nawet jeśli osobiście nie zostaniesz zwolniony za błąd, takie zdarzenie przyniesie niepożądane problemy twojemu zespołowi i projektowi jako całości. Dlatego bądź szczególnie ostrożny podczas operacji usuwania lub tworzenia tabel w bazie danych, plików, instancji usług i dokumentów w bazie wiedzy projektu. Jeśli natrafisz na adres nowego połączenia, upewnij się przynajmniej u dwóch różnych osób, co można tam robić. Sprawdzaj swoje uprawnienia w środowiskach nie metodą prób i błędów, ale za pomocą odpowiednich poleceń. Na przykład uprawnienia do usuwania plików za pomocą polecenia `ls`, uprawnienia do pracy z tabelami w mysql za pomocą polecenia `SHOW GRANTS FOR ‘user’@’host’;` i tym podobne. Praktycznie w każdym narzędziu będziesz mieć podobną możliwość.

Podczas edytowania plików, na wszelki wypadek, zachowuj kopię oryginału.

Między stażystą a ostatecznym użytkownikiem buduje się kilka barier.

Gdybyś mógł od razu oddać swój produkt użytkownikowi, mógłbyś nie podejmować pracy, a wyruszyć na "wolne wody". Ale póki nie masz takiej możliwości (a wraz z tym i odpowiedzialności), musisz przejść przez kilka etapów kontroli w projekcie.
Pierwszym z nich jest ocena przez mentora. Ocenia on rozwiązanie nowicjusza z technicznego punktu widzenia. Jeśli mentor nie został wyznaczony, należy go znaleźć. W tym celu należy wybrać kogoś z doświadczonych uczestników projektu i podczas przerwy poprosić go o przyjrzenie się rozwiązaniu: czy zadanie zostało rozwiązane poprawnie? Jeśli zacznie oglądać i odpowiadać, to znaczy, że mentor został znaleziony. Jeśli zignoruje - warto zapytać jeszcze kogoś innego.

Kolejny etap to zapewnienie jakości. Po rosyjsku - testerzy. Po radziecku - normalizacja i OTK. Muszą upewnić się, że wyniki pracy stażysty odpowiadają postawionemu przed nim zadaniu. Rzadko będą zagłębiać się w kod. Najczęściej testerzy będą sprawdzać zbudowany projekt, który programista zapisuje w systemie kontroli wersji.

Trzeci etap to menedżer wydania. Może nie być osobnej osoby do tego zadania, ale rolę tę i tak ktoś pełni. Sprawdza, czy testerzy potwierdzili, że projekt można wydać. Następnie wykonuje działania mające na celu dostarczenie produktu do końcowych użytkowników.
W małych organizacjach te bariery mogą z różnych powodów nie istnieć. Jednak nie postawią nowicjuszowi zadania wprowadzenia zmian w czymś ważnym. Ponieważ ten ryzyko nikomu nie jest potrzebne.

Najpierw trzeba zacząć stawiać czoła wyzwaniu, a potem zobaczymy.
Napoleon Bonaparte

Mam nadzieję, że artykuł pomoże ci pokonać swoją nieśmiałość i wysłać swoje pierwsze CV. Oczywiście, musisz się wcześniej przygotować. Ale nie należy zbytnio przeciągać. Z pewnością już kilka lat uczyłeś się w uczelni lub szkole wyższej. Dokąd jeszcze to ciągnąć? W końcu lepiej raz usłyszeć „nie” od specjalisty i przeanalizować błędy, niż codziennie mówić „nie” samemu sobie i zatrzymywać się w zawodowym rozwoju.

Po zatrudnieniu należy skupić się na tym, aby wyrosnąć ze stażysty w pełnoprawnego członka zespołu. Taki rozwój zwykle wiąże się ze wzrostem wynagrodzenia.

Życzę cierpliwości i wytrwałości.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.