Pár kedves barátommal megalapítottunk a MEP - Managers of Engineering Projects-et, ahol közösen fogunk szakmai témában blogot vezetni. Ezért ezen az oldalon már csak Targetprocessel kapcsolatos cikkek fognak megjelenni, a projektmenedzsmenttel és vezetéssel kapcsolatos bejegyzéseket a másik blogban fogom publikálni.

http://mep.ninja

http://mepninja.blog.hu

Előző rész: Sebesség a Szoftverfejlesztésben I.

A Szoftverfejlesztés Sebességének Modellje

Kezdjük egy áttekintő nézettel, megijesztelek már az elején. A kép meglehetősen rémisztőnek tűnik, de bízz bennem, el fogom magyarázni az utolsó bitig. A végén lesz egy erőteljes eszközöd amivel analizálhatsz hasonló problémákat.

A diagramon olyan dolgok és tevékenységek vannak, amik valahogy érintik a fejlesztés sebességét. A zöld azt jelenti, hogy egy tevékenység növeli a sebességet. Minél több van, annál jobb. A sárga jelzi valaminek a maximalizálhatóságát. Például: felhalmozhatsz technológiai adósságokat (technical debt) és növelheted a sebességet (Short term boost), de ha túl sokat halmozol fel, akkor az jelentősen le fog téged lassítani. A piros dolgok lassítják a fejlesztést, minél kevesebb van belőlük, annál jobb. Aztán, a zöld nyilak pozitív hatással vannak az adott tevékenységre. Például a fókuszált munka (Focused Work) növeli a fejlesztés sebességét (Development Speed).

A piros nyilak a csökkenését jelentik. Például a több fejlesztői jártasság (Skills) csökkenti a rendszer bonyolultságát (system complexity) (a jó fejlesztők kevésbé bonyolult rendszereket hoznak létre).

Most nézz az ábrára és tegyél fel hasonló kérdéseket: Mik növelik a fejlesztés sebességét? Mik csökkentik azt? Mit tehetünk, hogy gyorsabban (és jobb!) szoftvereket hozzunk létre? A modell néha hiányos lehet, de ez rendben van. Szabadon módosíthatod.

Most pedig elmagyarázom a modell különböző részeit, analizálom azokat és ötleteket adok a sebesség növelésére. Remélem, hogy ez egy jó kezdet lesz ahhoz, hogy mélyebben kezdj el gondolkodni és még több megoldást generálj. Vágjunk bele.

Jártasság és Tapasztalat

Elég nyilvánvaló, hogy a jártasság (Skills) növeli a fejlesztés sebességét. A jártasabb fejlesztők gyorsabban oldanak meg problémákat és kevésbé bonyolult rendszereket alkotnak. Néhányan azt mondják, hogy 10x-es hatékonysági különbség is lehet egy igazán jártas és egy kevésbé jártas fejlesztő között. Habár nem hiszem, hogy ez egy általános vélekedés.

A következő triviális kérdés, hogy mit lehet tenni a fejlesztői jártasság növelése érdekében? Először is, toborozhatsz  kizárólag tapasztalt fejlesztőket. Ez működhet, de ez a modell nem skálázódik túl jól. A tapasztalt emberek hajlamosak nehéz problémákon dolgozni, amik igénylik a jártasságukat. Hány cég van a világon, ami valóban nehéz feladatokon dolgozik? Nem túl sok. A másik oldalon ott van, hogy ha a terméked nem egy rakéta tudomány, akkor nincs szükséged csupa PhD-s fejlesztőre a csapatodban. Szóval minden cégnek különböző jártasságokra van szüksége. Egy tapasztalt fejlesztő a Google-nél nem egyenlő egy tapasztalt fejlesztővel egy outsourcing-os cégnél.

Rendben van, meghatároztad hát, hogy mit jelent a céged számára a Tapasztalt Fejlesztő, de még mindig küzdesz azért, hogy eleget találj belőle. A skálázhatóság problémája. Emlékszel? Szóval nem annyira tapasztalt fejlesztőket is fel kell venned, hogy növekedhess. Oké, de abszolút olyanokra lesz szükséged, akik szeretnek új dolgokat tanulni.  Hogy szerezhetne bárki is jártasságot, ha nem szeret tanulni? Kíváncsiság, élénk elme, szenvedély — ezek az értékek fontosak.

Egy cégnek meg kell adnia mindent, hogy segítse az embereket a tanulásban. Itt van néhány lehetőség:

Vegyél meg minden könyvet, amit az emberek kérnek

Minden cégnek kell, hogy legyen egy jó könyvtára. A legtöbb kiváló fejlesztő tudom, hogy sokat olvas. Nem tudod az embereknél az olvasást erőltetni, de nagyon könnyen elérhetővé teheted, hogy egy jó könyvet csak megragadjanak és elkezdjék olvasni.

Küldd az embereket konferenciákra

A legtöbb ember azt gondolja, hogy a konferenciák az új tudás forrásai. Talán, de én azt gondolom, hogy sokkal inkább a szenvedélyre hatnak. A konferenciák motiválnak, hogy folyamatosan tanulj, próbálj ki új dolgokat, a legjobb esetben pedig irányt mutatnak.

Szeretek olyan konferenciákat látogatni, ahol a témák újak számomra. Például, amikor elkezdtem User Experience-t tanulni, két nagy konferenciára mentem el. Az első különösen hasznos volt, a második már nem annyira.

Szervezz tanulással kapcsolatos eseményeket

Az egyik legjobb módja hogy meganulj valamit az, ha könyvet írsz a témáról. Kevésbé extrém módja pedig az, ha felkészülsz egy prezentáció megtartására, vagy egy workshop-ra. Egy cég szervezhet belső konferenciát, hogy fellendítse ezt a folyamatot. Nem mindenki kész arra, hogy közönség előtt beszéljen, de többen megpróbálják. A mi cégünkben 2 napos konferenciák vannak 6 havonta. Nincsenek külsős előadók, minden prezentációra a mi csapatunk tagjai készülnek fel.

Egy másik jó gyakorlat, ha teret biztosítasz közösségi meetupoknak. Van egy kis konferencia termünk, ahol 80 ember fér el és boldogok vagyunk, hogy menedéket adhatunk a helyi UX közösségnek, .NET közösségnek és iOS közösségnek.

Természetesen van más módja is annak, hogy külsős eseményeket szervezz.

Biztosíts időt az új dolgok tanulására

Ez nem úgy hangzik, mint egy kötelező gyakorlat. Lehet, hogy nem. Mégis, ha egy cég szabadidőt biztosít kizárólagosan tanulásra, az fantasztikus. A híres 20%-os Google idő egy jó példa (vannak pletykák miszerint ez megszűnt, de ezek a pletykák nem bizonyítottak). Nálunk a Targetprocess-nél Orange Friday-ek vannak.

Minden péntek arra van szánva, hogy személyes projekten keresztül tanuljunk. Többen Coursera kurzusokat csinálnak, cikkeket olvasnak, vagy új technológiákat próbálnak ki. Lehetetlenség mérni ezeknek a tevékenységeknek a hatékonyságát, de itt van néhány haszon:

• Tény, hogy ez azt jelenti 4 munkanap van egy héten. Az ötödik nap az nem egy tipikus munkanap.
• Csábító azoknak az embereknek akik szeretnek tanulni, így ez egy hatalmas plusz a toborzásnál.
• Könnyebb megtartani az embereket, mióta lehetőségük van kipróbálni valami újat, amit szeretnének.
• Az emberek gyorsabban szereznek új jártasságokat.

Egy hátránya van csak — ez valószínűleg csökkenti az össz fejlesztési sebességet. Az emberek egy nappal kevesebbet dolgoznak, ami direktben 20%-kal csökkenti a fejlesztés sebességét. Mi az ami ennél fontosabb? Az attól függ. Ha nagyon közel vagy egy release-hez, taktikailag nem túl bölcs minden pénteket képzésre költeni, ha azonban Maraton üzemmódban (szerk: lásd előző bejegyzés) vagy — érdemes lehet.

szemtelen hirdetés
A Targetprocess-nél dolgozom — ahol egy igazán király vizualizációs projektmenedzsment szoftvert készítünk. Ha egy agilis eszközre van szükséged, ami támogatja a Scrum, Kanban vagy egyéb típusú projekteket, akkor próbáld ki. 

