10 otázek, které položit budoucímu zaměstnavateli

Přijímací pohovory jsou až příliš často pod taktovkou zaměstnavatele. Dokážete zvládnout tohle množství práce? Jaké jsou vaše silné a slabé stránky? Jak vnímáte tuto stránku našeho podnikání?

Na konci pohovoru pak ale nemáte dost informací o tom, jestli se vám v práci bude líbit a projekty vás budou bavit. Kolik znáte vývojářů nebo dizajnérů, kteří někde pracovali méně než rok? Méně než 9 měsíců? Vsadím se, že jich bude dost.

Připravil jsem pro vás několik otázek, které byste se měli zeptat předtím, než se rozhodnete zavázat podstatnou část vašeho života některé firmě.

1) Jak vyvíjíte software? Říkáte o sobě, že jste “lean”, “agile” nebo “scrum”?

Tohle může samo o sobě rozhodnout o přijetí nebo odmítnutí nabídky. Pokud pracovní procesy ještě nebyly alespoň trochu formalizované, tak se může stát, že nastoupíte na pozici, kde vaším hlavním úkolem bude řízení chaosu. To, že si společnost myslí, že dělají “lean” nebo “agile”, může znamenat že vkročíte do rozumně nastaveného procesu. Taky to ale může znamenat, že strávíte polovinu vašeho času na schůzích, kde se pomocí balíčků karet přiřazují problémům náhodné odhady časové náročnosti.

Není tedy důležité, co přesně vám odpoví. Jde o to, aby už bylo učiněno vědomé rozhodnutí, jak má být vývoj organizovaný, a aby vám tento vybraný způsob přišel smysluplný. Pokud při popisu zní příliš mnoho buzzwords, tak zvyšte ostražitost.

2) Jak spolupracují dizajnéři s vývojáři?

Hážou dizajnéři návrhy stránek a obrazovek přes zeď jako nařízení, co a jak musí vypadat, nebo existuje prostor pro spolupráci a iterování? Má váš budoucí zaměstnavatel vůbec nějaké dizajnéry?

Vývojáři navrhující uživatelské rozhraní jsou téměř určitě znamením, že uživatelská přítulnost není pro firmu důležitá a většina produktů je nejspíš k ničemu. Pokud narazíte na hodně dobrého produkťáka se smyslem pro dizajn, tak můžete mít štěstí, ale jinak většinou každý střílí od boku a na výsledném produktu to je znát.

3) Jakou úroveň má automatizované testování? Průběžná integrace (Continuous Integration)?

Automatizované testování může být super. Já sám používám automatizované jednotkové/integrační/akceptační testy pro všechny produkty, které vyvíjím. Tyto testy tvarují rozhraní a dělají kód udržovatelným v dlouhodobém horizontu. Můžete však narazit na extrémisty z obou protipólů.

  1. My nemáme testy.

    Odejděte. Jinak vás čeká ošklivé setkání s miliónem řádků kódu, kde jenom původní autoři měli šanci dělat změny a nerozbít při tom produkt. Vina za zavlečení chyb však padne na vás.

  2. Náš kód má 100% pokrytí testy

    Kecy. Anebo většina testů kontroluje volání privátních metod, nic neověřuje, případně aplikuje jiné fígle na dosažení 100% pokrytí testy. Pokus o libovolnou změnu v aplikaci buďto rozbije všechny testy anebo nerozbije nic. Oba výsledky jsou nebezpečné. A vina za rozbití testů padne samozřejmě na vás.

4) Na čem *přesně* budu pracovat? Jaký je váš tech stack?

Pracovní nabídky jsou notoricky známé tím, že neříkají pravdu, aby přitáhli zájem vývojářů. Často se stává, že ve firmě je jeden člověk, který má jako koníček technologii X, takže ji uvede v popisu pozice i když s ní vůbec nesouvisí. Například:

“Požadujeme zkušenosti s Ruby on Rails, vývojem pro iOS, HTML5 a Node.js…, znalost Perlu je výhodou.”

Ve skutečnosti to znamená:

“Většinu času budete udržovat serverovou aplikaci o dvou miliónech řádků Perlu. Chci to všechno přepsat do Rails a líbí se mi iOS, ale to vlastně nikdy nebudeme dělat.”

5) Jakou velikost mají vaše týmy? Jak velký bude můj tým?

Horu Fuji se vám nepovede přesunout, ať jste sebevíc chytřejší. Pokud jsou velikosti týmů malé a počet týmů není vysoký, tak je poměrně velká šance, že můžete přednést rozumné argumenty a opravit problémy v organizaci vývoje nebo uvnitř týmu. Ve velké organizaci narazíte na struktury optimalizované pro blokování změn. Změny jsou děsivé a doteď jsme byli svým způsobem úspěšní i se současným procesem a 100/200/1000 lidmi. Proč bychom měli potřebovat cokoliv měnit? Vy jste jediný, kdo vybočuje z normálu, takže tím problémem jste vy sám. V menším týmu nemůžete výrazně vybočovat z normálu, protože normál je z velké části definován taky vámi.

