🥇Zbavujeme sa strachu pred prvým zamestnaním

Záber z filmu „Harry Potter a väzeň z Azkabanu“

Problémom tohto sveta je, že vzdelaní ľudia sú plní pochybností, zatiaľ čo idiotov plných sebadôvery.
Charles Bukowski

Nedávno som mal ďalšiu individuálnu hodinu programovania. Na rozdiel od bežných hodín, tentoraz sa téma netočila okolo konštrukcie jazyka alebo problémov pri riešení úloh. Študent sa podelil o svoje obavy týkajúce sa budúceho zamestnania. Bol pomerne bystrý, jeden z tých, ktorí chodia na kurzy, rýchlo prechádzajú celým programom a prichádzajú s originálnymi riešeniami, ale neustále sa úprimne podceňujú. Podľa môjho názoru takéto pochybnosti vyplývajú len z nedostatku informácií. Tento nedostatok som sa snažil zaplniť improvizovane počas hodiny.

Otázky boli približne takéto:

Každý rok z vysokých škôl vychádza množstvo študentov a všetci idú hľadať prácu. Veď to je naozaj veľa ľudí. Určite si vezmú tých najlepších a mne sa miesto nepodarí získať.
Čo ak niečo pokašlem a hneď ma vyhodia?
Čo ak v procese práce zistia, že som hlúpy a vyhodia ma?

Tento študent nebol prvý, komu som odpovedal na podobné otázky. Vznikajú u mnohých, a zvyčajne musím rozprávať bez prípravy. Tentoraz som sa rozhodol zapísať si svoj monológ do zápisníka. Myslel som, že napíšem pár odstavcov, ale nakoniec mám celý článok.

V článku je opísaný pohľad z mojej perspektívy a na základe mojich skúseností. Naša realita je však veľmi rôznorodá a v nej sa dejú úžasné veci. Ak s niečím nesúhlasíte alebo má váš zážitok iný charakter, prosím, napíšte komentár.

Článok bol písaný pre vývojárov, nie však len pre nich. Ak plánujete robiť testovanie, administráciu alebo niečo iné v IT, niektoré rady vám tiež prídu vhod.

Vôbec ma nezamestnajú.

Keď si predstavíte, že každoročne množstvo univerzít vydáva stovky študentov, stáva sa to nepríjemným. Ako súťažiť s takou obrovskou hordou?

Žiaľ, nie všetci absolventi majú dostatočné technické zručnosti. Skúste sa spýtať niektorého známeho študenta z univerzity: ako sa ich skupina dostáva k skúškam z predmetov ako „databázy“ alebo „základy algoritmizácie a programovania“? V skupine z 30 ľudí sa v tom najlepšom prípadne nájdú 3-5 „pokročilých“ ľudí, ktorí všetko skutočne urobili sami. Ostatní len odpisujú od nich, memorujú odpovede na otázky a skladajú ich.

Takto to bolo, keď som sa učil sám. Môj zážitok však nemusel byť reprezentatívny. Preto som tento otázku položil niekoľkým rôznym študentom. Odpoveď bola približne rovnaká. Odpovedajúci boli z rôznych vysokých škôl a kolejí. Úvahy o príčinách nechávam mimo tohto článku. Na plnohodnotný výskum nemám silu, tak som urobil záver z dostupných faktov.

Medzi stovkami absolventov, len niekoľko desiatok predstavuje záujem pre zamestnávateľov.

Nielenže má máloktorý absolvent reálnu konkurenciu voči schopnému študentovi s dobrou prípravou. Avšak aj keď ste sa poctivo učili, po prvom pohovore vás pravdepodobne nezoberú. Po druhom, asi tiež nie. Všetko sa môže vyvinúť dobre, ale je lepšie sa nastaviť nie na obliehanie, ale na obliehanie. Neúspešný pokus zamestnať sa je len dôvod na to, aby ste spravili analýzu vlastných chýb a skúsili to znova. O príprave na pohovory hovoriť nebudem. Na internete je už o tom napísané dosť. Povedal by som len, že v priebehu pohovorov existujú nuansy, na ktoré sa vo vašom učebnom pláne pravdepodobne nevenuje čas. Hľadajte tieto informácie sami, môžu skrátiť počet pokusov.