Segíts az embereknek jobban megérteni a domain-t

A domain tudás alapvető minden szoftverfejlesztő számára. Segít a problémákat mélyebben megérteni, jobb és gyorsabb megoldásokat szállítani és csökkenteni a feladatok újbóli elvégzését. Lehetővé teszi a fejlesztőknek, hogy korábban észrevegyék a rossz megoldásokat. Domain tudás nélkül a fejlesztők vakon készítik el azt, amit a Product Owner-ek vagy a Business Analyst-ek kérnek. Egy jó domain tudással egy fejlesztő könnyen talál ki kiváló megoldásokat saját maga, vagy lesz tagja a UX csapatnak, hogy különböző megoldásokról ötleteljenek.

A domain tudás különösen fontos, ha terméket fejlesztetek. Az élet rövid, és nehéz sok domaint alaposan megismerni. Így a végén a megfelelő dolgokra kell fókuszálni. Legjobb ha megtalálod, hogy mi hajt téged és fertőz meg.

OK. Most beszéljünk egy kicsit a tapasztalatról.

Tapasztalat

A munkatapasztalat szintén sokféleképpen hat a sebességre. Egy 20 év tapasztalattal rendelkező fejlesztő jellemzően gyorsabban old meg egy problémát, mint egy 5 év tapasztalattal rendelkező (mégha valahogy azonos jártasságaik is vannak). Megjegyzem, hogy a jártasság (skill) nem egyenlő a tapasztalattal (experience). Lehet egy csomó tapasztalatod egészen irreleváns területeken és így nem fogod tudni megoldani a legtöbb cégre jellemző problémát.

Személyesen azt gondolom, hogy a jártasság az a tényező, ami a leginkább befolyásolja a szoftverfejleszés sebességének növekedését. Ha van egy csokor tapasztalt fejlesztőd, designered és tesztelőd — jó esélyetek van arra, hogy valami jót hozzatok össze. Ha csak kezdő fejlesztőid vannak — szinte semmi sem segíthet, hogy növeld a sebességet.

A legtöbb cég a problémák széles körével küzd: némelyik ezek közül egyszerű, némelyik kihívásokkal teli. A tapasztalatlan fejlesztőket minden felvillanyoz, hiszen minden probléma új tudást jelent számukra. A tapasztalt fejleszők válogatósabbak és sokkal jobb, ha megfelelő komplexitású feladatot kapnak. Így jó, ha széles skálája (jártas/tapasztalt) van az embereknek a szervezetben, de az átlag jártasságnak magasnak kell lennie. A megfelelő egyensúly persze minden cég számára egyedi, de legalább gondolkozz el a problémán.

Folytatás hamarosan...

Az erdeti cikk itt található: 

https://www.targetprocess.com/articles/speed-in-software-development/

Előző cikkemben (7 interjú a Google-nél) elmeséltem, hogyan is zajlott egy felvételiztetési folyamat a világ egyik legjobb cégénél, a Google-nél. Most azonban azt is szeretném veletek megosztani, hogy mi mindent tanultam ez alatt a két hónap alatt, hogyan tudok ebből én is és ti is a legtöbbet profitálni. Lehet, hogy egyszer neked is interjúkat kell majd vezetned, vagy épp te leszel az, akit interjúztatni fognak mások, és így kicsit felkészültebben vághatsz neki egy kiválasztásnak. Azt hiszem a HR-eseknek is tudok segíteni a tapasztalataim megosztásával, hátha ennek hatására ők is átalakítják szervezetükben a toborzási folyamatot. Én így tettem.

Legalább 100 alkalommal felvételiztettem már az elmúlt 5 évben. Legtöbbször természetesen szoftverfejlesztőket, de volt hogy grafikust, projektmenedzsert vagy éppen a Ház.hu vállalkozásunkhoz mindenest. Ez idő alatt rutint szereztem abban, hogy milyen kérdéseket érdemes feltenni, hogyan lehet valakiről rövid idő alatt megállapítani, hogy szeretnék-e vele együtt dolgozni vagy sem. Eddig azt hittem, hogy egész jó módszert fejlesztettem ki, de rájöttem, hogy van még mit csiszolni rajta. Számomra fontos volt, hogy az emberekben alapvetően azt nézzem, milyen potenciál van bennük, mennyire képesek fejlődni és hogy mennyire akarnak. Meg kell legyen hát a motiváció is. Ezt követte csak az, hogy milyen szinten van a tudásuk. Persze nagyon fontos, hogy valaki mit tud, de sokkal fontosabb, hogy hova tud eljutni. Figyeltem azt is, hogy mennyire tudom elképzelni az illetőt a csapatomban, mennyire tudok vele én és a többiek is együtt dolgozni. Képes lehet-e betölteni lyukakat (hiányzó vagy nem betöltött szerepek), amiket eddig nem tudtunk megoldani. Az interjúk pedig tipikusan úgy épültek fel, hogy a személyes találkozó alkalmával az emberre figyeltem, milyen a karaktere, jó hangulatban telik-e az interjú, megvan-e a közös szimpátia (csajok azt mondanák, kémia). A szakmai részekbe az interjú folyamán nem nagyon mentünk bele, azt igyekszem inkább egy előre megírt kód formájában felmérni. Gyakran használok még egy pár perces logikai feladványt is, amiből egész jó eséllyel lehet következtetni az illető problémamegoldó képességére.

Azt találtam, hogy a Google-nél hasonló értékek számítanak, de azért mégis másképp tekintenek a kiválasztásra. Laszlo Bock könyvében azt írja, hogy első helyen az általános kognitív képességeket figyelik, jó eszű munkatársakat keresnek, akik hamar alkalmazkodnak az új helyzetekhez. Ezután a vezetői alkalmasságot nézik. Nem lesz mindenkiből vezető, legalábbis titulusában biztosan nem (hisz a Google-nél mindenki maga választja meg, mi kerül a névjegykártyájára). Projektről projektre azonban előfordul, hogy ilyen szerepbe kerülnek emberek, ezért a természetes vezetésre termettséget keresik. Harmadik helyen áll a Guglisság (Googler-ség), ami a szórakozást, alázatot, kötelességtudatot jelenti és mindent, amiben a cég hisz. Megfogalmazhatjuk úgy is, hogy a jelölt szellemisége passzoljon a szervezet szellemiségéhez, hisz tudjuk, a "kultúra megeszi reggelire a stratégiát" (Peter Drucker: "culture eats strategy for breakfast"). Végezetül pedig számít a munkakörrel összefüggő tudás. Ez a tudás pedig inkább legyen általános, mint specializált, mert az új munkahelyen nem feltétlenül lesz az a jó válasz, ami az előző munkahelyen az volt.

Mennyire éreztem ezeket az elveket a felvételik alkalmával? Azt kell mondjam, hogy kézzelfoghatóan nem nagyon. Viszont mégis azt érzem, hogy ezek jelen voltak. Hét interjún vettem részt, mindegyiken feladatot kellett megoldanom. Minden feladatra jó megoldást adtam, végül mégse tettek ajánlatot. Ennek oka pedig az, hogy valamelyik területen nem találtak alkalmasnak, nem tudta minden interjúztató elképzelni velem a közös munkát, vagy épp nem talált elég ügyesnek. Minden alkalommal kaptam visszajelzést, minden interjút követően. Többször kiemelték, hogy örömteli számukra, hogy nem ragaszkodom a saját ötleteimhez, ha egy interjúztató segíteni szeretett volna, terelni valamilyen irányba, akkor vevő voltam a gondolataira és tudtam azt folytatni. Az is pozitív volt, hogy észre tudtam venni a hibáimat, volt hogy egy teszteset átgondolása közben jöttem rá, hogy a kód egy része nem működik és tudtam javítani. Az sokszor másodlagos volt, hogy helyes a megoldás, gyorsan csináltam meg, szép kódot írtam. Persze ezek is elvárások, mert ha ezeket nem teljesítettem volna, akkor alapból kivágnak. Azt gondolom, hogy érdemes ezen kicsit elmélázni és észrevenni, hogy mennyire zseniális feladatokat adtak fel. Egyszerű feladatok, amiknek sok megoldása van, sok helyen lehet bennük hibázni, de nem fogja az ember azt a frusztrációt érezni, hogy nem tudja megoldani a feladatot. Az interjúztató pedig nem arra figyel, hogy a jelölt eljut-e a célba, hanem arra, hogy milyen úton jut el oda. A megtett út sokkal fontosabb, mint a célba való megérkezés!

