První kroky do IT: Jak získat práci junior vývojáře

Na závěr si osvoj pravidlo, které ušetří hodiny práce: nejdřív si data prohlédni v příkazové řádce, až potom je zapoj do aplikace. Napiš si malý test, který ověří, že API vrací očekávaný tvar. Tím předejdeš situaci, kdy tvůj kód spadne kvůli tomu, že jedno pole má jiný název, než předpokládáš. S takovým základem zvládneš první projekt s API bez zbytečného tápání.

Pokud nedostanete odpověď nebo vás odmítnou, neberte to osobně. Trh je plný firem, které hledají různé typy lidí. Zkuste to znovu, ale poučte se: upravte životopis, dodělejte projekt, naučte se novou technologii. Každý neúspěch je zpětná vazba. Důležité je vydržet a posílat dál. Často se první práce najde přes známé – dejte vědět na sociálních sítích, že hledáte, a nebojte se zeptat v komunitních skupinách. Osobní doporučení má velkou váhu.

Při práci s vestavěnými nástroji je klíčové mít pod kontrolou verzi kódu. Než začnete s rozsáhlejšími refaktoringy, vytvořte si commit nebo si alespoň uložte aktuální stav. Pokud se něco pokazí, můžete se snadno vrátit. Také si zvykněte dělat refaktoring v malých krocích a po každé operaci spustit testy. IDE vám dá vědět, pokud něco není v pořádku, ale automatické testy jsou vaší pojistkou, že se nic nerozbilo.

První krok spočívá v zavedení sémantického verzování pro každou knihovnu zvlášť. Formát tři čísla (hlavní, vedlejší, oprava) funguje dobře, ale musí být striktně dodržován. Hlavní číslo zvyšujte pouze při nekompatibilních změnách API, vedlejší při přidání funkce zpětně kompatibilním způsobem a opravné při opravě chyby. Důležité je, aby se tyto změny promítaly i do závislostí. Pokud knihovna A změní hlavní verzi, knihovna B, která ji používá, musí ve svém manifestu explicitně uvést nový rozsah povolených verzí. Bez toho vznikne chaotický stav, kdy různé části projektu používají nekompatibilní kombinace.

Nezapomeňte také na podporu uložených procedur a funkcí. Některá IDE umí zobrazit kód procedur, zvýraznit chyby a umožnit jejich spuštění s parametrem. To ušetří čas při ladění. Ale pozor – některé nástroje zobrazují procedury jen jako text a neumožňují jejich krokování. Pokud toto potřebujete, testujte přímo na vaší databázi, ne na demo serveru. Další praktickou funkcí je porovnání schémat – ať už mezi dvěma databázemi, nebo verzemi. Bez tohoto nástroje budete muset ručně psát skripty a porovnávat je, což je zbytečná práce.

Další pastí je komunikace přes e-mail nebo chat, kde zákazník nevidí vaši mimiku. Psaná komunikace je doslovnější, takže každá formulace typu „určitě" nebo „zaručeně" je zbytečná. Místo toho používejte slova jako „předpokládám", „plánuji", „odhaduji". Pokud pracujete na projektu, který se může protáhnout, rovnou řekněte, že termín je orientační a upřesníte ho po prvním kroku. Nikdy nenechávejte zákazníka v nejistotě – kdykoli se odhad změní, okamžitě mu to sdělte, i kdyby to bylo jen o den.

Typická chyba je přidávat si k odhadu „tajnou rezervu" a pak zákazníkovi oznámit termín o dva dny delší, než reálně potřebujete. Takový přístup sice chrání vás, ale ničí důvěru. Zákazník vás přestane brát vážně, jakmile zjistí, že pokaždé slíbíte déle a pak to stejně nestíháte. Mnohem lepší je říct kratší termín, ale s jasnou podmínkou: „Když mi pošlete podklady do zítřka, stihnu to do konce týdne. Pokud ne, posouvá se to o dva dny." Tím přesouváte odpovědnost na zákazníka a vyhnete se slibům, které nemůžete ovlivnit.

Na pohovor si připravte krátký příběh o projektu, který jste dělali. Vysvětlete, proč jste ho dělali, jaké problémy jste řešili a co jste se naučili. Nebojte se přiznat, co nevíte – u juniorů se to očekává. Ale ukážete, že přemýšlíte, pokud si předem nastudujete základní koncepty: algoritmy, datové struktury, HTTP, relační databáze. Nepodceňujte ani logické úlohy – na pohovorech bývají běžné.

Začni s voláním GET na veřejné API, které nevyžaduje registraci ani klíč. Otevři si terminál a použij nástroj pro příkazovou řádku, nebo si vytvoř malý skript v jazyce, který už znáš. Tvůj první požadavek může být jen načtení dat ve formátu JSON. Odpověď si vytiskni na obrazovku. Důležité je sledovat, jakou strukturu data mají – jestli je to pole, objekt, nebo vnořený objekt. To je základ pro to, abys uměl data zpracovat dál.

Při výběru integrovaného vývojového prostředí (IDE) se často soustředíte na jazyky, které plánujete používat, a na vzhled prostředí. To je ale jen polovina úspěchu. Pokud pracujete s databázemi, je podpora SQL nástrojů klíčová. Než se rozhodnete, zkuste si odpovědět na otázku, jaké databázové systémy používáte – MySQL, PostgreSQL, SQL Server, nebo třeba Oracle. Každé IDE má jinou úroveň integrace a ne vždy to, co vypadá dobře v prezentaci, funguje bez problémů v praxi.