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

Ještě z filmu „Harry Potter a vězeň z Azkabanu“

Problém tohoto světa je, že vzdělaní lidé jsou plní pochybností, ale idioti jsou plní sebevědomí.

Charles Bukowski

Nedávno jsem učil další lekci programování jeden na jednoho. Na rozdíl od běžných hodin nebylo tématem konstrukce jazyka nebo řešení problémů. Student sdílel své obavy ohledně budoucího zaměstnání. Sám student byl docela chytrý. Jeden z těch, kteří na kurz přicházejí, absolvuje celý program rychleji než kdokoli jiný a s originálními řešeními, ale celou dobu se upřímně podceňuje. Podle mého názoru takové pochybnosti vznikají pouze z nedostatku informací. Tuto mezeru jsem se snažil během lekce improvizovaně vyplnit.

Otázky zněly nějak takto:

• Každý rok mnoho studentů vystuduje vysoké školy a všichni si hledají práci. To je hodně lidí. Pravděpodobně najmou ty nejlepší, ale nedostanu místo.
• Co když to pokazím a hned mě vyhodí?
• Co když si v průběhu práce uvědomí, že jsem hloupý a vyhodí mě?

Tento student nebyl první, komu jsem na podobné otázky odpovídal. Mnoho lidí je má a obvykle je musí sdělit bez přípravy. Tentokrát jsem se rozhodl svůj monolog zapsat do sešitu. Myslel jsem, že to bude pár odstavců, ale nakonec to stačilo na celý článek.

Článek popisuje pohled z mého pohledu a na základě mých zkušeností. Náš svět je však velmi rozmanitý a dějí se v něm úžasné věci. Pokud s něčím nesouhlasíte nebo jsou vaše zkušenosti nějak odlišné, napište komentář.

Článek byl napsán vývojářem pro vývojáře. Pokud však plánujete dělat testování, administraci, nebo cokoli jiného v IT, pak se vám některé rady budou také hodit.

Vůbec vás nevezmou

Když si představíte, že mnoho univerzit každoročně absolvuje stovky studentů, je to nepříjemné. Jak konkurovat tak obrovskému davu?

Bohužel ne všichni absolventi mají dostatečné technické vzdělání. Zkuste se zeptat některého univerzitního studenta, kterého znáte: jak se lidé v jeho skupině dostanou ke zkouškám z oborů jako „databáze“ nebo „základy algoritmizace a programování“? Ve skupině 30 lidí bude v lepším případě 3-5 „pokročilých“ kluků, kteří si vlastně všechno dělali sami. Zbytek z nich jednoduše zkopíruje, nacpe odpovědi na otázky a odešle.

Tak to bylo, když jsem studoval sám. Moje zkušenost však nemusí být reprezentativní. Tuto otázku jsem tedy položil několika různým studentům. Odpověď byla v podstatě stejná. Respondenti byli z různých univerzit a vysokých škol. Diskuse o důvodech ponechám mimo rámec tohoto článku. Nemám dostatek času na plnohodnotné studium, a tak vyvodím závěr z dostupných faktů.

Mezi stovkami absolventů je pro zaměstnavatele zajímavé jen několik desítek

Jen málokterý absolvent dokáže s dobrou přípravou poskytnout skutečnou konkurenci schopnému studentovi. I když jste však studovali svědomitě, po prvním pohovoru vás s největší pravděpodobností nepřijmou. Po druhém asi taky. Všechno může dobře dopadnout, ale je lepší se připravit ne na přepadení, ale na obléhání. Neúspěšný pokus získat práci je pouze důvodem, abyste zapracovali na svých chybách a zkusili to znovu. Nebudu mluvit o přípravě na pohovor. Na toto téma už toho bylo na internetu napsáno hodně. Řeknu jen, že v rozhovorech jsou nuance, na jejichž vysvětlování si váš tréninkový program pravděpodobně nebude potřebovat čas. Tyto informace si vyhledejte sami, může to snížit počet pokusů.

Šílenství je přesné opakování stejné akce. Čas od času doufat ve změnu

Albert Einstein