6) Je možnost pracovat vzdáleně (z domu)?

Nemusíte ani chtít pracovat vzdáleně, nebo pracovat vzdáleně podstatnou část času. Přesto tuto otázku položte.

Proč? Tohle je přímý ukazatel toho, jestli zaměstnavatel požaduje pracovní výsledky nebo živé těla na židlích. Doopravdy chcete pracovat tam, kde zaměstnanec trávící v kanceláři deset hodin denně (většinou brouzdáním internetu a zbytečným schůzováním) je ceněn více, než člověk produkující 2-10x víc než on? Jasně že ne. Některé odvětví mají podivné legislativní důvody pro to, aby vyžadovali přítomnost všech na pracovišti, takže to je jedno z možných ospravedlnění pro zákaz práce na dálku. Ve velké většině případů však platí, “každý musí být v kanceláři” === “záleží nám víc na přítomnosti v práci než na výsledcích”.

7) Máte základní pracovní dobu?

Pokud je pozice ze po všech stránkách perfektní, ale nenechává vám prosto vyzvednout děti, zajít si do posilovny nebo navštěvovat každý týden čtenářský kroužek, bude to pro vás fungovat? Pravděpodobně ne. Pokud jednáte se zákazníky, potřeba pokrýt určitý časový úsek není nepřiměřená, ale pořád je možné mít pružné pravidla pro základní pracovní dobu. Přísné lpění na základní pracovní době může znamenat, že většina pracovních procesů je synchronních (místo asynchronních), což striktně omezí vaši schopnost udělat vaši práci. Zkuste tady víc vyzvídat a zjistěte si, proč přesně firma vyžaduje základní pracovní dobu a co to o ní vypovídá.

8) Proč nabíráte nové lidi? Jedná se o nový produkt? Růst? Náhradu za někoho, kdo nedávno odešel?

Vysoká fluktuací poukazuje na to, že v organizaci je něco špatně. Může to být špatné finanční ohodnocení, nerovnováha mezi pracovním a soukromým životem, jedovatá firemní kultura, atd. Jestli někdo odešel, zjistěte proč. Pokud společnost roste, tak se vám můžete stát, že nastoupíte do firmy se sto zaměstnanci, o které jste si mysleli, že jich má jenom dvacet.

9) Jakou nejzajímavější věc jste tady vy osobně vytvořil(a)?

Rád pracuji na produktech, které se dostanou k zákazníkům. Některé společnosti ne. Zjistěte si, jaký byl poslední úspěšný produkt, na kterém pracoval člověk vedoucí pohovor, a kdy se dostal do rukou zákazníkům. Řekne vám to, jestli firma dodává po malých přírůstcích nebo alokuje obrovské rozpočty na projekty, které selžou. Na kolika projektech, které se nikdy nedostali k zákazníkům, jste pracovali vy? Jak jste se cítili, když byl projekt ukončen?

Dotazem na nejzajímavější věc se dozvíte, jestli jsou zaměstnanci hrdí na svoji práci. Programátor nebo dizajnér se rád rozpovídá, pokud vytvořil něco alespoň trochu zajímavého, co se líbilo zákazníkovi. Ten samý pocit hrdosti chcete nejspíš prožívat taky.

Dejte si pozor na “Napsal jsem interní nástroj, který…” nebo “Přepsal jsem open-source nástroj, protože…”. Někteří vývojáři si rádi honí ego znovu-vynalézaním kola a mrháním firemních peněz na projekty, které nejsou úplně potřebné nebo užitečné pro firmu jako celek. Pokud má někdo pocit, že potřebuje přepsat kompilátor, tak je pravděpodobně blázen a téměř určitě na omylu.

10) Co byste si přál vědět o vašem zaměstnavateli předtím, než jste sem nastoupil? Jaké jsou nejhorší stránky této práce?

Žádná organizace není ideální, všude jsou nějaké problémy. Přestaňte si nalhávat, že existuje dokonalý zaměstnavatel — neexistuje.

V dobré společnosti se lidi vedoucí pohovor nebudou bát být úpřimný a mluvit o špatných stránkách. Když se někdo nebojí poukázat na problém, pak tento problém může být vyřešen. Žádný vztah, společnost nebo produkt není dokonalý. Přístup k řešení problémů definuje, jestli vás chození do práce bude ubíjet nebo povzbuzovat. “Dnes se musím zase zabývat X. Posraný život.” nebo “Dnes můžu zkusit opravit X. Dnes je den, kdy tento problém vyřešíme navždy.”

Ve špatné společnosti vám řeknou “Mojí největší slabostí je příliš silný perfekcionizmus”. Tohle jsou možnosti:

  1. Člověk, který vede pohovor, vám lže, aby vás navnadil přijmout nabídku. Vědí, že změna práce je velice nákladná a nepříjemná, takže počítají s tím, že u nich po nástupu uvíznete.
  2. Člověk, který vede pohovor, se bojí být úpřimný. Našli jste kulturu mlčení, a měli byste být radši připraveni sklonit hlavu a ignorovat problémy.
  3. Poslední možností je ta, že dotyčný uvěřil hezkému obrázku prezentovaného firmou. Je to stejně špatné jako lhaní, jenom si neuvědomují, že lžou. Jestliže povinný 80-hodinový pracovní týden nepřijde nikomu jako problém, tak radši odejděte. Jinak se sami stanete obětí vymývaní mozků, anebo budete spolupracovat s lidmi, kteří si neuvědomují problémy kolem sebe.

Ne všechny společnosti jsou špatné, je však důležité vědět, do čeho jdete. Náš čas na této planetě je omezený, a vy ho nechcete promrhat kopáním jámy se skloněnou hlavou.

Závěrem

Jaké jsou vaše oblíbené otázky při hledání práce? Podělte se o ně v komentářích.

Pokud vás zajímá problematika hledání práce, přečtěte si taky jak si najít práci v zahraničí.

Tento příspěvek je volným překladem z anglického originálu 10 questions to ask your potential employer, který publikoval Stefan Kendall.

12 thoughts on “10 otázek, které položit budoucímu zaměstnavateli
  1. Ptám se, jak vypadá kancelář, kde budu sedět – nejlépe, pokud to rovnou ukážou. Zajímá mě, jestli dostanu žádný/jeden/dva externí monitory a jestli je prostředí pro mě dostatečně pohodlné (ano, jsou stále firmy, které neumí hned při nástupu dát vývojáři externí monitor za 3k).

    Příště se zeptám i jak často chodí zaměstnanci na školení, jestli mi zaplatí cestu na vhodnou konferenci apod.

  2. Diky za clanek :-)

    Ja bych se zeptal, jestli maji nejakou formu QA a co to pro ne znamena. Jooo testujeme zpravidla znamena … no, proste nic dobreho, takze bych si chtel promluvit s tymem/zajit snimi na obed a popovidat si jak testuji, jak to vnimaji a co jim to prinasi. Pak bych si chtel promluvit primo s testerem i Idealne s QA Leaderem, abych zjistil jakou maji strategii a jakou mentalitu, zdali to nedelaji jen proto ze to delaji a kde se v ramci svych strategii s testingem vydi za 2roky a jak toho chteji dosahnout. No a pak bych chtel videt testy, etc.

    Myslim si, ze je to vzajemny a mocny zpusob jak poznat firmu a tym a zaroven si muzou udelat i obrazek o vas, nez pri pohovoru vysvetlovat, co dela tento sql dotaz ;-)

  3. Verzovani, nasazovani (na produkci pomoci F5 nebo git / svn?); verze (php / html); prescasy a pohotovost ano ci ne…

    Proste, aby za super inzeratem nebylo osetrovani php4 proceduralniho prasokodu na produkcnim serveru po sobotach a nedelich s nulovou sanci delat neco noveho a neco se naucit…

    Jj, na otazku “dva monitory?” odpoved “k cemu?” je libustka :)

  4. Hezký článek. K otázce “4) Na čem přesně budu pracovat? Jaký je váš tech stack?” bysh si dovolil doplnit ještě malé rozšíření:

    “Jakým způsobem za 3 měsíce vyhodnotíme moji práci zde, jaká je přesně představa toho co budu dělat, jaký je jasný cíl?”

    Má to dvě roviny:

    1) Jde o to, aby obě strany měli jasno kam se ubírají a již v průběhu času obě mohli mít představu jak se k danému cíli posouvám. A taky po těch cca 3 měsících šlo objektivně zhodnotit odvedenou práci. Z toho taky pak může být výchozí pozice o úpravě platu po zkušební době. Nebo taky důvod k odchodu :o)

    2) Pokud není firma schopna něco takového aspoň rámcově stanovit, tak je otázkou čeho všeho ještě není schopna. Nebo naopak čeho schopná je ;o). Za mě dost dobrý důvod mnohem víc se ptát nebo se na pohovoru rozloučit.

  5. Mou pracovni zkusenost na pozici programatora ve vykupto.cz presne vystihuje tento clanek :) Neco podobneho nikdy vice!

  6. I just stumbled upon your website and enjoyed reading this great post. I appreciate you for the sharing of this great post.

  7. Your website is such impressive with its valuable stuff. I would like to get more useful reading stuff from you because your task is much appreciable.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax