IT-alan työpaikat

Jos halvalla saa, niin mikäs siinä. Mutta isot IT-talot Suomessa eivät ainakaan sitä laatua ole koskaan löytäneet - sieltä löytyy kyllä sellaisia vipeltäjiä (näissä Accenture, CGI, Tieto ja vastaavissa) ettei niitä ainakaan pitäisi päästää koneen ääreen. Suomessa kun ei pääse eroon huonoista työntekijöistä niin sellaisethan noissa isoihin pesiytyy - sinne sotkuun se hukkuu.

Voihan se myös olla että kun saan huonoa laatua riippumatta koodaajien kansalaisuudesta etsinkin vikaa väärästä paikasta.

Suomalaisen koodaajan etu on, että hän osaa ajatella ja uskaltaa kertoa mielipiteensä. Jos organisaatio on rakennettu niin, ettei koodaajalle jää muuta ajateltavaa kuin algoritmit eikä hänen mielipiteensä juurikaan vaikuta niin suuri osa potentiaalista jää hyödyntämättä (tämä pätee myös venäläisiin ja itä-eurooppalaisiin).
 
Voihan se myös olla että kun saan huonoa laatua riippumatta koodaajien kansalaisuudesta etsinkin vikaa väärästä paikasta.

Suomalaisen koodaajan etu on, että hän osaa ajatella ja uskaltaa kertoa mielipiteensä. Jos organisaatio on rakennettu niin, ettei koodaajalle jää muuta ajateltavaa kuin algoritmit eikä hänen mielipiteensä juurikaan vaikuta niin suuri osa potentiaalista jää hyödyntämättä (tämä pätee myös venäläisiin ja itä-eurooppalaisiin).

Musta ylipäänsä tämä jatkuva puhe pelkästä koodauksesta vie pahasti harhaan. Puhtaita koodareitakin (mitä se ikinä tarkoittaakaan) varmaan on, mutta etupäässä minä näen tämän insinöörityönä ja se koodaaminen on SW/HW insinöörille sama kuin lujuuslaskenta konesuunnittelijalle. Työkalu, jolla tehdään asioita.

Oma tärkein osaamiseni on nimenomaan tuossa ajattelussa, siinä että ymmärrän esimerkiksi elektroniikkaa/tietoliikennetekniikkaa/automaatiotekniikkaa/signaalinkäsittelyä ja pystyn sitten alkamaan toteuttamaan SW tai HW koodilla sitä järjestelmää mitä ollaan tekemässä ja mitä halutaan toteuttaa yhdessä niiden elektroniikka/tietoliikenne/automaatio/signaalinkäsittely jne. insinöörien kanssa.

Tämä on aika kaukana "tässä on speksi, mikset jo koodaa" ajattelusta. Toisaalta ehkä tuo "tässä on speksi, mikset jo koodaa" ajattelu on syynä, että nämä isot palvelutalot tuottavat niin uskomattoman määrän puhdasta kuraa.
 
Mitä (taitojen ajan tasalla olevan) full stack web devaajan Helsingissä pitäisi pyytää palkkaa tänä päivänä, kun tässä insinöörityöstä on ollut puhetta? Sellaisen hintahaarukka-arvio kun työkokemusta reilusti > 10 vuotta.
 
Viimeksi muokattu:
Musta ylipäänsä tämä jatkuva puhe pelkästä koodauksesta vie pahasti harhaan. Puhtaita koodareitakin (mitä se ikinä tarkoittaakaan) varmaan on, mutta etupäässä minä näen tämän insinöörityönä ja se koodaaminen on SW/HW insinöörille sama kuin lujuuslaskenta konesuunnittelijalle. Työkalu, jolla tehdään asioita.

Puhutaan koodauksesta, koska se on kätevämpi puhetatapa kuin "ohjelmistoinsinööri tekee montaa juttua" (joka tuntuu olevan vain surkea käännös). Mikään koodaus ei ole sellaista mitä voi automaattisesti generoida, koska sellainen mielellään jo generoidaan - tai tehdään se generaattori. Tosin mitä tulee lujuuslaskenta esimerkkiin, niin eikös se ole osalle nimenomaan päätyö - eikä suinkaan vain yksi työkalu? Näin käsittääkseni ainakin rakentamisen puolella.

Mikäli "insinöörit" eivät osaa tehdä yhteistyötä ilman että siinä tarvitaan jatkuvaa kädestä kiinni pitämistä kirjaimellisesti, niin pelottaa kyllä lopputulos. Toivoisi insinöörien osaavan jutella asiasta tekniikan - ja määrittelyjen kautta. Ei siihen tarvita jatkuvaa yhdessä olemista, se on hyvinkin tehotonta jos lähdetään jatkuvasti "palaveeraamaan" kun ei uskalleta hoitaa asioita. Valitettavasti nimenomaan tätä lähestymistapaa näkee liikaa, otetaan liikaa keskusteluja sen sijaan että tehtäisiin asioita. Miten ihmeessä valtavat OSS-projektitkaan ovat syntyneet, kun yleensä osapuolet eivät ole toisiaan ikinä nähneetkään.

"tässä on speksi, mikset jo koodaa" olisi sellainen mitä soisi tapahtuvan enemmän monissa tapauksissa. Valitettavasti säätäjiä on liikaa tällä alalla, jotka eivät saa edes yksinkertaista protokollaa käsiteltyä, koska eivät osaa lukea speksejä. Siinä sitten diskuteerataan ja ihmetellään palavereissa miksi asiat eivät toimi sen sijaan että tehtäisiin asiat oikein. Toinen osapuoli on tietysti se, ettei osata kirjoittaa niitä speksejä - se kun vaatii taitoa. Vaan jos niitä speksejä ei osata lukea kuitenkaan, niin miksi niitä kukaan opettelisi kirjoittamaankaan.
 
"tässä on speksi, mikset jo koodaa" olisi sellainen mitä soisi tapahtuvan enemmän monissa tapauksissa. Valitettavasti säätäjiä on liikaa tällä alalla, jotka eivät saa edes yksinkertaista protokollaa käsiteltyä, koska eivät osaa lukea speksejä. Siinä sitten diskuteerataan ja ihmetellään palavereissa miksi asiat eivät toimi sen sijaan että tehtäisiin asiat oikein. Toinen osapuoli on tietysti se, ettei osata kirjoittaa niitä speksejä - se kun vaatii taitoa. Vaan jos niitä speksejä ei osata lukea kuitenkaan, niin miksi niitä kukaan opettelisi kirjoittamaankaan.

Se palaveri pidetään sitä varten, että määritellään sellainen protokolla joka on oikeanlainen kyseiseen käyttötarkoitukseen.

En ole törmännyt merkittäviin ongelmiin speksien tulkinnassa tai kirjoituksessa. Yleensä ongelma on siinä, mitä on yritetty speksata.

Edelleen suosittelen vähän laajentamaan sitä näkökulmaa omasta hiekkalaatikosta.
 
Se palaveri pidetään sitä varten, että määritellään sellainen protokolla joka on oikeanlainen kyseiseen käyttötarkoitukseen.

Se ei ikinä synny siinä palaverissa - saisi olla erittäin triviaali sellainen joka syntyisi. Ja mikäli se on niin yksinkertainen, niin miksi siihen tarvitaan palaveri?
 
Mitä (taitojen ajan tasalla olevan) full stack web devaajan Helsingissä pitäisi pyytää palkkaa tänä päivänä, kun tässä insinöörityöstä on ollut puhetta? Sellaisen hintahaarukka-arvio kun työkokemusta reilusti > 10 vuotta.

Tähän ei taida olla oikeaa vastausta, Suomessa on aika harvinaista että yritykset ilmaisisivat palkan jota he aikovat maksaa (vaikka useimmilla on taulukkopalkat erilaisiin tilanteisiin ja sen mukainen budjetointi). Joskus olen joidenkin ei-PK-seudun yritysten nähnyt näitä ilmaisevan, mutta muuten on heikkoa. Ulkomailta taas jos ottaisi esimerkkinä vaikka Gitlabin, niin he kyllä mainitsevat palkkatason olevan n. 100k€/vuosi. Mutta heidänkään laskurissa ei valitettavasti sanota onko se kokonaispalkkaus (eli ennen työnantajan maksuja) vai työntekijälle maksettava osuus.

Ei tosin varmaan ole Suomesta kukaan töissä siellä minkä takia asiaa ei ole mainittu, mutta Gitlabilla on muuten hienot tiedot mitä kaikkea heillä voi ansaita ja mitkä edut:

Compensation Calculator | GitLab
 
Se ei ikinä synny siinä palaverissa - saisi olla erittäin triviaali sellainen joka syntyisi. Ja mikäli se on niin yksinkertainen, niin miksi siihen tarvitaan palaveri?

Ei se synnykään siinä palaverissa. Palaverissa käydään läpi mitkä on ongelmat, mitä niille pitää tehdä ja kuka tekee. Sitten pidetään seuraava palaveri ja katsotaan mitkä ovat vielä mahdolliset puutteet tai onko toteutuksessa tullut vastaan ennakoimattomia ongelmia. Palaverin välillä voi käydä ongelman kimppuun vaikka tussitaululla pienemmällä porukalla mikä on aivan helkutisti tehokkaampaa kuin kirjoitella meilejä tai selittää telcossa. Suuressa kansainvälisessä yrityksessä telcoja ei voi välttää, mutta melkoisia face-to-face kommunikaatiohaasteita pitää olla ihmisellä, jos väittää telcon ja sähköisten viestinten olevan yhtä tehokas kuin kasvokkain samassa tilassa tai vähintään läheisyydessä toimiminen.

Se, että toteutetaan jotain paskaa vain koska "se nyt on tässä speksissä" on resurssien tuhlausta ja saattaa johtaa myöhemmin ongelmiin ja bugeihin joiden ratkaisussa ja ympäripääsemisessä vasta kestääkin.
 
Mikäli "insinöörit" eivät osaa tehdä yhteistyötä ilman että siinä tarvitaan jatkuvaa kädestä kiinni pitämistä kirjaimellisesti, niin pelottaa kyllä lopputulos. Toivoisi insinöörien osaavan jutella asiasta tekniikan - ja määrittelyjen kautta. Ei siihen tarvita jatkuvaa yhdessä olemista, se on hyvinkin tehotonta jos lähdetään jatkuvasti "palaveeraamaan" kun ei uskalleta hoitaa asioita. Valitettavasti nimenomaan tätä lähestymistapaa näkee liikaa, otetaan liikaa keskusteluja sen sijaan että tehtäisiin asioita. Miten ihmeessä valtavat OSS-projektitkaan ovat syntyneet, kun yleensä osapuolet eivät ole toisiaan ikinä nähneetkään.

Se mitä tarvitaan ja se mikä on optimaali on kaksi eri asiaa. Softatyö ei välttämättä vaadi sitä että väki on samoissa tiloissa mutta jos ovat niin siitä saa kyllä aika paljon etua.
 
Scrumissa refinement on minusta pakollinen toistuva taski. Ilman refinementtiä ei mahdollisia user storyyn liittyviä impedimenttejä saada kiinni riittävän ajoissa, joka taas johtaa lisääntyneeseen määrään ei-suunniteltua työtä ja sitä kautta huonoon ennustettavuuteen. Varsinkin tuotekehitysorganisaatiossa huono ennustettavuus voi aiheuttaa isojakin ongelmia tapauksissa joissa eri tuotekomponenttien välillä on riippuvuuksia.

Ei se refinement välttämättä tarkoita että koko tiimi istuu jossain kopperossa, mutta on ihan perusteltua että tasaisin väliajoin käydään parilla silmäparilla käydään läpi tiimille annetut uudet user storyt jotta niihin liittyvät epäselvyydet saadaan ratkottua ennenkö ne voidaan todeta toteutuskelpoisiksi.

Miten ylipäätään voi suunnitella sprintin sisällön jos ei asioita taskiteta etukäteen?

Edit: Mainitaan vielä että nimenomaan livenä tuollainen asioiden läpikäynti nyt vaan toimii parhaiten. Jotain sekvenssikaavioita ja muuta on kätevä draftailla taululle ja kynnys mielipiteiden esittämiselle on matala. Jossain telcossa kun yrität selittää teknisen asian toimintaa ilman mitään lennossa tehtävää visualisointia, niin aika vaikea tuollaista on monesti seurata verrattuna livetilanteeseen.
 