Az egyik legkülönösebb dolog, amivel az interjúk folyamán találkoztam, hogy nem volt konkrét pozíció, amibe felvételiztettek és nem volt konkrét egyén/főnök, aki döntött volna a felvételemről. Amennyiben megfelelőnek találtak volna, úgy mehettem volna bármelyik irodába dolgozni, ott ajánlottak volna projekteket és választhattam volna, hogy melyik tetszik. Így ők maguk se tudták volna előre, hogy ki lesz a felettesem, nem lett volna lehetősége dönteni arról, hogy felvesz vagy sem. Erről még csak az interjúztatóim se dönthettek. Egy jegyzetet kellett készíteniük az interjúról és 4-5 dimenzióban értékelni az alkalmasságomat egy talán 0-4 skálán. A szakmaiság csak az alap volt, több fentebb felsorolt tényezőt is néztek. Nem kell azonban mindenben kiválónak lenni, de azért legyél mindenben elég jó és legyen terület amiben tényleg kiváló vagy. A jegyzeteket egy értékelő bizottság nézi át, és közösen döntenek arról, hogy a jelöltet javasolják-e felvételre (aki látta a Gyakornokok / The Internship című filmet, emlékezhet is a jelenetre). Meglepő módon a folyamat végén ott van még Larry Page is, aki tulajdonosként a végső döntést meghozza és adott esetben el is utasíthatja a jelöltet. Ez azért kicsit hihetetlen számomra, hogy egy ekkora cégnél, ennyi alkalmazott mellett erre van még ideje, de ha tényleg meg tudja csinálni, akkor nagy nagy elismerésem és le a kalappal előtte.

A Google 400 jelöltből egyetlen egyet vesz fel. Ez 0.25% és 25-ször kevesebb, mint a Harvadra felvettek aránya. Mégis 5000 embert vesznek fel évente, ami azt jelenti, hogy 1.3 millió jelöltet kell interjúztatni. Hogyan lehet ezt mégis hatékonyan csinálni? Azt hiszem úgy, hogy az elején nagyon durván és rövid idő alatt rostálják az embereket, előszűrést végeznek. Először telefonon (Hangouts + Google Docs) interjúztatnak, hogy a jelöltet ne kelljen utaztatni, és kőkeményen az alapokat vizsgálják. Engem elsőre a fejvadász hívott fel, aki megtalált és így visszagondolva, már ő is tesztelt, volt egy extra interjú. Megvizsgálta, hogy komolyan érdekel-e a lehetőség, felhívta a figyelmemet, hogy ha belevágok, akkor kemény dió lesz és 1-2 hónapig is eltarthat, próbált elbizonytalanítani, hátha nem vagyok kellően elhivatott. Segítségeket adott, hogy milyen típusú kérdésekre számíthatok és hogy miből lenne célszerű felkészülni. Jól jött a segítség, de itt is inkább azt éreztem, hogy mondjam le magam az interjút, ha már a kérdések elolvasásából rájövök, hogy ez nem nekem való. Végezetül pedig tök alap algoritmuselméleti kérdésekkel vizsgáztatott (pl.: mennyi az összefésülő rendezés futásideje átlagos és pesszimista esetben). Hogy örülnék én is, ha ezt már a HR-esünk el tudná végezni helyettünk úgy, hogy a szakmát nem is érti, de ezekből mégis fel lehet készülni.

Miután a fejvadászos megbeszélések megvoltak, következett a 2 telefonos interjú. Persze csak akkor kell a másodikon részt venni, ha az első jól sikerül és nem esünk még ki. Interjúztatónk pedig bárki lehet, aki a Google-nél dolgozik hasonló területen, mint amire minket is fel akarnak venni. Általában valami problémamegoldós feladatra lehet számítani, ahol egy algoritmust kell kitalálni és Google Docs-ban lekódolni. Fontos, hogy a rendelkezésre álló idő alatt az ember megértse a problémát, tudjon kérdezni. Jellemző, hogy a jelölt nem kap meg minden információt, neki kell tudni az megszereznie, ezzel vizsgálható, képes-e valós szituációban teljesíteni, vagy csak a 100%-os specifikációt követeli. Meg kell tudni oldani a feladatot időn belül. 45 perc áll rendelkezésre és elvárt, hogy szállítsunk megoldást. Nem elég az, ha valaki szállítani tud, az is fontos, hogy a határidőt tartani tudja. A feladatoknak tipikusan lesznek egyszerű megoldásai és nem triviális megoldásai, kezelendő esetei. Elvárt, hogy a jelölt észrevegye a lehetséges utakat és azokra lehetőleg teszteseteket is tudjon mondani. Az interjúztatók segítőkészek és próbálnak is terelgetni. Teszik ezt mindazért, hogy a jelöltet próbára tegyék, képesnek találják-e arra, hogy másokkal együtt tud-e dolgozni. Utoljára pedig ott van, hogy milyen érzés alakul ki bennük a jelölttel kapcsolatban. Ez nagyon fontos! Lehet, hogy valaki objektíven nézve minden kérdésre jól felel, de valami belső hang mégis azt súgja, hogy nincs valami rendben. Ebben az esetben hallgass rá, ne vedd fel. Személyes tapasztalatból tudom, hogy ilyenkor nem válik be a jelölt. Volt, hogy ketten interjúztattunk, minden kérdésünkön átment, mind a kettőnknek volt valami rossz érzése, de objektíven azt kellett mondanunk, hogy felvennénk. Felvettük és 1 hónap után meg is kellett válni a jelöltünktől, nem tudtunk együtt dolgozni.

Az interjúk kapcsán a jelöltnek szerintem fontos tudnia, hogy az interjúztató nem azért van ott, hogy őt szívassa. Sokszor az interjúztató ugyan úgy izgulhat. Van, hogy az interjúztató az interjú előtt 5-10 perccel még dolgozott, így ráhangolódni se tud rendesen egy interjúra, persze reméljük ilyen ritkán fordul elő. Nekem az a tapasztalatom, vagy legalábbis én az interjúkon arra törekszem, hogy az inkább egy jó beszélgetéshez hasonlítson, mintsem egy egyetemi vizsgához. Gondolkodjunk közösen, ismerjük meg, hogy a jelölt tényleg milyen. Én nem egyszer tanultam a jelöltektől már az interjú folyamán és próbálok én is 1-2 hasznos útravalót adni nekik akkor is, ha nem is vesszük fel végül.

Aki fejlesztő, vagy fejlesztőket interjúztat, azoknak javaslom, hogy nézzék át az alábbi oldalt: The Five Essential Phone-Screen Questions. Nem mai blog bejegyzés (10+ éves), de szerintem még most is megállja a helyét. Aki nem tud helyes szintaktikájú kódot írni, nem ismeri az OO design-t, nincs tisztában a reguláris kifejezésekkel, nem ismeri az alapvető adatszerkezeteket, vagy nem bánik jól a bitekkel, az gondolkodjon el róla, hogy megvannak-e a helyes alapjai ahhoz, hogy igazán jó fejlesztő lehessen. Tudom, hogy ma már ennél magasabb szinteken kódolunk, de ezek nélkül mégis úgy érzem nem lehet elég stabil az alapunk.

A HiredInTech oldal segített nekem még 2 tipikus interjú kérdést alaposan megérteni. Az egyik az algoritmusokkal (algorithm design) kapcsolatos, a másik a rendszerek tervezésével (system design). Nagyon jó leírás és példa van arra, hogyan kell ezeket végigcsinálni és meg lehet azt is tanulni, hogy interjúztatóként mire kell odafigyelni, hogyan lehet segíteni. Az algoritmusokkal kapcsolatos 5 pont szerintem nem csak a programozóknak, de más területen dolgozóknak is hasznos lehet.

1. Követelmények beazonosítása
2. Ötletek végiggondolása
3. Komplexitás meghatározása
4. Kódolás (Megvalósítás)
5. Tesztelés

