Zbavujeme se strachu z prvního zaměstnání

Zbavujeme se strachu z prvního zaměstnání
Záběr z filmu „Harry Potter a vězeň z Azkabanu“

Problém tohoto světa spočívá v tom, že vzdělaní lidé jsou plní pochybností, zatímco idioti jsou plní jistoty.

Charles Bukowski

Nedávno jsem vedl další individuální lekci programování. Na rozdíl od běžných hodin se tématem nestala konstrukce jazyka ani problém při řešení úkolu. Student se podělil o své obavy ohledně budoucího zaměstnání. Sám žák byl docela bystrý. Jeden z těch, kteří přicházejí na kurzy, projdou celým programem nejrychleji a s originálními řešeními, ale neustále se upřímně podceňují. Podle mého názoru takové pochybnosti vznikají pouze z nedostatku informací. Tento nedostatek jsem se snažil vyplnit improvizovaně během lekce.

Otázky zněly přibližně takto:

  • Každý rok z vysokých škol vycházejí tisíce studentů a všichni se vydávají hledat práci. To je přece hodně lidí. Určitě vezmou ty nejlepší, a pro mě už místo nezbyde.
  • Co když udělám chybu a hned mě vyhodí?
  • Co když během práce zjistí, že jsem hloupý, a vyhodí mě?

Tento student nebyl prvním člověkem, kterému jsem odpovídal na podobné otázky. Tyto obavy se objevují u mnoha lidí a obvykle o nich musím mluvit bez přípravy. Tentokrát jsem se rozhodl zaznamenat svůj monolog do poznámkového bloku. Myslel jsem, že napíšu pár odstavců, ale nakonec to vyšlo na celý článek.

V článku je popsán pohled z mého úhlu a vycházející z mých zkušeností. Avšak náš svět je velmi různorodý a ve něm se dějí úžasné věci. Pokud s něčím nesouhlasíte nebo je vaše zkušenost jiná, prosím, napište komentář.

Článek byl psán od vývojáře pro vývojáře. Ale pokud plánujete se věnovat testování, administraci nebo čemukoliv jinému v IT, část rad se vám také hodí.

Vůbec nenajmou.

Když si představíte, že každoročně mnoho univerzit vychovává stovky studentů, cítíte se nekomfortně. Jak konkurovat tak obrovské masu?

Bohužel, ne všichni absolventi mají dostatečné technické znalosti. Zkuste se zeptat nějakého známého studenta z univerzity: jak se lidé v jeho skupině dostávají k zkouškám z předmětů jako "databáze" nebo "základy algoritmizace a programování"? Ve skupině o 30 lidech se v nejlepším případě najdou 3–5 "pokročilých" studentů, kteří skutečně všechno zvládli sami. Ostatní prostě opisují od nich, memorují odpovědi na otázky a skládají zkoušky.

Tak to bylo, když jsem studoval já sám. Nicméně moje zkušenost mohla být nereprezentativní. Proto jsem tuto otázku položil několika různým studentům. Odpověď byla zhruba stejná. Odpovídající byli z různých vysokých škol a kolegií. Úvahy o příčinách ponechám mimo tento článek. Na plnohodnotný výzkum mi nezbývá síla, proto učiním závěr z dostupných faktů.

Mezi stovkami absolventů představuje pouze několik desítek zajímavost pro zaměstnavatele.

Jen málo absolventů dokáže vytvořit skutečnou konkurenci pro schopného studenta s dobrým vzděláním. Nicméně, pokud jste se i pilně učili, po prvním pohovoru vás pravděpodobně nevyberou. Po druhém, asi také ne. Všechno se může vyvinout dobře, avšak je lepší se připravit ne na útok, ale na obléhání. Neúspěšný pokus o zaměstnání je pouze důvodem k tomu, abyste se zamysleli nad chybami a zkusili to znovu. O přípravě na pohovory nebudu hovořit. Na toto téma už bylo na internetu napsáno spousta. Řeknu jen, že v průběhu pohovorů existují nuance, na které ve vašem studijním programu pravděpodobně nebyl čas. Hledejte tyto informace sami, mohou vám zkrátit počet pokusů.

Šílenství je přesné opakování téže akce. Znovu a znovu, v naději na změnu.