Viimeksi muokattu:
Voisi kuvitella noiden ongelmien olevan siinä mielessä pieniä, että niitä voitaisiin ratkoa kehittyneemmillä videoneuvottelu- ja tiimityö-ratkaisuilla. Enkä nyt tarkoita mitään Skype-palaveria, jossa joku sharee web cam kuvaa postit-taulusta. Sellaisenkin olen kauhukseni joskus nähnyt ohi kävellessä. Nykyään tussitaulutkin yms ominaisuudet löytyy ja toimivalla tasolla.

Ohjelmistotuotannosta en voi sanoa tietäväni, mutta kuulostaa silti erikoiselta että paikallinen f2f olisi välttämättömyys eikä muunlaisia yhteydenpitokanavia voisi käyttää korvaten täysin sen säännöllisen paikallisen palaverin. Tämä siitä kuvakulmasta, että on tehnyt useita vuosia töitä kansainvälisessä ympäristössä, jossa kaikki on käytännön pakosta eri maista tai mantereilta.
 
Voisi kuvitella noiden ongelmien olevan siinä mielessä pieniä, että niitä voitaisiin ratkoa kehittyneemmillä videoneuvottelu- ja tiimityö-ratkaisuilla. Enkä nyt tarkoita mitään Skype-palaveria, jossa joku sharee web cam kuvaa postit-taulusta. Sellaisenkin olen kauhukseni joskus nähnyt ohi kävellessä. Nykyään tussitaulutkin yms ominaisuudet löytyy ja toimivalla tasolla.

Ohjelmistotuotannosta en voi sanoa tietäväni, mutta kuulostaa silti erikoiselta että paikallinen f2f olisi välttämättömyys eikä muunlaisia yhteydenpitokanavia voisi käyttää korvaten täysin sen säännöllisen paikallisen palaverin. Tämä siitä kuvakulmasta, että on tehnyt useita vuosia töitä kansainvälisessä ympäristössä, jossa kaikki on käytännön pakosta eri maista tai mantereilta.

Kuten JCSH tuossa sanoi (kerrankin ollaan samaa mieltä :)) kyse ei ole siitä onko se välttämätöntä vaan siitä onko se tehokkaampaa. Jos samalla konttorilla saa vähemmässä ajassa enemmän aikaan ja parempaa tulosta niin tottakai työnantajan kannattaa palkata se porukka samalle konttorille. Aina se ei ole mahdollista kun se osaaminen ei ole paikanpäällä tai paikanpäällä ei ole tarpeeksi tekijöitä, eikä työvoima välttämättä ole halukas muuttamaan siihen tiettyyn kaupunkiin saati maahan. Kansainvälisissäkin projekteissa kokemukseni mukaan pyritään kuitenkin keskittämään jokainen osa-alue mahdollisimman paikallisesti sen sijaan, että jokaisen lohkon toteutus hajautettaisiin yksittäisille kehittäjille ympäri palloa.

Oikeat videoneukkarit ovat ihan kivoja (ja kalliita), mutta eivät nekään silti ole samalla tasolla sen kanssa, että seisotaan vierekkäin saman taulun tai laitteen ääressä.
 
Viimeksi muokattu:
Erityisesti vanhan koodin päälle tulevissa uusissa featureissa mä olen nähnyt liikaa sitä, että annetaan tarkat speksit jotka sisältää vaikeasti toteutettavia yksityiskohtia ja kokonaisuuden kannalta triviaalit yksityiskohdat sitten kaksinkertaistaa työn määrän.

Toki jokainen tiimi ja projekti on omalainen. Mä saan kuitenkin kiksit siitä, kun voin selittää ongelman ja koodaajat sparraa mahdollisia ratkaisuja. Kun on itse koodannut monta vuotta voi keskustella aiheista heidän tasollaan.

Mä olen nähnyt tiimejä joissa paljoa keskustelua ei tarvita, ja semmoisia joissa sitä sitten tarvitaan. Usein tuo liittyy siihen kuinka kauan ovat olleet yhdessa, miten heitä on johdettu, mikä on itseluottamus jne. Tavoite toki olisi ettei turhaa palaveeraamista tarvisi, mutta jos tiimi kokee tarvitsevansa keskustelua niin sitten tarvitsevat. Kallista on tehdä sekundaa tai olla hyödyntämättä tiimin potentiaalia kuvittelemalla että kaikki toimivat samalla tavalla.

Puhutaan koodauksesta, koska se on kätevämpi puhetatapa kuin "ohjelmistoinsinööri tekee montaa juttua" (joka tuntuu olevan vain surkea käännös). Mikään koodaus ei ole sellaista mitä voi automaattisesti generoida, koska sellainen mielellään jo generoidaan - tai tehdään se generaattori. Tosin mitä tulee lujuuslaskenta esimerkkiin, niin eikös se ole osalle nimenomaan päätyö - eikä suinkaan vain yksi työkalu? Näin käsittääkseni ainakin rakentamisen puolella.

Mikäli "insinöörit" eivät osaa tehdä yhteistyötä ilman että siinä tarvitaan jatkuvaa kädestä kiinni pitämistä kirjaimellisesti, niin pelottaa kyllä lopputulos. Toivoisi insinöörien osaavan jutella asiasta tekniikan - ja määrittelyjen kautta. Ei siihen tarvita jatkuvaa yhdessä olemista, se on hyvinkin tehotonta jos lähdetään jatkuvasti "palaveeraamaan" kun ei uskalleta hoitaa asioita. Valitettavasti nimenomaan tätä lähestymistapaa näkee liikaa, otetaan liikaa keskusteluja sen sijaan että tehtäisiin asioita. Miten ihmeessä valtavat OSS-projektitkaan ovat syntyneet, kun yleensä osapuolet eivät ole toisiaan ikinä nähneetkään.