Sokszor esünk abba a hibába, nem csak interjún, de valós projektekben is, hogy egyből a 4-es ponttal kezdünk. Nem ismerjük pontosan mit kell csinálni, nem nézzük meg, hogy van-e több megoldási javaslatunk, azok mennyire lesznek jók futásidőben, egyéb erőforrásokban, csak belecsapunk a közepébe. Ezután pedig van, hogy az 5-ös pontot is elhanyagoljuk, nem tesztelünk teljeskörűen. Örülünk, hogy találtunk egy megoldást és hátradőlünk. Szerintem aki programozott, csinált már hasonlót, de legalább ismer egy embert, aki hallott már olyat, hogy valaki így járt el :)

A rendszertervezés se ördögtől való logikán alapul, hasonló az előzőhöz:

1. Követelmények és use casek (használati esetek) összeszedése
2. Absztrakt tervek készítése
3. Szűk keresztmetszetek beazonosítása
4. Skálázhatóság

Egy magyar KKV-ban dolgozó vezetőként sajnos úgy érzem nem lehetek annyira válogatós, mint a Google. Tanulni azonban mégis csak sokat lehet a fent leírtakból. Én nem tehetem meg, hogy inkább nem veszek fel két jó jelöltet, nehogy véletlen felvegyek egy olyat, akit aztán később el kell bocsátani. Ismerősöm mesélte, aki a Google-nél dolgozik hogy az egyik csoportban volt aki nagyon nem akart dolgozni és egy évig tartott, míg végül elbocsátották. Addig keresték, hogyan tudnák megmenteni, felzárkóztatni, másik csapatot találni neki. Mi ezt nem engedhetjük meg. Törekedjünk persze arra, hogy olyan jelölteket vegyünk fel, akik be fognak válni. Azonban ha ez nem így lesz, akkor nekik is és magunknak is azzal tesszük a legjobbat, hogy a legrövidebb időn belül elválnak útjaink és így lesz lehetősége megtalálni a számára megfelelő vállalatot.

Szeretném azért azt is elmondani még, hogy nem kell csüggednünk, ha nem járunk még ott, ahol a Google. Nekik se ment minden az első naptól kezdve. Az értékrendjük ugyan nem sokat változott és az elejétől tudták, hogy számukra mi fontos, de a kiválasztási folyamatuk korántsem volt nyerő és voltak tévutak. Az első pár évben volt hogy 30-40 interjún is át kellett essenek a jelöltek, ami 6-9 hónapig tartott. Utálták a fejlesztők a Google-t, mert ez egy baromi hosszú folyamat. Pedig Laszlo Bock arról is ír a könyvében, hogy az interjúztatók a jelöltet már az első fél percben megítélik és tesztek bizonyítják, hogy itt már 95%-ban meg is hozták a döntést. Az interjú maradék része csak arra kell, hogy bizonyítsák maguknak a jelölt tényleg tudja vagy épp nem tudja, amit elvárnak tőle. Volt, hogy a legjobbakat akarták megtalálni egy igen kacifántos úton. Óriási plakátokat helyeztek el egész Amerikában, aminek megfejtése önmagában már egy felvételi feladat volt. Ezután a weboldalt meglátogatva további rejtvényeket kellett a jelölteknek megoldani. Azt hiszem ebből a folyamatból végül senkit se sikerült felvenniük.

Végezetül aki eddig eljutott az olvasásban, annak legyen itt pár érdekes, elgondolkodtató kérdés, melyet a Google is használt korábban. Szívesen fogadok megoldásokat a csaba [at] szirjak [dot] com címre.

1. Honnan ered a Google neve? (Ebben még segítek egy kicsit: Names of large numbers)
2. Van 9 teljesen egyforma golyód és egy kétkarú mérleged. Az egyik golyó hajszálnyival nehezebb a többinél. Hány méréssel tudod megtalálni a nehéz golyót.
3. Írj egy olyan függvényt, ami megközelítőleg visszaadja a PI értékét és ehhez az összeadás, kivonás, szorzás, osztás műveleteket használhatja, illetve egy random szám generátort, ami 0-1 közötti értékeket ad vissza.
4. Hogyan állapítod meg egy tetszőlegesen magas (N emeletes) épület esetén 2 tojás segítségével, hogy melyik az az emelet, ahonnan a tojást leejtve az még épp nem törik össze.

Ti milyen érdekes kérdésekkel találkoztatok interjúkon? Ti milyen kérdéseket szoktatok feltenni a jelölteknek?

Ebben a bejegyzésben azt szeretném megosztani veletek, hogy milyen csodálatos kalandban volt részem az elmúlt 2 hónapban. Rengeteget tanultam és sok mindent gondoltam át annak hatására, hogy a Google azt akarta váltsak vissza a vezetői pályáról a fejlesztői szerepbe, ha csak egy rövidebb időre is...

Júliusban kaptam egy LinkedIn üzenetet, hogy tudnék-e úgy kódot írni whiteboardon is a Google irodájában, mint ahogy azt tettem Sublime-ban a Game of Life esetén. Egy Google fejvadász ugyanis megtalálta a http://csaba.szirjak.com oldalon az Easter Egget. Az oldalt tavaly év végén hoztam létre, hogy gyakoroljam az AngularJS-t és a Material design-t és az Easter Egg is azt a funkciót töltötte be, hogy tanuljak pár új dolgot.

Mit tehet ilyenkor az ember, ha megkeresik a világ egyik legjobb cégétől, azzal a kérdéssel, hogy szeretnél-e nálunk dolgozni? Egyeztettem a cégünk tulajdonosával, hogy ez egy olyan lehetőség, amit ki kell próbálni, mert sokat tanulhatunk és profitálhatunk belőle. Igent mondtam hát a kihívásra. Igaz, hogy 5 éve nem programozóként dolgozom és munkahelyen nem is kódolok, az angolom pedig épp csak annyira elég, hogy külföldön boldoguljak vele, vagy egy kocsmában beszélgetni tudjak, de hát ők tudják, én sokat nem veszíthetek. Mivel nem voltam teljesen biztos magamban, megkérdeztem azért Adrit és Anyut is, hogy mit szólnak egy ilyen lehetőséghez, ha összejönne tényleg tudnának ebben támogatni? Meglepetésre igen volt a válasz. Ezek után megpróbáltam eltántorítani a fejvadászt, hogy nem elég jó az angolom és nem fejlesztőként dolgozom. Nem sikerült. Azt mondta, hogy az számít, hogy mennyire jó a problémamegoldó képességem, mennyire tudok jól kommunikálni (nem az angolom mennyire jó), megérteni a problémát és kooperatívan dolgozni. Ezek mellett még nagyon fontos, hogy milyenek a programozói alapismereteim, mennyire tudok big picturben, architektúrákban gondolkodni. Elárulta azt is, hogyan talált meg. Megnézte 2004-ben, hogy milyen eredmények születtek az ACM programozó versenyeken és mi éppen ekkor a csapatunkkal kijutottunk a közép-európai döntőbe. Azt mondta, hogy gondoljam át komolyan, hogy bele akarok-e vágni, mert ha igen akkor 1-2 hónapig is eltarthat és komoly felkészülést igényel.

Döntöttem, vágjunk bele, a sok interjú valamelyikén úgyis elvérzek, de legalább elmondhatom, hogy interjúztam a Google-nél és biztosan tanulok is belőle. Az első 2 kör Google Hangoutos interjú, amin 45-60 percben valamilyen algoritmust kell kitalálni egy adott problémára. Az első akadályt viszonylag könnyen vettem, az algoritmusra hamar kitaláltam a megoldást, a kódolás is egész jól ment Google Docs-ban. Egy pici segítséget kaptam, amit felhasználva még szebbé tudtam tenni a kódot, ennek elvileg örült az interjúztató, hogy be tudtam építeni a kapott segítséget. A következő alkalommal pedig egy olyan függvényre volt szükség, ami képes más függvényeket becachelni, illetve el kellett mondanom, hogyan valósítanám meg a Google keresőmezőjét, milyen kihívások vannak frontend és backend oldalon. Az első interjú úgy éreztem jól sikerült a második már annyira nem, de azt mondták, hogy elégedettek voltak, mikor tudnék kimenni Zürichbe? Mivel ez augusztus közepén történt és sok meló várt rám szeptemberben, ezért azt kértem, hogy szeptember vége legyen az időpont. Közben kiderült, hogy nem 3 interjú vár még rám, hanem 5…

