Jak mluvit s klientem o termínech, aniž byste slibovali nemožné

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é.

Běžná chyba je posílat stejný životopis do všech firem. Místo toho si každou firmu projděte a zjistěte, jaké technologie používá. Pokud hledají React a vy máte zkušenost s Vue, napište, že jste se s Reactem už setkali, a připravte si pár otázek nebo postřehů. Personalisté ocení, když ukážete zájem o konkrétní firmu, ne jen hromadnou odpověď.

Na závěr si zapamatujte, že UI/UX není jen práce designéra. Je to společný jazyk, kterým mluvíte s týmem, ale i s uživatelem, pro kterého produkt tvoříte. Když při kódování přemýšlíte o tom, proč je prvek tam, kde je, a jak se uživatel dostane k cíli, stáváte se lepším vývojářem i partnerem v týmu. Začněte malými kroky – proveďte si audit stávajícího kódu, najděte nekonzistence a navrhněte opravu. Taková snaha se vyplatí nejen na projektu, ale i v rozvoji vašich vlastních dovedností.

Na závěr nezapomeňte testy pravidelně spouštět a sledovat, jak se chovají. NUnit integruje s CI nástroji, takže testy můžete automaticky pouštět při každém commitu. Pokud testy začnou selhávat, je důležité zjistit příčinu co nejdříve. Vždy čtěte výstup testů – obsahuje informace o tom, která očekávání nebyla splněna. Po napsání testů se zamyslete, zda nepokrývají všechny důležité scénáře, včetně okrajových případů, jako jsou prázdné vstupy, maximální hodnoty nebo výjimky. Dobré testy vám dají jistotu při úpravách kódu a výrazně zkrátí dobu hledání chyb.

Nejdřív si ujasněte, jakou technologii chcete dělat. Není nutné umět všechno, ale měli byste mít solidní základ v jednom jazyce – ať už je to JavaScript, Python, Java nebo C#. Ideální je vybrat si oblast, která vás baví: webové aplikace, mobilní aplikace, backend, data nebo třeba testování. Pokud nevíte, začněte u webu – je to nejdostupnější a nejvíce žádané. Projděte si několik tutoriálů, vytvořte si vlastní projekt a hlavně ho dokončete. Nedokončené projekty jsou nejčastější chybou začátečníků.

Komunikace odhadů času patří k nejcitlivějším momentům spolupráce. Zákazník chce jasný termín, vy ale víte, že se může cokoliv změnit. Základem je rozlišovat mezi pojmy „odhad" a „závazek". Odhad je pracovní hypotéza, závazek je pevný slib. Pokud obojí smícháte, dříve nebo později narazíte. Místo slov „bude hotovo" používejte „předpokládám" nebo „odhaduji". Tím dáváte najevo, že časový údaj není věštěním z křišťálové koule, ale výsledkem analýzy.

Mezi časté chyby začátečníků patří posílání obrovských pull requestů, které mění mnoho věcí najednou. Takové změny se obtížně kontrolují a často končí zamítnutím. Rozdělte práci na menší, logicky ucelené části – každý pull request by měl řešit jeden problém. Dále se vyhněte tomu, abyste se snažili vyřešit všechno najednou, nebo abyste měnili věci, které s daným problémem nesouvisí. A pozor také na to, abyste nezasahovali do cizích pull requestů bez vyzvání – počkejte, až vás maintainer požádá o spolupráci.

Jak na první pohovor a co si připravit Když máte hotový projekt, je čas začít posílat životopisy. Životopis by měl být stručný – ideálně jedna stránka. Pište do něj jen to, co souvisí s IT: používání Git, znalost konkrétních technologií, odkazy na váš GitHub nebo portfolio. Nepište věci jako „umím pracovat v týmu" – to je fráze. Místo toho uveďte konkrétní příklad, kdy jste něco spolupracovali nebo řešili problém. Školy a kurzy uvádějte, ale nechte je na konci.

Pozor také na přístupnost, kterou vývojáři často podceňují. Nejde jen o povinnost, ale o praktickou funkčnost. Uživatelé se zhoršeným zrakem, pohybovým postižením nebo jen s modrým filtrem na obrazovce ocení, když dodržíte kontrastní poměry, nastavíte správné alt texty u obrázků a umožníte ovládání klávesnicí. Typická chyba? Spoléháte na to, že stačí barevně odlišit tlačítko, ale ignorujete, že barevně slepý uživatel nerozpozná, že je aktivní. Přidejte ikonu nebo textovou změnu kromě barvy, a problém je vyřešen.

První commit: od návrhu k přijetí Než začnete psát kód, založte si vlastní větev (fork) a v ní vytvořte samostatnou větev pro vaši změnu. Postupujte podle pokynů v dokumentaci – pokud tam není řečeno nic jiného, držte se stylu kódu, který už v projektu existuje. Napište testy pro novou funkci a ověřte, že všechny stávající testy procházejí. Commitové zprávy pište stručně a výstižně – popište, co děláte a proč, ne kopírujte celou diskuzi z issue. Po odeslání pull requestu se připravte na to, že maintaineři mohou požadovat úpravy. To je normální součást procesu, neznamená to, že vaše práce je špatná.