"tässä on speksi, mikset jo koodaa" olisi sellainen mitä soisi tapahtuvan enemmän monissa tapauksissa. Valitettavasti säätäjiä on liikaa tällä alalla, jotka eivät saa edes yksinkertaista protokollaa käsiteltyä, koska eivät osaa lukea speksejä. Siinä sitten diskuteerataan ja ihmetellään palavereissa miksi asiat eivät toimi sen sijaan että tehtäisiin asiat oikein. Toinen osapuoli on tietysti se, ettei osata kirjoittaa niitä speksejä - se kun vaatii taitoa. Vaan jos niitä speksejä ei osata lukea kuitenkaan, niin miksi niitä kukaan opettelisi kirjoittamaankaan.
 
Puhutaan koodauksesta, koska se on kätevämpi puhetatapa kuin "ohjelmistoinsinööri tekee montaa juttua" (joka tuntuu olevan vain surkea käännös).
Miten olisi ”ohjelmistokehitys”?

Toivoisi insinöörien osaavan jutella asiasta tekniikan - ja määrittelyjen kautta. Ei siihen tarvita jatkuvaa yhdessä olemista, se on hyvinkin tehotonta jos lähdetään jatkuvasti "palaveeraamaan" kun ei uskalleta hoitaa asioita.
Ei kukaan ole sanonut että kaikesta pitäisi palaveerata kun voi kasuaalisti mennä istumaan läppärin kanssa kollegan viereen ja hoitaa asian muutamassa minuutissa.
Ehkä se sitten on minipalaveri, mutta tehokkaampaa se on käyttää pari minuuttia oikein kuin yrittää 30min selittää slack:ssa jotain asiaa ja sitten tehdä sekin päin vittua.

Valitettavasti nimenomaan tätä lähestymistapaa näkee liikaa, otetaan liikaa keskusteluja sen sijaan että tehtäisiin asioita.
Totta, mutta näkee vielä 1000 kertaa enemmän sitä että ei mietitä tai suunnitella mitään vaan tehdään hätiköimällä paskaa ja ajalliset että rahalliset vahingot kasvavat pilviin asti.

Miten ihmeessä valtavat OSS-projektitkaan ovat syntyneet, kun yleensä osapuolet eivät ole toisiaan ikinä nähneetkään.
Boheemin pelkästään devaajien pyörittämän ”tehdään kun jaksetaan” OSS-projektin ja liiketoiminnan päällä pyörivän softaprojektin välillä on ero kuin yöllä ja päivällä.

Valitettavasti säätäjiä on liikaa tällä alalla, jotka eivät saa edes yksinkertaista protokollaa käsiteltyä, koska eivät osaa lukea speksejä. Siinä sitten diskuteerataan ja ihmetellään palavereissa miksi asiat eivät toimi sen sijaan että tehtäisiin asiat oikein. Toinen osapuoli on tietysti se, ettei osata kirjoittaa niitä speksejä - se kun vaatii taitoa. Vaan jos niitä speksejä ei osata lukea kuitenkaan, niin miksi niitä kukaan opettelisi kirjoittamaankaan.
Palaverien aiheet oikean elämän projekteissa yrityksissä on yleensä kaikkea muuta kuin jonkin protokolla speksin käyttöoppaan ihmettelyä.
 
"tässä on speksi, mikset jo koodaa" olisi sellainen mitä soisi tapahtuvan enemmän monissa tapauksissa. Valitettavasti säätäjiä on liikaa tällä alalla, jotka eivät saa edes yksinkertaista protokollaa käsiteltyä, koska eivät osaa lukea speksejä. Siinä sitten diskuteerataan ja ihmetellään palavereissa miksi asiat eivät toimi sen sijaan että tehtäisiin asiat oikein. Toinen osapuoli on tietysti se, ettei osata kirjoittaa niitä speksejä - se kun vaatii taitoa. Vaan jos niitä speksejä ei osata lukea kuitenkaan, niin miksi niitä kukaan opettelisi kirjoittamaankaan.
Kummasti sitä vain standardoimiselimissäkin kun ihan oikeasti suunnitellaan niitä protokollaspeksejä pidetään säännöllisesti f2f palavereita, missä suunnitellaan sitä protokollaa. Luulisi, että kerran homma toimii ihan yhtä hyvin näkemättä, niin osaisivat jättää moiset turhuudet järjestämättä. Kalliiksikin tulee kun eri firmojen asiantuntijat matkaavat ympäri maailmaa.
 
Täältä varmaan löytyy väkeä, jotka käy näitä palkkakeskusteluita useamminkin? Nyt tullu omalta työntilaajalta halua siirtää minut heidän listoille ja pitäisi palkkatoivetta heittää. Taustasta sen verran, että kävin sellaisen pikakoulutuksen läpi, muu työkokemus lähinnä myynnin puolelta. Työkokemusta tulee olemaan siirtoajankohdassa sen melkein 1.5v. Mitähän tuolla kehtaisi pyytää?

Tiimi on pieni ja talo on enemmän perinteisen alan suht iso firma, jossa vasta aloitellaan softakehitysyksikköä isommin kasaamaan.

edit: niin joo ja työ on pk-seudulla. Työnkuvana tehdä pääsääntöisesti web kehitystä asp.net core ja react työkalulaatikossa. Vähän pääsee tekemään Unityllä kevyitä taskeja.
 
Viimeksi muokattu:
Luulis, että työn tilaajalla on joku käsitys palkkatasosta neuvottelujen pohjaksi?

Hyvä lähtökohta tosin on sekin, että haluavat sut itselleen. Nyt kun verotiedot ovat taas julki niin katso muiden palkkalistoilla olevien tuloja?
 
Luulis, että työn tilaajalla on joku käsitys palkkatasosta neuvottelujen pohjaksi?

Hyvä lähtökohta tosin on sekin, että haluavat sut itselleen. Nyt kun verotiedot ovat taas julki niin katso muiden palkkalistoilla olevien tuloja?
Koitin kysellä haarukkaa, mitä olen aika aikaisemmin tehnyt, mutta nyt aika uusi alalla. Eikös noi verotiedot jääny 100k€, en ihan sinne taida päästä [emoji16]
 
Koitin kysellä haarukkaa, mitä olen aika aikaisemmin tehnyt, mutta nyt aika uusi alalla. Eikös noi verotiedot jääny 100k€, en ihan sinne taida päästä [emoji16]

