IT-alan työpaikat

[ulti_]

Kannattaa myös ajatella sitä, että ehkä testillä lähdetään tarkoituksella katsomaan miten hakija reagoi oman sopivuusalueen ulkopuolella. Turhaan niitä testejä turhan vakavasti ottaa. Pitää vaan heittää omat ennakkoluulot nurkkaan ja leikkiä mukana.

 

[woodeye]

Onko käynyt mielessä että "ajastettu algoritmitehtävä" testaa jotain muutakin kuin osaamista?

Jollei ole motivaatiota viedä testiä loppuun, onko motivaatiota olla hyvä työntekijä? Tälläisellä testillä saadaan karsittua useampi ei-toivottu työnhakijaryhmä.

 

[Illotus]

Työhaastatteluissa tai niiden yhteydessä tehtävät testit aika harvoin edustavat mitenkään hyvin tulevia työtehtäviä. Hyvin usein se on suunnilleen samaan rooliin rekryttäville sama sapluuna.

Ekoihin paikkoihin mennään oppimaan ja hakemaan kokemusta, juniorina ei yleensä pääse valikoimaan kovin paljon millaista hommaa saa. Uran tekeminen on pitkä prosessi. Vaikka se eka työpaikka olisi ihan unelma, niin kyllä sieltä yleensä jossain kohti kannattaa olla suuntaamassa muualle, jos ei muuten niin palkkakehityksen perässä pysyäkseen.

 

[FireFly Renaissance]

Toivottavasti löytyy kuitenkin myös firmoja, joissa rekry vastaa selkeämmin haluttuja työntekijäprofiileja. Jos haet esim. bäkkiä ja tietokantoja mutta firma testaa sinua frontilla ja UX-suunnittelulla, on ihan ymmärrettävää, jos siirryt katselemaan muita mahdollisuuksia.

Ei se kyllä minustakaan ole.

Rekry on vain jonkun näkemys siitä miten, ehkä voisi löytää työntekijän. Yleensä kenenkään toimenkuva ei ole miettiä niitä rekryasioita täysipäiväisesti, tai jos on, silloin ne vasta perseestä ovatkin, kun niillä testataan mitä ja kaikkea, mutta ketään ei kiinnosta tekninen osaaminen.

Ja, jos firma on pieni joutuu joka tapauksessa tekemään kaikennäköistä mistä taloon tulee rahaa. Jos firma on suuri saa varautua siihen, että organisaatiot ja tehtävät menee mullin mallin vaikka pari kertaa vuodessa.

Harrastus on harrastus ja työ on työ, mutta jos se työ on edes sinnepäin mistä tykkää se on jo paljon parempi kuin, ettei se ole sinnepäinkään.

 

[FireFly Renaissance]

Agile manifeston 5. prinsiippi:

"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."

Kertoo enemmänkin yrityksestä paljon enemmän, jos se pakottaa ihmiset tiukkaan muottiin, tappaa motivaation ja hidastaa työntekoa sanelemalla tarkkaan kaiken. Jos hommat tulee tehtyä ja hyvin, niin on ihan sama mikä OS, IDE, terminaali, jne. jollain on käytössä (kunhan nyt tietoturvan jne. puolesta ovat ok).

Jos ollaan vähän isommassa organisaatiossa kyllä sillä on aika paljon väliä käyttääkö 100 kehittäjää yhtä samaa työkalua vai sataa eri työkalua. Toki on sitten eri asia sanellaanko ne työkalut ylhäältä alas tai paljonko niihin saa vaikuttaa, mutta jos oikeasti tehdään isoa niin kyllä silloin pitää olla jotain yhteisiä käytäntöjä. Siinä on sitten veteen piirretty viiva mikä on tarpeellista ja mikä vittuilua. Se, että kaikki kaatuu siihen montako entteriä tai välilyöntiä mihinkin kirjoitetaan on toki ihan pelleilyä.

Toinen juttu taas, jos tekee yksin omaa projektia (jota ei muille jaella) silloin ei tarvi moisia miettiä.

 

[JCSH]

Jos ollaan vähän isommassa organisaatiossa kyllä sillä on aika paljon väliä käyttääkö 100 kehittäjää yhtä samaa työkalua vai sataa eri työkalua. Toki on sitten eri asia sanellaanko ne työkalut ylhäältä alas tai paljonko niihin saa vaikuttaa, mutta jos oikeasti tehdään isoa niin kyllä silloin pitää olla jotain yhteisiä käytäntöjä. Siinä on sitten veteen piirretty viiva mikä on tarpeellista ja mikä vittuilua.

Jees, jos sulla on 100 kehittäjää joista jokainen ylläpitää sitä omaa tiettyä työkalusettiään devaamisen ohella niin siinä tuhlautuu aika perkeleesti aikaa ja rahaa sen sijaan että siellä on parin tyypin tiimi joka ylläpitää kaikille niitä kahta tai kolmea "virallista" settiä.

Se, että kaikki kaatuu siihen montako entteriä tai välilyöntiä mihinkin kirjoitetaan on toki ihan pelleilyä.

No niin no, nykyaikaisilla koodin formatointityökaluilla tämän ei pitäisi olla mikään ongelma. Siinä nyt menee se sekunti kun ajaa sen formatterin ennen kun survoo committia sisään.

 

[Bladekill]

Jees, jos sulla on 100 kehittäjää joista jokainen ylläpitää sitä omaa tiettyä työkalusettiään devaamisen ohella niin siinä tuhlautuu aika perkeleesti aikaa ja rahaa sen sijaan että siellä on parin tyypin tiimi joka ylläpitää kaikille niitä kahta tai kolmea "virallista" settiä.

Mihin se aika oikein menee? Nykyiset devaustyökalut vaativat käytännössä muutaman minuutin (ehkä joskus tunnin) kuukaudessa jos sitäkään ellei puhuta joistain todella nicheistä FPGA IDE:stä mistä suurin osa ei ole kuullutkaan. Toiseksi en näe sillä suurta merkitystä onko firmassa 30 devaajaa vai 3000 kun kuitenkaan ainakaan jälkimmäisessä tapauksessa kaikki 3000 eivät hankaa sitä samaa softaa vaan firmassa on useita tuotteita/projekteja tulilla yhtäaikaa. Sitten kun ne softa tiimit ovat käytännössä 2-50 henkilöä niin en näe kovin suurta arvoa sillä että jokin tekemiselle sokea keskushallinto määrää työkalut. Todennäköisesti siitä tulee enemmän haittaa kun joku IT-osasto määrää käyttöön hitaat, raskaat ja vanhanaikaiset työkalut jotka nimenomaan vaativat sitä säätämistä ja ylläpitoa devaamisen sijasta.

 

[Bertta]

Työkalut kannattaisi pakata kontteihin siten, että kaikilla on varmasti identtinen perusympäristö. Suuremmissa yrityksissä voi mennä etenkin alussa runsaasti aikaa pelkästään työympäristön kasaamiseen ja myöhemminkin epäyhteensopivuudet aiheuttavat helposti turhaa työtä.

 

[Incredible Buff]

Onko käynyt mielessä että "ajastettu algoritmitehtävä" testaa jotain muutakin kuin osaamista?