Érdemes tudni, hogy a Google ha ajánlatot tesz valakinek, akkor az ajánlatát 1 évig fenntartja. Az interjúk pedig eléggé általánosak, nem konkrét pozíciókra keresnek embert, így gyakorlatilag bármely irodába mehetsz, és választhatsz projektet is azok közül, ahova kell ember. A fizetések a helyi országhoz vannak igazítva. Én azért választottam Zürichet, mert nincs messze, ott van egy jó barátom már 4 éve a Google-nél és talán itt a legmagasabb a fizetés is az egész világon.

Eredetileg nem gondoltam, hogy idáig eljutok, így azzal sem kalkuláltam, hogy készülni kell majd. De ha már így alakult, akkor nem tehetem meg magammal, hogy felkészületlenül megyek. Készítettem hát egy 1 hónapos tervet, hogy melyik reggel, melyik hétvégén mit fogok tanulni. Algoritmuselmélet, Rendszertervezés, Elosztott rendszerek, Java, Javascript. Hétvégén egész jól is ment a készülés, de hétköznap nem. Ezért inkább azokra a részekre koncentráltam, amit tényleg élveztem is, meg amit használni is tudok/fogok a közeljövőben. Nagyon meglepő volt, hogy milyen segédanyagokat biztosítottak számomra, kaptam rengeteg linket a felkészüléshez a Google-ös HR-estől. Érdemes lehet ebből tanulni amúgy. A http://old.hiredintech.com/app oldalt kiemelném a többi közül, mert ez volt számomra a leghasznosabb és ebből tudom a legtöbbet beépíteni a saját interjúztatási folyamatunkba is. A Java-t annyira néztem csak át, hogy algoritmusokat le tudjak kódolni benne, de Design patterneket már nem gyakoroltam. A Javascript azonban nagyon lázbahozott, mert szeretem a funkcionális programozást és tetszenek azok a dolgok, amik az ES6-tal bekerültek (http://es6-features.org/#Constants). Ezt ráadásul két kedvenc programozós oldalamon is tudtam gyakorolni, mind a kettő támogatta az ES6-ot. A http://www.codewars.com/ oldalon 5 kyu-ig jutottam, szerintem 30-40 feladatot csináltam meg, míg a https://www.codingame.com/ oldalon sikerült Clash of Code-ban (https://www.codingame.com/leaderboards/clash/country/hu) a legjobb magyarnak lenni. Ezek mellett amúgy elolvastam Bock László - A Google titok című könyvét (https://www.libri.hu/konyv/laszlo_bock.a-google-titok.html), hogy a cég kultúrájával jobban tisztában legyek.

Az interjú időpontja szeptember 26-27-re volt kitűzve. Hétfőn repülés és ismerkedés a várossal, majd kedden 5 interjú és este hazarepülés. Sajnos valahogy sikerült a Google-nek elfelejteni lefoglalni a repülőt, így 2 nappal előtte szóltak, hogy csúsztassuk már az interjút. Ez azért egy csöppet csalódás, de ezen már ne múljon. Áttettük egy héttel későbbre, és így hétfő helyett vasárnap lett az utazás és hétfő az interjúk (október 2-3).

A repülőt, a szállást a Google intézte, ezekért nem kellett külön fizetni. A kajára is biztosítottak napi $50-et, amit számlával kell igazolni, de ezzel nem foglalkoztam. A szállás a B2 Boutique Hotel + Spa-ban volt, amit a Google irodájától 50m, de lehet hogy 100m is megvan gyalog. Ennek örültem, hogy reggel nem azon kell majd stresszelni, hogy odatalálok-e. A repülő azonban nem volt a legpraktikusabb, mert hazafelé csak átszállásos jegyet tudtak venni. Nem merték bekockáztatni a korábban induló közvetlen járatot, így hétfőn Frankfurtot is meglátogattam egy 10 perces gyors 1 km-es séta erejéig.

Az egész utazás egyébként tök jól jött ki, kaptam egy csomó segítséget, amit így utólag is köszönök mindenkinek, mert így tudtam csak az interjúra koncentrálni, nem kellett az utazáson stresszelni. Az egyik barátom hajnalban kivitt a reptérre és még a szavazásra is be tudtunk előtte ugrani. Ikertesója pedig hétfőn jött ki értem este 11-kor. Egykori évfolyamtársam és jó barátom Zürichben fogadott autóval és elvitt a szállodához. Puccos kis 4 csillagos szálloda, a tetőn nyitott medencével. Szép nagy szobát kaptam, üvegfalú fürdőszobával, hogy az agyból lehessen látni ha zuhanyzik valaki. Óriási puha ágy, hatalmas TV, rengetegféleképpen állítható hangulatvilágítás. De most pont nem azon volt a hangsúly, hogy ezeket kipróbáljam, barátommal helyette elmentünk megnézni a Google irodát kívülről, hogy másnap ne tévedjek el azon az 50 méteren :). Utána elmentünk ebédelni. 1 pizza 6000-7000 Ft a Vapianoban (ismerősöm meghívott, köszi!), és ez kábé igaz egész Zürichre, hogy minden kaja háromszor annyiba kerül, mint itthon. Szerencsére a fizetések meg még ennél is többszörösek. Kaja után megnéztük a várost, és közben a barátom mesélt egy csomó dolgot, hogy itt mi hogyan működik. Van egy szép nagy tó, olyan mintha az ember a Balaton mellett lakna, körbe meg hegyek. A város azonban nekem kb olyan volt, mintha Budapesten lennék, de tény, hogy nem a városoktól, építészettől szoktam lázba jönni. Délután 16:30 körül kimentünk a haveromékhiz, akik 10-15 percre laknak a Google-től, egy Zürich melletti kisvárosban. Itt megismerhettem a 1.5 éves kislányát, akivel korábban még nem találkoztam és találkoztam kisfiával is, aki már 5 éves. Korábban őt még csak a földön kúszva láttam, most meg azzal fogadott az ajtónyitáskor ordítva, hogy “Szia Chaar-Lee, úgy vártunk már! Miért késtetek?”. Vaó :) Párjával sajnos nem tudtunk sokat beszélgetni, pedig kíváncsi lettem volna, hogy feleségként milyen élmény odakint, mik a tapasztalatok, de ez azt hiszem ráér addig, ha netalántán ajánlatot tennének (hisz úgyis csak minden 400. embernek adnak ajánlatot). A gyerekekkel viszont tök jót játszottunk, a végén a kislány is megkedvelt, akinek épp aznap volt a névnapja. Este aztán haverom visszavitt a szállásra és hagyott pihenni, hogy készülni tudjak a nagy napra.

Írtam magamnak még itthon indulás előtt egy checklistet, hogy miket kell átnéznem. Kinyomtattam 6 system designos kérdésre a megoldásomat, feltettem a laptopra a kódokat amiket Java-ban és Javascriptben írtam, illetve volt még pár segédlet, pl a http://bigocheatsheet.com/, amivel jó ha tisztában van az ember, ha a Google-höz megy. A Google jófej volt és kaptam egy voucher-t, ami vagy egy sörre, vagy egy bor elfogyasztását biztosította. Mivel a szálloda egy több mint 100 éves sörfőzde helyén vagy épp rá épült, ezért a sört választottam. Az étkezde egy hatalmas könyvtár volt, 2-3 emelet magasban körben könyvek voltak a polcokon. 3 hatalmas csillár lógott a mennyezetről, amit egyedileg ide készítettek és vagy 15-20 fém kör alkotta, amikre zöld borosüvegek voltak fejjel lefelé felrakva, ezekben pedig világított pici izzó. Baromi hangulatos volt. Ahogy pedig körbenéztem kb azt láttam, hogy az a pár ember aki most itt van az vagy a Google-höz jött interjúra, tipikus programozó fejük volt, vagy a Google egy másik irodájából jöhetett megbeszélésre, mert nekik meg Google logó volt a ruhájukon. A sör mellé kaptam némi rágcsát, chips, M&M’s, és pikáns mogyoró. Miután ezt szép lassan elfogyasztottam felmentem a szobámba, átnéztem még amit átakartam és vettem egy jó nagy meleg zuhanyt. Ugrás az ágyba és alvás.