Aby se rozhovory nezměnily v šílenství, musíte se po každém novém pokusu zlepšit. Zapamatujte si nebo zapište otázky, které jste během rozhovoru položili. Až se vrátíte domů, prohlédněte si tento seznam a zkontrolujte se pomocí internetu. Tak pochopíte, kde jste s tazatelem udělali chybu. To se také stává. Projděte si nebo prostudujte témata, u kterých jste si vedli špatně, a zkuste to znovu.

Navíc je zde výrazná sezónnost trhu práce. Chytré společnosti plánují nábor na základě data ukončení studia. Na jaře je pro nováčky více volných míst než jindy. Konkurence je však v tuto chvíli vyšší.

Hloupé - vyhodit

Když je přijat člověk bez zkušeností, jsou pro něj odpovídající očekávání.

Očekává se, že nováček v práci:

• Znalost obecného technického základu
• Studium specifik oborové oblasti společnosti
• Zvládnutí používaných nástrojů a postupů

Některé organizace poskytují nováčkům školicí kurzy o používaných technologiích, nástrojích a místních postupech. Například slušné chování při používání firemního emailu, postup pro změnu dokumentů ve wiki, lokální funkce práce s VCS a bug tracker.

Existují i ​​technické úvodní kurzy, ale jejich užitečnost je sporná. Pokud jde o zaměstnání, pak jsou zaměstnavatelé přesvědčeni, že máte dostatečnou úroveň znalostí. Nejlepší je prostě absolvovat takové kurzy v dobré víře, jako malou formalitu. Možná v nich skutečně bude něco užitečného.

Když se pustíte do práce, pamatujte, že začátečník rozhodně nebude pověřen řešením naléhavého, složitého a zároveň důležitého úkolu. S největší pravděpodobností zde bude pouze jedna z těchto vlastností. Nebo jednoduché, ale naléhavé: opravte rozvržení, pošlete někomu soubor, zopakujte problém. Nebo obtížné, ale bez naděje na dokončení - aby začátečník nasbíral více rake. Nebo důležité, ale experimentální. Například projekt, po kterém všichni dlouho toužili, ale nemohou najít čas na realizaci.

Úkoly na zvládnutí nástrojů budou „obtížné“ a umělé. S největší pravděpodobností se bude jednat o zjednodušenou verzi hlavního systému. Takové úlohy používají stejný technologický zásobník a stejné doménové podmínky jako celý projekt. V tomto případě nebude výsledek provedení předán koncovému uživateli. To může být demotivující, ale je lepší tomuto sentimentu odolat. Umělý úkol musí být proveden svědomitě, jako by na něm závisel osud projektu.

Výsledek řešení vašeho prvního problému o vás utvoří první dojem mezi kolegy, kteří u pohovoru nebyli.

Další možností pro úlohu masteringu je „spustit projekt na místním počítači/testovacím prostředí“. Někdy je tento proces popsán v pokynech. Většinou jsou ale staré a místy zastaralé. Projektu můžete přinést skutečné výhody, pokud napíšete nové pokyny s objasněním problémů, které se objevily. Určitě jste na univerzitě museli napsat RGR na zprávu o některých oborech. Tady je to skoro stejné. Dokument by měl odrážet akce, které je třeba provést ke spuštění.

Kroky ke spuštění produktu v testovacím prostředí jsou obvykle něco takového:

• klonovat úložiště, přepnout na nějakou větev nebo značku
• vytvořit nějaký konfigurační soubor
• připravit strukturu databáze
• naplňte jej testovacími daty
• sestavit nebo zkompilovat projekt,
• spusťte sadu konzolových skriptů v určitém pořadí

Během procesu místního spouštění systému nevyhnutelně nastanou neočekávané problémy.

Nalezená řešení problémů musí být přidána do pokynů k nasazení. Až budete příště postupovat podle pokynů, tyto problémy již nebudou nastat. Při vyplňování konfiguračních souborů a volání skriptů je třeba dbát na to, která hodnota se kde používá a čemu by se měla shodovat. Pokud je například projekt sestaven pomocí systému CI a poté spuštěn skriptem, je důležité pochopit, kam napsat název větve nebo číslo potvrzení. Stává se, že skript zahrnuje přenos IP adresy nebo DNS jména databáze, jejího přihlašovacího jména a hesla. V tomto případě musíte vědět, jakou adresu použít pro testovací prostředí, jaké tam jsou přihlašovací údaje a jaká hesla pro ně musíte zadat.

