Lueskelin taannoin Jeff Atwoodin blogikirjoitusta siitä, miksi monet ohjelmoijan pestiä hakevat työnhakijat eivät oikeasti osaa ohjelmoida.
Olemme Codentossa aina käyttäneet (relevanteissa) työhaastatteluissa yksinkertaisia ohjelmointitehtäviä. Niistä kertyneen kokemuksen pohjalla minunkin pitää todeta, etteivät yllättävän monet tosiaankaan osaa ohjelmoida, vaan joko takeltelevat tai suoraan epäonnistuvat yksinkertaisissakin tehtävissä. Kuten esimerkiksi, “miten printtaat merkkijonon käänteisessä järjestyksessä käyttämällä vain primitiivirakenteita”:
sub print_reverse ($) {
my @chars = split '', $_[0];
for (my $i = @chars - 1; $i >= 0; $i--) {
print $chars[$i];
}
}
Kyllä, ihan totta, jotkut eivät onnistu tässä ollenkaan, eivät vaikka saavat valita ihan minkä ohjelmointikielen tahansa, liberaalisti aikaa sekä vihjeitä ja vinkkejä haastattelijoilta.
Aluksi otimme ohjelmointitehtävät mukaan voidaksemme seurata miten haastateltava lähestyisi esitettyä ongelmaa, tarkentaisiko tarvittaessa, mikä on kielipreferenssi jne. Nykyään ohjelmointitehtävän tärkein merkitys on kuitenkin yksinkertaisesti tiputtaa pois ne jotka joko a) va… kaunistelevat totuutta CV:ssä tai b) ovat käytännön esimerkki Dunning-Krugerin efektistä.
Nykyään ohjelmointitehtävä on yleensä neljännellä portaalla työhaastatteluprosessissamme: CV:n läpikäynti → kahvi/lounas/puhelinkeskustelu → yleishaastattelu → 1. tekninen haastattelu → 2. tekninen haastattelu. Jo nyt, ja tulevaisuudessa entistä pienempi osa meille töihin hakevista on entuudestaan tuttuja, joten haastatteluihin etenevistä on odotettavissa entistä enemmän hylkäyksiä. Jos mitään ei muutettaisi.
Siispä siirrämme ohjelmointitehtävän – ohjelmointikyvyn ollessa relevantti – kokeiluna jo heti CV:n tarkistuksen jälkeen ja tehtäväksi verkossa. Atwoodin kirjoituksen kommenteissa on vinkkejä erilaisista jaetuista editoreista, kuten Etherpad ja Google Docs. Niiden paremmuudesta haastattelukäyttöön emme osaa vielä tietenkään sanoa mitään. Jos jollakulla on omia kokemuksia jaetuista editoreista nimenomaan ohjelmointitehtävissä, niin kirjoittakaa ihmeessä kommentteihin!
Se mitä tästä konkreettisesti toivomme on tietysti tarpeettomiin haastatteluihin käytetyn ajan väheneminen. Aika on rahaa – konsulttibisneksessäkin.
If you enjoyed this article, please consider sharing it!
Tässä yksi vaihtoehtoinen lähestymistapa tuolle että käytetään jaettua editoria jne:
Tein vähän aikaa sitten tunnin mittaisen etäohjelmointitehtävän lontoolaiseen softataloon. Idea oli se, että ajan alkaessa latasin zip-tiedoston joka sisälsi yksinkertaisen ohjelmiston; minulla oli tunti aikaa tehdä sähköpostiviestissä olleen speksin mukainen muutos ohjelmistoon, käyttämällä juuri niitä työkaluja kuin haluan. Ajan päättyessä projekti piti zipata (oli homma valmis tai ei) ja lähettää takaisin heille, ja sen jälkeen kirjoittaa meili (15 min aikaa) jossa kuvailin mitä tein.
“Ohjelmisto” oli melko yksinkertainen kivi-paperi-sakset -peli komentorivikäyttöliittymällä; kahden pelaajan peli piti muuttaa tietyllä tavalla turnausmuotoiseksi. Tunnin aikaraja kuitenkin teki tehtävästä riittävän haastavan: itse en ehtinyt saada speksin muutoksia täysin tehtyä, mutta olivat silti tyytyväisiä ja pääsin jatkoon (kuulemma hyvin harvat saavat tuon täysin tehtyä). Käytin itselleni tuttua IntelliJ IDEA -ideä, ts. pystyin pitkälti keskittymään olennaiseen.
Olin etukäteen vähän skeptinen testien suhteen rekryprosessissa, mutta mielestäni tämä testi oli hyvä. Se kertoo kandidaatista monia asioita; mm. sen, kuinka selkeää ja luettavaa koodia hän tuottaa tavallaan “oikeankaltaisessa” projektissa. Testi edellyttää olemassaolevan koodin ymmärtämistä ja muokkaamista, eikä siinä oikein voi huijata copy-pasteamalla jostain googlatun ratkaisun (tai ainakin moisen huomaisi helposti).
Pari huomautusta: 1) Tämä ei ollut ensimmäinen askel jonka ko. firmaan tein; aiemmin oli ollut tekninen puhelinhaastattelu tai -seulonta (jossa varmaan putoavat useimmat niistä jotka eivät yhtään osaa ohjelmoida). 2) Työnantajalla olisi hyvä olla useita tällaisia tehtäviä joita vaihdella (ja tarvittaessa tehtäviä eri ohjelmointikielille) – vaarana kenties muuten on että sana leviää ja tehtävään voi varautua etukäteen.
Tein itsekin Jonin kuvaileman kaltaisen sähköpostikoodaustehtävän hiljattain. Firmalla oli tunkki, johon sai vapaavalintaisena hetkenä lähettää mailin, jonka jälkeen sai paluuviestinä 2 tehtävänantoa ja 2 tuntia aikaa tehdä ne. Koska hain testauspainotteiseen positioon, piti myös suunnitella tai ajan riittäessä toteuttaa mahdollisimman kattavat testit tehdyille ratkaisulle.
Tehtävät olisi voinut tehdä usealla kielellä ja kaikki olivat voimakkaan algoritmipainotteisia.
Ero Google Docs -pohjaisessa ja sähköpostipohjaisessa haastattelussa on nähdäkseni siinä, kuinka suuren paineen haluaa haastateltavalle antaa. Kaikki docs-koodaustestejä tehneet kaverini ovat sanoneet tunteneensa voimakasta painetta siitä, että heidän koodauksensa etenemistä seurataan merkki merkiltä. Editorin vilkkuva kursori kutsuu kirjoittamaan koodia heti ensimmäisestä sekunnista lähtien. On makuasia, haluaako ihmisille antaa täyden rauhan vai vain osittaisen. Jos haluaa vain varmistua siitä, että ohjelmointitaitoa on yli nollan verran, on online-koodaus ehkä parempi. Jos taas haluaa kysyä hiukkasen haastavampaa algoritmista, voi ehkä olla parempi antaa haastateltavan tehdä ratkaisu vähemmällä valvonnalla.
Viittasin nyt itse vain ja ainoastaan lyhyisiin ohjelmointitehtäviin, joilla on tarkoitus nopeasti sulkea pois ihmisiä. Pitkät ohjelmointitehtävät sopivat oikeasti vasta siihen vaiheeseen, kun hakijan osaamisesta on jo kohtuullisen hyvä kuva.
Toisaalta hyvältä ohjelmistonkehittäjältä odotetaan paljon muutakin osaamista kuin pelkkää ohjelmointitaitoa, joten en myöskään halua pistää liian paljon painoarvoa puhtaalle ohjelmointitaidolle. Meitä on kuitenkin moneen junaan ja hyvään tiimiin tarvitaan eri asioita eri tavalla osaavia ihmisiä.
Se millaisia ihmisiä haetaan on tietysti organisaatiokysymys. Codento hakee nimenomaan ohjelmistotuotannon moniosaajia, joilla on myös edellytykset toimia itsenäisesti vieraassa organisaatiossa. Ei siinä pelkällä ohjelmointikyvyllä pärjää.
Jos organisaatio hakee tarkkaan lokeroitua “ohjelmoijaa,” niin tietysti puhdas ohjelmointikyky korostuu työhönottopäätöksessä jolloin nimenomaan sitä kannattaakin testata.