Jollei ole motivaatiota viedä testiä loppuun, onko motivaatiota olla hyvä työntekijä? Tälläisellä testillä saadaan karsittua useampi ei-toivottu työnhakijaryhmä.

Niinpä. Meillä on entry level positioihin joskus käytetty tuollaista ajastettua tehtävää ja se on ollut ohjelmointikielellä jota harva osaa ja ihan yleisen tason tehtävä kuten algoritmi eikä odotusarvokaan ole ollut, että kukaan sitä saisi annetussa ajassa ratkaistua. Kyse ei ole ollut mitata ko. kielen osaamista vaan jotain ihan muuta, mutta saahan noista kieltäytyä, mutta ei tartte sitten ihmetellä miksei töitä löydy.


Kyllähän sieltä paljastui sitten niitä "vittu mitä paskaa" - tapauksia hyvin nopeasti ja se oli sitten takki ja ovi.

 

[Randomizer]

Työkalut kannattaisi pakata kontteihin siten, että kaikilla on varmasti identtinen perusympäristö. Suuremmissa yrityksissä voi mennä etenkin alussa runsaasti aikaa pelkästään työympäristön kasaamiseen ja myöhemminkin epäyhteensopivuudet aiheuttavat helposti turhaa työtä.

Tämä. Vielä erityisesti projekteissa/tuotekehityksen elinkaarilla olisi parasta olla standardit työkalut/ympäristöt käytössä. Valitettavasti näissä hommissa (DevOps) on tullut nähtyä vaikka ja minkälaista viritystä eri projektien välillä. Pahinta on se että käytetään erilaisia työkaluja, mutta kukaan ei ota omistajuutta niistä. Sitten arvotaan kuka niiden ylläpitoa jne. hoitaa. Samaan asiaan voi pahimmillaan olla käytössä monta erilaista työkalua vaikka hommat voisi hoitaa yhdellä keskitetyllä resurssilla ja/tai käyttämällä kontitettuja ympäristöjä standardiseteillä.

 

[JCSH]

Mihin se aika oikein menee? Nykyiset devaustyökalut vaativat käytännössä muutaman minuutin (ehkä joskus tunnin) kuukaudessa jos sitäkään ellei puhuta joistain todella nicheistä FPGA IDE:stä mistä suurin osa ei ole kuullutkaan. Toiseksi en näe sillä suurta merkitystä onko firmassa 30 devaajaa vai 3000 kun kuitenkaan ainakaan jälkimmäisessä tapauksessa kaikki 3000 eivät hankaa sitä samaa softaa vaan firmassa on useita tuotteita/projekteja tulilla yhtäaikaa. Sitten kun ne softa tiimit ovat käytännössä 2-50 henkilöä niin en näe kovin suurta arvoa sillä että jokin tekemiselle sokea keskushallinto määrää työkalut. Todennäköisesti siitä tulee enemmän haittaa kun joku IT-osasto määrää käyttöön hitaat, raskaat ja vanhanaikaiset työkalut jotka nimenomaan vaativat sitä säätämistä ja ylläpitoa devaamisen sijasta.

No riippuu mitä tekee. Jos kyseessä on joku Javascript toteutus jossa kaikki riippuvuudet tulee npm:n yli ja lopulta devaajalla on valittavana että käyttääkö siihen koodin editointiin VS Codea, Emacsia, Atomia vai Notepad++:aa ja gitin käyttöön komentoriviä, gitk:ta, SourceTreetä tai mitä ikinä niin joo, sitten devaaja voi huoletta valita omat työkalunsa. Ihan devauskoneen käyttiksestä lähtien.

Mutta jos kyseessä on vaikkapa astetta isompi C++ himmeli jolla on joku tusinan verran erilaisia ulkoisia riippuvuuksia ja joka pitää kääntää parille kolmelle eri käyttikselle niin sitten alkaakin tulemaan pikkasen enemmän rajoitteita siihen mitä työkaluja voi käyttää. Toki sen koodieditorin ja git clientin voi vielä valita mutta jotta homma toimii sulavasti niin on muuten fiksattu käyttämään tiettyjä toolchainejä. Jolloin esim. yksi tai jopa kaksi niistä mahdollisista devauskoneen käyttiksistä voi tippua pois.

Eikä tuon todellakaan tarvi olla minkään IT-osaston määräämä asia vaan ihan R&D organisaation oman tukitiimin. Joka toimii sen perusteella mitä R&D organisaation tekniset liidit pyytävät niiltä.

 

[Incredible Buff]

Itse olen ainakin kohteliaasti ilmoittanut, etten etene testiin, ja pahoitellut mahdollista haittaa työnantajalle. Viitaten tiettyihin vastauksiin ketjussa, en näe, miksi kenenkään ensimmäinen reaktio kieltäytymiseen sen taustoja tuntematta tulisi olla, että hakijassa on jotain erittäin negatiivista. Rekry kuitenkin on neuvottelu ja yleensä sen tuloksena ei ole sopimusta.

Yritin tuossa nyt lähinnä selventää niiden testien tarkoitusta. Se ei ilmeisesti auennut niin yritetään vielä. Sen yleisluontoisen testin tarkoituksena, kuten nyt vaikka algoritmi, ei ole useinkaan mitata juuri sitä spesifiä osaamista, kuten nyt vaikka backend tai frontti kuten tuolla esimerkkinä mainitsit vaan muita asioita. Siksi noista ei sen perusteella kannata kieltäytyä, että kiinnostus on jossain tietyssä teknologiassa.

Näin työnantaja näkökulmasta niin se testistä kieltäytyminen on lähes yksi ja sama. Porukkaa putoaa muutenkin rekryn eri vaiheissa pois.

 

[TGO]

Hieman välillä rekryävän puolen apuna olleena ihmetyttää kuinka porukka yrittää syväluodata firman sopivuutta jonkin yksittäisen haastatteluun liittyvän testin avulla.
Kieltämättä 2h algoritmitehtävät tietyllä ympäristöllä kuulostavat ehkä vähän ylimitoitetulta, mutta näihin tuskin on päädytty sen vuoksi että haluttaisiin karsia pois ne jotka osaa tehdä omia valintoja.

Rekrypuolella ei ole aina ihan niin helppoa kuin tästä ketjusta voisi päätellä. Senkin uhalla että tulee vastapalloon valitusta rekryn kädettömyydestä, niin yritän palauttaa maan pinnalle. Koodaajaa rekrytoidessa saa tyypillisesti paljon hakemuksia joista on vaikea päätellä suoraan sopivuutta. Niinpä täytyy selvittää asiat haastattelussa.
Koska koodaajia on ihmisinä erilaisia ja tiimeissä erilaisia rooleja, meidän firmassa on päädytty siihen että koodaajan haastettalussa on hyvä olla suullinen osuus ja käytännön testi. Tällä palstalla on toki vain täydellisiä koodaajia, voi olla vaikea uskoa kuinka harva esiintyy edukseen molemmissa osissa.


Suullisessa osuudessa yritetään selvittää osaako hakija kommunikoida ja onko yleisesti edellytyksiä hommaan. Jutellaan niistä niiden asioiden tärkeimmistä piirteistä joita olisi aluksi tarkoitus käyttää (ihan vaan ekojen tuotteiden frameworkkejä, GIT, testaus, jne).