Šialenstvo je presné opakovanie tej istej činnosti. Znova a znova, s nádejou na zmenu.
Albert Einstein

Aby proces pohovorov neprešiel do šialenstva, po každom novom pokuse sa musíte zlepšiť. Zapamätajte si alebo si zapíšte otázky, ktoré vám boli položené počas pohovoru. Po návrate domov si tento zoznam prejdite a overte s pomocou internetu. Takto zistíte, kde ste sa zmýlili vy a kde - tazateľ. To sa tiež stáva. Opakujte alebo študujte témy, na ktoré ste odpovedali zle, a skúste to znova.

Okrem toho existuje jasne vyjadrená sezónnosť trhu práce. Odborné firmy plánujú nábor s ohľadom na dátumy ukončenia štúdia. Na jar je viac pracovných miest pre nováčikov ako v ostatnom čase. Avšak aj konkurencia je v tomto období vyššia.

Hlúpy — vyhodia

Keď prijímajú človeka bez skúseností, existujú od neho príslušné očakávania.

Od nováčika sa v práci očakáva:

Poznanie základnej technickej základne
Studovanie špecifík predmetovej oblasti firmy
Osvojenie používaných nástrojov a praktík

V niektorých organizáciách organizujú pre nováčikov školenia o používaných technológiách, nástrojoch a miestnych praktikách. Napríklad pravidlá slušného správania pri používaní firemnej pošty, postup pri zmene dokumentov vo wike, miestne zvláštnosti práce s VCS a bug trackingom.

Existujú tiež technické úvodné kurzy, ale ich užitočnosť je otázna. Ak sa dostalo až na zamestnanie, zamestnávatelia sa presvedčili, že máte nejakú dostatočnú úroveň vedomostí. Najlepšie je takýto kurz prejsť úprimne, ako malú formalitu. Možno v nich naozaj bude niečo užitočné.

Keď začnete pracovať, pamätajte, že nováčikovi určite nepovedia, aby riešil naliehavú, zložitú a zároveň dôležitú úlohu. Pravdepodobne bude len jedna z týchto vlastností. Buď jednoduchá, ale naliehavá: oprava layoutu, preposlanie nejakého súboru niekomu, reprodukcia problému. Alebo zložitá, ale bez akejkoľvek nádeje na dokončenie — len pre to, aby si nováčik nazbieral čo najviac skúseností. Alebo dôležitá, ale experimentálna. Napríklad projekt, ktorý všetci dávno chcú, ale nemôžu si na jeho realizáciu vyhradiť čas.

Úlohy na osvojenie nástrojov budú "ťažké" a umelé. Pravdepodobne to bude zjednodušená verzia hlavného systému. V podobných úlohách sa používajú tie isté technológie a tie isté termíny z predmetovej oblasti ako v celom projekte. Pri tom výsledok nebude dodávaný koncovému užívateľovi. Môže to demotivovať, ale tomuto pocitu je lepšie sa brániť. Umelú úlohu treba vykonať svedomito, akoby na nej závisela budúcnosť projektu.

Výsledok splnenia vašej prvej úlohy vytvorí prvý dojem o vás u kolegov, ktorí neboli na pohovore.

Iná varianta úlohy na osvojenie si nastrojov je „spustiť projekt na lokálnom počítači/testovacom prostredí“. Niekedy je tento proces popísaný v pokynoch. Ale zvyčajne sú zastarané a na niektorých miestach neaktuálne. Môžete priniesť skutočný prínos projektu, ak napíšete nové pokyny s objasneniami k vzniknutým problémom. Určite ste na VŠ museli písať RGR na správa k nejakým disciplínam. Toto je takmer to isté. V dokumente by mali byť uvedené kroky, ktoré je potrebné vykonať na spustenie.

Zvyčajne sú kroky na spustenie produktu na testovom prostredí približne takéto:

klonovať repozitár, prepnúť sa na nejakú vetvu alebo tag
pripraviť nejaký konfiguračný súbor
pripraviť štruktúru databázy
naplniť ju testovacími údajmi
vykonať zostavenie alebo kompiláciu projektu,
spustiť súbor konzolových skriptov v určitej sekvencii

Počas spustenia systému lokálne nevyhnutne vzniknú nepredvídané problémy.

