Fiksuja vai tyhmiä rekrykysymyksiä?
Eräänä päivänä käytiin n. 10 rakettitieteilijän kesken keskustelu hyvistä rekryhaastattelukysymyksistä. Keskustelun sisältö ja rakettitieteilijöiden tapa pohtia haastattelukysymysten laatua kertovat sekä Raketin rekryprosessista että Raketti-kollegoista. Siksipä julkaisemme pohdiskelun tässä lähes alkuperäisessä muodossaan.
Lienee tarpeetonta sanoa, että keskustelu on luonteeltaan tekninen ja varsin pitkä. Se tuskin haittaa aiheesta kiinnostuneita.
Pohjustetaan ensin: lyhyesti Rakettitieteen rekryprosessin tekninen osa menee nykyisellään niin, että katsomme useammalla silmäparilla hakijan itsensä valitseman koodinäytteen, josta tarvittaessa esitämme lisäkysymyksiä.
Ja koska tiedämme, että kokeneet kehittäjämme selviävät hyvin asiakastyön pahoissakin paineissa, mutta saattavat jäätyä aikarajoitteisessa koodipähkinässä, annamme hakijalle tämän tarvitseman ajan koodinäytteen tekemiseen, ellei sitä löydy valmiina takataskusta. Tästä pidämme jatkossakin kiinni.
Nyt kuitenkin pohdinnassa oli nimenomaisesti rekrykysymyksiä ja tehtäviä, jotka Rakettitieteilijöiden mielestä antavat kuvaa koodaajan osaamisesta ja tavasta ratkoa teknisiä pulmia. Keskustelu liittyi tilanteeseen, jossa aprikoimme tapaa varmistella erään työnhakijan teoreettista osaamispohjaa.
Lähetin alla olevan kysymyspatteriston eräälle rekrykandidaatille varsinaisen haastattelun jälkeen lähinnä saadakseni nopean käsityksen, onko itseopiskelleen tyypin teoriaymmärryksessä jotain oleellisia aukkoja. Noihinhan kaikkiin on jokin alkeiskurssin teos, jossa tuon (ja paljon muuta) oppii.
Mitä mieltä olette moisesta, onko ylipäänsä järkevä setti tai kysytäänkö oikeita asioita?
Would you be able to implement _right_now_, in a language of your choosing, structures like a hashtable and a B+ tree.
What are the valid values of an 8bit signed integer, and why? The value of 11111111 is?
Are you familiar with the challenges described in the Byzantine Generals problem, and have you tackled with them?
Would you be able to implement an LRU cache?
What is the computational complexity of the classical quicksort algorithm?
Are you familiar with TCP slow start?
What is a left outer join?
Some things typical to functional programming?
– Ihan järkevältä vaikuttaa.
– Ihan hyviä kysymyksiä kyllä.
– Miksi kysyt?
– Ymmärtääkseni onko yhdellä hakijalla mahdollisia aukkoja perustiedoissa, ja kun on kerran itseopiskelemassa niin voin pointata aihealueisiin mihin perehtyä.
– 4 ja 1 on ehkä turhan lähellä toisiaan, vai onko nelosessa oletuksena että on jo joku valmis hakurakenne jota voi käyttää?
– Totta. Mutta myös että onko mielestänne muita geneerisiä, perustavanlaatuisia juttuja joita voisi koittaa hahmottaa yksinkertaisella kyssärillä? Ihminen kun yleensä ei tiedä mistä on tietämätön, ja on helppo luulla osaavansa asia X, jos ei hahmota sitä isoa aukkoa.
– Jotain säikeistykseen liittyvää, että tunnistaako racet?
– Noi on aika teoreettista. Voisi kysyä myös jotain ihan peruskäytäntöä, kuten että millaisen mergerequ-systeemin laittaisit pystyyn jos saisit itse päättää.
– Hmm, mikä olisi järkevä concurrency-kyssäri?
– Mun lemppari on double-checked locking, sen kun voi helposti mokata.
– Mutta noi on tosi plättisriippuvaisia, pakko speksata kieli.
– Sinänsä rinnakkaisuus on ihan universaali ongelma, joten mieluiten ei just jonkin tietyn kielen fiitsöriä
– Ihan turha kysyä tuollaisia, ei näitä kukaan muista. Käske sen invertoida stringi paperilla pseudokoodilla in-place
– Todellakin näin. Mä en koskaan muista yhdenkään asian nimeä tai syntaksia tarkistamatta sitä jostain käsikirjantyyppisestä lähteestä. Mut sit käsitteet kyllä jää mieleen ja sovellan monimutkaisiakin juttuja jatkuvasti käytännössä.
– Mulla on vähän sama vika, mutta oon nopea etsimään mun bookmarkeista .
– Jos ois tommoiset haastattelukyssärit niin varmaan itsekin mokaisin
9. Piirrä deterministinen ja epädeterministinen tilakone?
– Vähän konkreettisempaa mieluummin. Tässä regex, millainen [nd]fa? Törmäsinpä tässä hiljattain siihen, että javan regex-moottori tekee ilmeisesti jotain mikä muistuttaa recursive descentiä. Isolla syötteellä räjäytti pinon.
– Noi on jo ihan tehtäviä, ei nopeita kyssäreitä – pitäisikö teidän mielestänne sellaisia teettää?
– Ei kai, jos noi on tarkoitettu vain itseopiskelun suuntaamiseksi.
– No se oli alkuperäinen käyttötarkoitus, mutta kyllähän tuosta voisi halutessaan lähteä laajentamaan jotain "tarkistakaa nämä jutut kaikilta jossain kohtaa rekryprosessia".
– Ja toki sitten kysymys haluaako.
– nfa:t on kyllä pikkuisen eksoottinen aihe.
10. Kerro, miten dfa ja nfa eroavat toisistaan. Riittää, että ymmärtää termit.
– Hm. Mä jouduin googlaamaan noista jokaisen termin paitsi 8-bit signed integer. Ja olen kuitenkin kohtien 1 ... 5 asioita tehnyt ja käyttänyt. En vain tiennyt tai muistanut miksikä niitä kutsutaan.
Eli jos joku olis haastattelussa kysynyt noita minulta, olisin joutunut häpeissäni marssimaan ulos. Ite en kysyisi tuolla tavalla.
– No tuo 8bit signed integer on vaikein koska siinä ei speksattu formaattia.
– 11111111 on vähän kompa, siihen on kaksi vastausta.
– Kolme.
– Mä oisin niihin ykkösiin sanonu että kyllä mä oon yhden, kahden ja N:n komplementtejä laskeskellu paperilla kyllästymiseen saakka, mutta silti pitäis tarkistaa lähteestä että mitäs toi oikeesti on. Tiedän kyllä mistä on kysymys.
– 2^8
– Voi olla että nyt paljastin että en ole "oikea koodaaja", mutta shoot. Signed integer, ei unsigned.
– Mulle riittäisi hyvin toi sun vastaus, joka kertaa että tiedät kahden komplementin ja miten binäärit toimii.
– Totta kai tiedän 🙂 Tehny jotain fixed point -omia väsäyksiäkin joskus kun tarttin.
– Ne muut etumerkkiformaatit on kieltämättä "hieman" eksoottisia nykyaikana.
Mutta siis tarkoituksena ei ole narauttaa ihmistä vaan tsekata enempi "jos et osaa vastata tähän niin lue aiheesta".
– Kohdat yhdestä viiteen osaisin tehdä, kun nyt katsoin mitä ne tarkoittaa. En kumminkaan osaisi jonkun katsoessa selän takaa. Tosin mä nyt en osaa kirjoittaa omaa nimeäni oikein, jos joku katsoo päälle. Funktionaalisesta ohjelmoinnista tiedän kyllä mistä on kyse, mutten suostu koskemaan siihen.
– Mä itse asiassa tuskailin että millä nimittäisi tuota 8-bittistä, koska byte-char-short ja niin pois päin on kaikki vähän kielikohtaisia termejä
– Oktetti on se tekninen termi nimenomaan kasibittiselle.
– Mutta harvassa on nykyään nekin plättikset, joissa tavu (siis pienin erikseen osoitettavissa oleva muistiyksikkö) ei olisi 8-bittinen.
– Mutta ottaako oktetti sitten kantaa sisällön tulkintaan mitenkään?
– Jos se pitäs tulkita signed integeriksi.
– En tiedä, olenko vaan missannut jotain, mutta toi Byzantine Generals problem meni totaalisesti ohi nimenä. Oon säätäny ton kans tietämättä koskaan sen nimeä, mut haastattelus oisin vaan kysyny, et mikä se on.
– Hyvä pointti, ehkä se vaan esiintyi omissa koulukirjoissa niin jatkuvasti.
– Oktetti on vain kahdeksan bitin verran dataa. "8-bit signed integer" on ihan oikea termi ton kysymyksen kontekstissa.
11. Selitä jotain oliopohjaisen ohjelmoinnin ja proseduraalisen ohjelmoinnin eroja käytännön tasolla.
– Uuh, esseekysymys.
– Byzantine Generals on lohkokoetju-entusiasteille.
– Mikä olisi hyvä korvaava termi? Koska BG kuitenkin käsittelee nimenomaan hajautetun järjestelmän konsensuksen luomisen monia ongelmia, tärkeää ihan kaikelle eikä vain bittirahalle.
– Tuo on totta. Ehkä sitä vois hieman paloitella, tai ilmaista käytännön kautta.
– Pelkästään jo voit pyytää selittämään miten hajautetuissa järjestelmissä hanskataan konsensus.
– Voisko sen sijaan, että kysyy termien selityksiä tehdä sellaisen kysymyksen joka kysyis "mitä tekisit tilanteessa, jossa tarvitset tällaista toiminnallisuutta?" Ja sitte tilanteet ois valittu siten että niihin löytyis pakettiratkaisu jostain noista termien aiheista. Vastaukset saattais yllättää hyvyydellään, ja ne ei riippuisi siitä että onko tietosanakirjatietoa.
– Konkreettiset esimerkkitilanteet olisi joo parempia. Vaatii toki enemmän vaivaa laatia.
– Tähän sanoisin: "Sitten varmaan tehhään vaikeita asioita!" Uskoisin että se ois vaivan arvoista, kun saisi haastateltavista hyvin irti tietoa ja innostuksen tasoa.
– Öö, onks 5:n vastaus polynomial?
– Sekin on vähän kompa.
– Nopeasti hain termiä "aikavaativuus" mutta toi ei taida olla ihan oikea termi sille.
– "Asymptotic time complexity" olisi kai vähän täsmällisempää.
(Mutta yhä tarpeeksi epätäsmällistä jotta kompa säilyy. :)
– Onks se sitten logaritminen? (lukee wikipediaa…)
– Klassisen quicksortin keskimääräinen aikavaativuus (jollain järkevällä syötejakaumalla) on O(n log n), mutta pahimmassa tapauksessa O(n^2) (joka siis on polynominen).
Tietty nykymaailmassa klassinen kompleksisuusanalyysi on yhä kauempana käytännöstä, kun muistihierarkiat merkkaa niin paljon.
– Paitsi tietty embossa ei niitä muistihierarkioita kai vieläkään kauheammin ole.
Mutta siellä taas varmaan kiinnostanee enemmän reaaliaikarajoitteet kuin skaalautuvuus.
Ehkä vois kysyä jotain tyyliin "describe in theory or with examples differences in computational complexity for some algorithms", tai sama selkeämmällä lauserakenteella 🙂
– Embossa kiinnostaa paljon myös muistin ja prossutehon tradeoff. Siitä vois pyytää esimerkin, jos tyyppi hakee embohommiin.
– Tai paremmin vielä, voisi itse keksiä tilanteen jossa on selkeä tradeoff muistin käytön ja prossun käytön välillä… Tai siis miten se sanotaan. Että voi joko käyttää paljon muistia ja prosessoida nopeasti, tai käyttää vähän muistia mutta tarttee enemmän prosessointia. Ja sitte pitäs valita tai selittää tapoja vaihtaa kuormaa muistilta prossulle tai toisin päin jossain toimenpiteessä. Oon tollaseen törmänny keskimäärin jokaisessa emboasiassa mitä oon tehny.
– Tietenkin se on tärkeetä myös muualla kuin embossa, mutta rajoitukset ei oo yhtä ilmiselvät.
– En mäkään kyllä noilla kyssäreillä pääsis haastattelusta läpi.– Osaan todennäköisesti, vastaisin “saat kympin jos mua kiinnostaa”.
Tuon vois korvata monivalintakyssärillä jossa on kolme vaihtoehtoa:
Muistan ulkoa hirveästi termejä, teorioita, protokollia, käytäntöjä ja algoritmeja
Osaan ratkaista ongelmia.
En mitään näistä.
– Niin, se on sitten toinen kysymys mikä on läpipääsykriteeri.
– Vai onko sitä?
– Mietin itse tuossa, että mitäköhän sellaisia perustavanlaatuisia "kaikki tietää" -juttuja on jotka on menneet multa täysin ohi.
– Unknown unknowns.
– Noi on oikeesti tosi vaikeita asioita.
– Siis kysymysten luonti, jos haluaa jonkun kyssäripatterin 🙂
– Voi myös kysyä, miten mikroprosessori laskee yhteenlaskun? 🙂
– Mua pyydettiin haastattelussa toteuttamaan yhteenlasku c:n bittioperaatioilla.
– Kerrankin jäädyin kunnolla, vaikka periaatteessa tiesin miten homma tehdään.
– No joo ok, carry-adderin piirto taululle vois olla hyvä. En muista ulkoa, mutta saisin kasaan puolessa tunnissa varmasti. Ehkä 5min? Who knows.
– Kyllä multakin se varmaan olisi helpommin onnistunut. C:llä menee paljon kömpelömmäksi.
– Niin no. Ja toiset ei saisi ikinä aikaiseksi, vaikka olisivat kovia koodareita.
– Ja toiset jäätyis koetilanteessa koska koetilanne. Esim itse tekisin juuri niin.
– Täällä asiakkaalla haastatteluongelmat on tyyliin koodaa keilauksen pistelasku tai yksinkertainen json/rest API javalla. Keilaustehtävässä säännöt saa paperilla, ei mitata osaako keilata.
– Kuulostaa asialliselta.
– Ei se raketinteko tuota hankalampaa ole.
– Kun tehtävä on päällä niin ne hiostaa vuorotellen että mitä tekisit seuraavaksi ja miksi teit tuommoisen ratkaisun.
– Googlaamatta en ois paljoa osannut sanoa noista. Mut tosiaan kun katsoin käsitteiden merkityksen niin huomasin että olin asioita jo soveltanutkin.
– Oikea vastaus toki siihen TCP slow starttiin on : "Classic, Cubic vai Vegas?"
– Jep, hengessä "What do you mean, an African or an European swallow?"
– What is your favorite color?
– Ja oikea vastaus on sellanen, joka annetaan heksadesimaalina ja vielä mainitaan mikä formaatti on kysymyksessä?
– Onnea vaan joutua ikinä tekemään mitään slow startiin liittyvää, mutta onpahan ehkä tullut tankattua joskus jotain tylsää OSI-pinoa tms.
– Embopuolella on parikin kertaa tullu vastaan tilanne missä ois päässy tekemään jos ois nostanu käden ylös. Jja ilmeisesti kuuminta hottia on ajaa softaa suoraan hypervizorin päällä ja toteuttaa tcp javalla yms. Mitä näitä nyt olikaan.
Mun 2¢: Minä jäädyn ainakin helposti, jos pitää edes naiivi algoritmi jossain haastattelussa kirjoittaa. Muuten koodireview:t yms ovat menneet hyvin, mutta algoja varten tarvitsen rauhallisen tilanteen. Toisaalta taas normaali työpaine (serveri on alhaalla ja rahaa menee, asiakkaan pomo hengittää niskaan) on ihan ok. Eli kannattanee miettiä millaista paineensietokykyä oikeasti kaivataan, koska ei sekään ole binääriarvoinen skalaari.
– Omat rse-haastiskokemukset oli et puhelinhaastiksessa tosiaan hieman kuumotti noi algojutut, varsinkin kun niiden voip pätki jatkuvasti, jatkettiin sit google docisissa. mut sit live-tilanteessa haastiksessa oli paljon relampaa kun jengiä oikeasti kiinnosti enemmän se et miten ongelmia ratkoo, eikä sitä et tietääkö kaikki asiat etukäteen.
– Mut toki toi on suht raskas prosessi työnantajallekin ja paljon epämääräisyyttä mukana.
– Meillä oli edellisessä paikasssa musta hyvä ja simppeli systeemi: "ajattele ääneen" ja sitä toistettiin riittävän usein. Vaikka ei olisi osannut, jos tyypin tapa ajatella oli fiksu, niin siitä sai helposti jopa enemmän pojoja kuin toinen, joka osasi paremmin, mutta jotenkin vain ajautui ratkaisuun eikä osannut selittää sitä.
Kuulostaako Rakettitiede kiinnostavalta työpaikalta?
Ota yhteyttä Markoon, niin jutellaan (tai hae GDPR-korrektisti rekryjärjestelmän kautta)!
P.S. Tsekkaa myös kolmiosainen blogisarjamme, jota varten kysyimme tuoreilta rakettitieteilijöiltä, miltä rekryprosessi tuntui ja miten he ovat viihtyneet Raksulla.