Sitten käytännön osuus mittaa huomattavasti eri alueita kuin tässä on spekuloitu. Meillä käytännön osuus on suht lyhyt (aika ei rajoitettu, mutta ei siinä yli tuntia mene) ja ilkeästi paikan päällä tehtävä.
Käytännön tehtävät ovat mielestäni aika yksinkertaisia. Vähän algoritmia ja vähän ohjelmointiekielen ominaisuuksia (kielen jota hakija väittää hyvin osaavansa). Näihin riittää ihan tekstieditori. Ja kun ~90% hakijoista koodaa bugeja, haastattelija toimii kääntäjänä ja suoritusympäristönä. En itse uskonut bugien määrää ennen kuin näin.
Testi mittaa, pystyykö hakija yhtään mihinkään pienen paineen alla. Lisäksi saadaan jotain käsitystä tarvitseeko mahdollisen palkkauksen jälkeen olla koko ajan auttamassa ihan perusjutuissa. Koodari muuten voi olla ihan hyvä vaikkei perusjuttu menekään oikein suorilta paineen alla. Joskus on joutunut palkkaamaan sellaisen jolla käytännön osuus on mennyt melko huonosti ja ennalta arvattavasti ongelmanratkaisukyky on ollut sitten työssäkin melko huono.

Yritän tässä siis sanoa että käytännön osuudet harvoin yrittävät mitata osaako hakija kaikkia niitä tekniikoita ja frameworkkeja joita hänen olisi työssään tarkoitus käyttää. Etenkin jos nämä frameworkit ovat tulevaisuudessa osittain kiinni tiimin jäsenistä itsestään jne. Jos tällaista testiä yrittäisi saada aikaan, siitä olisi erittäin vaikea saada lyhyessä ajassa suoritettava (niin että tavallinen koodari siis myös pääsisi siitä läpi) ja lisäksi vielä helposti varmistettavaa. Käytännön osuutta on myös vaikea tehdä sellaiseksi että se kertoisi hakijalle sopiiko firma hakijalle. Jos jollain palstalaisessa on helppo ja hyvä vastaus koodaajan osaamisen varmistamiseen erilaisiin tehtäviin, suosittelen rekryfirman pystyttämistä. Jos voisi tarjota vaikka 5ke / kpl osuvia devaajia niin bisnestä luulisi riittävän.

 

[OD.]

Jos on varaa valita työpaikoista, niin siitä vaan kieltäytymään testeistä. Mikäli taas on työttömänä ja ihmettelee, että miksei saa duunia, niin kehotan vähän venymään haastattelutilanteissa ja osoittamaan yhteistyökykyä osallistumalla testeihin.

Jos koet, että muutaman tunnin "tuhlaaminen" testeissä on ajanhukkaa, niin voi pojat tulet pettymään työelämässä pahasti. Parhaissakin paikoissa joutuu välillä tekemään asioita, joiden hyötyä ei ymmärrä tai homma kiinnosta ja näin se vaan toistaiseksi menee. Can do-asenne on yksi työntekijän tärkeimmistä ominaisuuksista. En palkkaa enää ainuttakaan henkilöä, joka ei ole valmis edes yrittämään.

 

[Paapaa]

Pelkkien algoritmien tenttailu myös viittaa siihen, että sopivia hommia ei olisi tarjolla.

Aikamoista spekulointia. Sen sijaan, että kokemattomana yrität vetää johtopäätöksiä siitä, mitä todellinen työnteko olisi, olisit tietenkin voinut kysyä, millaisiin projekteihin sinut voitaisiin palkata?

Nyt tuli vähän sellainen kuva, että teilasit firman vain siksi, että siellä oli rekryvaiheessa tuollainen testi. Et voi päätellä juuri mitään tulevien projektien sisällöstä tai oikeastaan mistään muustakaan vain tuon testin olemassaolon perusteella.

Itse pyrkisin ulos tuosta asenteesta - jos kyse oli asenteesta. Kannattaa nähdä kaikki erilaiset testit mahdollisuuksina. Tuossa testissä opit ehkä jotain paineensietokyvystäsi ja algoritmiosaamisesta. Ehkä opit jotain siitä, miten toimit kun joudut tekemään jotain epämieluisaa. Ehkä olisit oppinut firmasta jotain uutta menemällä ulos omasta mukavuusalueestasi. Jatkokierroksilla olisi voinut tulla käytännön tehtäviä? Ehkä olisit feilannut ja jäätynyt, mutta kun seuraavassa unelmatyöpaikassa tulisi sama tilanne eteen, olisit paremmin valmistautunut.

Puhuit myös siitä, kuinka olisit halunnut arvioida firman koodin laatua. Ensinnäkin kannattaa muistaa, että arvioit silloin luultavasti yhden projektin tai jopa vain yhden devaajan koodin laatua. Firman sisällä varianssi voi olla valtavaa. Eli ei kannata vetää liian pitkälle meneviä johtopäätöksiä siitäkään. Tavallaan tuo on hyvä asia (halu jatkuvasti parantaa työn laatua), mutta vain jos kommunikoit sen oikein. Jos rekryäjälle tulee vahingossakaan sinusta ylimielinen fiilis, se voi olla haitaksi. Toisen työtä arvioidessa kannattaa olla erityisen tahdikas.

 

[JCSH]

Itse olen ainakin kohteliaasti ilmoittanut, etten etene testiin, ja pahoitellut mahdollista haittaa työnantajalle. Viitaten tiettyihin vastauksiin ketjussa, en näe, miksi kenenkään ensimmäinen reaktio kieltäytymiseen sen taustoja tuntematta tulisi olla, että hakijassa on jotain erittäin negatiivista. Rekry kuitenkin on neuvottelu ja yleensä sen tuloksena ei ole sopimusta.

Siis oikeasti, sä olet kertonut kuinka sulla ei ole oikeastaan mitään käytännön työkokemusta alalta ja valitat kuinka et saa hommia mutta silti sulla on pokkaa kieltäytyä rekrytehtävistä?
Sanotaan näin että alkaa aika vahvasti vaikuttaan siltä että sulla on astetta pahempia asenneongelmia joka selittää sen miksi potentiaaliset työnantajat välttelee sua kuin ruttoa.

 

[kjns]

Tavallaan tuo on hyvä asia (halu jatkuvasti parantaa työn laatua), mutta vain jos kommunikoit sen oikein. Jos rekryäjälle tulee vahingossakaan sinusta ylimielinen fiilis, se voi olla haitaksi. Toisen työtä arvioidessa kannattaa olla erityisen tahdikas.

Tätä kannattaa tosiaan varoa vaikka innokas (ja kyvykäskin) olisi. Ei nyt varsinaisesti it:tä, mutta meidän firmaan haastateltiin ehdokkaita markkinointikoordinaattorin tms paikkaan, ja siellä yksi just koulusta valmistunut ja itseluottamusta puhkuva tyyppi kertoili, ettei malta odottaa kuinka hän pääsee kertomaan markkinointiosastolle mitä kaikkea siellä tehdään vanhentuneilla metodeilla ja miten hänen avullaan osasto saadaan nostettua ihan nextille levelille ja työtavat sekä projektit tuotua nykyaikaan.