Albert Einstein

Aby se absolvování pohovorů nestalo šílenstvím, je třeba po každém novém pokusu se zlepšit. Pamatujte si nebo si zaznamenávejte otázky, které vám byly položeny během pohovoru. Po návratu domů si tento seznam projděte a ověřte se pomocí internetu. Tak pochopíte, kde jste se mýlili vy, a kde — dotazující. Něco takového se také stává. Opakujte nebo nastudujte témata, na která jste špatně odpověděli, a zkuste to znovu.

Kromě toho existuje výrazná sezónnost na trhu práce. Chytré společnosti plánují nábor s ohledem na data absolvování škol. Na jaře je více volných míst pro nováčky než v ostatních obdobích. Nicméně také konkurence je v tomto období vyšší.

Hloupého — propustí.

Když zaměstnávají člověka bez zkušeností, existují odpovídající očekávání.

Od nováčka v práci se očekává:

  • Znalost obecného technického základu.
  • Studium specifik předmětu společnosti.
  • Osvojení používaných nástrojů a praktik.

V některých organizacích se pro nováčky organizují školení o používaných technologiích, nástrojích a místních zvyklostech. Například pravidla slušného chování při používání firemního e-mailu, postup změny dokumentů na wikipedii, místní zvláštnosti práce s VCS a chybným trackovacím systémem.

Existují také technické úvodní kurzy, ale jejich užitečnost je sporná. Pokud došlo k zaměstnání, znamená to, že zaměstnavatelé se přesvědčili, že máte nějakou dostatečnou úroveň znalostí. Nejlépe je takové kurzy prostě projít svědomitě jako malou formalitu. Možná v nich skutečně bude něco užitečného.

Když začnete pracovat, pamatujte, že nováčkovi určitě nepřidělí řešení naléhavého, složitého a zároveň důležitého úkolu. Pravděpodobně bude mít jen jednu z těchto vlastností. Buď jednoduché, ale naléhavé: opravit rozvržení, přeposlat někomu nějaký soubor, reprodukovat problém. Nebo složité, ale bez šance na dokončení — jen proto, aby nováček nasbíral co nejvíc zkušeností. Nebo důležité, ale experimentální. Například projekt, který všichni dávno chtějí, ale nemohou vyčlenit čas na realizaci.

Úkoly pro osvojení nástrojů budou "složitými" a umělými. Pravděpodobně to bude zjednodušená verze hlavního systému. V podobných úlohách se používá stejný technologický stack a stejné termíny z oblasti jako v celém projektu. Přitom výsledek provedení nebude předán koncovému uživateli. To může demotivovat, ale tomuto pocitu je lepší odolat. Umělý úkol je potřeba vykonávat svědomitě, jako by od něj závisela budoucnost projektu.

Výsledek vyřešení vaší první úlohy vytvoří první dojem o vás u kolegů, kteří nebyli na pohovoru.

Další variantou úlohy pro osvojení si nástrojů je "spustit projekt na lokálním počítači/testovací prostředí". Někdy je tento proces popsán v pokynech. Ale ty jsou obvykle zastaralé a místy neaktuální. Můžete přinést skutečný přínos projektu, pokud napíšete nové pokyny s upřesněními k vzniklým problémům. Určitě jste na vysoké škole psali RGR pro zprávu o nějakých předmětech. Tady je to téměř to samé. V dokumentu by měly být uvedeny kroky, které je třeba provést pro spuštění.

Obvykle jsou kroky pro spuštění produktu na testovacím prostředí přibližně takovéto:

  • klonovat repozitář, přepnout se na nějakou větev nebo tag
  • vyhotovit nějaký konfigurační soubor
  • připravit strukturu databáze
  • naplnit ji testovacími daty
  • provést sestavení nebo kompilaci projektu,
  • spustit sadu konzolových skriptů v určité sekvenci

Při spouštění systému lokálně nevyhnutelně vzniknou nepředvídané problémy.

