Jednou z činností, které vás, jako seniorního vývojáře, mohou potkat, je dělání pohovorů s kanditáty, kteří by chtěli ve vaší firmě pracovat. Řekl bych, že je to docela zodpovědná (a zajímavá) činnost. Přece jenom, vybíráte své potencionální kolegy.Přesto bývá (dost často) tento úkol pojat nekoncepčně a nahodile. Pohovor dělá, kdo má zrovna čas, zkouší se věci, které s prací přímo nesouvisí, v rámci firmy to každý dělá "trochu" jinak... Tak jako v jiných oblastech, i zde je známkou kvality konzistence.
Před časem jsem psal, jak dělám java pohovor já, kde jsem popsal postup, který používám cca poslední dva roky. (Teď se změnou zaměstnání jsem v něm provedl dvě úpravy, o kterých napíšu, až si to trochu "sedne".) Jedním z bodů, který po vývojářích vždycky chci, je, aby mi před pohovorem poslali ukázku svého (java) kódu dle vlastního výběru. Pojďmě se na to podívat trochu zevrubněji.
Proč chci ukázku kódu?
Kromě úvodní informační části pojímám interview jako diskuzi. Je to diskuze mezi mnou - team leaderem, či architektem - a potencionálním kolegou. Své názory umím hájit, ale nejsem autoritativní - myslím, že nejlepší řešení vyrůstají z kvalitní diskuze.Kód, který mi kandidát pošle (a který pak spolu probíráme), je pro mne podkladem pro takovou diskuzi. V kódu si pomocí TODO označím místa, na která se chci zeptat. Jsou to místa, která mě nějak zaujmou - nejsou mi třeba jasný, jsou inspirativní, anebo je považuji za chybná. Nad tím pak diskutujeme.
Jak říkám, nejsem autoritativní, nemám dopředu připravený jedno řešení, které chci slyšet; takže pokud je kandidát schopen své řešení obhájit, je to skvělé. V pořádku je, i pokud přizná chybu, že něco není úplně OK, dneska by to udělal jinak apod. Špatným znamením je, pokud k tomu kandidát nemá co říct.
Je to podobný, jako bychom už byli spolu na projektu a diskutovali refactoring nějakého staršího kódu. Nebo dělali code review. Takže věc, kterou - pokud se staneme kolegy - budeme v budoucnu běžně dělat.
Dobré je, že nediskutujem nějaké moje řešení. Je to kandidátův přínos k diskuzi - on zná kontext kódu, on může poukázat na pěkný design, zajímavou implementaci, efektivní algoritmus. A nebo aspoň dobře odvedenou práci. Pamatujete? Je to kód dle vlastního výběru. Čili kandidát volí prostor k diskuzi. Protože nejde jen o tu diskuzi - také se ptám: Proč jste se rozhodl mi ukázat právě tento kód?
Ta otázka je důležitá. Občas lze narazit na kandidáty, kteří prostě "obcházejí pohovory". A stejně tak, jako nevěnují pozornost dané firmě (prostě jen hledají jakoukoliv práci), nevěnují pozornost ani kódu, kterým se prezentují. Přitom je to úžasná možnost představit se v dobrém/nejlepším světle a vystoupit z řady (jiných kandidátů).
Kde vzít kód?
Někdy se setkám s tím, že daný vývojář řekne něco ve smyslu: "Ale já žádný kód na ukázku nemám. A to co momentálně píšu na projektu, nemůžu/nesmím dát k dispozici třetí straně." To zdánlivě vypadá jako show-stopper. Ale není.Já samozřejmě nechci, aby někdo porušoval NDA. To je neetické. Ale i v takové situaci se dají věci řešit. Když se chce. V první řadě, je dobré si zjistit, co je předmětem NDA. Moje osobní zkušenost je, že to vývojáři většinou nevědí. Zkrátka "něco" podepsali. V takovém případě je dobré se zeptat někoho, kdo to ví.
Já když jsem chtěl ve své diplomové práci použít část práce, kterou jsem dělal pro tehdejšího zákazníka, tak jsem se jednoduše zeptal firemního právníka. Ten se podíval do příslušné smlouvy a řekl: "jo, můžeš to použít, akorát uveď zdroj. A pro jistotu, udělej tyhle anonymizační kroky: ..."
Čímž je řečena jedna možnost, jak to řešit. Ať už jste podepsali cokoliv, nikdo vás nemůže zbavit autorství vašeho kódu. A pokud kód "dostatečně" zanonymizujete, neměl by nikdo nic namítat. Otázkou je, jak určit, kolik to je "dostatečně". Nevíte-li, máte "tvrdé" smlouvy, máte pochybnosti - konzultujte.
Další možností je napsat nový kód. Cože?! Mám napsat nový kód? Práce navíc?! Jo, přesně tak. Chcete tu práci. Nebo ne? Já prostě chci vidět na pohovoru váš kód. Pokud nemůžete využít předešlou, nebo následující možnost, je to také jedna z cest. Já vám umožňuji prezentovat kód dle vašeho výběru. Tak napiště něco, co vás baví. A nemusí toho být moc. Nějaký návrhový vzor, vychytaný algoritmus, vyřešený problém, co vás před časem zaujal? To je ono! Myslím, že byste si to mohli užít. Pokud ne, asi jste se minuli povoláním. V tom případě... nemám zájem.
Nejjednodušší samozřejmě je, pokud nějaký kód, který můžete ukázat, máte k dispozici. Možná ho máte na GitHubu, Bitbucketu, nebo doma v kredenci. Třeba máte archiv minulých projektů, nebo schované nějaké prototypy. Každopádně máte něco, co se dá rovnou vzít a ukázat. Za takový kód se asi nebude stydět - nechali jste si ho přece z nějakého důvodu, ne? A tím se dostáváme k jádru tohoto článku.
Měl by mít vývojář portfolio?
Pokud přijdete (jako vývojář) někam na pohovor a přinesete s sebou ukázku své práce, buďte si jistí, že jste minimálně vystoupili z řady ostatních uchazečů. Téměř nikdo to totiž nedělá. A pokud vaše úkázky za něco stojí (nebo jsou dokonce excelentní ;-) je dost pravděpodobné, že jste ostatní kandidáty zastínili. To ještě neznamená, že to máte v kapse. Ale výrazně jste zvýšili svoji šanci na úspěch.Řeknu vám svůj příběh. Když jsem se ucházel o práci (java vývojáře) u svého minulého zaměstnavatele, byla to jediná firma, kterou jsem oslovil - líbila se mi a vybral jsem si ji jako místo, kde bych chtěl pracovat. Na pohovor jsem si (sám od sebe) přinesl ukázky svého kódu, screenshoty aplikací (tehdy jsem dělal hodně frontendů) a taky generovanou dokumentaci ke svým aplikacím. A krátce jsem svou práci u pohovoru představil. Nevím, jaký to mělo vliv na mé přijetí. Faktem je, že jsem dostal vyšší nástupní plat, než jsem si sám řekl.
Když jsem se ucházel o svou současnou práci, nepřinesl jsem si na pohor nic. (Ha!) Důvodem je, že jsem nehledal práci vývojáře. Resp. rád bych si trochu zakódoval (tak z 1/3), ale hlavně mě zajímala práce team leadera (vývojářů). A taky architekta. Takže místo ukázky kódu jsem dal na vrchol svého CV odkaz na svůj blog (kde o těchto věcech píšu) a u pohovoru jsem se snažil tyto témata prezentovat a čerpat z nich. Myslím, že to fungovalo :-)
Takže jaká je odpověď na titulní otázku? Je subjektivní a není jednoznačná. Ale já se kloním k názoru, že vývojář by portfolio mít měl. Za každého hovoří jeho práce. A ta není někde v CV nebo mezi slovy na pohovoru. Je v textovém souboru někde na disku. Je tam, nebo ne? ;-)
Obecne si myslim ze je nutne aby se lide zamysleli jak nejlepe se umet prodat a jakou formou. Je mnoho sikovnych lidi ale neumi to prodat, bud se stydi, netusi nebo jim to je tak trochu nejak jedno, protoze proste jen neco hledaji. Pritom staci jen trochu logicky uvazovat...
OdpovědětVymazatPekny clanek dekuji.
Moc hezký článek :-)
OdpovědětVymazatPokud by si toto přečetl před pohovorem každý kdo se v IT uchází o zaměstnání, tak by byl život hned krásnější :-)
Nikdy by mě nenapadlo žádat o práci vývojáře a neukázat při tom svůj kód. Přijde mi to natolik nesmyslné, že dokud jsem tohle nepřečetl, ani mě nenapadlo, že by to tak nedělali všichni.
OdpovědětVymazatMožná to závisí od dané domény. Dokážu si představit, že u startupu to může vypadat jinak (ovšem přímou zkušenost nemám). Ale v enterprise oblasti je to běžné, že po vývojářích kód nikdo nechce. Pohovory většinou vypadají jako přes kopírák: CV -> nejaký test -> HR.
Vymazata pak to vypadá jako na Microsu (just joking ;))
VymazatSouhlas, u pohovoru by měla být řeč o kódu. Ovšem setkal jsem se s tím, a jako konzultant jsem prošel hodně pohovorů, pouze dvakrát. Jednou to bylo u Google, i když to zrovna není povedená varianta.
OdpovědětVymazatJá si myslím, že o kódu/programování by měla být většina technického pohovoru (pokud poptávám vývojáře). Na mém pohovoru to dělá 2/3 celkového času - prvně kandidátův kód a pak moje zadání.
VymazatPřečetl jsem si znova tvůj článek o Googlu a musím říct, že ta část s "programováním" do Google Docs se mi dost nelíbí - čím dál víc se kloním k tomu a s nažím se to přizpůsobit, že lidi na pohovoru by měli dělat věci, které pak budou dělat i v práci. (A předpokládám, že u Googlu se normálně programuje v nějakém IDE ;-) Takže jak zadání, tak forma by tomu měly odpovídat.
Jak říkám, zrovna u Googlu to nebylo vhodně zvolené, u mě se tím shodili. Ale minimálně třeba FizzBuzz test, a to i na papír, by měl každý napsat.
VymazatČlánek určitě velmi zajímavý. My jsme to řešili tak, že jsme kandidátům ukázali část kódu (vývojář) nebo analýzy (analytik) a nechali uchazeče zhodnotit, co si o daném artefaktu myslí. Tím jsme se vyhnuli situaci, že musíme řešit nějaké NDA.
OdpovědětVymazatJinak určitě by mě zajímal i názor, jak se připravit na pohovor architekta. Tam je přeci jenom trochu delší doba, než člověk dokáže zjistit, jestli je uchazeč dostatečně kvalitní (pomineme-li nějaká obecná kritéria, pak je to asi dost o pocitu).
Tu část, kdy kandidát řešil můj kód/projekt jsem používal taky a následovala hned po části s jeho kódem. Teď jsem od toho upustil a posunul to o kousek dál (zatím nebudu konkrétní, potřebuju si to ozkoušet praxí). Důvod je, že je to dost statické, hodnotit/diskutovat nad něčím hotovým, uzavřeným. Ale určitě je to dobrá eventualita - pokud je ten příklad dobrý dá se na tom hodně poznat: úroveň seniority, smysl pro design, porozumění cizímu kódu/projektu, základní koncepty atd.
Vymazat(Roli) architekta jsem nikdy nepoptával, tak mi k tomu chybí zkušenosti. Ale dělal bych to dost podobně - chtěl bych po něm ukázku architektury, kterou navrhl a nad tím bychom diskutovali. Ideálně pokud by donesl nějaké UML. A pak bych si nachystal svoje zadání - návrh nějakého systému. Návrh by byl dost vágní, aby šel různě rozvíjet.
jak hodnotite variantu, ze nechteji vas kod, ale ze si vas u pohovoru primo otestuji napriklad se zeptaji na neco o datovych strukturach napr. binarni strom?
OdpovědětVymazatZnalost algoritmů a datových struktur je jednou ze ctností dobrého programátora. Ale ne nutně elementární - to se odvíjí od abstrakce jazyka. Daleko podstatnější to bude u C, méně Javy a minoritní třeba u Groovy. Obecně si ale myslím, že je dobré tyto věci znát.
VymazatJestli je to vhodná otázka (a třeba i jediná) záleží na kontextu pohovoru - bude implementace algoritmů a struktur běžnou součástí práce kandidáta? Pokud ne, tak je to vhodná doplňující otázka, ale neměl bych se rozhodovat jenom podle ní.
Shodou okolností jsem se s touhle otázkou nedávno dvakrát setkal. Jednak jsem ji sám dostal na pohovoru. Mám docela dobrou paměť, takže si pořád pamatuju věci, co jsme se učili ve škole v předmětu Algoritmy a datové struktury. Takže jsem to "z hlavy" odvykládal. Nicméně nikdy jsem nic takového neimplementoval.
Podobnou otázku dostal i jeden můj kolega a (prý) to nedopadlo moc dobře. Přitom je to člověk, na kterého můžu dát velmi dobrou referenci - odvádí kvalitní práci a je to efektivní problem solver. Nakonec byl přijat (možná i díky mé referenci), ale stejně tak mohl propadnout sítem. Takže v tomhle případě si myslím, že to nebyl vhodný (nebo dostatečný) způsob zjišťování znalostí.
Mám pocit, že autor příspěvku i některé komentáře možná trochu přeceňují význam pohovorů. Podle mě je důležitější, jak se kandidát osvědčí během zkušební doby. Pohovor by měl tedy především odfiltrovat kandidáty, u nichž by bylo zbytečné vůbec se zkušební dobou začínat (s ohledem na související finanční výdaje, papírování, čas atd.). Je určitě fajn zkoušet různě inovovat formu pohovoru, ale mnohem více se člověk doví, až z kandidáta opadne stres a snaha se předvést a zabředne do každodenního stereotypu :-)
OdpovědětVymazatJinak co se ukázkového kódu týče, posledních pár let jsem strávil prací na IS pro dvě velké korporace... A nedovedu si popravdě představit žádný výsek kódu (tvořeného vesměs týmem lidí), u něhož by mi stálo zato ho nějak anonymizovat a dolovat povolení z korporátních struktur. :-) Osobně bych tedy raději pro účel pohovoru investoval den a něco ad hoc sepsal.
Ano, plné kvality kandidáta se osvědčí ve zkušební době. To asi nikdo nebude rozporovat. Článek ovšem řeší jiné téma - jeden konkrétní aspekt v rámci pohovoru.
VymazatV podstatě bych mohl souhlasit s názorem, že "pohovor by měl odfiltrovat kandidáty, u nichž by bylo zbytečné se zkušební dobou vůbec začínat.". Ovšem neznám kontext tohoto komentáře, takže se obávám, že mám diametrálně odlišnou představu, jak by měl vypadat kandidát, se kterým "má smysl začínat zkušební dobu".
jak byste se zachovali kdyby prisel clovek s jasnymi referencemi v jinem jazyce/frameworku, ale ve vami pozadovanem by plaval. napriklad by chtel zmenit podobod?!
OdpovědětVymazatObčas se to stává a to rozhodování je velmi individuální. Otázka je, co to jsou jasné reference. CV snese všechno (LinkedIn taky). Ale předpokládám, že je seniorní v něčem jiném než v Javě.
VymazatV první řadě záleží, jak moc je ten jazyk jiný a jak přesvědčivé jsou důvody pro změnu. Pokud někdo dělá 7 let v .Netu a najednou chce jít na Javu, tak mě zajímá: proč - z mého pohledu jsou to zaměnitelné technologie a očekával bych určitý pokles seniority. Chápu, že někdo chce jít z PHP na Javu, nebo z Javy na Ruby. Některé "přestupy" ale nedávají na první pohled smysl, takže tomu chci porozumět.
Druhou věcí je, jestli je ten člověk opravdu v dané oblasti seniorní. To nejsem, na úrovni jazyka, schopen posoudit. Ale měly by vysvítat určité principy - jak je na tom s designem, nástroji, pracovními postupy, "společnými programátorskými základy" apod. A pokud opravdu seniorní je, jestli je ta jeho seniorita přenositelná do oblasti, kterou potřebuji já. Já občas říkám: (programovací) jazyk se člověk naučí za 3 dny, nějaký framework za 3 měsíce (až 1/2 roku). Ale landscape se bude učit minimálně 3 roky. A pokud má něco takového za sebou, mělo by to být znát. Takže pokud např. dělal v objektovém jazyce s ORM, tak mě nezajímá, že neumí Hibernate, ale že těm principům ORM rozumí. To je přenositelné (a základy Hibernatu se "naučí" za týden ;-)
No a třetí věcí je, jestli má takový člověk rozumný finanční požadavky (rozumný = ukotvený v realitě). Pokud si někdo řekne plat seniora, ale z mého pohledu je v nové technologii junior a zároveň nevidím potenciál dostat se rychle na seniorní úroveń i v novém jazyce, tak bohužel. Ale to už je v podstatě jiný problém a sice jak reálně lidi odhadují svoji senioritu.
Jinak výše řečené se týká přechodu z jazyka/plaformy. Pokud není v požadavku konkrétní framework, tak mě to většinou nezajímá, pokud dotyčný zná nějaký ekvivalent.
VymazatČili když chci webovou Javu, tak očekávám, že bude znát servlety, ale je mi jedno, jestli zná Spring nebo Java EE. Pokud chci komponentový frontend, tak je mi jedno, jestli jsou to JSF, Vaadin, nebo Wicket. A nebo třeba Flex. Od určité míry abstrakce jsou tyhle věci zaměnitelné, ale stojí na stejných principech.
A to je to, co mě zajímá, jestli kandidát umí. Protože základy nového frameworku se naučí za chvíli. Ale pokud uměl správně používat ten starej, tak je dost pravděpodobný, že bude dobře používat i ten nový. A naopak.
Preco cakat na kvalitneho developera ktory "pride sam, len to chce cas", ked na www.freelancer.com sa da vybrat podla skusenosti s technologiami, lokality aj ceny? Je tento sposob najimania kolegov nevhodny?
OdpovědětVymazatNe každá práce je vhodná pro kontraktory. Navíc nemusím najímat vývojáře na konkrétní projekt. A například u nás, nám najímání kontraktorů zapovídá firemní politka (i když to snižuje naši flexibilitu při alokování na projekty).
VymazatDalší věcí je, že "výběr podle zkušenosti s technologiemi" mi nemusí stačit. Co třeba při pohovoru zajímá mne, je cultural match. A nezajímá mne jenom "aktuální snapshot technologií", ale snažím se udělat projekci do budoucna (= potenciál).
Jinak pokud chci najmout kontraktory, tak je to způsob zcela běžný - prostě je seženu kdekoliv :-)
Vymazat