Reggel előbb keltem, mint ahogy az ébresztő be volt állítva. Ez mégis csak annak a jele, hogy izgulok, pedig azt hittem nem fogok. Hisz interjúztattam már több mint 100 embert és ezt is úgy próbáltam felfogni, mint egy jó kis beszélgetés, de lehet ezt az agyam mégse hitte el teljesen. Lementem reggelizni, szépen nyugisan intéztem a dolgokat. Majd összepakoltam a szobámban és 9:20-kor elindultam, hogy nehogy elkéssek. 9:45-re kellett odaérni és volt még hátra egy checkout az első emeletről és egy 50 méteres séta. A checkout lehet 1 percig is eltartott a séta pedig lehet 2-t is kitett, így 9:23 körül ott voltam az iroda előtt. Alapszabály, hogy ilyen időpontokra nem érkezünk korán, max 1-2 perccel előtte, így párszor körbejártam a Google irodákat és közben próbáltam az agyam átállítani angolra. Szerintem vagy 3x biztos bemutatkoztam magamnak séta közben angolul :) 9:43-kor pedig egy nagy lélegzetvételt követően megindultam az ajtó felé. Odabent a recepciós nem azt mondta, hogy mindjárt hívom a HR-est, akivel találozom, hanem azt, hogy itt van egy érintőképernyős masina, írjam be hogy ki vagyok, kihez jöttem és milyen célból. Majd ezután jön a személy akit keresek. Oké. 5 perc várakozást követően jött is a HR-es, aki hozza a nyomtatott kitűzőt, amivel közlekedni fogok tudni a Google-nél. Közben néztem a 3 nagy TV-t a várakozóban, amin kis négyzetek, téglalapok tűntek fel a Google színeiben és benne írások jelentek meg, mintha valaki gépelne. Egyszer csak azt látom, hogy “népszavazás 2016”, majd “népszavazás eredménye”, majd “444.hu”. Hmmm… Realtime mutatja ki mire keres éppen és szinte mindig volt magyar keresés a képernyőn. Vicces és ötletes. Legalább látják a dolgozók minden nap, hogy amin dolgozik cég azt használják is emberek (ja, kb 1.000.000.000 naponta).

Kisérőm felkísért az interjú szobába és megkezdődött a legjobban várt, legizgalmasabb rész. Innen már nincs menekvés, most aztán jönnek emberek és megkérdeznek jól, mindezt persze angolul. Az első kettő algorituselmélet volt. Általános iskolában tanult matematikai műveletek, kódolás, dekódolás, fél információk. Próbálnak tesztelni minden irányból, hogy mire hogyan reagálok, hogyan oldom meg a problémát. Ezt követően a Javascript tudásom lett vizsgálva, de még ez is eléggé algoritmusos téma volt, egy fura rendezést és szűrést kellett implementálni egy adatsoron. Az interjúztatók konkrétan egymás kezébe adták a kilincset, pihenés nem volt.

A harmadik után a negyedik srác már azért jött, hogy elvigyen ebédelni és menet közben beszélgessünk és megmutassa az irodát. Ő nem jegyzetelt semmit, tőle szabadon kérdezhettem, amiről beszéltünk arról a HR elvileg nem tud semmit. Volt három étterem amiből lehetett választani, mediterrán, keleti és vegyes. Én a mediterránt választottam. Teljesen tömve volt, nagy volt a nyüzsgés. 2500 ember kajál itt ingyen. Közben elmentünk a konditerem mellett, amit szintén tudnak használni az alkalmazottak. Az itt dolgozó barátom mondta, hogy van squash pálya is, illetve squash liga a cégben, így biztosan van megfelelő partner a játékhoz. Kaja után megnéztünk pár minikonyhát az egyes emeleteken. Szép nagy kávéfőzők, ahol te magad darálod a kávét, meg te töltöd meg, olyan mint az éttermekben. Valamelyikben csocsóasztal volt, valamelyik meg olyan volt mint egy könyvtár. Itt volt egy polcnyi társasjáték, nagyjából 100 darab. Ebből 20-30% jófajta, ami nekem is megvan. De a Dominion hiányzott a készletből, ez azért csalódás.

Lejárt az időnk és társalgó partnerem elkísért az új interjú szobába. Itt egy valószínüleg orosz, idősebb srác fogadott. Ő szerintem system designból kérdezett ki elsősorban frontend vonalon. Szerette volna tudni, hogyan tárolnék kliens oldalon ilyen meg olyan adatokat. Aztán arra volt kíváncsi, hogy mit csinálnék, ha egy product manager azt mondja, hogy lassú az alkalmazás. Feltettem 6-8 kérdés a teszteléshez, hiba feltáráshoz, de mindegyikre az volt a válasz, hogy ez nem oldja meg a problémát. Aztán áttértünk arra, hogy oké, mit lehet tenni ha gyorsítani szeretnénk az alkalmazást. Erre is ledaráltam 6-8 lehetőséget, erre úgy vettem észre elismerően jelzett vissza, hogy szép listát adtam. Mondta amúgy, hogy ez egy nyitott kérdés, nincs jó válasz csak érdekli hogyan közelítem meg a problémát. El lehet lesni, tanulni ezt a megközelítést :) Utána azt hiszem német srác jött. Ismét Javascriptből kaptam a kérdéseket. Itt a papíron egy kód, mit fog ez kiírni? Vicces volt, mert minden sor kódot kétszer át kellett nézni mit is fog csinálni. Volt benne olyan is, amit nem szabad, de azért működik. Szerencsére meg tudtam adni a helyes megoldást, mert később begépeltem emlékezetből a kérdést és az jött ki, amit én is mondtam. 

Ezt követően egy olyan függvényt kellett írnom, ami egy tetszőleges másik függvényt N alkalommal próbál meg lefuttatni, egészen addig amíg nem sikerül neki. Közben pedig a success és error callbackeket is kezelni kell. Adtam egy rekurzív megoldást, amit szerintem elsőre nem értett, mert kérte magyarázzam el még egyszer, miért fog ez működni. Aztán mondta találjunk egy egyszerűbb megoldást. Itt 5-10 percig félreértettük egymást, mert én azt hittem aszinkron függvényről beszélünk és ezért vannak callbackek. Aztán mondta, hogy egy szinkron függvény. Így már meg tudtam adni azt a megoldást amire vágyott.

Az interjú után pedig lekísért a recepcióra, majd elköszöntünk. Még érkezéskor kaptam egy welcome package-t, amiben van egy gömb alakú rubik kocka és chrome logót vannak rajta. Kaptam még egy Google nyomatos füzetet, meg egy logózott kulacsot. Felpakoltam hát és elhagytam az irodát. Haverommal megbeszéltük még előző nap, hogy hívjam és kikísér a vonathoz. Így is lett. Innen már csak az utazásra kellett koncentrálnom és átgondolni, mi hogyan sikerült.

Ezt azonban baromi nehéz megmondani. Én jól éreztem magam, nem vagyok elégedetlen, úgy érzem, hogy nem tudtam volna jobban felelni a kérdésekre. A kérdéseknek azonban nincs egzakt helyes megoldása azt se tudom, hogy eljutottunk-e addig ameddig az interjúztatók szerették volna, hisz volt amikor egy problémán volt amikor két kérdésen is dolgoztunk. Még mindig úgy érzem, hogy egy álomban vagyok és ez nem történhetett meg, meg az se, hogy ajánlatot tegyenek, hisz az egész tök szürreális. 5 éve nem dolgozom programozóként, nem jó az angolom, mégis miért vennének fel? Közben meg az interjúk alapján még el is tudnám hinni, hogy tetszettem nekik...

2 hét várakozás...