Verotoimistoon vaan, siellä saat päätteellä haettua kenen tahansa tiedot. Tai puhelimellakin tuo kai onnistuu, oikeasta numerosta ei itellä oo hajua.
 
Koitin kysellä haarukkaa, mitä olen aika aikaisemmin tehnyt, mutta nyt aika uusi alalla. Eikös noi verotiedot jääny 100k€, en ihan sinne taida päästä [emoji16]
Noilla tiedoilla on vähän vaikea vaan sanoa mitään, kun alanvaihtaja jne. Palkkahaitari on n. 3-5ke (kummastakin päästä varmasti vuotaa) joten lyöt kuvittelemasi oman tehtävään liittyvän osaamisen siihen akselille asteikolla nöösipoika - guru.
 
Koodaripulaa
Valtion piikkiin koulutetaan lisää koodareita. Valmiille koodareille ei kuitenkaan kukaan tarjoa töitä.
Itse tällä hetkellä "ei ihan oman alan duunissa", lähetelly hakemuksia ja noin 50% edes vaivautuu vastaamaan.
 
Koodaripulaa
Valtion piikkiin koulutetaan lisää koodareita.
Pulaa taitaa olla lähinnä ammattitaitoisesta halpatyövoimasta.

Itse tällä hetkellä "ei ihan oman alan duunissa", lähetelly hakemuksia ja noin 50% edes vaivautuu vastaamaan.
Tuleeko sieltä pelkästään ihan geneerisiä "kiitos, mutta ei kiitos"-vastauksia, vai tuleeko jotain henkilökohtaista palautettakin, että miksi ei?
 
Varmaan ekojen työpaikkojen saannissa on haasteita, mutta kyllä koodaajiata nyt vaan on pulaa. Me palkataan aika paljon ulkomailta (jotka ovat siis hakeneet suomessa julkastua paikkaa) ja maksetaan niille ihan sitä samaa palkkaa kuin suomalaisille - eikä kyse ole mitenkään siitä että ulkomaalaisia erityisesti halutaan.

Jos hakee paikkoja eikä tule vastauksia tai pääse haastatteluista eteenpäin kannattaa aktiivisesti miettiä hakemustaan, mitä ja miten sanoo haastattelussa (tai jos miettii paljon niin koittaa miettiä vähemmän) ja kehittää osaamistaan. Hakemuksista valitaan 10-15 parasta jatkoon, haastattelujen kautta ehdokkaat pudotetaan yleensä yhteen. Jos ei pääse eteenpäin se tarkoittaa ettei ollut houkuttelevimpien hakemusten joukossa (mieti ennen joka hakemusta miten voisit parantaa sitä, kysy kavereiden mielipidettä ja tutki yritystä yleisesti).

Tämä nyt kuullostaa aika paskamaiselta, mutta loppujen lopuksi tuo on aika yksinkertaista. Voi olla pienestä kiinni miksi yksi hakemus vetoaa ja toinen ei. Haastatteluissa taas voi olla ihan eri jutuista kiinni (esim ei kannata hakemuksessa kuitenkaan väittää osaavansa asioita joita ei oikeasti osaa).

On ikävää, että kaikki hakevat ”valmista” tekijää, se vaikeuttaa paljon alkuun pääsyä. Voi kuitenkin riittää että on ymmärrystä asioista niin että pystyy keskustelemaan niistä. Esim meillä varmasti saa plussaa jos on käyttänyt AWS’n palveluita ja ymmärtää vaikkapa sen mikä on kinesis tai lambda. Niitä voi harjoitella aikalailla ilmaiseksi ja osaa sen jälkeen ainakin keskustella aiheesta.
 
Varmaan ekojen työpaikkojen saannissa on haasteita, mutta kyllä koodaajiata nyt vaan on pulaa. Me palkataan aika paljon ulkomailta (jotka ovat siis hakeneet suomessa julkastua paikkaa) ja maksetaan niille ihan sitä samaa palkkaa kuin suomalaisille - eikä kyse ole mitenkään siitä että ulkomaalaisia erityisesti halutaan.

Jos hakee paikkoja eikä tule vastauksia tai pääse haastatteluista eteenpäin kannattaa aktiivisesti miettiä hakemustaan, mitä ja miten sanoo haastattelussa (tai jos miettii paljon niin koittaa miettiä vähemmän) ja kehittää osaamistaan. Hakemuksista valitaan 10-15 parasta jatkoon, haastattelujen kautta ehdokkaat pudotetaan yleensä yhteen. Jos ei pääse eteenpäin se tarkoittaa ettei ollut houkuttelevimpien hakemusten joukossa (mieti ennen joka hakemusta miten voisit parantaa sitä, kysy kavereiden mielipidettä ja tutki yritystä yleisesti).

Tämä nyt kuullostaa aika paskamaiselta, mutta loppujen lopuksi tuo on aika yksinkertaista. Voi olla pienestä kiinni miksi yksi hakemus vetoaa ja toinen ei. Haastatteluissa taas voi olla ihan eri jutuista kiinni (esim ei kannata hakemuksessa kuitenkaan väittää osaavansa asioita joita ei oikeasti osaa).

On ikävää, että kaikki hakevat ”valmista” tekijää, se vaikeuttaa paljon alkuun pääsyä. Voi kuitenkin riittää että on ymmärrystä asioista niin että pystyy keskustelemaan niistä. Esim meillä varmasti saa plussaa jos on käyttänyt AWS’n palveluita ja ymmärtää vaikkapa sen mikä on kinesis tai lambda. Niitä voi harjoitella aikalailla ilmaiseksi ja osaa sen jälkeen ainakin keskustella aiheesta.

Toi on jännä juttu. Itse olen firman sisällä pystynyt siirtymään projekteihin/tehtäviin ilman aikaisempaa kokemusta (mm. testaajasta koodaajaksi ilman suurempaa aikaisempaa kokemusta enterprise level koodaamisesta) niistä techeistä mitä noissa käytetään. Käytännössä on joutunut opettelemaan tyhjästä todella paljon asioita mutta kuitenkin tunnen että todella nopeasti noita oppii, vaikken todellakaan ole mikään mensan jäsen, enkä yybernörtti. Abstraktointitaito on tärkeää ja kokonaisuuksien hahmottaminen.

