Aktuálně mám několik čerstvých zkušeností z opačné strany interview, tak bych se chtěl podělit o své dojmy. Na (Java) pohovoru jsem nebyl již několik let, v podstatě od "krize", kdy jsem si testoval stav trhu :-) a musím říct, že to byla zajímavá profesní zkušenost.
Budu diskrétní, takže nebudu prozrazovat konkrétní zadání a ani nebudu jmenovat jednotlivé firmy. Pro lepší představu pouze uvedu, že ve všech případech šlo o nadnárodní korporace, kde je běžným komunikačním jazykem angličtina. Také se budu věnovat pouze technickým kolům pohovorů, tzn. že různé HR a psychologické srandičky si odpustím.
No, a protože moje paměť je děravá a výběrová, zaměřím se pouze na signifikantní rysy daného pohovoru. Taky vynechám takové ty běžné věci, jako je probírání projektů nad CV.
Co bych předeslal, že měly všechny pohovory společné:
- nikde po mně nechtěli vidět můj kód,
- nikde po mně dopředu nechtěli nějakou specifickou přípravu
- a nikde po mně (naštěstí) nechtěli psaní testů.
Algoritmy na white boardu
Tohle byla taková algoritmová klasika - měl jsem (za předpokladu, že neexistují Java Collections) naimplementovat spojitý seznam. S povděkem jsem si vzpomněl na školní předmět Algoritmy a datové struktury a i po těch cca šesti letech vydoloval celkem slušnou implementaci.
Implementace probíhala na whiteboardu, doplňovaná diskuzí. Debata byla uvolněná a nebazírovalo se na termínech. Výhodou whiteboardu je, že kromě kódu se dají kreslit různé pomocné schématka apod., nad kterými se dá dále diskutovat. A je to takové agilní :-)
Závěr: tohle je celkem příjemná metoda pohovoru, která ale staví na více méně fixních a teoretických znalostech. Navíc tam není moc prostoru pro invenci. Schválně, kolikrát už jste (v Javě) implementovali nějaký základní algoritmus a kdy jste naposledy vymysleli nějakou novou metodu sortování? Nicméně, pokud člověk nepřijde nabiflovaný algoritmy, dá se touto metodou sledovat, jak uvažuje a dobírá se řešení.
"8 let."
Jak dlouho máte zkušenost s JSF?"
"Rok a půl."
"Musíme to zaokrouhlit na celý roky."
"OK, tak rok."
Na začátku tohohle interview byl seznam asi patnácti technologií, kdy jsem měl říct, jak dlouhou s nima mám zkušenost. Zkušenost musela být vyjádřená v celých rocích. Pak jsme jednotlivé technologie procházeli pomocí kontrolních otázek.
Např. u Java Core to byl vztah metod equals a hashCode. U JPA tři způsoby dotazování (JPQL, Criteria API a native SQL) apod. Platné byly pouze zkušenosti z projektů. Např. to, že mám Flex certifikaci a navrhoval jsem architekturu, kde byl Flex jako frontend, nic neznamenalo (člověk by řekl, že aspoň jednooký mezi slepými králem).
Závěr: pro mne jednoznačné nejhorší zkušenost - člověk je jenom souhrnem aktuálních znalostí, vůbec se nepočítá s nějakým potenciálem, schopností řešit problémy, vymýšlet řešení apod. Navíc ten checklist mi přijde hrozně zavádějící: když jsem Spring Security použil na dvou projektech v délce cca 3 let, ale čisté práce na něm bylo maximálně 3 týdny (konfigurace plus nějakej ten custom handler) - jak dlouhou zkušenost mám s touto technologií?
Druhý příklad se týkal návrhu rozhraní a ev. jeho implementace. Zadání bylo (schválně) velmi volné a strohé, aby podnítilo přemýšlení a diskuzi. Požadavek byl pro mne lehce cizokrajný a příslušná (zevrubná) diskuze mne celkem obohatila (i když výsledné řešení bylo celkem konformní).
Závěr: tohle interview se mi profesně líbilo nejvíc - šlo nejvíc do hloubky, testovalo jak znalost algoritmů, tak přemýšlení nad nejednoznačným problémem. Čili otestovalo jak základní znalosti, tak myšlenkový potenciál.
Mmch. před časem psal o otázkách při pohovoru Banter.
Implementace probíhala na whiteboardu, doplňovaná diskuzí. Debata byla uvolněná a nebazírovalo se na termínech. Výhodou whiteboardu je, že kromě kódu se dají kreslit různé pomocné schématka apod., nad kterými se dá dále diskutovat. A je to takové agilní :-)
Závěr: tohle je celkem příjemná metoda pohovoru, která ale staví na více méně fixních a teoretických znalostech. Navíc tam není moc prostoru pro invenci. Schválně, kolikrát už jste (v Javě) implementovali nějaký základní algoritmus a kdy jste naposledy vymysleli nějakou novou metodu sortování? Nicméně, pokud člověk nepřijde nabiflovaný algoritmy, dá se touto metodou sledovat, jak uvažuje a dobírá se řešení.
Checklist technologií
"Jak dlouho máte zkušenost s J2EE?""8 let."
Jak dlouho máte zkušenost s JSF?"
"Rok a půl."
"Musíme to zaokrouhlit na celý roky."
"OK, tak rok."
Na začátku tohohle interview byl seznam asi patnácti technologií, kdy jsem měl říct, jak dlouhou s nima mám zkušenost. Zkušenost musela být vyjádřená v celých rocích. Pak jsme jednotlivé technologie procházeli pomocí kontrolních otázek.
Např. u Java Core to byl vztah metod equals a hashCode. U JPA tři způsoby dotazování (JPQL, Criteria API a native SQL) apod. Platné byly pouze zkušenosti z projektů. Např. to, že mám Flex certifikaci a navrhoval jsem architekturu, kde byl Flex jako frontend, nic neznamenalo (člověk by řekl, že aspoň jednooký mezi slepými králem).
Závěr: pro mne jednoznačné nejhorší zkušenost - člověk je jenom souhrnem aktuálních znalostí, vůbec se nepočítá s nějakým potenciálem, schopností řešit problémy, vymýšlet řešení apod. Navíc ten checklist mi přijde hrozně zavádějící: když jsem Spring Security použil na dvou projektech v délce cca 3 let, ale čisté práce na něm bylo maximálně 3 týdny (konfigurace plus nějakej ten custom handler) - jak dlouhou zkušenost mám s touto technologií?
Algoritmy a rozhraní
Na tomto pohovoru jsem dostal dva příklady. První se týkal "jistého" vyhledávacího algoritmu, implementovaného pomocí dvou zanořených cyklů (mmch. jediný kód, byť na papíře, který jsem na pohovorech viděl). Měl jsem určit, jestli algoritmus pracuje vždy správně, jaká je jeho složitost, jak by se dal optimalizovat, jaká bude jeho složitost po optimalizaci atd.Druhý příklad se týkal návrhu rozhraní a ev. jeho implementace. Zadání bylo (schválně) velmi volné a strohé, aby podnítilo přemýšlení a diskuzi. Požadavek byl pro mne lehce cizokrajný a příslušná (zevrubná) diskuze mne celkem obohatila (i když výsledné řešení bylo celkem konformní).
Závěr: tohle interview se mi profesně líbilo nejvíc - šlo nejvíc do hloubky, testovalo jak znalost algoritmů, tak přemýšlení nad nejednoznačným problémem. Čili otestovalo jak základní znalosti, tak myšlenkový potenciál.
Moje otázky
Na všech pohovorech jsem se hodně ptal a strávili jsme mýma otázkama poměrně dost času. Měl jsem vždycky připravenou stejnou sadu otázek:- Jaká je struktura společnosti?
- Jak velké je oddělení, kde bych pracoval?
- Jaký je budoucí kolekiv?
- Kdo bude můj šéf a uvidím ho na některém kole pohovoru?
- Jak vypadá moje budoucí pracoviště?
- Jakým způsobem jsou vedeny projekty?
- Jaké se používají metodiky?
- (obligátní) Jaké se používají technologie?
- Jaké podpůrné technologie se používají (Continuous Integration, Issue Tracking, Version Control)?
- Funguje nějaký osobní rozvoj (školení atd.)?
- Jak budou vypadat další kola pohovoru?
Mmch. před časem psal o otázkách při pohovoru Banter.
Jak se dalo čekat, na trhu je to bída. Vybral jsi něco? Zajímávé otázky, zařadím na svůj seznam.
OdpovědětVymazatKe spojitému seznamu atd. Skutečně je největší slabinou korporátních programátorů to, že neumí setřídit kolekci? Ulehčují si práci, protože se to snadno zkouší a mají pak dojem, že se rozhodli na základě objektivních faktů. Navíc ptát se někoho na vztah hashcode a equals je sice elementární, ale zrovna tohle prokazuje certifikace, ne? Neplýtvají tak svým časem?
Vybral, ale zatím budu diskrétní (i vzhledem k tomu, co jsem psal výše). Za dva měsíce to budu mít na LinkedInu.
VymazatTo je obecná slabina většiny pohovorů, že testují základní a nízkoúrovňové znalosti a nezabývají se nadstavbou nad nimi, což je daleko důležitější.
A je to stejný jako s těma certifikacema - SCJP je jenom předpokladem pro ty zajímavější certifikace, které už ale dělá jenom minimum lidí.
Me prijde spis ta certifikace jako plytvani casem, viz http://stackoverflow.com/a/990602/581205 . Naopak s EQHC se da vyblbnout: co vede k chybam, co k pomalosti, jaka je slozitost, co se se slabym HC da delat kdyz jsou objekty Comparable, atd. Navic to je dotaz nezavisly na jazyku.
OdpovědětVymazatNedavno jsem s odrenyma usima absolvoval jeden desne dlouhy pohovor a libilo se mi na nem ze se snazili zjistit jak premyslim. To ale moc neslo protoze jsem ke vsemu co chteli uz neco podobnyho videl a hlavne protoze mi to vubec nemyslelo. Z otazek jsem mel radost, nezajimaly je zadne technologie, vychazi se z toho ze se stejne nevi co bude kdo za rok dva delat a potrebne veci je mozno se doucit.
Díky za odkaz, výborná diskuze. Myslím, že jsou tam pěkně shrnutý pro a proti. Mě nejvíc konvenuje tenhle názor.
VymazatAle zpátky k mému interview. Podle mne by správná otázka tazatele měla znít: Proč jste si dělal tu certifikaci, když ve Flexu neprogramujete? Nebo: Proč vám zaměstnavatel tu certifikaci zaplatil?
Souhlasím s tím, že je dobrý se (při pohovoru) nevázat na konkrétní technologie. Ale úplně bez nich to taky nejde - technologie totiž představují určitý kontext. Technologie je nástroj, který funguje v určitém prostředí. Já vždycky říkám, že nový jazyk se naučím za 3 dny. Ale naučit se (a pochopit) celý landscape, který je kolem toho vystavěný, trvá 3 roky.
Nj, já mám taky zkušenosti s anglickými firmami a jsou podobné. Nezajímá je co umím, co jsem se naučil sám, ale to, s čím mám praxi a taky zaokrouhlená na roky. Potom mě jako testera zkoušeli z toho, co je to shalow a deep copy v javě. No a divili se, když jsem jim řekl, že tohle sice vím, ale pokud to budu potřebovat na té pozici, tak jsme si fakt nerozumněli. Šel jsem na testera (něco mezi test analytikem a manažerem) a je vůbec nezajímalo nic z testování, klasifikace rizik, výkonnostní testy nic. Jenom mě zkoušeli z javy.
OdpovědětVymazatHm, to zní jako dost tristní zkušenost.
VymazatNa druhou stranu, ono je dost těžké ten pohovor připravit - jak to budu dělat, jaké od toho čekám výsledky atd. Myslím, že většinou to lidi moc nepromýšlí. Dost často dělá technický pohovor nějaký senior, který má zrovna čas a takhle nahodile se dost špatně drží konzistence. O cílevědomém zlepšování ani nemluvě.
Zaujimave skusenosti! Skusim sa aj ja podelit: U nas robim pohovor na Javistu tak hodinka diskusia + prakticka cast - podla sikovnosti programatora tak 1-2h. Najprv porozpravam o nasich projektoch, opisem technologie. Potom prejdeme uchadzacovo CV a sledujem ake ma skusenosti, co mi vie povedat a o predchadzajucich projektoch, ake technologie ho zaujali. Potom mame pripraveny list otazok (asi 150, napisal som ich pocas jednej dlhej cesty Praha-Slovensko) a snazime sa vyberat otazky ktore sedia na uchadzacove CV a nase projekty. Inymi slovami, snazim sa najst v com je uchadzac dobry a ako by sa hodil do teamu - nedavame otazky z toho co vobec nevie, nech nie je zbytocne nervozny. Whiteboard testy som zrusil - podla mna je to strestujuce a pomale a take neohrabane. Namiesto toho dame uchadzacovi laptop, nechame ho vybrat si IDE a dame mu internet (moze pouzivat Google a StackOverflow - co len chce) a dame mu vyriesit nejaku pragmaticku (vytiahnut nejake data z DB, nieco s nimi urobit) ulohu (algoritmizaciu moc neskusam - staci mi ak clovek vie kedy ma pouzit ArrayList, LinkedList, HashSet atd.). Samozrejme uchadzac vzdy dostane priestor na otazky - cim viac a konkretnejsie sa pyta tym je mi to sympatickejsie. Niektori len tak kyvnu plecami ako keby im bolo UPLNE jedno kde budu pracovat - toto nepochopim ...
OdpovědětVymazatDěkuji za názor.
VymazatTo je výborný nápad, dát kandidátovi notebook a IDE. Taky jsem nad tím přemýšlel, ale bohužel jsem to nikdy nedotáhl do konce. Představoval jsem si, že by například mohl napsat nějaké unit testy k existujícímu kódu (a třeba i nějaký refactoring), nebo naimplementovat nějaké rozhraní.
To s těmi uchazeči, kterým je jedno, kde budou pracovat, trochu chápu. Alespoň v enterprise oblasti, pokuď se nejdená o nějaká zvučná jména, jsou firmy dost zaměnitelné a inzaráty se podobají jako vejce vejci. Takže pokud nemá člověk nějaké (nejlépe interní) reference, tak se stejně rozhodne na základě zpracovaných dojmů z pohovoru a hlavně osobní zkušenosti (ale to už je přijatý). Lepšim řešením je, samozřejmě, si dopředu vytipovat firmy, kde bych chtěl pracovat, ale to není vždy možné a tak přichází "průzkum bojem".
Ten spojovy seznam davaji na pohovorech obcas kolegove ;-). Osobne to nemam moc rad, cloveka to stresuje, alespon me by to stresovalo. Kdyz jdu na pohovor ja, davam prakticky priklad. Je to takovy workshop, kde se snazime s uchazecem najit vhodne reseni problemu, na ktery by u nas mohl narazit. Cilem je poznat, jak dany uchazec premysli. Doplnujici otazky vyplavou na povrch postupem casu. Docela me prekvapilo, ze i lide u kterych bych nevahal ani minutu, meli problemy. Proste chci rici, ze kazdemu (z pohledu zajemce o praci) vyhovuje nejaky zpusob. Snadno se pak stane, ze nekoho kvalitniho minete, protoze mu dany typ nesedi. Osobne bych tedy ty whiteboardy, notebooky a IDE neprecenoval a spolehnul se na intuici. Chapu, ze se to tezko nejak kvantifikuje, ale pokud si clovek projde nekolik desitek pohovoru, tak pozna jestli proti nemu na druhe strane sedi bullshitar a nebo nekdo kvalitni.
OdpovědětVymazatPokud člověk dělá pohovorý častěji, tak si vypracuje nějakou metodu/nástroj. Řekl bych, že je důležité, aby byl konzistentní a v duchu lean/kanbanu to postupně zlepšoval. Úskalím je, že pokud to má člověk v režii, tak si to nastaví podle sebe a pak mu můžou úspěšně vycházet lidé, kteří jsou mentálně podobní. Ale možná, že je to tak správně - protože většnou hledáme někoho, kde zapdadne (do firmy, do týmu).
VymazatTo s tou intuicí - mám stejný pocit :-) jak se říká: some people just click.