Některé úkoly se mohou zdát jednoduché pro zkušené vývojáře, ale náročné pro stážisty. To je normální.

Vývojáři musí každý den řešit technické problémy. Zkušení zaměstnanci již řadu problémů vyřešili, nováčci se s nimi teprve vypořádali. Nejlepší taktikou je zaznamenat všechny chyby, které se vyskytly v dokumentu „řešení problémů s ${task name}“. U každého problému je potřeba zformulovat hypotézu o příčině, najít řešení na internetu a jedno po druhém je vyzkoušet. Výsledek každého pokusu musí být rovněž zaznamenán.

Registrace vašeho výzkumu ve formě dokumentu vám umožní:

• vypusťte z hlavy malé detaily. Například konfigurační parametry, DNS/IP adresy, konzolové příkazy a SQL dotazy.
• zapamatujte si „co jsem dělal včera“, když úkol trvá několik dní
• netoulej se v kruzích. Vždy si můžete přečíst, co jste dělali předtím, a pochopit, že jste se vrátili k původnímu problému
• jasně odpovězte na otázku: "Co jsi dnes dělal?" i když ještě neexistuje hotové řešení.

Musíte být schopni sdělit stav svých úkolů kolegům

Čas od času se kolegové budou zajímat o vaše úspěchy a podělí se o ty své. Vyhraďte si na to nějaký čas denně nebo týdně.

Pokud neevidujete problémy, se kterými jste se setkali a které jste vyřešili, pak popis vašich úspěchů bude vypadat takto: „Zkoušel jsem ten úkol udělat, ale nejde mi to. Stále hledám řešení." Z tohoto příběhu není jasné, zda stážista něco dělal nebo jen seděl a četl. Potřebuje pomoc? Změnila se situace od včerejška?

Pokud si ponecháte dokument, který hledá řešení, můžete říci: „Snažím se udělat tento úkol. Měl jsem takové chyby. Takto jsem se rozhodl. Tohle jsem ještě neřešil. Existují tyto hypotézy a řešení. Teď je zkontroluji."

Pokud lze úkol jakýmkoli způsobem měřit, pak by měl stav obsahovat čísla. Například pro úlohu „napiš jednotkové testy pro modul“ můžete říct „Mám v plánu udělat 20 testů, teď jsem jich napsal 10“.

Čím více podrobností poskytnete, tím lépe vaši kolegové porozumí tomu, co jste dělali. Vytvoříte si tak kladný vztah k vám mezi vašimi kolegy a umožníte jim pochopit, zda potřebujete pomoc nebo ne.

Neváhejte a požádejte o pomoc

Výše jsem psal, že když se objeví problém, je třeba formulovat hypotézu o jeho příčinách a možných řešeních. Stává se však, že hypotézy nejsou oprávněné a nezávisle nalezená řešení problému nefungují. V tomto případě je lepší požádat o pomoc. Abyste nezneužívali pozornost svých kolegů, musíte si na každý problém sednout sami. Pokud jste nebyli schopni najít řešení během několika hodin, je čas požádat o radu zkušenější soudruhy.

Dobré místo, kde začít, je zeptat se: „setkal se už někdo s tímto problémem? se stručným popisem problému. Je vhodné připojit část chybové zprávy nebo snímek obrazovky. Je lepší poslat tuto zprávu poprvé na nějaký obecný pracovní chat. Tímto způsobem neodvádíte pozornost těch, kteří jsou opravdu zaneprázdněni prací. Bezplatní kolegové uvidí vaši zprávu a budou moci pomoci.

Pokud po zprávě v obecném chatu nikdo nepomohl, zkuste zastihnout zkušeného kolegu během přestávky: oběd, jít na čaj/kávu, zahrát si tenis nebo kouřit. Pokud to nevyjde, nahlaste své potíže na schůzce nebo vstoje.