Nájdené riešenia problémov treba doplniť do pokynov na nasadenie. Potom pri dodržiavaní pokynov, sa tieto problémy už nebudú objavovať. Pri vypĺňaní konfiguračných súborov a spúšťaní skriptov, treba venovať pozornosť, aká hodnota sa kde používa a s čím by mala súhlasiť. Napríklad, ak sa projekt zostavuje pomocou CI systému a potom sa spúšťa skriptom, je dôležité pochopiť, kde napísať názov vetvy alebo číslo commitu. Niekedy to môže byť tak, že skript predpokladá predanie IP adresy alebo DNS názvu databázy, jej používateľského mena a hesla. V tomto prípade je potrebné vedieť, akú adresu použiť pre testovacie prostredie, aké používateľské mená tam existujú a aké heslá treba uviesť.

Niektoré úlohy sa môžu javiť jednoduché pre skúsených vývojárov a spôsobovať ťažkosti stážistom. To je normálny jav.

Vývojári musia každý deň riešiť technické problémy. Skúsení zamestnanci už čelili mnohým problémom, zatiaľ čo nováčikovia ich ešte len musia zvládnuť. Najlepšou taktikou bude zaznamenať všetky stretnuté chyby do dokumentu „riešenie problémov s ${nazvanie zadania}“. Pre každú problém je potrebné formulovať hypotézu o príčine, nájsť na internete možnosti riešenia a postupne ich vyskúšať. Výsledok každej pokusy je tiež potrebné zdokumentovať.

Zozbieranie vašich zistení do dokumentu umožní:

vyprázdniť si hlavu od drobných detailov. Napríklad konfiguračné parametre, DNS/IP adresy, príkazy v príkazovom riadku a SQL dotazy.
spomenúť si na "čo som robil včera", keď sa úloha natiahne na niekoľko dní.
neblúdiť v kruhu. Vždy si budete môcť prečítať, čo ste robili skôr a pochopiť, že ste sa vrátili k pôvodnému problému.
jasne odpovedať na otázku: "čo si spravil dnes?" aj keď ešte nemáte pripravené riešenie.

Musíte vedieť komunikovať stav svojich úloh kolegom.

Priebežne budú kolegovia zaujímať vaše úspechy a budú sa s vami deliť o svoje. Na toto by sa každý deň alebo týždeň malo vyčleniť trochu času.

Ak nesledujete stretnuté a vyriešené problémy, opis vašich úspechov bude vyzerať takto: "Pokúsil som sa vyriešiť úlohu, ale nepodarilo sa mi to. Momentálne hľadám riešenie." Z takéhoto rozprávania nie je jasné, či stážista niečo robil, alebo len sedel a čítal Habr. Potrebuje pomoc? Zmenila sa situácia od včera?

Ak vediete dokument s hľadaním riešení, môžete povedať: "Snažím sa spraviť túto úlohu. Narazil som na takéto chyby. Tieto som vyriešil takto. S touto som sa ešte nezvládol vyrovnať. Mám takéto hypotézy a návrhy na riešenia. Aktuálne ich overujem."

Ak sa úloha dá aspoň trochu merať, mali by sa v stave uvádzať čísla. Napríklad k úlohe "napísať jednotkové testy pre modul" môžete povedať "plánujem urobiť 20 testov, momentálne som napísal 10."

Čím viac podrobností poskytnete, tým lepšie vaši kolegovia pochopia, čo ste robili. To vytvorí pozitívny dojem u kolegov a umožní im pochopiť, či potrebujete pomoc alebo nie.

Nebojte sa požiadať o pomoc.

Už som písal, že pri vzniknutí problému je potrebné formulovať hypotézu o jeho príčinách a možnosti riešení. Môže sa však stať, že hypotézy sa nepotvrdia a samostatne nájdené riešenia nefungujú. V takom prípade je lepšie požiadať o pomoc. Aby ste nepreháňali pozornosť kolegov, mali by ste si nad každým problémom posedieť sami. Ak sa vám za pár hodín nepodarilo nájsť riešenie, je čas požiadať o radu skúsennejších kolegov.

Najlepšie je začať otázkou: „stretol sa niekto s problémom predtým?“ s krátkym popisom problému. Je dobré priložiť časť správy o chybe alebo snímok obrazovky. Túto správu je najlepšie poslať prvýkrát do nejakého spoločného pracovného chatu. Takto neodvádzate od práce tých, ktorí sú skutočne zaneprázdnení. Voľní kolegovia pritom uvidia vašu správu a môžu pomôcť.