Siksi on vähän outoa että työpaikkailmoituksissa vaaditaan stäkki erilaisia teknologioita jo valmiiksi vaikka joka tapauksessa suurinosa asioista opetellaan työn ohessa. Parhaimmissakin tapauksissa vaikka osaisit monia vaadittavia teknologioita, joudut silti opettelemaan firman tavat tehdä asioita, projektin arkitehtuurin jne. jne. jotka vievät ison osan opetteluajasta. Siksi sanoisin että kaikista tärkein asia jos minä olisin rekrytoimassa olisi kyky oppia uusia asioita(ja motivaatio), jopa ihan pohjalta, tietysti mukava jos on jotakin konkretiaa näyttää että omaa tämmöisen tärkeän taidon (suosittelijat, omat projektit, opinnot jne. jne). Toki jonkilaiset pohjataidot on oltava alalla (koodausta, testausta, systeemiymmärrystä, jne.) mutta nuo suorat räätälöidyt techvaatimukset ovat vähän typeriä, IMO.
 
Viimeksi muokattu:
Siksi on vähän outoa että työpaikkailmoituksissa vaaditaan stäkki erilaisia teknologioita jo valmiiksi

Aika usein ei sentään "vaadita", vaan lähinnä toivotaan tai annetaan osviittaa, minkä parissa tullaan työskentelemään. Käytännössä sitten osa osuu kohdalle, osa ei, ja haastattelussa selviää että kaveri kyllä todennäköisesti oppii riittävän nopeasti uuden stäkin.
 
Aika usein ei sentään "vaadita", vaan lähinnä toivotaan tai annetaan osviittaa, minkä parissa tullaan työskentelemään. Käytännössä sitten osa osuu kohdalle, osa ei, ja haastattelussa selviää että kaveri kyllä todennäköisesti oppii riittävän nopeasti uuden stäkin.

Kyllähän se, jos ilmoituksessa lukee "toivomme hakijalta seuraavaa: (tähän kymmenen riviä lyhenteitä)" vähän antaa ymmärtää, että nämä pitää osata, jotta paikka tippuu. Ja tyhmähän tuollaista listaa on antaa, jos asia ei ole kynnysehto, koska silloin vain osa, ehkä pätevistäkin hakijoista, jättää koko lapun lähettämättä.

Toki viimevuosina on alkanut näkemään vähän järkevämpiä ilmoituksia, joissa on listattu esimerkiksi erikseen tärkeitä ja toissijaisia asioita.
 
Monessa firmassa käytetään samaa työhakemuksen muotoa kaikkiin positioihin, mutta suodatukset ja käytännön kriteerit vaihtelee tiimien mukaan.

Mä en ole koskaan hakenut paikkaa jossa täyttäisin kaikki vaatimukset ja olen jotenkin olettanut että niiden pointti on tavallaan vaan kuvata teknologioita joiden kanssa joutuu työskentelemään (toki on hyvä olla kokemusta osasta tai vastaavista muista teknologioista)...
 
Toisaalta on haaste erottua jos hakijoita on 200, sinulta puuttuu sekä tutkinto että osa tekistä ja hakemukset jatkoon valitsee ei-devaaja.

Suhteita peliin, ikävä tosiasia, jolla saa hieman etua tai ainakin haastattelun. Eli toisinsanoen pyytää esim. jotain kaveria suositteleen. Se on sit siitä kaverista kii kehtaako suositella.
 
Viimeksi muokattu:
Toisaalta on haaste erottua jos hakijoita on 200, sinulta puuttuu sekä tutkinto että osa tekistä ja hakemukset jatkoon valitsee ei-devaaja.

Pääsääntöisesti rekryprosesseissa on mukana myös esimiehiä, tiiminvetäjiä ja mahdollisia tulevia kollegoita. Ei niitä hakemuksia kuitenkaan sieltä kasasta fiilispohjalta vedetä.
 
Kooditestit on myös yksi joissa onnistuessaan voi erottua. Ehkä omasta näkökulmasta ideaalisin prosessi ensimmäiseen alan työpaikkaan olisi 1) personal projektien pläräily, 2) behavioraalinen haastattelu, 3) relevantti sopimus kouraan. Tämä varmaan onnistuisikin silloin kun tekijöistä on pulaa.
Ihan vain vinkkinä kooditesteihin. Jos niissä pyydetään tekemään jokin tietty asia, niin ei kannata alkaa tekemään ihme monimutkaisia virityksiä ihan vain esitelläkseen, että osaa käyttää jotain erikoisia ominaisuuksia ja täten tekee sen tehtävänsä todella monimutkaisesti. Jos haluaa esitellä taitojaan enemmän niin lisää vaikka yksikkötestejä tai jotain vastaavaa mukaan. Tälläkin tippuu nopeasti jatkosta.
 
Pääsääntöisesti rekryprosesseissa on mukana myös esimiehiä, tiiminvetäjiä ja mahdollisia tulevia kollegoita. Ei niitä hakemuksia kuitenkaan sieltä kasasta fiilispohjalta vedetä.

Tosin monessa yleensä isommassa firmassa siinä on edessä "apinafiltterinä" joku HR-tyyppi joka on IT-asioista pihalla kuin lumiukko. Tällaisiin firmoihin hakiessa tärkeintä on näyttää ensin paperilla hyvältä, että pääsee siitä HR-henkilön filtteristä läpi siihen kasaan, jota tarkastelevat ihmiset ymmärtävät asioista jotain.

Edit, lisäys:

Olen itse rekrytoivana esimiehenä toimiessani ihmetellyt joskus HR-henkilön läpi päästämien henkilöiden huonoa laatua tai hyvien hakijoiden vähyyttä ja mennyt katsomaan HR-henkilön "hylätyt"-kasaa ja löytänyt sieltä useita hyviä hakijoita. HR-henkilö on päästänyt läpi sellaiset henkilöt, jotka ovat osanneet cut'n'pasteta työpaikkailmoituksessa olevat sanat hakemukseensa ja suodattanut sellaiset henkilöt, jotka oikeasti osaavat niitä tekniikoita, mutta eivät käyttäneet hakemuksessaan juuri sitä akronyymiä/termiä, joka työpaikkailmoituksessa mainittiin. Eli kannattaa työpaikkaa hakiessaan aina tehdä hakemuksesta sellainen, että vähintään 50% työpaikkailmoituksessa mainituista termeistä/akronyymeistä esiintyy edes jollain tavalla hakemuksessa.
 