Pokud se vyřeší známé problémy, může to všechno skončit. Pokud je problém nový, tak začne vyšetřování, kde bude nutné podle okolností jednat.

„Důležité“ úkoly pro začátečníky, které koncový uživatel potřebuje, budou nudné a malé. Například „přidejte do sestavy další sloupec“ nebo „opravte překlep v tištěné podobě“ nebo „implementujte metodu modelu pro načítání atributů klienta z DBMS“. Účelem takových úkolů je, aby se začátečník seznámil s danou oblastí a začlenil se do každodenní práce.

Důležité je nejen technické řešení problému, ale také rozšíření znalostí z probírané oblasti.

Termíny se objeví v popisu úkolu, v chatech a konverzacích. Mohou vypadat jako známá podstatná jména. V rámci informačního systému však mají zvláštní, přesnější význam. Význam objevených termínů je nejlépe zaznamenán ve speciálním dokumentu – slovníku termínů. Při přidávání do slovníku stačí napsat své chápání slova, ale pro skutečné dekódování je lepší kontaktovat analytika. Pokud chybí, přejděte ke staromilcům projektu. Udržování slovníku pojmů je jedním z nejjednodušších způsobů, jak se seznámit s tématem projektu.

Jakmile najdete se svými kolegy společnou řeč, začnou vás vnímat nikoli jako nového stážistu, ale jako rovnocenného specialistu.

Existují speciální úlohy, například „zapsat testy jednotek pro modul“. Těžko se na ní můžete zaseknout na delší dobu při hledání řešení. Přitom je to dost vážné a dává se to nejen pro trénink cvičenců. Písemné testy zvyšují stabilitu projektu tím, že omezují chyby v aplikaci a zkracují dobu testování na lidech. V ideálním světě se unit testy píší hned během vývoje, ale realita je pokaždé jiná. Stává se, že vývojář modulu si to nechá úplně v hlavě a nevidí potřebu je psát. "Všechno je zřejmé, co se dá testovat?" Někdy se moduly píší v rush módu a na unit testy nezbývá čas. Takže v reálném světě nemusí existovat testy jednotek. Proto je úkol psaní jednotkových testů přidělen začátečníkovi. Stážista si tak bude moci rychleji zvyknout na projekt a projekt ušetří čas lépe placených specialistů.

Stává se, že stážistům a nováčkům je přidělena role plnohodnotných testerů. Obvykle před tím musíte produkt lokálně nasadit a přečíst si požadavky. V důsledku toho se od nového zaměstnance očekává, že:

• otázky typu „když to uděláš takhle, dopadne to takhle. Toto není v požadavcích. To by mělo být?"
• úkoly v nástroji pro sledování chyb „požadavky to říkají, ale ve skutečnosti je to jinak“.

Testování je pro tento článek příliš široká oblast. Pokud dostanete podobný úkol, vyhledejte na internetu nejlepší způsob, jak jej splnit.

Když něco zkazíš, dostaneš padáka

Pokud se v normální organizaci najednou stane, že nezkušený zaměstnanec získá přístup k něčemu kritickému a něco zkazí, pak bude na vině ten, kdo to dovolil. Protože začátečník ve výchozím nastavení nemá přístup ke kritické infrastruktuře. S adekvátním vedením nenechají všechny pejsky ztratit na nezkušeném cvičáku.

Pokud se něco stane, nevyhodí vás kvůli jednomu incidentu. Lidé se učí z chyb. Stážista, který to pokazil, se naučil cennou lekci a je velmi odlišný od ostatních stážistů. Pokud vyhodíte někoho, kdo něco pokazí, přijde na jeho místo někdo jiný a pokazí to stejným způsobem.

Hlavní je se z chyb poučit a neopakovat je.

Pokud člověk ze svých chyb nevyvodí důsledky, pokusí se s ním rozloučit. Svět je však rozmanitý. V nějaké gangsterské organizaci vás při první chybě mohou okamžitě vyhodit z okna. Ale je lepší se takovým společnostem vyhnout tím, že se nejprve zeptáte nebo zjistíte více během pohovoru.