Ak po správe v spoločnom chate nikto nepomohol, skúste chytiť skúseného kolegu počas prestávky: na obede, pri ceste za čajom/kávou, pri zápase tenisu alebo počas fajčenia. Ak sa vám to nepodarí, povedzte o svojich ťažkostiach na porade alebo standupe.

Pri riešení známych problémov môže byť týmto všetko ukončené. Ak je problém nový, začne sa vyšetrovanie, kde bude potrebné konať podľa okolností.

„Dôležité“ úlohy nováčikov, ktoré sú potrebné koncovému užívateľovi, budú nudné a malé. Napríklad „pridať ďalší stĺpec do správy“ alebo „opraviť preklep v tlačovej forme“ alebo „implementovať metódu modelu na načítanie atribútov klienta z DBMS“. Cieľom takýchto úloh je, aby sa nováčik oboznámil s predmetnou oblasťou a začlenil sa do každodennej práce.

Je dôležité nielen technicky vyriešiť úlohu, ale aj rozšíriť vedomosti v predmetnej oblasti.

V popise úlohy, v chatoch a rozhovoroch sa objavia pojmy. Môžu vyzerať ako už dobre známe podstatné mená. Avšak v rámci informačného systému nadobúdajú osobitný, presnejší význam. Význam nájdených pojmov je najlepšie zaznamenať do špeciálneho dokumentu — slovníka pojmov. Pri pridávaní do slovníka stačí napísať svoje porozumenie slova, a pre skutočné vysvetlenie je lepšie obrátiť sa na analytika. Ak ten nie je k dispozícii, tak na dlhoročných členov tímu. Vedenie slovníka pojmov je jedným z najjednoduchších spôsobov, ako sa priblížiť k obsahu projektu.

Akonáhle nájdete spoločnú reč s kolegami, začnú vo vás vidieť nie nováčika-stážistu, ale rovnocenného odborníka.

Existujú špeciálne úlohy, ako napríklad „napísať jednotkové testy na modul“. Na nich sa pravdepodobne nepodarí dlho uviaznuť pri hľadaní riešení. Zároveň sú dostatočne vážne a nie sú určené len na školenie stážistu. Napísané testy zvyšujú stabilitu projektu tým, že znižujú chyby v aplikácii a skracujú čas potrebný na testovanie vykonávané ľuďmi. V ideálnom svete sa jednotkové testy píšu hneď v priebehu vývoja, ale realita býva vždy iná. Niekedy má vývojár modulu všetko v hlave a nevidí potrebu ich písania. „Všetko je jasné, čo tu testovať?“ Niekedy sa moduly píšu v urgentnom režime a na jednotkové testy nie je čas. Takže v reálnom svete môžu chýbať jednotkové testy. Preto je úloha písania jednotkových testov zverejnená nováčikovi. Tak stážista rýchlejšie získa prax v projekte a projekt ušetrí čas drahším odborníkom.

Občas sa stáva, že stážistom a nováčikom sa zverujú úlohy plnohodnotných testerov. Zvyčajne je potrebné predtým spustiť produkt lokálne a prečítať si požiadavky. Od nového zamestnanca sa očakáva:

otázky ako „ak to urobím takto, dostanem to takto. V požiadavkách to nie je. Ako by to malo byť?“
úlohy v bug trackeri „v požiadavkách je napísané takto, ale v skutočnosti inak“.

Testovanie je mimoriadne rozsiahla oblasť činnosti pre tento článok. Ak vám bola zadelená takáto úloha, vyhľadajte na internete, ako ju najlepšie vykonať.

Ak sa vám to nepodarí — vyhodia vás.

V normálnej organizácii, ak by sa náhodou stalo, že nezkušený zamestnanec získa prístup k niečomu kritickému a niečo pokazí, vina bude na tom, kto to dovolil. Pretože nováčik predpokladane nemá prístup k kritickej infraštruktúre. Pri adekvátnom vedení sa nemení na neostrihanej stážistovi.