Viimeksi muokattu:
Tosin monessa yleensä isommassa firmassa siinä on edessä "apinafiltterinä" joku HR-tyyppi joka on IT-asioista pihalla kuin lumiukko. Tällaisiin firmoihin hakiessa tärkeintä on näyttää ensin paperilla hyvältä, että pääsee siitä HR-henkilön filtteristä läpi siihen kasaan, jota tarkastelevat ihmiset ymmärtävät asioista jotain.

Edit, lisäys:

Olen itse rekrytoivana esimiehenä toimiessani ihmetellyt joskus HR-henkilön läpi päästämien henkilöiden huonoa laatua tai hyvien hakijoiden vähyyttä ja mennyt katsomaan HR-henkilön "hylätyt"-kasaa ja löytänyt sieltä useita hyviä hakijoita. HR-henkilö on päästänyt läpi sellaiset henkilöt, jotka ovat osanneet cut'n'pasteta työpaikkailmoituksessa olevat sanat hakemukseensa ja suodattanut sellaiset henkilöt, jotka oikeasti osaavat niitä tekniikoita, mutta eivät käyttäneet hakemuksessaan juuri sitä akronyymiä/termiä, joka työpaikkailmoituksessa mainittiin. Eli kannattaa työpaikkaa hakiessaan aina tehdä hakemuksesta sellainen, että vähintään 50% työpaikkailmoituksessa mainituista termeistä/akronyymeistä esiintyy edes jollain tavalla hakemuksessa.

Ihan perusjuttuhan on hakemusta tehdessä vastata vain siihen toivelistaan.
 
Joissain tapauksissa tuo filtteri on pakollinen jos niitä hakemuksia tulee suunnilleen se kokonainen vuori. Jollain automatiikalla niistä on mentävä läpi ja varmasti moni hyvä hakija karsiutuu.
 
Yhdessä työhaastattelussa HR-tyyppi pommitti ihan ihme kysymyksillä. Osaaminen tuntui olevan toissijaista.
 
Kooditestit on myös yksi joissa onnistuessaan voi erottua. Ehkä omasta näkökulmasta ideaalisin prosessi ensimmäiseen alan työpaikkaan olisi 1) personal projektien pläräily, 2) behavioraalinen haastattelu, 3) relevantti sopimus kouraan. Tämä varmaan onnistuisikin silloin kun tekijöistä on pulaa.

Harvemmalla ammatikseen tekevällä on oikeasti mitään personal projekteja mitä pläräillä tai, jos on ne eivät ole pläräilemisen arvoisia käytetyn efortin/laajuuden suhteen. Opiskelijoilla ja harrastustaustaisilla voi olla, ja silloin niitä toki kannattaa katsoa. (Ja siis vaikka itse hakisi ensimmäistä paikkaa rekryprosessi on yhteinen)

Useat tekniikan alan ihmiset myös värkkää vapaa-ajallaan kyllä tekniikkaa, mutta ei oman alansa. 8h päivässä kun riittää useimmille saman aiheen kimpussa.
 
Meillä tiimit saavat suodattaa itse hakemukset, ja useimmiten tekevät niin. Ainoana haittana on, että voi mennä aika paljon aikaa (mutta kokemuksen mukaan maksaa itsensä takaisin parempina hakijoina).
 
Useat tekniikan alan ihmiset myös värkkää vapaa-ajallaan kyllä tekniikkaa, mutta ei oman alansa. 8h päivässä kun riittää useimmille saman aiheen kimpussa.

Omassa kaveripiirissäni ja itseni mukaan lukien on monta 10-15 vuotta softa-alalla työskennellyttä, enkä usko että kellään on mitään erityisen upeaa henkilökohtaista projektia, jota voisi esitellä työhaastattelussa. Kaikki tosiaan näpräävät kaikennäköistä tekniikkaan liittyvää, mutta koodaus tehdään työaikana. Silti varsin hyväpalkkaisia ovat kaikki. Ekaan työpaikkaan varmaan vipuvarreksi jotain tuollaista voi tarvitakin, siitä eteenpäin mennään CV:llä ja koodaustesteillä.
 
Kaikki tosiaan näpräävät kaikennäköistä tekniikkaan liittyvää, mutta koodaus tehdään työaikana.

Kummallisia, eikö tosiaan ihmiset nauti koodaamisesta vapaa-aikana? Kyllähän se vie eteenpäin sitä osaamista, kun leikkii asioilla joita ei työssään tarvitse - kenties sitä voi tarvita vaikka seuraavassa urapolussaan. Kyllä ainakin itse koodaan myös vapaa-ajalla ja osa noista iltakoodauksista on tuonut myös työpaikkakutsuja. Vaikka kuulun tuohon mainitsemaasi kategoriaan.
 
Kummallisia, eikö tosiaan ihmiset nauti koodaamisesta vapaa-aikana? Kyllähän se vie eteenpäin sitä osaamista, kun leikkii asioilla joita ei työssään tarvitse - kenties sitä voi tarvita vaikka seuraavassa urapolussaan. Kyllä ainakin itse koodaan myös vapaa-ajalla ja osa noista iltakoodauksista on tuonut myös työpaikkakutsuja. Vaikka kuulun tuohon mainitsemaasi kategoriaan.
Monella kun on perhettä ja pieniä lapsia, niin silloin sitä vapaa-aikaa ei vain ole, ja jos hetki sattuisikin olemaan, niin ei tosiaan kiinnosta tai jaksa koodata enää jos sitä on jo koko viikon muutenkin tehnyt töissä. Tämä taitaa olla yksi yleisimpiä syitä.
 
  • Tykkää
