Mar 15 2011
Kuidas liigutada Fuji mäge
Viimase paari nädala üks kõige poleemilisemaid IT-teemasid Eestis on kahtlemata valimistulemuste (mitte)näitamine, mida, kuidas ja kui palju on võimalik ning praktiline testida jt seonduvad küsimused. PostgreSQL leidis leidis endale ootamatult koha mainstream meedia sõnavaras ja igaühel on oma arvamus või ka mitu.
Vaidlejad kipuvad jagunema kahte leeri:
Ühel pool on need, kes väidavad, et sellise probleemi tekkimine oli üldse absurdne, oleks pidanud palju rohkem ja põhjalikumalt testima, stsenaariume läbi mängima jne. Nende iseloomulik tsitaat on: “kui mina midagi sellist teeksin, siis ma teeks küll palju paremini”.
Teisel pool on inimesed, kes on ilmselt ka ise sarnaselt põletada saanud ning võtavad tagasihoidlikuma positsiooni. Nendelt kuuleb väiteid stiilis: “teatud klientidega ongi väga raske”, “kõik konfiguratsioonid polegi saavutatavad” või “muidugi tahaks me ka paremini teha, aga elu seab omad piirangud” jne (tegemist pole muuseas üldse valimiste või Helmesega seotud rahvaga).
Minu meelest ei taba kumbki pool probleemi tegelikku iva. See, et tarkvaras esineb probleeme, on teatud määral paratamatu. Iga projekt on mingis mõttes uus, igal tarkvaratükil on müriaad sõltuvusi, igas konfiguratsioonis on nendest sõltuvustest erinev kombinatsioon jne. Me võime asju testida kuitahes palju, alati on garanteeritud mingid ootamatused, vähemalt ma ise pole osalenud veel üheski projektis, kus pärast asja valmimist poleks olnud põhjust käega otsaette lüüa ning mõne detaili tähelepanuta jätmise pärast oma taipamatust kiruda.
Lahendus ei peitu mitte selles, et kivist vett välja pigistada ja testmaatrikseid tuhandekordistada, vaid selles, kuidas tekkivatest probleemidest võimalikult valutult üle saada. Miks valimistulemused nähtavale ei tulnud, seda mina ei tea. Võibolla oli tõesti tegemist kriminaalse lohakuse ja puuduliku testimisega, aga võibolla siiski mingi konfiguratsiooni iseärasusega, mida polnud varem võimalik isoleerida.
Aga kui probleem ilmnes, oleks kindlasti olnud võimalik leida parem lahendus, kui järjekindlalt lubadusi anda, et “15 minuti pärast saab korda” ja samas uuesti ning uuesti sama reha otsa kukkuda. Kuna algandmed olid vähemalt laias laastus teada, oleks saanud üles visata kasvõi Exceliga tehtud staatilise pildi, mida iga paari minuti tagant värskendada ning keegi poleks probleemi tähelegi pannud. Suurim ebaõnnestumine oli siin võimetus outside the box mõelda ning eristada probleemi kriitilist osa (telekas ei muutu peamised numbrid) vähemtähtsast (andmebaas ei vasta päringutele piisavalt hästi).
Enamik IT-ettevõtteid annavad inimestele värbamisel suhteliselt otseseid ja igavaid katseülesandeid: progeda selline veebikomponent, disainida taoline andmebaasimudel jne. Selle tulemusel saame inimesed, kes suudavad lahendada tüüp-probleeme, aga ootamatuse ees tõstavad käed püsti. Samas, nagu ülal postuleeritud, on ootamatused ainus asi, mida kindlasti oodata võib.
Selline intervjueerimise viis testib faktide mäletamist, aga mitte mõtlemist.
Samas Microsoft ja ka mitmed teised ettevõtted on tuntud oma värbamiskultuuri poolest, kus rõhutakse eelkõige inimeste taiplikkusele ja probleemide lahendamise oskusele, vt kasvõi raamatut How Would You Move Mount Fuji. Küsimus seisneb siis selles, et kuidas Fuji mägi teise kohta nihutada. Sarnased pealtnäha programmeerimisega mitteseotud küsimused on nt “hinnata, mitu bensiinijaama on USA-s”, vt lähemalt nt Joeli asjakohasest artiklist.
Oluline on rõhutada, et Fuji mäe küsimuse puhul pole tegemist mingi tõmbekaga, vaid täiesti tõsise probleemipüstitusega, mis testib kandidaati oskust asjaoludesse süüvida, täpsustavat infot hankida (Miks on vaja nihutada? Kui palju on vaja nihutada? Millised ressursid meil kasutada on?) ning rasketele probleemidele loomingulisi lahendusi (tehnoloogia, tööjõud, poliitilised probleemid, jne jne) leida.
Kuna ma ise olin juba koolis suur ülesandelahendaja, on see lähenemine mulle muidugi imponeerinud. Siiski võin kätt südamele pannes öelda, et harjumus katsuda ka kõige keerulisemates või absurdsemates situatsioonides lahendusi leida on mind karjääris aidanud rohkem kui ükski tehniline fakt või oskus.
PS Kirjutasin need näited enne maavärinat, mis terve Jaapani koos Fuji mäega kaks ja pool meetrit paigast nihutas. Oh well.
outside the box mõtlemine ja exceliekspordi veebi paiskamine pole mitte inseneride ja tarkvaratootmise, vaid tootejuhtimise probleem. Nende kahe rolli segiajamine tekitab paksu pahandust. Minu esimene küsimus oleks, et kas selles mõttes tootejuhtimine oli tellija või täitja roll. Ja kui see lepingus polnud kokku lepitud, siis langeb vastutus eelkõige tellijale. Aga kui tellitud oli valmislahendus, siis jah, klient ootab toimivat toodet, mitte spetsifikatsioonile vastavalt teostatud inseneriülesannet.
Microsofti intervjuuküsimuste osas pani mind korralikult järele mõtlema alltoodud.
http://blogs.msdn.com/b/ericlippert/archive/2011/02/14/what-would-feynman-do.aspx?PageIndex=3
http://theoatmeal.com/comics/interview_questions
Ivo, mõlemas näites mainitud küsimused on “ahaa”-tüüpi ülesanded, mitte mõtlemisega lahendatavad ülesanded, need on erinevad kategooriad.
Ahaa-ülesandel on vajalik, et lahendaja tuleks ühe konkreetse mõtte peale ja sellest piisab.
Fuji ülesande puhul on vajalik, et lahendaja mõtleks välja terve hulga erinevaid asju ja võimalusel alternatiivseid lahendusi, mis on palju olulisem. Feynman mõtles palju erinevaid asju välja ja on seega ilmselgelt edukas kandidaat.
Aga Lippertil on selles osas õigus, et MSis keegi tänapäeval nii lambist asju ei küsi, pigem küsitakse asju stiilis “kuidas sa disainiksid spellerit/mäluhaldurit/HTTP asemele paremat võrguprotokolli”. Mõelda saab samapalju, kuigi minu meelest on Fuji natuke huvitavam
Jaanus ütleb:
outside the box mõtlemine ja exceliekspordi veebi paiskamine pole mitte inseneride ja tarkvaratootmise, vaid tootejuhtimise probleem
Ma pole päris nõus jaotustega, et “see on minu töö, see on sinu töö ja sinu probleem ning mind ei huvita”. Tegelikult on kõik sildid nagu “tootejuhtimine”, “analüüs”, “arendus”, “juurutus” jne kunstlikud ning vahet pole, kes on konkreetne inimene, kes üht või teist ülesannet täidab. Oluline on see, et praegu olid kõik osalised mingis stampmõtlemises kinni ja keegi ei suutnud selle peale tulla, et ülesannet mingil muul viisil lahendada.
Veel üks tore kontranäide:
http://thedailywtf.com/Articles/Riddle-Me-An-Interview.aspx
Tsitaat: “the job will go to a candidate who manages to answer the question by designing an extremely overcomplicated solution for a completely non-existent problem.”
Ja veel üls üks kontranäide samast kohast:
http://thedailywtf.com/Articles/The_Complicator_0×27_s_Gloves.aspx
Ehk minu elukogemus ütleb, et kui arendajad lasta lühikese keti otsast lahti, siis hakkavad nad niivõrd väljaspool kasti mõtlema, et tulemuseks on tõepoolest ülikeerukad lahendused olematutele probleemidele.
Rääkides valimistest, teoreetiliselt. Tegelikult toimunut ma täpselt ei tea, lihtsalt südaöine analüüs.
Kui lepingus oleks olnud trahv iga ajaühiku eest, mille jooksul rakendus ei vasta eelnevatele nõuetele, siis oli Helmese käitumine kõige mõistlikum. Valimiste tulemuste näitamine on sellisel juhul nende jaoks tegelikult mitte tähtis, võrreldes trahviga ja jutt outofthebox mõtlemisest ei päde. Ainult raha.
Isegi kui kellelgi oli ka olemas plaan b, testitud lahendus, staatiline sisu mujal päris võimsas serverifarmis, testitud võimsusega võibolla tuhandeid päringuid sekundis või rohkem, siis selle kasutamiseni ei jõuta, mitte kunagi.
Kusjuures minu arvates trahvirahad riiki tegelikult ei huvita, ainult Helmest. Riigil on lugemata raha, eriti e-ürituste ajal, pigem palju. Nagu paraadide ajal, mainet pigem vähe ning raha ilutulestikule on.
Hmm, tellija oleks saanud käituda teisiti, kirjeldada soove üldsõnalisemalt või hoopis täpsemalt? Jahah. Või teha veel plaan c? Või suuremad trahvid? Või tellima “ee, ilus ilutulestik” ilma tingimuste tõttu kohtusse sattumata? (1 eurone vurr on ka ilus)
Seda teemat, klient ja tellija, võime sinuga rääkida õlleklaasi taga, ma ei taha siin rääkida kogemustest W, peab kasutama kustutamise klahvi, et mitte ütelda paari väga krõbedat sõna.
Ainuvõimalik lahendus: mitte sattuda sellistesse tellija-klient suhetesse.
Kusjuures eriti jabur on, et kõik tegid endast parima.
Offf, see, kas “extremely overcomplicated” lahendust aktsepteeritakse või ei, sõltub muidugi hindaja kogemusest ja taiplikkusest.
Siin rakendub seesama põhimõte: täpselt nagu töölesaaja peab olema suuteline ka väljaspool stampolukordi mõtlema, ei tohi ka hindaja konkreetses valemis kinni olla.
Muuseas, ma ei väida, et tavalist progemisoskust ei peaks üldse kontrollima, loomulikult peab. Aga peab kontrollima ka mõtlemisoskust.
Juhani, ma arvan, et lepingutingimustest olenemata:
mainekaotuse hind Helmesele > 8500€ > taipliku inimese kulu, kes oleks valimiste ajal asjadel näppu pulsil hoidnud.
100% minu isiklik arvamus muidugi.
Targo – ma vihjan sellele, et mõtlemisoskuse kontroll ise ei tohi olla debiilne küsimus a la “kuidas disainiksid jalgratta kalale”, sest seda pole lihtsalt tarvis. Kui tahta kontrollida töökoha taotleja nutikust ja mõtlemise avarust, siis ei saa seda teha mingi nüri bürokraat netist leitud totra “out of the box” küsimusega, vaid küsimuse esitaja peaks ka ise mingil määral nutikas olema ja küsimus peaks omama mingitki “common senset”.
Jah, enesestmõistetavalt ei saa mõtlemisvõimetu inimene testida kellegi teise mõtlemisvõimet