Öcsémékhez tartunk, hogy unokaöcsémet a második születésnapján felköszöntsük. Feleségem kérdezi, hogy hívtak-e esetleg. Nem, nem hívtak, de lehet írtak emailt, nézd meg a telefonomon. Még jó, hogy mások aggódnak helyettem is és többször kérdezik meg, hogy jött-e visszajelzés, mint ahogy nekem eszembe jut. Ránézett a leveleimre és azt látta, hogy jött levél a Google-től. Pulzus megemelkedett vagy 10-zel. Elkezdte felolvasni angolul a levelet, amiben ez állt: I am afraid I do not have good news: the overall feedback was not supportive enough for us to proceed with your application. Fura, semleges érzés. Egyszerűen abszurd szituáció, mert a két hónap alatt attól féltem a legjobban, hogy mi van ha mégis ajánlatot tesznek? Adjam fel a vezetői szerepemet, amiben úgy érzem megtaláltam önmagam? Nem lesz elég nekünk a januárban érkező Baba, mint változás? Kell nekünk új ország, régi szerep és hiányzó ismerősök, rokonok? De hát ez mégis csak a Google... Szerencsére lezárult, nem kell ezen tovább agyalni. Én pedig végülis maximálisan elértem a célomat, testközelből ismertem meg, hogy a világ egyik legjobb cége hogyan csinálja a felvételiztetést, eljutottam egészen a cél előtti utolsó kanyarig, ahol ugyan elbuktam, de ennek valószínüleg így kellett lennie, mert az élet más meglepetéseket tartogat számunkra.

A visszajelzések alapján a system design területen voltam a legügyesebb, ott elégedettek voltak a teljesítményemmel. Úgy látják, hogy inkább high-level tervezésben vagyok erősebb, ami köszönhető valószínüleg a vezetői éveknek. Az algoritmusok és kódolás területén két esetben azt kaptam, hogy határeset, de ez még elég lett volna, míg két interjúztató nem javasolt felvételre. Az egyik azt mondta, hogy túl sok hintre volt szükségem (úgy emlékszem, hogy megkérdezte, hogy mi van akkor, ha nem csak a természetes számok halmazán, hanem az egész számok halmazán értelmezzük a problémát), míg a másik esetben az volt a probléma, hogy a feladat komplexitását lassan számoltam ki. Itt tényleg elkövettem a hibát, hogy egy rövid "nlogn" válasz helyett egzaktul ki akartam számolni 2 paraméter függvényében és ez így lassabb volt. Teljesen igazuk van azonban, lehetett volna jobban is teljesíteni és egy másik szituációban lehet úgy is teljesítettem volna. Most már értem, hogy miért csak minden négyszázadik embert veszik fel és hogy miért írta Bock László, hogy inkább nem vesznek fel 2 jó jelöltet, nehogy 1 olyan bekerüljön, akitől később meg kell válni.

Folytatás ... Mit tanulhatunk 7 Google interjúból?

Régóta szerettem volna már egy Targetprocess bemutatót tartani az ismerőseimnek, ezt most végre sikerült is összehozni. A helyszínt a VCC:Live biztosította és elsősorban qBox-os (egyelőre zárt meetup vezetőknek, de erről írok majd később) barátok vettek rajta részt.

A cél az volt, hogy a Targetprocess filozófiáját röviden egy prezentáció keretében bemutassam, majd izzasztó kérdésekkel bombázzanak, amik a mindennapi működésükben problémát jelentenek és keresik rá a megoldást. Kicsit féltem azért a kérdésektől, hisz ezekre nagyon nem lehet felkészülni, én pedig azt ígértem, hogy élőben adok választ a felvetett problémákra. Azt hiszem egész tisztességesen helyt álltam és a Targetprocess is, mert 90-95%-ban sikerült megválaszolni a kérdéseket.

Akinek kedve van most meg tudja nézni a prezentációt és a bemutatót. Az első videó első fele a prezentációt tartalmazza, ezt követik a felmerült kérdések. A második videóban pedig a kérdések kerülnek megválaszolásra live demo keretében.

Prezentáció és Kérdések

Live Demo a felmerült kérdések alapján

Minden IT cég ügyvezetője a szoftvereit gyorsabban szeretné elkészíttetni. Az idő a legdrágább és legértékesebb erőforrás, így azt nem pazarolhatjuk el újraírásra, refaktorálásra, megbeszélésekre és különböző fizikai tevékenységekre. Igaz ez? Hát, ez attól függ...

Sok cég gyorsan növekszik, lelassul, majd meghal. A megfelelő fejlesztési sebesség esszenciális eleme a túlélésnek. Képzeld el, hogy van egy remek víziód, ami többször bizonyított és sokan hisznek benne. Természetesen tudod (persze ritka ez a valóságban, de tüzeljük egy kicsit a képzeletünket oké?), hogy ez a termék egy valódi sikersztori lehet. Már csak be kellene fejezni.

Van egy csapatod tucatnyi tehetséges és tapasztalt fejlesztővel, összeraktatok és leszállítottatok valamit az elmúlt 2 évben. A csapat kimerült. A jelenlegi termék a vízió kb. 10%-át valósítja meg. Mindenki azt mondja, hatalmas potenciál van benne, de a 10% pont nem elég ahhoz, hogy betörj a piacra. Küzdesz még pár hónapig, átlagos a látogatottság, átlag alattiak az értékesítések, elfogy a pénz, és egyszer csak vége, vége a cégednek. A nagy víziók lassú halált halnak. Kit hibáztathatunk? Lehet, hogy a probléma volt túl nehéz és a 2 év éppen csak elég lett volna a megvalósításra? Lehet, hogy a csapat túl gyorsan rohant előre, volt pár jó release-ük, de a végén eltemette őket a probléma komplexitása és a felhalmozódott technológiai adósságok? A sebesség a szoftverfejlesztésben egy meglehetősen extrémen összetett entitás. Egy csomó dolog hat rá, meglepően különös módokon. Ebben a cikkben a sebességgel kapcsolatos gondolataimat próbálom megosztani.

A sebesség két oldala

A legtöbb ember hajlamos azt hinni, hogy a Sebesség egy egyszerű dolog, de ez nem így van. Két nagyon eltérő típusa van a sebességnek: Rövidtávú sebesség (Sprint) és Hosszútávú sebesség (Maraton). A Sprint és Maraton egy tökéletes analógia ebben az esetben. A szoftverfejlesztésben (és természetesen a futásban is) nem csinálhatod egyszerre mind a kettőt. Vegyünk egy absztrakt becslési mértékegységet, mint például a pont. Teljes gázon dolgozva egy Sprintben 100 pontot is képes szállítani a csapat havonta. Itt is van az első véleményem:

Nem tudsz üzemeltetni ilyen sebességű Sprinteket egy hosszútávú termékfejlesztésnél.

Meglehet, hogy 3-6 hónapig is képes vagy 100 pont/hónap sebességen pörögni, de nagyon valószínűtlen, hogy ezt tudod egy évig csinálni. Sőt mi több, erős visszaesés (recoil) várható a nagy iramú (pace) fejlesztéseknél. És egy napon meg fogsz bánni mindent.

Egy ponton a legtöbb fejlesztő el fogja érni a "fuck it" pontot (piros pötty) és óriásit fog esni a teljesítményük.

A te célod a lehető legnagyobb sebességen teljesíteni folyamatosan hosszútávon (évekig). Erről szól a Maraton. Kitartásra és egyenletességre van szükséged.

Hogyan csináljunk szoftvert hosszútávon? Nah ez az "1 millió dolláros kérdés". A legvalószínűbb, hogy a válasz minden cégre egyedi, de építhetünk egy ésszerű elnagyolt modellt, ami segíthet a dolog megértésében.

Sprint, Maraton és... Ciklikusság!

Első ránézésre csak három lehetőségünk van...

Első lehetőség: Extrém Sprint

Pöröghetsz teljes sebességen, dolgozhatsz 12-14 órát naponta, töltheted magadba az energiaitalt, koffeint, cukrot és isten tudja még mi egyebet. Lehetsz éjjeli bagoly, alhatsz néhány órát naponta, és minimalizálhatod a kajálásra, higéniára és a mozgásra fordított időt. Egy hónapot adok neked. Esetleg hármat, ha nagyon jó formában vagy. A legjobb ebben az üzemmódban, hogy mindenki tudja mennyire rossz. A kiégés garantált és gyors.

Széljegyzet
Ismertem egy embert, aki egy egész éven át ebben az üzemmódban dolgozott! Egy csomó dolgot tanult és hatalmasat fejlődött, de ez nem volt ingyen. Valószínű, hogy a jelenlegi egészségügyi problémáit az Extrém Sprint üzemmód okozta. Okos ötlet elcserélni az egészséget a tapasztalatra? Nem hiszem.