Ak sa niečo stane, z dôvodu jedného incidentu nebudú vyhadzovať. Z chýb sa ľudia učia. Nedôveryhodný stážista dostal hodnotnú lekciu a tým sa výrazne odlišuje od iných stážistov. Ak sa nedôveryhodná osoba vyhodí, na jeho miesto príde iný, ktorý to isté pokazí.

Hlavné je učiť sa na chybách a viac ich neopakovať.

Ak však človek nedokáže vyvodiť z chýb, snažia sa s ním rozlúčiť. Avšak svet je rôznorodý. V nejakej zločineckej organizácii by ho mohli okamžite vyhodiť za prvú chybu. Ale takýmto spoločnostiam sa je lepšie vyhýbať, na čo je dobré si predtým zistiť viac informácií alebo získať poznatky počas pohovoru.

Incidentom je lepšie predchádzať.

Aj keď vás osobne nevyhodia za chybu, takýto incident prinesie nechcené problémy vášmu tímu a projektu ako celku. Preto buďte obzvlášť opatrní pri operáciách mazania alebo vytvárania tabuliek v databázach, súborov, inštancií služieb a dokumentov v databáze vedomostí projektu. Ak narazíte na adresu nového pripojenia, overte si to aspoň u dvoch rôznych ľudí, čo sa tam dá robiť. Skontrolujte si svoje práva na prostrediach nie metódou pokusu a omylu, ale príslušnými príkazmi. Napríklad práva na mazanie súborov pomocou príkazu `ls`, práva na prácu s tabuľkami v mysql pomocou príkazu `SHOW GRANTS FOR ‘user’@’host’;` a podobne. Takmer v každom nástroji budete mať podobnú možnosť.

Pri editovaní súborov si pre každý prípad uchovajte kópiu originálu.

Medzi stážistom a konečným spotrebiteľom sa stavajú niekoľko bariér.

Keby ste mohli okamžite odovzdať svoj produkt spotrebiteľovi, nemuseli by ste sa zamestnať a pustili by ste sa do „voľného plávania“. Ale pokiaľ nemáte takú možnosť (a zodpovednosť), musíte prejsť niekoľkými kontrolnými fázami na projekte.
Prvá z nich — kontrola mentorom. Ten hodnotí riešenie nováčika z technického hľadiska. Ak mentor nebol priradený, je potrebné ho nájsť. Na to je potrebné vybrať niekoho zo starších členov projektu a počas prestávky ho požiadať, aby sa pozrel na riešenie: je úloha správne vyriešená? Ak začne pozerať a odpovedať, znamená to, že mentor bol nájdený. Ak ignoruje, znamená to, že stojí za to sa opýtať ešte niekoho iného.

Ďalšia fáza — Quality Assurance. Po slovensky — testovači. Po sovietsky — normokontrola a OTK. Tí musia zabezpečiť, že výsledok práce stážistu zodpovedá stanovenej úlohe. Zriedkakedy sa budú zaoberať kódom. Najčastejšie testovači budú kontrolovať zostavený projekt, ktorý vývojár ukladá do systému správy verzií.

Tretia fáza — release manažér. Môže sa stať, že na túto úlohu nemusí byť osoba určená, ale niekto túto rolu vykonáva. Overuje, že testovači potvrdili, že projekt môže byť vydaný. Potom vykonáva kroky na dodanie produktu koncovým užívateľom.
V malých organizáciách tieto bariéry z rôznych dôvodov môžu chýbať. Avšak nováčikovi nepridelia úlohu na zmenu niečoho dôležitého. Pretože toto riziko nikto nechce.

Je potrebné najprv sa zapojiť do boja, a potom sa uvidí.
Napoleon Bonaparte

Dúfam, že článok vám pomôže prekonať vašu neistotu a poslať svoj prvý životopis. Samozrejme, predtým sa musíte pripraviť. Ale netreba to príliš odkladať. Určite ste už niekoľko rokov študovali na VŠ alebo na vysokej škole. Kam už ďalej ťahať? Napokon, lepšie raz počuť "nie" od odborníka a vykonať prácu na vlastných chybách, ako každý deň hovoriť "nie" sám sebe a zastaviť sa v profesijnom raste.

Po zamestnaní sa treba sústrediť na to, aby ste sa vypracovali zo stážistu na plnohodnotného člena tímu. Takýto rast zvyčajne sprevádza zvýšenie vášho platu.

Prajem vám trpezlivosť a vytrvalosť.

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.