Je lepší se incidentům vyhnout

I když vás osobně nevyhodí za chybu, takový incident způsobí nechtěné problémy vašemu týmu a projektu jako celku. Buďte proto obzvláště opatrní při operacích mazání nebo vytváření tabulek v databázi, souborů, instancí služeb a dokumentů v databázi znalostí projektu. 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. Zkontrolujte svá práva v prostředích nikoli metodou pokus-omyl, ale pomocí příslušných příkazů. Například práva na mazání souborů pomocí příkazu `ls`, práva na práci s tabulkami v mysql pomocí příkazu `SHOW GRANTS FOR 'user'@'host';` a podobně. Téměř v každém nástroji budete mít podobnou příležitost.

Při úpravách souborů si pro jistotu uschovejte kopii originálu.

Mezi školitelem a koncovým uživatelem je postaveno několik bariér.

Kdybyste mohli okamžitě dát svůj produkt spotřebiteli, nebyli byste schopni získat práci, ale vydat se na „volné plavání“. Zatímco ale takovou možnost (a zároveň odpovědnost) nemáte, musíte projít několika fázemi kontroly projektu.
První z nich je ověření mentorem. Ten hodnotí nováčkovo rozhodnutí z technického hlediska. Pokud mentor nebyl přidělen, musíte ho najít. Chcete-li to provést, musíte si vybrat jednoho ze staromilců projektu a během přestávky ho požádat, aby se podíval na řešení: byl problém vyřešen správně? Pokud začne hledat a odpovídat, pak se našel mentor. Pokud to ignoruje, stojí za to se zeptat někoho jiného.

Další fází je zajištění kvality. V ruštině - testery. V sovětském stylu - oddělení standardní kontroly a kontroly kvality. Musí zajistit, aby výkon stážisty byl v souladu s úkolem, který mu byl přidělen. Zřídka si přečtou kód. Nejčastěji testeři zkontrolují sestavený projekt, který vývojář ukládá do systému správy verzí.

Třetí fází je správce vydání. Na tento úkol možná není samostatná osoba, ale někdo stále hraje roli. Zkontroluje, zda testeři potvrdili, že projekt může být uvolněn. Poté provádí činnosti k dodání produktu koncovým uživatelům.
V malých organizacích tyto bariéry nemusí existovat z různých důvodů. Nedají však nováčkovi za úkol něco důležitého změnit. Protože toto riziko nikdo nepotřebuje.

Nejprve se musíte zapojit do bitvy a pak uvidíme.
Napoleon Bonaparte

Doufám, že vám tento článek pomůže překonat vaši nejistotu a odeslat svůj první životopis. Samozřejmě se musíte nejprve připravit. Ale není třeba se přehánět. Pravděpodobně jste již několik let studovali na univerzitě nebo vysoké škole. Kam dál? Nakonec je lepší jednou slyšet „ne“ od specialisty a pracovat na chybách, než si každý den říkat „ne“ a přestat profesně růst.

Po přijetí se musíte zaměřit na to, abyste ze stážisty vyrostli v plnohodnotného člena týmu. Tento typ růstu obvykle přichází se zvýšením vaší mzdy.

Přeji vám trpělivost a vytrvalost.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

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

• Komplex

• Důležité

• Naléhavé

• Nic z výše uvedeného

Hlasovalo 75 uživatelů. 20 uživatelů se zdrželo hlasování.

Co jste museli udělat zpočátku ve svém prvním zaměstnání?

• Nainstalujte produkt lokálně

• Otestujte stávající produkt

• Proveďte školení, falešný úkol

• Udělejte pro klienta experimentální, skutečný projekt

Hlasovalo 63 uživatelů. 25 uživatelů se zdrželo hlasování.

Kolik studentů ve vaší skupině bylo schopno samostatně plnit úkoly v technických předmětech během školení?

• 1 z 10

• 1 z 5

• Každou vteřinu

• Všechno, až na vzácné výjimky

Hlasovalo 70 uživatelů. 19 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com