Második lehetőség: Mérsékelt Sprint

Dolgozhatsz 8-10 órát naponta, kipréselve magadból a maximális produktivitást. Nincs diskurálás, nincs munkahelyi sport és nincs semmi szórakozás. Néhány cég nem tesz semmit azért, hogy a munka izgalmas és kihívásokkal teli legyen vagy éppen szórakoztató. A projektek mindig késésben vannak és mindenki nyomás alatt dolgozik. Sajnos, ez az üzemmód évekig is eltarhat. Az emberek hozzá tudnak szokni és már észre sem veszik, hogy milyen szánalmasak. Megpróbálnak otthon kompenzálni a családdal és a hobbyval. Valódi veszély, hogy néhány hónapot követően a produktivitás esik és ezt észre sem veszi senki. Évekbe telhet mélyebben elgondolkodni magadról és megérteni, hogy mi történik.

Harmadik lehetőség: Maraton

Ez az üzemmód tűnik optimálisnak. A legjobb formádat hozod 6-8 órában naponta és marad idő pihenésre és mozgásra. Nem akarsz minden egyes percet kihasználni és azt a luxust is megengeded magadnak, hogy egy problémán kicsit elgondolkozzál. Nem kell a dolgokat AZONNAL áttolni! Ez jól hangzik. Habár, sok menedzser nem elégedett a Maraton üzemmód iramával. Gyorsabban akarják a dolgokat elkészíteni. Hiszem, hogy ez az egyszerű mód igen ritka a valóságban. A legtöbb cégnél a menedzserek megpróbálják a sebességet felturbózni a leghülyébb módokon, túlóráztatnak, tolják a feladatokat és próbálnak a "mi vagyunk a hősök" érzéssel motiválni.

Első ránézésre úgy tűnik, hogy nincs több lehetőségünk. De én azt hiszem, egy mégis csak akad. Bár őszintén szólva erről még soha nem hallottam.

Negyedik lehetőség: Ciklikus fejlesztés

Nem az Iteratív fejlesztésről beszélek. Tény, hogy az iteratív fejlesztést egyaránt alkalmazni lehet a Mérsékelt Sprintben és a Maraton üzemmódban is. A Ciklikus fejlesztés azonban az, amikor vegyíted az üzemmódokat. Egy rövid időre Sprintelhetsz, majd váltasz a Maraton üzemmódba. Véleményem szerint a helyes ütemezés:

1 hónap - Gyors Sprint
3 hónap - Maraton
1 hónap - Gyors Sprint
...

Hadd magyarázzam el mit értek Gyors Sebesség Üzemmódon. Ebben az üzemmódban a csapat (vagy akár egy teljes cég is) felhagy minden másodlagos tevékenységgel: az összes jövővel kapcsolatos megbeszélések, tanulás, HR tevékenységek, stb. A csapat az értékteremtésre fókuszál: kódírás, tesztelés, dokumentáció és szállítás.

A Gyors Sebesség Üzemmód egy relaxációs héttel ér véget. Ez a hét dedikáltan a refaktorálásra, a beszélgetésekre és a jövővel való foglalkozásra van szánva.

A haszon tiszta - az átlagsebesség magasabb lesz, mint a Maraton módban. A Gyors Sebesség Üzemmód a megfelelő Maraton periódusok után nem stresszes. Sőt mi több, az olyan alkalmak motiválóak lesznek, amikor a csapat felgyűri az ingujját, teszi a dolgát és gyorsan szállítanak. Amikor szállítasz valamit, az jó érzéseket vált ki benned. Ez egy remek teljesítmény, egy mérföldkő elérése. Kábító érzés tud lenni. Talán ezért van az is, hogy az emberek néha hajlandóak Extrém Sprint üzemmódban dolgozni.

Folytatás: Sebesség a Szoftverfejlesztésben II.

Az erdeti cikk itt található: 

https://www.targetprocess.com/articles/speed-in-software-development/

Több éve nem írtam már blogbejegyzést... Ennek azonban legfőbb oka az volt, hogy nem volt kellő motivációm és elegendő időm. Most azonban úgy döntöttem, hogy visszatérek!

A korábbi blogommal szemben, most nem elsősorban magamról, hanem szakmai témákról szeretnék írni. Közel 5 éve hagytam abba az írást, és 5 éve lettem vezető. Azt hiszem elég tapasztalatra tettem szert ahhoz, hogy tudjak már miről írni ebben a témában. A vezetést és projektmenedzsmentet pedig a Targetprocess szoftveren keresztül szeretném bemutatni nektek saját cikkekkel és pár általam hasznosnak ítélt cikk fordításával. Hiszek benne, hogy ez az eszköz a hazai szakmának is nagy segítséget fog nyújtani, ahogy nekem is sokat segített megérteni módszertanokat és fogalmakat. Én teljesen beleszerettem, mert nagyon passzol a gondolkodásmódomhoz és szinte bármit meg tudok benne csinálni, amit csak szeretnék. Ami pedig hiányzik, azzal jellemzően pár héten belül ki is jönnek. Valami gondolatolvasó is be lehet építve a szoftverbe, mert félelmetes látni azt, hogy az igény beküldése nélkül is tudják mire van szükségem. A napokban az egyik kolléga hiányolt 2 featuret és még aznap délután megjelent a TP-ben :)

A lényeg azonban az, hogy szerelmese lettem ennek a szoftvernek és azt tűztem ki célul, hogy ezt a remek eszközt megismertetem Magyarországgal. A nyáron vizsgát tettem belőle és Targetprocess Certified Expert lettem. Most már hivatalosan is tudok segíteni cégeknek abban, hogy megreformálhassák folyamataikat.

Vannak akik ismernek, de biztos vannak olyanok is, akik még nem, ezért pár dolgot elárulnék magamról azoknak, akik nyomon fogják követni írásaimat. 2000 elejétől foglalkozom szoftverfejlesztéssel és elsősorban webes technológiákat használtam, használok. PHP-ban fejlesztettem saját CMS keretrendszert, amivel több mint 100 projektben vettem részt. Java-ban fejlesztettem vesedialízis gépet, de a TV-s vetélkedőkhöz is ebben írtam a háttérszoftvereket (Legyen Ön is Milliomos, 4N4LN, Bumm!, stb...). Volt több saját cégem is, ebből az egyikben pókeres TV műsorokhoz adtunk technikát, így szinte minden Magyarországon készült pókerműsorban benne voltam. 5 éve fejlesztői csapatokat vezetek és mind a két munkahelyemen sikerült az agilis módszertanokat bevezetni. Azt gondolom, hogy a Scrumot és a Kanbant is kellően értem, tudom alkalmazni, erre bizonyíték lehet az is, hogy Coach nélkül sikerült a módszertanok bevezetése. A jelenlegi munkahelyemen pedig a hagyományos projektmenedzsmentről is sokat tanultam, és nagyon izgalmasnak tartom, ahogy az agilitás és a vízeséses módszertanok előnyeit össze lehet házasítani. Mind a kettőnek megvannak a maga előnyei és hátrányai, de tapasztalatom szerint nagyon nehezen alkalmazhatóak ezek vegytisztán minden projektre. Ezért jó az, ha az ember több mindent ismer és ki tudja választani adott szituációban a számára legmegfelelőbbet. Egy kicsit visszakanyarodnék még azonban a programozáshoz, mert ezzel azért nem hagytam fel :) Jelenleg a Javascript, NodeJS, ES6 és funkcionális programozás híve vagyok, kisebb hobby projekteken és Code Wars-on illetve Codingame-n élem ki programozó hajlamaimat. A tavalyi évben pedig fejlesztettem egy testreszabható társasjátékot Startupper néven, ami szintén a vezetésről és projektmendzsmentről szól játékos formában. Ezen játékokról később biztosan fogok írni még részletesebben is.

Bízom benne, hogy érdekes témákat sikerül majd találni számotokra. Remélem, hogy lesznek olyan esetek is, ahol nem értetek majd velem egyet, így egészséges viták alakulhatnak ki a különböző nézőpontok ütköztetésével.