Reactions: hmb
Viime kesän harjoittelijoista valittiin vajaa 10 parasta hakemusta haastatteluihin. Itse haastatteluissa skaala oli välillä ”haluan oppia miten kansainvälisissä yrityksissä toimitaan” ja ”nyt on kesä ja tämä on työharjoittelu, toivon voivani viettää paljon aikaa kavereideni kanssa” (nämä siis vastauksia kysymykseen ”mitä odotuksia kesälle”).
 
Omassa kaveripiirissäni ja itseni mukaan lukien on monta 10-15 vuotta softa-alalla työskennellyttä, enkä usko että kellään on mitään erityisen upeaa henkilökohtaista projektia, jota voisi esitellä työhaastattelussa. Kaikki tosiaan näpräävät kaikennäköistä tekniikkaan liittyvää, mutta koodaus tehdään työaikana. Silti varsin hyväpalkkaisia ovat kaikki. Ekaan työpaikkaan varmaan vipuvarreksi jotain tuollaista voi tarvitakin, siitä eteenpäin mennään CV:llä ja koodaustesteillä.
Emmä kyllä tajua miksi 10-15v hommia tehneelle pitäisi joku koodaustesti teettää, jos haastattelussa ei ole aivan pihalla. Itse olen säännön mukaisesti kieltäytynyt.
 
Monella kun on perhettä ja pieniä lapsia, niin silloin sitä vapaa-aikaa ei vain ole, ja jos hetki sattuisikin olemaan, niin ei tosiaan kiinnosta tai jaksa koodata enää jos sitä on jo koko viikon muutenkin tehnyt töissä. Tämä taitaa olla yksi yleisimpiä syitä.

Kiva (on mullakin kolme pientä lasta - tosin kasvaahan ne tuossa), vaan kyllähän sitä vapaa-aikaa ihmisellä on illallakin. Käytti sen sitten urheiluun tai muuhun harrastukseen, kyllä ihmisillä aina aikaa on jos osaavat sitä hallita. Silloin voi koodata asioita joita ei töissä tule tehtyä ja kehityttyä. Kyllä lähtökohtaisesti hieman kieroon katsoisin koodareita jotka eivät nauti siitä, eivätkä yritä kehittää itseään.

Työkseen koodaaminen ja vapaa-ajalla koodaaminen ovat aivan eri asioita.
 
Emmä kyllä tajua miksi 10-15v hommia tehneelle pitäisi joku koodaustesti teettää, jos haastattelussa ei ole aivan pihalla. Itse olen säännön mukaisesti kieltäytynyt.

On olemassa 10-15v hommia tehneitä, ja sitten on 10-15v hommia tehneitä. Ei ne uravuodet takana välttämättä takaa mitään. Jokainen on tietysti vapaa jättämään rekryn kesken missä kohtaa itse haluaa, mutta jos miettii työnantajan kannalta sitä että joku ei ole valmis kevyttä koodausnäytettä antamaan niin ei se nyt positiivisena asiana näyttäydy, vaikka kuinka olisi 15 vuotta kokemusta.
 
Kiva (on mullakin kolme pientä lasta - tosin kasvaahan ne tuossa), vaan kyllähän sitä vapaa-aikaa ihmisellä on illallakin. Käytti sen sitten urheiluun tai muuhun harrastukseen, kyllä ihmisillä aina aikaa on jos osaavat sitä hallita. Silloin voi koodata asioita joita ei töissä tule tehtyä ja kehityttyä. Kyllä lähtökohtaisesti hieman kieroon katsoisin koodareita jotka eivät nauti siitä, eivätkä yritä kehittää itseään.

Työkseen koodaaminen ja vapaa-ajalla koodaaminen ovat aivan eri asioita.

Mitä tekemistä on koodaamisesta pitämisellä ja itsensä kehittämisellä sen kanssa, että elämään mahtuu muitakin mielenkiinnon kohteita ja harrastuksia? Työt kannattaa valita niin, että sitä itsensä kehittämistä ei tarvi tehdä enää vapaa-ajalla.

Ei minkäään muunkaan ammatin harjoittaja jatka (ainakaan jatkuvasti) duunia vapaa-ajalla ihan vaan huvikseen. Tietenkin, tarpeeseen voi joskus koodatakin, kun kerran osaa.
 
On olemassa 10-15v hommia tehneitä, ja sitten on 10-15v hommia tehneitä. Ei ne uravuodet takana välttämättä takaa mitään. Jokainen on tietysti vapaa jättämään rekryn kesken missä kohtaa itse haluaa, mutta jos miettii työnantajan kannalta sitä että joku ei ole valmis kevyttä koodausnäytettä antamaan niin ei se nyt positiivisena asiana näyttäydy, vaikka kuinka olisi 15 vuotta kokemusta.
Haastattelijan ammattitaidottomuutta jos ei saa haastattelussa selville.
 
Mitä tekemistä on koodaamisesta pitämisellä ja itsensä kehittämisellä sen kanssa, että elämään mahtuu muitakin mielenkiinnon kohteita ja harrastuksia? Työt kannattaa valita niin, että sitä itsensä kehittämistä ei tarvi tehdä enää vapaa-ajalla

Ei minkäään muunkaan ammatin harjoittaja jatka duunia vapaa-ajalla ihan vaan huvikseen.

Istuthan sinäkin koneella vapaa-aikana? Eli ilmeisesti et tee töitä koneiden kanssa - seuraten logiikkaasi. Ei vapaa-ajalla koodaamisella ole mitään tekemistä töiden kanssa, paitsi jos kokee yleensäkin koodauksen inhottavana asiana - väittäisin että silloin kyseinen henkilö on väärällä alalla.

Tietysti on aina niitä rivikoodareita, joita ei kiinnosta koko ala.
 
Jos tuntuu että koodaustaitosi eivät kehity työtehtävien kautta riittävästi niin on aika vaihtaa firmaa. Jos vaan vuodesta toiseen ylläpidät samaa vanhaa softaa samalla stäckillä niin ei kai siinä paljoa kehity, kun ei ole pakko. Vapaa-ajalla koodaus ei ole omasta mielestä se oikea ratkaisu tuohon ongelmaan.
 

Statistiikka

Viestiketjuista
258 471
Viestejä
4 497 530
Jäsenet
74 212
Uusin jäsen
floppana

Hinta.fi

Back
Ylös Bottom