Nalezená řešení problémů je třeba doplnit do pokynů k nasazení. Pak při dalším následování pokynů tyto problémy již nebudou vznikat. Při vyplňování konfiguračních souborů a volání skriptů je třeba věnovat pozornost tomu, jaká hodnota se kde používá a s čím by měla korespondovat. Například pokud je projekt sestaven pomocí CI systému a následně spuštěn skriptem, je důležité pochopit, kam napsat název větve nebo číslo commitu. Někdy skript předpokládá předání IP adres nebo DNS názvu databáze, jejího uživatelského jména a hesla. V tom případě je třeba vědět, jakou adresu použít pro testovací prostředí, jaká tam jsou uživatelská jména a jaká hesla je třeba uvést.

Některé úlohy se mohou zdát jednoduché pro zkušené vývojáře a vyvolávat potíže u stážistů. To je normální jev.

Vývojáři se každý den potýkají s technickými problémy. Zkušení zaměstnanci již mnohé z těchto problémů vyřešili, zatímco nováčkům teprve zůstává, aby se s nimi vypořádali. Nejlepší taktikou bude zaznamenávat všechny potíže do dokumentu „řešení problémů s ${název úkolu}“. Pro každý problém je potřeba formulovat hypotézu o příčině, vyhledat na internetu možné řešení a postupně je vyzkoušet. Výsledek každého pokusu je také potřeba zaznamenat.

Sepsání vašich poznámek do dokumentu vám umožní:

  • vylít z hlavy drobné detaily. Například konfigurační parametry, DNS/IP adresy, příkazové řádky a SQL dotazy.
  • vzpomínat na to, „co jsem dělal včera“, když úkol trvá několik dní.
  • nebloudit dokola. Vždy si budete moci přečíst, co jste dělali dříve, a pochopit, že jste se vrátili k původnímu problému.
  • jasně odpovědět na otázku: „co jsi dnes udělal?“ i když hotové řešení zatím neexistuje.

Musíte umět sdělovat stav svých úkolů kolegům.

Pravidelně se kolegové budou zajímat o vaše úspěchy a sdílet své. Na to se denně nebo každý týden vyhrazuje trochu času.

Pokud nesledujete narazily a vyřešené problémy, váš popis úspěchů bude vypadat jako: „Snažil jsem se splnit úkol, ale nedaří se mi. Zatím hledám řešení.“ Z takového vyprávění není jasné, zda stážista něco dělal, nebo jen seděl a četl na internetovém portálu. Potřebuje pomoc? Změnila se situace od včerejška?

Pokud budete mít dokument s hledáním řešení, můžete říci: „snažím se splnit tento úkol. Měl jsem takové chyby. Některé jsem vyřešil tímto způsobem. S tímto jsem se ještě nevyrovnal. Mám takové hypotézy a možnosti řešení. Teď je ověřuji.“

Pokud je úkol nějak měřitelný, měl by ve stavu znít čísla. Například pro úkol „napsat jednotkové testy pro modul“ můžete říci: „plánuji udělat 20 testů, zatím jsem napsal 10.“

Čím více podrobností sdělíte, tím lépe vaši kolegové pochopí, co jste dělali. To u kolegů vytvoří pozitivní dojem a umožní jim pochopit, zda potřebujete pomoc nebo ne.

Nebojte se požádat o pomoc.

Výše jsem psal, že když se objeví problém, měli byste formulovat hypotézu o jeho příčinách a možné řešení. Někdy se však stane, že hypotézy se nepotvrdí a samostatně nalezená řešení nefungují. V takovém případě je lepší požádat o pomoc. Abychom nezahlcovali pozornost kolegů, měli bychom si nad každým problémem nejprve posedět sami. Pokud se během pár hodin nepodaří najít řešení, je čas hledat radu u zkušenějších kolegů.

Nejlépe začít otázkou: „narazil už někdo na tento problém?“ s krátkým popisem situace. Je dobré přiložit část zprávy o chybě nebo screenshot. Toto sdělení je nejlepší poslat poprvé do nějakého obecného pracovního chatu. Takto neodvádíte pozornost těch, kteří jsou opravdu zaměstnaní. Volní kolegové tak uvidí vaši zprávu a mohou pomoci.

Pokud po zprávě v obecném chatu nikdo nepomůže, zkuste chytit zkušeného kolegu během přestávky: na oběd, při cestě pro čaj/kávu, během tenisové partie nebo při cigaretě. Pokud se to nepovede, informujte o svých potížích na poradu nebo stand-upu.