Ei saanut kylläkään paikkaa jostain ihmeen syystä...

 

[OD.]

Itse olen ainakin kohteliaasti ilmoittanut, etten etene testiin, ja pahoitellut mahdollista haittaa työnantajalle. Viitaten tiettyihin vastauksiin ketjussa, en näe, miksi kenenkään ensimmäinen reaktio kieltäytymiseen sen taustoja tuntematta tulisi olla, että hakijassa on jotain erittäin negatiivista. Rekry kuitenkin on neuvottelu ja yleensä sen tuloksena ei ole sopimusta.

Kuvaamasi rekry ei ole mikään neuvottelu vaan sopivien hakijoiden karsinta. Neuvotteluja käydään sitten myöhemmin niiden kanssa, joiden katsotaan sopivan parhaiten ko. tehtävään.

Sitä, joka rekrytointia vetää tuskin kiinnostaa suoraan sanottuna paskan vertaa sun motiivit kieltäytyä testeistä. Kieltäytyi, vedetään nimi yli ja jatketaan seuraavan kanssa. Tää on rekrytoivalle vaan hyvä juttu, ei tarvinnut maksaa testistä.

 

[Antti Alien]

Työkalut kannattaisi pakata kontteihin siten, että kaikilla on varmasti identtinen perusympäristö. Suuremmissa yrityksissä voi mennä etenkin alussa runsaasti aikaa pelkästään työympäristön kasaamiseen ja myöhemminkin epäyhteensopivuudet aiheuttavat helposti turhaa työtä.

Juu ei. Aika monotonista hommaa pitää olla, jos ei koskaan tarvitse mitään uutta softaa koskaan. Virtuaaliväkkärän ja natiivijärjestelmän välisessä liikenteessä on lisäksi aina jos jonkinlaista ongelmaa liittyen polkuihin, tiedosto-oikeuksiin, reititykseen, käyttäjänimiin ja ties mihin. Mieluummin pieni skripti, joka potkaisee kehitysympäristön välttämättömät palat ylös, ja loput saa kehittäjä asentaa itse mielensä mukaan.

Meillä on buildijärjestelmä kontissa ja siitäkin on kyllä melkein enemmän haittaa kuin hyötyä. Plussat: kääntäjien ja kirjastojen versiot ovat tiedossa ja buildin voi toistaa melko luotettavasti. Miinukset: melkolailla kaikki muu.

 

[FireFly Renaissance]

Vahva kiinnostukseni alusta asti on ollut välttää insinöörimäiset positiot. Ne ei vain ole minun juttu. Tässä tapauksessa rekryssä kävi ilmi, että firma hakee koulutettavia tarpeisiinsa, mutta ei sinänsä tarjoa hakemustani vastaavaa työtä. No, ei se mitään, olen varautuneen kiinnostunut ja rekryn edetessä sitten osaltani päättelen, olenko haettua materiaalia. Jos saan testin, mietin, haluanko tehdä pääasiassa tällaista tai siihen liittyvää toimintaa työpäivän verran viisi kertaa viikossa.

Jos työnantajana aikoo testata esim. fronttijannua C++-tason algoritmipähkinöillä (riippuu kontekstista miten tähän päädytään), kannattaa luultavasti tehdä se jo haastattelussa, jolloin hommalle voi antaa kontekstia ja saa myös feedback loopin hakijalle mielenkiintoisista asioista. Ei sovi kaikille, mutta omasta mielestäni näin.


Astuin mukavuusalueeltani ulos syyskuussa kun laitoin ensimmäisen työhakemukseni vaativalle alalle, johon en omaa mitään formaalia koulutusta. Helvetin mukavaa humanistina päätyä suoraan tekniseen C++-työhaastatteluun, jossa monotoninen insinööri tenttaa GCC:n bugeista etkä tiedä mistään mitään, ja tyyppien naamoista näkyy, että olisivat voineet käyttää aikansa paremmin.

Rehellisesti sanottuna mahdoton yhtälö. Joko haluat mennä tekemään sitä software engineeringiä insinöörien kanssa tai sitten et halua alalle. Suomessa Hervantavakiolla laskettuna n.90 % ohjelmoijista on insinöörikoulutuksen käyneitä, joten käytännössä joka ainoassa paikassa on myös insinööritaustaisia ohjelmoijia, todennäkösesti enemmistönä ja käytetään insinöörimäistä työotetta, koska tuotteita pitää tehdä taloudellisten raamien rajoissa.

Ja, jos jossain ei ole insinööritaustaisia tekijöitä kyseessä on todennäköisimmin nimenomaan ne algoritmit, data science tmv. matematiikkapainotteisempi tehtävä, joita et halunnut tehdä.

Olen kuitenkin tavannut useammankin "humanisti"taustaisen insinöörin, ei se mikään ongelma ole, jos ei halua itse tehdä siitä ongelmaa.

 

[JCSH]

Vahva kiinnostukseni alusta asti on ollut välttää insinöörimäiset positiot. Ne ei vain ole minun juttu.

No sitten et halua koodariksi.

 

[FireFly Renaissance]

Tää on nyt vähän autovertauksena tälleen, että vapaa-ajallla on mukava rassata sitä Corvettea, mutta jos haluaa työkseen tehdä pitää vaan huoltaa se naapurin Pösö kun se sen pajalle tuo.

Mutta Pösöäkin voi olla ihan kiva räplätä jos autoista tykkää, ja aina joskus sinne pajalle saattaa tulla se Mustang. Jos vielä onnistuu tekemään ittensä ajan kanssa kulmakunnan kovimmaksi mekaanikoksi voi päästä rassaamaan vaikka formuloita.

 

[Mechanical Man]

jaaha on kyllä järkkymätön oikeassa olemisessaan. Tiedä sitten missä se vika on oikeasti, useammassa ohjelmistoalan ammattilaisessa vai sinne pyrkivässä henkilössä..

ps. tämä osuu henkilöön, mutta jaaha itse aloitit

 

[JCSH]

Väärinymmärtämisen määrä ketjussa on kyllä valitettavaa. Arvostan io-techiä alustana paljon, mutta nyt keskustelu voisi muutamalta tyypiltä olla harkitumpaa. Pientä confirmation biasin hälventämistä.

No kerro nyt sitten minkälaisia hommia sä koodarina haluat jos haluat välttää "insinöörimäisiä positioita"?

 

[JCSH]

Hankala sanoa olematta ensin töissä alalla. Varmaan hommat etenee tyyliin "tässä on tiimi, tutustu siihen", "tässä on stäkki ja työkalut x, tutustu niihin", "tässä on codebase y, tutustu siihen", "tässä on asiakkaalta tullut bugiraportti, katso jos saat sen selvitettyä", jne. Jossain vaiheessa vähän myöhemmin tulee "asiakas haluaisi tällaista, voitko dekryptata vaatimukset ja/tai implementoida ne?", ja tässä vaiheessa olisi hyvä, jos haluttu asia ei ole V8:n cache-optimointia, koska tiimistä toivottavasti löytyy siihen orientoituneempi jannu.

No sitten ilmainen neuvo jolla säätät paljon aikaa:

Kaikki koodarit tekevät insinöörimäistä työtä. Josset halua tehdä insinöörimäistä työtä niin koodarin ura on täysin väärä ura sulle. Jos haluat tehdä töitä lähellä koodausta joka ei ole ihan niin insinöörimaistä niin olettaen että sulla on graafista silmää, voisit ehkä harkita UXD alaa. Tosin sekin kyllä yleensä vaatii jonkin verran insinöörimäistä työtä.

 

[hsalonen]

"tässä on tiimi, tutustu siihen" -> vähänkin sosiaalisempi kaveri tulee toimeen tiimin kanssa alkaen päivästä 1 ja ei käytä työaikaa (pl. lounastauot) tiimiin tutustumiseen
"tässä on stäkki ja työkalut x, tutustu niihin" -> tästä ei firma saa yhtään mitään rahaa ja periaatteessa noi pitäisi osata jo työhaastattelussa. Jos ei osaa, niin sitten vaikka @JCSH tulee näyttämään ne sinulle, mutta aikaa on vaan pari tuntia ja sinun pitäisi olla semmoinen fiksu yksilö, että voi sisäistää ainakin osan asioista tässä ajassa..
"tässä on codebase y, tutustu siihen" -> no joo, mutta tämä on käytännössä se eka viikko ja tätä + käyttöoikeuksia pyöritellään hetki alussa, mutta tämä ei ole sitä varsinaista työtä ja tässä et tuota firmalle mitään hyödyllistä..
"tässä on asiakkaalta tullut bugiraportti, katso jos saat sen selvitettyä" -> tuskin laittavat junioria tähän
"asiakas haluaisi tällaista, voitko dekryptata vaatimukset ja/tai implementoida ne?" -> tuskin edelleen laittavat junioria miettimään järjestelmän ominaisuuksia ja nämä käy vaikka aika-arvioinnin läpi ja siihen et ole ensimmäisenä kuukautena kyvykäs..

--

Todennäköisemmin niin, että eka homma on "implementoi tähän dropdowniin valinnat "Muunsukupuolinen" ja "En halua kertoa"". Käy sitten @Mechanical Man kanssa läpi, miten puskette nämä testiin. Tässäkin miehen aika on vähissä, niin pitäisi oppia kerralla. Tehtävät on alussa helppoja ja selviä, mutta vaikeutuvat kun kokemusta tulee enemmän. Kuitenkin konkreettisia, oikeita tehtäviä, eikä mitään codebasen ylläpitoa ja haltuunottoa. Ja jos se koodi on kauheaa ripulia, niin tuskin ketään haluaa maksaa sinulle siitä, että kaunistelet sitä kaiken työaikasi ja haukut sen tekijää. Jos aikaa on, voit purkaa teknistä velkaa, mutta kannattaa varautua siihen, että tekee oikeita asioita, eikä ryhdy minkään projektin ylläpitäjäksi.

--

Esimerkkihenkilöt on satunnaisia vedoksia ketjusta. Ei välttämättä ole tulevalla työnantajalla töissä. Kuitenkin kiireisiä kavereita, jotka ei taluta kädestä, vaan auttaa työaikansa puitteissa.

 

[pelitys]

Hankala sanoa olematta ensin töissä alalla. Varmaan hommat etenee tyyliin "tässä on tiimi, tutustu siihen", "tässä on stäkki ja työkalut x, tutustu niihin", "tässä on codebase y, tutustu siihen", "tässä on asiakkaalta tullut bugiraportti, katso jos saat sen selvitettyä", jne. Jossain vaiheessa vähän myöhemmin tulee "asiakas haluaisi tällaista, voitko dekryptata vaatimukset ja/tai implementoida ne?", ja tässä vaiheessa olisi hyvä, jos haluttu asia ei ole V8:n cache-optimointia, koska tiimistä toivottavasti löytyy siihen orientoituneempi jannu.

Kuulostaa siltä että sun pitäisi ensin olla pitkä koodauskokemus että pystyt nopeasti omaksua stäkin, työkalut ja koodin ja sen jälkeen toimia projektipäällikkö/asiakkuuspäällikkönä tasolla ja tiketöidä koodaritiimiä asiakkaan toiveilla.

 

[Incredible Buff]

Jotenkin alkaa tuntumaan, että tää on hyvä ja pitkälle viety trolli, mutta ihan nyt oikeasti kannattaisi miettiä vähän omaakin asennetta, jos ei heti saa sitä mitä haluaa. Hirttäydyit edelleen tuossa testiasiassa kiinni siihen teknologiaan. Siinä voi olla ihan vissi syy miksi annetaan tehtävä tuntemattomalla teknologialla, että nähdään miten kaveri reagoi. Eräs kaveri reagoi tuollaisessa testissä tyyliin "vittu mitä paskaa, ei jaksa enää" kun ei saanut sitä heti ratkeamaan. Rekry jäi siihen, koska on riskinä, että kaveri reagoi samalla tavalla, kun projekti alkaa vähän tökkimään.

 

[Mechanical Man]

Teit arvion vajavaisin tiedoin ja vaikka sinulle on kuinka kerrottu, ettei se testi kuvaa tehtävää työtä, pitäydyt kannassasi etkä ymmärrä todennäköisesti tehneesi erittäin vajavaisen päätöksen.

 

[Jorsetti]

Tätä kannattaa tosiaan varoa vaikka innokas (ja kyvykäskin) olisi. Ei nyt varsinaisesti it:tä, mutta meidän firmaan haastateltiin ehdokkaita markkinointikoordinaattorin tms paikkaan, ja siellä yksi just koulusta valmistunut ja itseluottamusta puhkuva tyyppi kertoili, ettei malta odottaa kuinka hän pääsee kertomaan markkinointiosastolle mitä kaikkea siellä tehdään vanhentuneilla metodeilla ja miten hänen avullaan osasto saadaan nostettua ihan nextille levelille ja työtavat sekä projektit tuotua nykyaikaan.

Ei saanut kylläkään paikkaa jostain ihmeen syystä...

Missään tosiaan ei ole täydellistä ja samaa kakkaa on tarjolla eri paketeissa. Kun on asuntolainaa ja muuta pikku vikaa itsessäänkin, niin parannusehdotuksiakin joutuu annostelemaan pienissä paloissa. Jännästi ajallakin on parantava vaikutus moneen asiaan, tämän päivän stara on huomisen symbianjäte.

 

[JCSH]

Testi oli about tutulla kielellä ja säännöiltään kohtuullinen (googlaus sallittu, jne.). Tilanteeseen ei liittynyt draamaa. Arvioin esimerkkikysymykset ja päättelin, että työnantaja hakee erilaista devaajaa kuin mitä itse olen. Ei valtavasti eroa siitä, että työilmoituksen luettuani päätän, etten ole sopiva hakija. Jostain syystä se on ihmisille vaikea hyväksyä; en sitten tiedä, onko taustalla omia huonoja kokemuksia vai mitä. Moni koittaa ekstrapoloida asiasta ties mitä, mutta homma todellakin on niin simppeli kuin että arvioin rekryn etenemistä ja päätin olla jatkamatta seuraavalle kierrokselle. Mihinkään yksittäiseen tekijään ei kannata hirttäytyä, koska kyseessä on arviointi huomioiden tekijät x, y, z, w, jne.

Tai sitten kyse on siitä että täällä on useita henkilöitä jotka ovat olleet tällä alalla useita vuosia, jopa vuosikymmeniä. Henkilöitä jotka ovat olleet useammissa työpaikkahaastatteluissa niin haastateltavina kuin haastattelijoina. Henkilöitä jotka ovat joutuneet tekemään noita koodaustestejä ja henkilöitä jotka ovat suunnitelleet noita koodaustestejä. Ja arvioineet niiden lopputuloksia ja tehneet päätöksiä siitä että kuka rekrytään ja ketä ei rekrytä.

Ja me sanotaan sulle, meidän kokemuksen syvällä rintaäänellä, että tää sun järkeily on täysin todellisuudesta irtautunutta ja teet aivan massiivisia virheitä jos oikeasti haluat työllistyä IT-alalle koodarina. Sä voit joko kuunnella meitä tai et mutta suosittelen että kuuntelet jos meinaat haluta töitä.

Spoileri

Olettaen että tämä ei ole joku long con trollaus missä kohta tulet ilmoittamaan kuinka jotenkin maagisesti sait työpaikan josta sulle maksetaan 8k€ kuussa

 

[hsalonen]

Riippuu toki paikasta. Pointtini ei ollut niinkään listata jokaista työtehtävänä vaan sisäänajoa ja vähittäin tehtävien vaikeutumista. En suoraan näe, miksi bugin korjaaminen olisi juniorille sopimatonta, jos jannulla on yhtään intuitiota ja tuntee käytettyä koodia? Ehkä toisen vuoden kesätyöläistä ei, mutta ei junioriakaan? Ja miksei junioriakin otettaisi mukaan antamaan feedbackia hommaan? Käsittääkseni joissain paikoissa on käytäntönä.

Sinulla on jotenkin hirveän pitkä aika siihen, kunnes pääset tekemään tuottavaa työtä. Firman sisäänajo maksaa, firman sinulle tarjoama koulutus maksaa, etkä sinä aikana tuota firmalle mitään - maksat vaan enemmän, kun joku joutuu kädestä pitämään kiinni (= viet hänen työaikaansa). Sen takia haastatteluissa kysytään näitä teknologioita joilla firma tekee töitä, ettei niitä tarvitse erikseen opettaa. Koodaustestikin olisi todennäköisesti pyrkinyt osoittamaan, että voit tehdä yhden palasen itsenäisesti, varsin nopeasti ja riittävällä laadulla. Tai kestät paineita ja osaat pilkkoa vaikean tehtävän helppoihin osiin, jne..

Sinulla on intialainen näkemys asiasta: firma kouluttaa sinusta asiantuntijan johonkin järjestelmään/teknologiaan X pikkupalkalla, jonka jälkeen voitkin vaihtaa firmaa ja/tai pyytää reilusti lisää palkkaa, kun nyt osaat asian X oikeasti.

--

Feedbackkia otetaan koostetusti kaikilta ketterissä retroissa, eikä siihen laiteta ketään istumaan tuottamaan feedbackkia koko työaikansa. Tämä on kyllä merkki terveestä itseluottamuksesta, että uskot osaavasi asiat paremmin ja kehittäväsi koodia paremmaksi ehdotuksillasi, mutta esim. koodauskäytäntöjä kehitetään yhdessä, eikä yksi juniori kirjoittele niitä uusiksi samalla kun tutustuu koodiin.

--

Minulla ja sinulla on kovin eri kuva, mitä työaikanasi tekisit.. Jos menet tehtaan kokoomalinjastoon, niin ei kukaan selitä sinulle koko tehtaan toimintaa ja ota palautetta tehtaan toiminnan tehostamiseksi. Siellä halutaan sinut omaan paikkaasi kokoamaan tuotetta mahd. pian ja riittää, että osaat sen oman pienen palasen. Sitä pitäisi tehdä mahdollisimman tehokkaasti, eikä mahdollisimman täydellisesti. Perfect is the enemy of good.

 

[JCSH]

Se, että softa-alalla tuo olisi epänormaalia käytöstä kuulostaa vähän huolestuttavalta.

Ei vaan softa-alalla on epänormaalia käytöstä että juniorihommaa hakeva tyyppi kieltäytyy tekemästä jotain yksinkertaista ohjelmointiharjoitusta rekryprosessin aikana. Aiemmin mainitsit jotain linkitetystä listasta, jos kyse oli siitä niin sehän on aikalailla niin perusohjelmointitehtävä kuin vain voi olla ja jota voi käyttää käytännössä kaikissa juniorikoodari haastatteluissa selvittämään että osaako se tyyppi oikeasti koodauksen perusteita vai ei.

 

[JCSH]

Linkitetty lista oli esimerkkitesteissä lämmittelynä, jota seurasi progressiivisesti vaikeutuvia tehtäviä. Jos saan kysymyksen pelkästä linkitetystä listasta, oletan, että nyt testataan, että tyyppi osaa laittaa kaksi palikkaa päällekkäin. Jos en mene täysin lukkoon ja kuse tehtävää, sitä ideaalisesti seuraisi sitten profiiliini relevantimpia kysymyksiä. Jos taas olen saamassa mini-HackerRank-tyylistä testipatteria, oletan, että firma hakee erilaista kaveria kuin mitä itse olen.

Jos tosiaan luulit, että minulta kysyttiin vain linkitettyä listaa ja kieltäydyin siitä, olet muodostanut aika epätarkkoja käsityksiä koko hommasta. Kannattaa vain rohkeasti kysyä yksityiskohdista, jos tuntuu epäselvältä. Myös jos vaikuttaa, että nyt tyyppi on täysin kujalla, on mahdollista, että olet tulkinnut asiaa väärin.

No mitä kysymyksiä siinä sitten kysyttiin? Ja mikä oli sen position kuvaus mihin olit hakemassa? Siis sillai pääpiirteittäin.

 

[Paapaa]

oletan, että firma hakee erilaista kaveria kuin mitä itse olen.

Kaikesta paistaa läpi, ettet kysynyt, millaista työtä olisit alkanut tehdä. Tai millaisia projekteja siellä tehdään, vaan teit oletuksia aika hatarin perustein. Yhä edelleen: et voi testistä päätellä työn sisältöä.

 

[Bladekill]

Ei taida olla kuin pari sivua sitten kun puhuttiin softa-alan laadusta ja joku taisi jopa mainita kuinka "niihin tärkeisiin hommiin hankitaan sitten ihan omat kaverit". Noh tuota noin...
https://www.bloomberg.com/news/arti...ax-software-outsourced-to-9-an-hour-engineers

In offices across from Seattle’s Boeing Field, recent college graduates employed by the Indian software developer HCL Technologies Ltd. occupied several rows of desks, said Mark Rabin, a former Boeing software engineer who worked in a flight-test group that supported the Max.

The coders from HCL were typically designing to specifications set by Boeing. Still, “it was controversial because it was far less efficient than Boeing engineers just writing the code,” Rabin said. Frequently, he recalled, “it took many rounds going back and forth because the code was not done correctly.”

 

[PornReindeer]

Ei taida olla kuin pari sivua sitten kun puhuttiin softa-alan laadusta ja joku taisi jopa mainita kuinka "niihin tärkeisiin hommiin hankitaan sitten ihan omat kaverit". Noh tuota noin...
https://www.bloomberg.com/news/arti...ax-software-outsourced-to-9-an-hour-engineers

Mainittiinhan artikkelissa että euroopassa on tehty vähemmän offshorehommaa ja myös:

Under Dennis Muilenburg, a longtime Boeing engineer who became chief executive in 2015, the company has said that it planned to bring more work back in-house for its newest planes.

Ja sehän on hyvä kysymys onko 50 vuotta vanhan koneen retrofit nähty niin "tärkeäksi hommaksi", ettei esim. näytön koodausta ei voisi ulkoistaa...

 

[Stephen Elop]

Ja sehän on hyvä kysymys onko 50 vuotta vanhan koneen retrofit nähty niin "tärkeäksi hommaksi", ettei esim. näytön koodausta ei voisi ulkoistaa...

Nyt kun Boeingin matkustajakone on laskeutunut vain pari kertaa epäsuotuisasti tonttiin, niin herääkin kysymys kuinka kaukana ollaan sotilaskoneiden koodin toteutuksen ulkoistamisessa?

Ja koodausvirheet mahdollistavat vallan uudet poliittiset sotilastoimenpiteet. "Ohjelmavirheen takia ohjus lähti liikkeelle ja osui Teheraniin." Eli palkataankin kunnon guru koodaamaan halutunlainen virhe koodiin.

 

[embedded]

Itse olen ainakin kohteliaasti ilmoittanut, etten etene testiin, ja pahoitellut mahdollista haittaa työnantajalle. Viitaten tiettyihin vastauksiin ketjussa, en näe, miksi kenenkään ensimmäinen reaktio kieltäytymiseen sen taustoja tuntematta tulisi olla, että hakijassa on jotain erittäin negatiivista. Rekry kuitenkin on neuvottelu ja yleensä sen tuloksena ei ole sopimusta.

Näin sivusta seuraajana rupesi mietityttämään että jos olet usein kieltäytynyt kooditestistä, niin montako työpaikkaa olet tällöin saanut,
tai päässyt vielä kys. työhaastattelussa jatkoon,
ja oletko tällä hetkellä työsuhteessa ?

 

[yannara]

Jos kieltäytyy testeistä, tai mistä tahansa, kuten psykologisista kokeista, niin kertoo että henkilö ei ole kovin motivoitunut tähän työtehtävään yms. Joskus henkilöt on "pakotettu" haastattellun, esim koulussa tai työttämänä. Toisena voi olla, että on kuvitellut jotain muuta mitä sitten haastattelussa on paljastunut. Jokainen tekee omat valinnat, itse muistan että joissakin työhaastatteluissa ensimmäinen reaktio testeihin oli hiema nihkeä, mutta sitten vähän asiaa sulateltuani menin ihan tyytyväisenä niihin testeihin. Nykyään kun on työkokemusta ja kokemusta monesta työantajasta, niin ei kelpaa mikä tahansa ja sitä yrittää tulkita haastatteluissa koko ajan, viihtyisinkö täällä jne.

 

[Bladekill]

Yhdestä paikasta on annettu kooditesti. Jos en tee pyydettyä testiä niin lähtökohtaisesti siksi että paikka ei vaikuta sopivalta.

Viime elokuuksi lopetin hommat muualla ja siirryin hakemaan devauspuolelle. Piti olla parin kuukauden nakki löytää työtä, mutta haku jatkuu vielä jonkin aikaa ainakin.

Voi olla että jatkuu vielä tovin. Rekrytointi on neuvottelu kuten itse sanoit joku hetki sitten, mutta kun on uran alkuvaiheessa ilman työkokemusta niin ne omat neuvottelutpanokset ovat suht. ohuet.
Itse pidän n. 1-3 haastattelua viikossa ja kaikki ensimmäisen haastattelun läpäisevät laitetaan tekemään kotitehtävä tai joskus paikan päällä tapahtuva tekninen koe. Jos tyyppi on aivan 6/5 senior/lead devaaja iskunkestävällä portfoliolla niin sitten tuskin alan vaivaamaan noilla, mutta muuten testi tai ovi.

 

[Janz]

Vaihdoin muutama vuosi sitten testauspuolelta koodariksi. Heti ensimmäisestä haetusta paikasta tuli haastattelukutsu ja kooditesti. Tein testin (Aika perus CRUD näkymä jossa listataan/lisätään/poistetaan kamaa), ilmeisesti se meni OK, kävin haastattelussa, sain paikan.

En kyllä ymmärrä alkuunkaan "en tee testiä" tyylistä asennetta, etenkään jos on aktiivinen haku päällä. Nykyisellä kokemuksella onneksi noita vaihtotarjouksia tulee tasasin väliajoin ihan ilman hakemuksia tai testejä, niin ei ole tarvinnut semmoisia enää miettiä.

 

[Janz]

Itsekin sain ensimmäisestä hakemuksesta haastattelukutsun. Firmalla vain oli väärä käsitys siitä, mihin sovin. Portfoliossa pelkästään C++:aa ja assemblyä, joten varmasti vaikutti, että voisin sopia bäkkiin insinöröimään. Oikeasti olen enemmän fronttipuolen ihmisiä bäkkikiinnostuksella - mutta ilman relevanttia fronttikokemusta on ollut aika hiljaista saada haastatteluja sellaisiin paikkoihin. Vähitellen niitäkin alkaa varmasti tulemaan kun oppii hyödyllisempiä stäkkejä.

Vähän riskaabeleilla vesillä kyllä liikut jos oikeasti ajatuksena on hankkia se kokemus hyödyllisemmistä stäkeistä kotona (jos nyt luin oikein rivien välistä). Ennemmin hakeutuisin itse niihin bäkkärihommiin ensin jos niitä paremmin on tarjolla ja vaikka siellä sitten yrittää sisäisesti päästä tekemään fronttia.

 

[juhei]

Osittain myös ihan yleisenä kommenttina, niin ilman alan työkokemusta sen suoran ihannepaikan löytäminen on melko epätodennäköistä. Oppirahat pitää maksaa joka tapauksessa, ja jos menee sinne "ei ihan täydelliseen" työpaikkaan niiin saa ennenkaikkea sitä työkokemusta. Enkä tarkoita pelkästään riviä CV:ssä, vaan ihan sitä käytännön kokemusta että millaista se IT-alan työ on. Siellä voi vaikka huomata että joku asia mitä on pitänyt turhana alkaa kiinnostamaan ja vaikuttamaan omalta jutulta. On helpompi tehdä päätöksiä jatkon kannalta. Tosin muutkin on tainneet nämä asiat jo todeta täällä.

Jos oikeasti menee 4-10 haastattelua että löytyy sopiva paikka niinkuin arvioit (mitä vähän epäilen näiden juttujen perusteella, lähinnä sun odotukset työpaikasta vs. kokemus) ja vuodessa pääsee kolmeen haastatteluun, niin...

Onhan se mahdollista että kolmen vuoden odottelun jälkeen löytyy sopiva paikka. Järkevämpää on ottaa se entry level paikka vastaan kunhan ei ole täyttä vittuilua palkka ja työpaikan ilmapiiri, opetella ja nähdä käytännössä mitä se tekeminen oikeasti on, ja sitten 1-2 vuoden sisällä laittaa uudestaa haku päälle siihen unelmien paikkaan kun luultavasti tietää mitä haluaa. Jos oikein käsitin niin olet nyt työttömänä? ilman alan työkokemusta on varmaan ihan sama mitä taitoja sitä CV:n saat vaikkapa tuon kolmen vuoden aikana lisättyä jos samalla siellä näkyy pitkä työttömyysjakso.

Itsellä meni suurinpiirtein näin vaikka ei ollutkaan varsinaisesti suunnitelma: alkuun ei alanvaihtajana meinannut löytää sopivaa paikkaa, sitten otin asenteen että "kaikki kelpaa" kunhan saa alan työkokemusta kun muuten oli paperit kunnossa, ja vajaan 2 vuoden jälkeen pääsinkin sitten todella hyvään paikkaan missä esim. palkkataso nousi reilusti.

 

[JCSH]

Itsekin sain ensimmäisestä hakemuksesta haastattelukutsun. Firmalla vain oli väärä käsitys siitä, mihin sovin. Portfoliossa pelkästään C++:aa ja assemblyä, joten varmasti vaikutti, että voisin sopia bäkkiin insinöröimään. Oikeasti olen enemmän fronttipuolen ihmisiä bäkkikiinnostuksella - mutta ilman relevanttia fronttikokemusta on ollut aika hiljaista saada haastatteluja sellaisiin paikkoihin. Vähitellen niitäkin alkaa varmasti tulemaan kun oppii hyödyllisempiä stäkkejä.

No jos sun portfoliossa on pelkästään C++:aa ja Assemblya niin et ole fronttipuolen devaaja. Voi olla että sua kiinnostaa fronttipuolen hommat mutta kerta sulla ei ole mitään varsinaista koulutusta alalle eikä myöskään sun pitkän ajan harrasteprojektit sovi niihin hommiin mitä haluat tehdä niin lopputuloksena on että tulet kyllä varmaan junnaamaan paikoillasi pitkään.
Joten suosittelen kyllä että lähdet metsästämään työpaikkaa käyttäen sun omia vahvuuksia, eli C++, ja sitten jahka saat sen ekan työpaikan ja vähän oikeaa kokemusta alle niin on paljon helpompi sitten suuntautua toiseen suuntaan.

 

[FireFly Renaissance]

Kotonahan tuo kaikki devauskokemus on hankittu. Teet vain projektia toisen perään ja yrität kritisoida kaikkea mitä teet.

Kun ei devaa kotona vaan tekee työkseen niin siinä tulee paljon muutakin kaupan päälle kuin pelkästään koodia. Sitä varten työkokemusta arvostetaan ja sillä puolella on varmaan nyt enemmän opittavaa kuin siinä varsinaisessa "devaamisessa". Varsinkin kun on itseoppinut ja jäänyt kaikki (ryhmä)harjoitustyöt ja ohjelmistotuotannon ymv. kurssit käymättä, jotka ovat osa koulutusta. (Ja aika tärkeä osa)

 

[juhei]

Alalle täysin ulkopuolisena tulleena pari haastattelua ei ole vielä mitään. Sopiva paikka saattaa löytyä nopeasti tai sitten ei. Osalle se osuu suoraan käteen, osa ottaa mitä tahansa ja toivoo toivoo, osa jatkaa hakua pidempään ja työllistyy sitten, ja osa siirtyy jossain vaiheessa muualle. Mitään täydellistä paikkaa en ole hakemassa - mahdollista on, että kaupallinen devaus ei vain sovi minulle ja siksi kestää, mutta sen sitten näkee tulevaisuudessa.

Jos on omasta mielestä mahdollista että kaupallinen devaus ei sovi, niin kannattaisi mahdollisimman pian hankkia se kokemus kaupallisesta devaamisesta että osaa sanoa. Niinkuin tuossa yllä jo oikeastaan totesin.

 

[FireFly Renaissance]

Alalle täysin ulkopuolisena tulleena pari haastattelua ei ole vielä mitään. Sopiva paikka saattaa löytyä nopeasti tai sitten ei. Osalle se osuu suoraan käteen, osa ottaa mitä tahansa ja toivoo toivoo, osa jatkaa hakua pidempään ja työllistyy sitten, ja osa siirtyy jossain vaiheessa muualle. Mitään täydellistä paikkaa en ole hakemassa - mahdollista on, että kaupallinen devaus ei vain sovi minulle ja siksi kestää, mutta sen sitten näkee tulevaisuudessa.

Ei, mutta jos ne haastattelut ovat kerran kiven alla suosittelen ottamaan jokaisesta kaiken irti mihin pääsee. Työsopimuksen kirjoittamiseen asti saa peruutella ihan rauhassa, ja kelaa lukuunottamatta senkin jälkeen.

 

[penttip]

Minusta on ihan absurdi ajatus, että jättää täydellisenä keltanokkana testit tekemättä. Tuossa ei nähdäkseni olisi ollut mitään muuta kuin voitettavaa. Eli testistä olisit voinut saada hurjasti kokemusta siihen, miten se tuleva rekry todennäköisesti menee tulevaisuudessa sinne ns. "oikeaan" työpaikkaan. Ei sitä hommaa olisi pakko ottaa vastaan, vaikka haastattelujen ja testien jälkeen sinut valittaisiin. Nykyään on myös 6 kuukauden koeaika, ja se koeajan tarkoitus ei ole pelkästään se että työnantaja saa potkia työntekijän pihalle jos homma ei toimikaan - se on ihan yhtä paljon siksi, että työntekijä voi arvioida vastaako paikka sitä mitä uraltaan haluaa. Miksi siis ei hyödyntäisi tätä ja lähtisi kokeilemaan? Jos päätyy lähtemään koeajalla, ei sitä ole pakko CV:hen kirjoittaa, varsinkin jos on henkisesti jo muutenkin varautunut koodailemaan kotona seuraavat 3 vuotta, joten pikku aukot ei siinä vaikuta mitään.

Itsellä ei ole mitään kokemusta IT puolen testeistä, mutta normaaleista soveltuvuusarvioinneista useita kertoja. Tuosta voi kyllä sanoa, että jos olet kerran käynyt läpi koko päivän kestävän arvioinnin, lähdet seuraavaan arviointiin ihan eri tasolta verrattuna hakijaan, joka ei tiedä yhtään mitä tuleman pitää.

 

[juhei]

30 hakemusta, 1000 committia yksinään GitHubiin, 20 uutta projektia, neljä uutta kieltä, varmaan 20 versiota CV:stä. Ihan kohtuullisella kiireellä tuota on tullut tehtyä. Melko varmasti pääsen tulevaisuudessa laittamaan nimen mieluisaan työsopimukseen ja ura lähtee käyntiin.

Itsehän sinä sanoit ettei tiedä onko kaupallinen devaaminen sinua varten, ei se ollut minun spekulaatiota. Noi jutut mitä tossa kerrot on sitä harrastamista, eikä kaupallista devaamista eli töiden tekemistä palkkaa vastaan