Hledání technika do Olomouce je u konce. Děkuji všem za obrovský zájem a přeji vám, co jste neuspěli (bohužel můžeme přijmout jen jednoho), ať naleznete zaměstnání dle svého přání co nejdříve.
Musím říct, že to pro mě byla velmi dobrá zkušenost. Pohovory člověk většinou absolvuje ze strany zájemce o práci a pohled ze strany zaměstnavatele je pro mě docela nový a velmi přínosný. Hodně dlouho jsme přemýšleli koho že to vlastně chceme, snad ještě déle jsem formuloval inzerát v poněkud nezvyklém znění a za současného prozrazení několika, do té doby, neuvěřejněných informací. Asi první inzerát, který schvalovalo nejvyšší vedení společnosti. :-) Dnes musím konstatovat, že se nám to povedlo, a hlásili se přesně ti, které bychom rádi přivítali v našich řadách.
Nejvíce mě překvapilo, kolik lidí, přesněji řečeno kluků (ano, přihlášky přišly výhradně od mužů) se na toto místo přihlásilo. Řeklo by se, že administrovat LAMPu není zase takové terno a skutečně jsem očekával jen několik málo uchazečů (zejména absolventů) a že toto výběrové řízení potrvá dlouho. Nakonec, za dva týdny, přišlo něco přes 30 CV, ze kterých jsem vybral 9 kandidátů na pohovor. První CV přišlo asi 1h po oznámení inzerátu zde u mě na blogu, což mě velmi těší.
Do prvního kola pohovorů se dostalo 8 borců. Ten devátý se vyřadil sám tím, že na pohovor nepřišel a při telefonickém rozhovoru potom uvedl, že toho má dost. Tak jsem mu od jedné povinnosti odlehčil. Nerozumím tomu, proč se někdo hlásí na akci, o kterou nemá zájem a ani se dopředu neumí omluvit. Ale i takoví lidé jsou.
Zajímavé je, že uchazečů z Olomouce bylo málo a jejich kvalita je, snad až na jednoho, velmi malá. Do druhého kola se z Olomouce nikdo nedostal. Škoda.
V inzerátech nepadlo ani slovo o vzdělání. To je záměr. Tahle pozice je vhodná i pro absolventy středních (průmyslových) škol. Přes to kvalita uchazečů na prvním kole pohovoru (8 lidí) byla (až na jednu vyjímku) velmi vysoká a snad až na dva měli vysokou školu s titulem Ing.
Jeden inženýr nás šokoval. V tom špatném slova smyslu. Nevím, jak je možné dostat diplom za program v PHP a MySQL. Tak hluboko snad úroveň odborného školství neklesla. Ale to je věcí školy a státu. Jenže, představte si, dotyčný nevěděl ani to, co je SVN (ani nepoužíval žádný jiný verzovací systém) a ani neuměl zazálohovat MySQL (udělat její dump). Vhosta pro Apache nikdy nenastavoval. Není mi jasné, co a jak tedy programoval (bez verzí, bez záloh, bez webserveru). A ani to možná nechci vědět. Ten člověk neuměl vůbec nic a to dokonce ani ze svého vlastního CV. To není dobrá známka.
CV není a nemá být seznamem všeho, co jste v životě viděli. Do CV patří pouze to, co dobře umíte a chcete dělat. Na pohovoru se na to stejně přijde a zbytečně zdržujete sami sebe i zaměstnavatele. Kvalita CV je velmi důležitá, je to první seznámení s uchazeči. Proto nepodceňujte životopis, udržujte jej aktuální, ideálně i online. Není ani vyjímkou, že se z něj položky odebírají. Pokud nemáte o nějakou technologii zájem přestože ji umíte, nemusíte ji nabízet. Zaměstnavatel ocení přímé jednání.
Ještě drobná rada k datovému formátu. Pokud se hlásíte na pozici technika linuxových serverů, je opravdu krajně nevhodné posílat cv ve formátu doc nebo docx. Moji práci s výběrem to sice ulehčilo, ale vaše šance na takovou pozici je minimální.
Naopak kvalita ostatních uchazečů byla velmi vysoká a pohovor se po krátké chvíli (kdy oběma stranám bylo jasné, že ptát se na věci jako svn, kernel moduly, dovecot, a dumpy db je pod úrovní obou stran) sám úspěšně ukončil a další hodinku jsme si neformálně povídali o všem možném, včetně petabajtového úložiště ve vestavěném bytovém prostoru na půdě jednoho domku, svařování optických vláken a práci pro tajnou službu. Opravdu musím ocenit rozhled a znalosti mnoha účastníků a je nesmírně těžké někoho takového odmítnout (můžeme přijmout pouze jednoho), přestože jeho znalosti a dovednosti jsou famózní a hlavně aktuální, což ukazuje na schopnost se neustále učit. Ochota učit se nové technologie se špatně měří (na pohovoru to ani nejde), ovšem pokud někdo, kdo je v oboru 12 let zná a používá nikoliv PHP a MySQL, ale Git, Python, Mongo a Redis, je schopnost a ochota učit se naprosto zřejmá.
zdarec pane,
pěkný článek. tedy o tom, že personalistika se nedá dělat na koleně formou copy&paste nějakého inzerátu z jobsu a změny hlavičky. ocením i odstranění přívlastků dynamický a flexibilní. kdyby bylo víc firem s podobným přístupem, odrazilo by se to i na poptávce práce, vzhledem k tomu, že většina firem nedokáže říct, koho vlastně hledá (když si tak vzpomenu na všechny ty key account senior managery, z nichž se vyklubal nakonec podomní prodejce nebo obyčejný obchoďák…).
na stranu druhou, firmy si svým přístupem můžou za sběr nekvalitních uchazečů samy – pokud by byly takto upřímné, nenutilo by to uchazeče o práci cpát do CV všechny možné nesmysly. pokud se k náboru nového pracovníka postaví banda kreténů nebo to ve firmě zařizuje sekretářka se specializací vím-jaké-má-pan-ředitel-rád-kafe, dopadá to tak, že výběrko na asistentku asistenta zástupce šéfa marketingu trvá 3 měsíce, uchazeč projde 5 koly pohovorů, z čehož jedno je sezení u psychologa a druhé u grafologa, zpracuje pro firmu pár nápadů, aby následně zjistil, že „děkujeme Vám, ale na místo XXXXX byl vybrán vhodnější kandidát.“ O to je to lepší, když inzerát na stejnou pozici firma vypíše znovu za dva týdny. Takže bych nebyl tak moc rozhořčený nad „nevhodnými“ uchazeči. Vzhledem k tomu, co jsem napsal, a k rostoucí míře nezaměstnanosti se nedivím, že to lidi zkouší všude možně. A teď si představ, že bys napsal klasický „jobsovský“ inzerát s flexibilitou a dynamikou, kolik bys měl (nevhodných) uchazečů… :)
Každopádně tleskám k tvému přístupu, četl jsem si i samotný inzerát, všechna čest.
Díky. K tomu asi není co dodat :-)
Ono to hledání je oboustranný proces. Zaměstnavatel hledá (a ono je to dost drahé a ani se to na první pohled nezdá) a současně uchazeč hledá a je třeba limitován časem (to není nic přijemného). Teď jde jen o to, aby se dobře potkali.
Chci kolegu, kterého to bude bavit i proto jsem se snažil ten pohovor mít hodně neformální a spíše to brát jako takový pokec, ať se vzájemně poznáme a tak. Potom budeme 8h denně ve stejném kanclu, takže si musíme rozumnět. :-)
Dagi o tom zrovinka nedávno psal:
http://www.dagblog.cz/2012_10_07_archive.html#9210922464294543140
Tyhle typy mi taky jdou na nervy, ale kupodivu v Red Hatu jsem se ještě s žádným „CV expertem“ nesetkal. Méně je prostě více, to platí nejen pro design, ale taky pro životopis :-D
:-D
Moc to nechápu s tím doc(x). Protože to neříká nic o ničem.
Dále jsem nepochopil narážku na PHP + MySQL a úroveň našeho školství. Nějak tam nevidím souvislost. Proč by měl být vysokoškolák, který udělal nějaký komplexní projekt v PHP + MySQL horší než jiný.
Naopak to něco vypovídá o vás. Ale každopádně souhlasím s tím, že dneska sehnat někoho schopného a vyfiltrovat v CV bullshity je nadlidský úkol.
Ad PHP a MySQL. Za mých univerzitních studií (2001-2006) byla bakalářka určená pro praktické výtvory (u mě fyzikální experiment s kamerou a laserem, fourier a moiré, kde cílem bylo sestavit pokud možno novou aparaturu pro experiment; na informatice potom kámoši tvořili program na tvorbu a solving křížovek a 3D projekt pro znázornění zemětřesení modelu Země) a přesně na této bakalářské úrovni bych čekal projekt v MySQL a PHP (i když soudím, že na univerzitě by se mělo jít ještě vejš a používat alespoň relační databázi splňující SQL normy, ale to je můj názor).
No a na magisterském stupni to potom byla buď vysoce teoretická práce přinášející něco nového (nikoliv nový objev, od toho je Ph. D. a Doc.) a nebo praktická práce na vysoké úrovni (na fyzice to byl například měřící přístroj s kompletně novým přístupem pro měření veličiny). Ani na jedno mi projekt v PHP a MySQL nesedí.
Mě navíc bylo celkem jedno, z čeho má titul, já ho bral na pohovor proto, že měl v CV docela pěkný seznam databází (a můj oblíbený PostgreSQL), a měl to jako svůj projekt, takže jsem očekával odborníka.
V každém případě, tak jako tak, dotyčný uchazeč nevěděl o MySQL vůbec nic. Jak je to možné, když to používal jak na bakalářku, tak i na ing? A to mi vadí nejvíce, když už z toho má titul (vem čert z čeho), tak to musí znát od sklepa po půdu. Neznal ani základy.
K tomu doc(x). No vypovídá to o tom, že dotyčný ví kam jde a jaký o to má zájem. Je to pozice spojená výhradně s linuxem a v tomto prostředí se docx vyrobí o poznání hůře, než takové pdf nebo odf.
PHP a MySQL je přece jen prostředek. Tak samo to může dělat v čemkoli jiném. Důležitá je úroveň takové práce. A ta může být i s takovými prostředky vysoká.
Mám s touto kombinací nějaké zkušenosti a věřím, že se v tom dá udělat téměř cokoli. Uznávám, že MySQL by se mohla zadýchávat, takže tady bych pro finančnictví a kritické aplikace raději zvolil Postgre nebo Oracle. Ale ještě mi nikdo nedal rozumné argumenty, proč nepoužít PHP.
Standardy jsou politika. Obvykle se k nim vyjadřuje celá řada velkých hráčů a ne vždy je konsensus snadný. Pak se samozřejmě stává, že jeden z hráčů si takový standard vyloží po svém. A roli v tom může hrát i obchodní model a další.
Že klučina nevěděl je skutečně zarážející. Skoro to vypadá, jako by si ten titul vymyslel. Tomu by odpovídal i naivní přístup = nikdo mi na to nepřijde, že jsem blbej.
CV bych poslal v PDF. Ale doc/docx posílám na 99 % všem, byť jsem linuxák, protože cokoli jiného protistrana odmítá/nezná. To je holt realita.
Pazourek je také jen prostředek. Přesto používáme něco sofistikovanějšího a efektivnějšího. Budu se opakovat, ale myslím si, že na univerzitě (technického) typu by se měla používat a prosazovat špička v oboru. Například naše laboratoř optiky byla v době, kdy jsem tam studoval, přední pracoviště na světě ve kvantové kryptografii (ne díky mě, samozřejmně :-)). Jistě se shodneme na tom, že MySQL není špička ani po technické stránce, ani po stránce uživatelské. Existuje mnoho opensource produktů, které jsou daleko dál. Ostatně na univerzitách vznikali a vznikají základy pro dnešní OSS. Například nejpoužívanější databáze na světě, Berkeley DB. Nebo (Berkeley) UNIX aka BSD. V Praze studenti makají na vlastním jádře pro OS.
Ad to zadýchávání. V tom to není, výkonnostní limit má každý software (bylo-li to myšleno takto). MySQL má zásadní problémy s konzistencí dat, což mohu jako technik motající se kolem databází snadno dokázat.
„Pazourek je také jen prostředek. Přesto používáme něco sofistikovanějšího a efektivnějšího. “ Ale to neznamená, že pořád nemůžu používat pazourek. A pokud s ním dokážu to samé co vy se zapalovačem, tak jsem možná ještě větší machr než vy, ne? :)
Ad VŠ) Na školách nemusí být nutně to nejlepší. Ono to nemá ani moc smysl. Jednak je to dost drahé a hlavně zbytečné. Na VŠ se totiž učíte, především učit se. Když totiž máte titul, tak to o vás říká, že máte nějaký soubor vlastností díky, kterým jste dostudoval. Ale hlavně, že se dokážete učit. A umíte za relativně krátkou dobu nastudovat i dosti komplexní záležitosti.
Ad MySQL) Vzhledem k tomu, že chce Oracle za komerční licenci MySQL docela velké peníze, tak by mě ten důkaz docela zajímal.
Ad MySQL)
http://www.heronovo.cz/report-ztrate-dat-aneb-proc-nemam-rad-mysql/
Článek jsem psal pro 5.0, teď tu mám 5.5. Zkusme to.
Vytvoření tabulky projde i s nepodporovaným engine:
create table xxx (id int) engine=xxx;
show create table xxx;
CREATE TABLE `xxx` (
`id` int(11) DEFAULT NULL
) ENGINE=InnoDB…
Databáze vytvořila tabulku a dala mu default (nastavení default-storage-engine). Takže teďka appka může vesele předpokládat, že tam má tabulku typu xxx a bude chtít využívat jeho vlastnosti.
Chyba se se startem bez innodb (nebo jakéhokoliv engine) je tam také dodnes a jak koukám, tak to vylepšili tak, že tabulky v seznamu vidět jsou, takže hledání chyby bude opět složitější.
Ve spojení s předchozí „vlastností“ je to ideální prostředek pro silent data corruption (a přesně takto jsme přišli o data). Appka si vždycky dokáže vytvořit tabulky (i když daný engine není podporován) a mysql-server bez problémů naběhne i s chybnou konfigurací daného engine, jen tedy daný typ nebude aktivní. Ale tabulky z daného engine jsou v seznamech show tables.
Paráda, je to ještě horší než v 5.0.
Replikaci se mi nechce zkoušet, myslím, že to pro ilustraci stačí.
Určitě je nepříjemné, že neošetřili blbý vstup (i když si nejsem jistý, že to někde přece jen nevyhodí warning/error). Ale tady je chyba na straně obsluhy, nikoli MySQL. Když to chcete používat, tak se to musíte taky trochu naučit. Databáze nejsou pro BFU přece.
Možná si přečtěte ten článek.
V mysql clientu to warning napíše (resp jejich počet, pro samotný warning je třeba další příkaz), v případě loadu dumpu (mysqldump > mysql) nikoliv.
Technika vůbec nic nevaruje.
Server naběhne, krásně poslouchá na portu, dá se do něj připojit, jsou tam staré tabulky (teď už tedy i z neexistujících engine) a dokonce i ten import dumpu zálohy proběhne bez chyby a appka běží.
Tohle rozhodně nepovažuji za chybu obsluhy, protože nikde (kromě jednoho řádku logu, kam se ale není důvod dívat), nesvítí žadné upozornění.
V Unixovém světě není zvykem se dívat, jak „moc dobře“ to dopadlo, v takovém případě je nulový výstup. Naopak, když se to nepovede, tak ty appky začnou křičet.
To že si vymyslíte vlastní engine není chyba obsluhy? Ale jděte.
Kromě toho v dokumentaci je jasně napsáno, jak se v takovém případě databáze chová. Tady jste si naběhl na vidle. Pak vás těžko považovat za experta za db.
Asi jste to nepochopil a ten předchozí článek nečetl. To není vymýšlení si engine. Klidně si tam doplňte InnoDB, je to jedno. Pokud tam nebude InnoDB (samozřejmně také chybou obsluhy ;-)), tak se vytvoří default myisam. Kterému jaksi chybí transakce.
Btw. je to někde nahlášeno jako bug?
Odpovím si sám :) Je http://bugs.mysql.com/bug.php?id=34671
Takže chyba je na vaší straně. „Pls double check doc“ :)
K tomu Oracle. Ano, Oracle MySQL postupně uzavírá. Dneska už je fork MariaDB rychlejší než MySQL a nejspíše i rychleji reagují na chyby.
To se Oraclu nelíbí a tak uzavřel testovací suite. Takže od této chvíle si žádný fork nebude moci ověřit, zda je plně kompatibilní (z hlediska testů, které jsou skutečně důkladné) s offico MySQL.
Ano to vím. Ale to je obchodní rozhodnutí Oracle. S tím my nemůžeme nic dělat.
Ale můžeme. Můžeme ten produkt opustit. ;-)
Oracle bohužel zničil všechno, co se Sunem koupil.
Java mu slouží pro soudní pře.
Solaris uzavřel a opustil. Dříve byl Solaris hlavní platforma pro Oracle (DB) a je zvláštní, že s jeho koupí přesel na Linux. Což je sice velké plus pro linux, ale je škoda ukončit tak skvělý UNIX jako Solaris (odkud přišla spousta dobrých věcí i do dalších unixů).
Snad oracle neuzavře BTRFS. Když už nechce změnit licencování ZFS.
OpenOffice předal jinam.
MySQL uzavírá.
Zbyl snad jen HW, ale nevím, zda nějaké další SPARC T uvidíme.
Pokud jde o HW, tak jsem slyšel, nevím, co je na tom pravdy, že změnil licenční politiku a dost zákázníků přešlo ke konkurenci (IBM apod.)
Zdar Max
To Patrik Šíma:
Raději nové vlákno, tam to už je moc úzké.
Ano, všechno je chyba obsluhy ;-). Připadá vám takové chování tvůrců databáze, což je software, jehož primární vlastností je se starat o konzistenci dat, v pořádku?
Ostatně i ta replikace je vlastnost a v této knížce (http://www.heronovo.cz/recenze-knihy-mysql-profesionalne-%E2%80%93-optimalizace-pro-vysoky-vykon/) je krásně popsáno jak kontrolovat že to funguje a taky jak kontrolovat konzistenci dat. Promiňte, ale přesně to má dělat ten software, jinak je to k ničemu.
Abych to uzavřel, já osobně, ani naše firma, nechce produkt s takovými „vlastnostmi“ používat. Naštěstí je ve světě opensource dost lepších produktů a je si z čeho vybírat.
„Ano, všechno je chyba obsluhy . Připadá vám takové chování tvůrců databáze, což je software, jehož primární vlastností je se starat o konzistenci dat, v pořádku?“
Asi se opakuji, ale nekonzistenci dat zařídíte vy tím, že nečtete dokumentaci. Jiné odborné věci taky neděláte bez pečlivého prostudování. A pokud ano, tak se pak nedivte, že to nefunguje tak jak byste čekal.
Jaké chování tvůrců máte na mysli?
Ano, naštěstí je na výběr. Ale nebuďme naivní, že jiné produkty nemají své mouchy.
Každý produkt má své mouchy. Ale neznám jiný produkt, který se stará o data a který je ve své výchozí konfiguraci takhle nebezpečný.
Právě naopak, většina produktů kolem dat se chová až dost paranoidně a bezpečně. Počínaje od hw řadičů, které vypínají write cache, pokud jedou bez baterky (a write cache disků vypínají jaksi automaticky); od sw mdadm; drbd; systémů souborů až po databázový software.
Ve skutečnosti je dost těžké tyto produkty přinutit ke ztrátě dat a většinou vyžadují další parametr nebo odsouhlasení. Default je bezpečné nastavení i za cenu pomalého běhu. Cokoliv jiného (a možná méně bezpečného) si musí správce explicitně nastavit. A občas je to dost otravné, když se řadič brání přidání disku, který nese metadata jiného pole. Musí se explicitně smazat.
To je ale nepochopení toho produktu. Nemůžete přece po MySQL chtít, aby mělo vlastnosti Oracle Exadata 11g. Prostě filozofií toho produktu je takhle v defaultu fungovat. Ale pořád si stojím za tím, že uvedený příklad prostě nekonzistenci při správném použití neudělá.
O replikacích nic nevím, takže tady se neodvažuji diskutovat.
ad MyISAM) teď nevím co se vám nezdá. že to spadne do myisam, které je bez transakcí? a nejde ten fallback nastavit jinak? jinak myslím, že to má logiku. mysql je primárně určená pro čtení a nekritické zpracování dat – typicky weby. a tam se myisam hojně využívá. to je ovšem filozofie toho produktu, která se odvíjí od cílovky. jakmile vám to nevyhovuje, musíte vybrat něco jiného.
„mysql je primárně určená pro čtení a nekritické zpracování dat“
Takže je vlastně úplně jedno, jestli ta data jsou nebo nejsou v pořádku ;-).
Ten default engine lze nastavit na zcela libovolný engine. Ve starších verzích to byl (ve výchozím nastavení) myisam, dnes je to innodb. Na windows to bylo ještě trochu jinak. Ale to je celkem jedno. Vzhledem k filozofii mysql si moci vybrat libovolný podporovaný engine s jeho unikátními vlastnostmi (innodb a bdb má transakce, archive je komprimovaný a bez update atd.), je jakýkoliv skok do defaultu velkým problémem. Protože to spadne do engine, který ty žádané vlastnosti nemá.
Jedno to není, ale ten produkt má jiné určení. Když se vám defaultní nastavení nezdá, tak si to nastavte jak potřebujete. K nekonzistenci by dojít nemělo. Ale chyba se vyloučit nedá.
Jakou databázi vybrat je na počáteční analýze. Burzovní data bych do MySQL asi nestrkal. Tak samo bych osobákem neoral pole.