Při řešení známých problémů tím to skončí. Pokud je však problém nový, začne vyšetřování, kde bude třeba jednat dle okolností.

„Důležité“ úkoly pro nováčky, které potřebuje koncový uživatel, budou nudné a malé. Například „přidat další sloupec do zprávy“ nebo „opravit tiskovou chybu“ nebo „realizovat metodu modelu pro načítání atributů klienta z DBMS“. Cílem těchto úkolů je, aby se nováček seznámil s oborem a zapojil se do každodenní práce.

Je důležité nejen technicky vyřešit úkol, ale také rozšířit znalosti v daném oboru.

V popisu úkolu, v chatech a konverzacích se budou objevovat termíny. Ty mohou vypadat jako dlouho známé podstatné jméno. Nicméně v rámci informačního systému mají zvláštní, přesnější smysl. Nejlépe je zaznamenat význam nalezených termínů do speciálního dokumentu — slovníku termínů. Při přidávání do slovníku stačí napsat své pochopení slova, a pro skutečné objasnění je lepší se obrátit na analytika. Pokud není k dispozici, tak na pamětníky projektu. Vedení slovníku termínů je jedním z nejjednodušších způsobů, jak se připojit k tematické oblasti projektu.

Jakmile najdete společnou řeč s kolegy, začnou vás vnímat ne jako nováčka-stážistu, ale jako sobě rovného specialistu.

Existují zvláštní úkoly, například „napsat jednotkové testy na modul“. Na nich není pravděpodobné, že byste se na dlouho zasekli s hledáním řešení. Přitom jsou dost vážné a nejsou určeny pouze pro vzdělávání stážisty. Napsané testy zvyšují stabilitu projektu tím, že snižují množství chyb v aplikaci a zkracují čas potřebný na testování lidmi. V ideálním světě se jednotkové testy píší hned během vývoje, ale realita je vždy jiná. Někdy vývojář modulu drží všechno v hlavě a nevidí potřebu je psát. „Všechno je samozřejmé, co tady testovat?“ Někdy se moduly píší v hektickém režimu a na jednotkové testy není čas. Takže v reálném světě jednotkové testy nemusí být. Proto se úkol na napsání jednotkových testů svěřuje nováčkovi. Tak se stážista může rychleji zorientovat v projektu, a projekt může ušetřit čas dráže placených specialistů.

Někdy se stážistům a nováčkům přiděluje role plnohodnotných testerů. Obvykle je předtím potřeba rozvinout produkt lokálně a přečíst si požadavky. Od nového zaměstnance se očekává:

  • otázky jako „když to udělám takto, vyjde to takto. V požadavcích to není. Jak to má být?“
  • úkoly v bug-trackeru „v požadavcích je napsáno takto, ale ve skutečnosti je to jinak.“

Testování je příliš rozsáhlá oblast pro tento článek. Pokud vám byla přidělena podobná úloha, hledejte na internetu, jak ji nejlépe vykonávat.

Uděláš chybu — vyhodí tě.

Ve normální organizaci, pokud by se náhodou stalo, že nezkušený zaměstnanec získá přístup k něčemu kritickému a něco pokazí, pak bude vina na tom, kdo to umožnil. Protože nováček nemá výchozí přístup k kritické infrastruktuře. Při adekvátním vedení se nesmějí všichni hněvat na nezkušeného stážistu.

Pokud by se náhodou něco stalo, nebudou vás vyhazovat kvůli jednomu incidentu. Lidé se učí z chyb. Chybující stážista obdržel cennou lekci a tím se výrazně liší od ostatních stážistů. Pokud byste vyhodili chybujícího, na jeho místo přijde někdo jiný a pak udělá stejnou chybu.

Hlavní je učit se z chyb a už je nezopakovat.

Pokud se však člověk nepoučí ze svých chyb, pokusí se s ním rozloučit. Nicméně svět je různorodý. V nějaké gangsterské organizaci by jej mohli hned vyhodit z okna za první chybu. Ale je lepší se takovým firmám vyhnout, což lze předem zjistit nebo se dozvědět více během pohovoru.

Incidentům je lepší se vyhnout.

I když vás osobně nevyhodí za chybu, tato událost přinese nechtěné problémy vašemu týmu a projektu jako celku. Proto buďte obzvlášť opatrní při operacích odstraňování nebo vytváření tabulek v databázi, souborů, instancí služeb a dokumentů v projektové znalostní bázi. Pokud narazíte na adresu nového připojení, ověřte si alespoň u dvou různých lidí, co se tam dá dělat. Kontrolujte svá práva v prostředích ne metodou pokus-omyl, ale příslušnými příkazy. Například práva na odstraňování souborů pomocí příkazu `ls`, práva na práci s tabulkami v mysql pomocí příkazu `SHOW GRANTS FOR ‘user’@’host’;` atd. V téměř každém nástroji budete mít podobnou možnost.

Při úpravě souborů si pro jistotu vždy uchovejte kopii originálu.

Mezi stážistou a koncovým uživatelským se buduje několik překážek.

Kdybyste mohli ihned předat svůj produkt spotřebiteli, nemuseli byste se zaměstnávat, ale mohli byste se pustit do „svobodného plavání“. Ale dokud nemáte tuto možnost (a zároveň odpovědnost), musíte projít několika kontrolními fázemi v projektu.
Prvním krokem je hodnocení mentorem. Ten posuzuje řešení nováčka z technického hlediska. Pokud nebyl mentor přidělen, je třeba ho najít. K tomu stačí vybrat někoho ze starších členů projektu a během přestávky ho požádat, aby se na řešení podíval: je úkol správně vyřešen? Pokud začne koukat a odpovídat, mentor je nalezen. Pokud ignoruje, je dobré se zeptat ještě někoho jiného.

Další fází je zajištění kvality. V češtině – testeři. Hovorově – normokontrola a OTK. Ti musí zajistit, že výsledek práce stážisty odpovídá zadání. Zřídka se budou hlouběji zabývat kódem. Nejčastěji testeři budou kontrolovat hotový projekt, který vývojář ukládá do systému správy verzí.

Třetí fáze – release manager. Může se stát, že na tuto úlohu nebude vyčleněná zvláštní osoba, ale přesto tuto roli někdo plní. Kontroluje, zda testeři potvrdili, že projekt může být uvolněn. Poté provede kroky k dodání produktu koncovým uživatelům.
V menších organizacích tyto bariéry mohou z různých důvodů chybět. Nicméně, nováčkovi nedají úkol ke změně něčeho důležitého. Protože ten risk nikdo nechce.

Nejdříve je potřeba se vrhnout do boje, a pak se uvidí.
Napoleon Bonaparte

Doufám, že vám tento článek pomůže překonat vaši nejistotu a poslat svůj první životopis. Samozřejmě, musíte se předem připravit. Ale netřeba to přehánět. Pravděpodobně jste už několik let studovali na vysoké škole nebo na koleji. Kam dál to zdržovat? Nakonec je lepší jednou slyšet „ne“ od specialisty a opravit chyby, než každý den říkat „ne“ sám sobě a zastavit se v profesním růstu.

Po nalezení zaměstnání je důležité soustředit se na to, abyste se přeměnili ze stážisty na plnohodnotného člena týmu. Tento růst obvykle doprovází zvýšení vaší mzdy.

Přeji trpělivost a vytrvalost.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.

Jaké byly vaše první úkoly na vaší první práci v IT?

  • Složité

  • Důležité

  • Urgentní

  • Žádný z uvedeného

Hlasovalo 75 uživatelů. Zdrželo se 20 uživatelů.

Co jste asi dělali na začátku své první práce?

  • Instalovat produkt lokálně

  • Testovat stávající produkt

  • Provádět cvičební, nepravdivý úkol

  • Zabývat se experimentálním, skutečným projektem pro klienta

Hlasovalo 63 uživatelů. Zdrželo se 25 uživatelů.

Kolik studentů ve vaší skupině při výuce mohlo samostatně splnit úkoly z technických předmětů?

  • 1 z 10

  • 1 z 5

  • Každý druhý

  • Všichni, s výjimkou několika

Hlasovalo 70 uživatelů. Zdrželo se 19 uživatelů.

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster