IT-alan työpaikat

Tosi firmakohtaista. On noita ollu firmoja joissa 3-4 vuotta ollut on Senior. Ja taas toisaalla 10 vuoden kokemuksella vaan Software Developer.

Muok: Niin ja itse taisin siinä viiden vuoden kohdalla päivittää tittelin firmassa Software Developer -> Software Architect kun ei siellä tuollaista Senioria ainakaan minulle tyrkytetty.

Pelkkä vuosien vertailu ei kerro vielä itsessään kokemuksesta mitään. Kuten totesit, niin firmojen välillä on eroa. Toisissa kun astuu ovesta sisään on "Senior" ja toisissa edes 10 vuoden jälkeen tuo ei välttämättä tapahdu. Silti jälkimmäinen on todennäköisesti vielä osaavampi tekijä. Arkkitehdin roolissa voi sanoa, että sillä on hieman enemmän vielä merkitystä kuinka paljon ja laajaa kokemusta on alla. Fakta tällä alalla on kuitenkin se, että oppiminen ei lopu koskaan ja sitä kautta kehittyy työssään jatkuvasti, jos vain tahtoo.

Senior Developer vai Architect, meillä firmassa näillä ei ole hierarkiaa vaan kyse on enemmän työnluonteesta ja omista tahtotiloista. Usein kuitenkin porukka on ensin Seniorina, ja sitä kautta kerää vastuullisemmassa asemassa hankkeissa lisää kokemusta. Tämän jälkeen sitten Architect rooli on osalle ihan relevantti, ja osa pysyy Seniorina mutta kyseessä ei ole hierarkia niin tällä on vähemmän merkitystä. Muutenkin keinotekoiset rakenteet, etenkin firman sisällä tittelien suhteen ovat täyttä hukkaa (waste). Osaamista ei voi kiteyttää vain titteliin, ja asiakkaiden suuntaan kuitenkin ollaan jossain tietyssä roolissa. Tuotetaloissa varmasti eri tavalla, mutta näin konsulttipuolen kokomuksella.
 
Senior developer ja Architect nyt ei ole oikein verrattavissa muutenkaan, koska työnkuva on eri. Tai ainakin pitäisi olla, ellei ole annettu Architect titteliä ihan vain egorunkkaus mielessä etkä oikeasti tee arkkitehtuurisuunnittelua koodauksen ohella. Itse en kyllä uskaltaisi laittaa uudiskehitys-softaprojektin ainoaksi arkkitehdiksi kaveria jolle on annettu kyseinen työnimike ihan vaan huvikseen ilman näyttöä, voi nimittäin saada valtavasti vahinkoa aikaan.
 
Viimeksi muokattu:
Senior developer ja Architect nyt ei ole oikein verrattavissa muutenkaan, koska työnkuva on eri. Tai ainakin pitäisi olla, ellei ole annettu Architect titteliä ihan vain egorunkkaus mielessä etkä oikeasti tee arkkitehtuurisuunnittelua koodauksen ohella. Itse en kyllä uskaltaisi laittaa uudiskehitys-softaprojektin ainoaksi arkkitehdiksi kaveria jolle on annettu kyseinen työnimike ihan vaan huvikseen ilman näyttöä, voi nimittäin saada valtavasti vahinkoa aikaan.

Työnkuva on eri, tai miten se nyt mielletään. Kyllä niissä päällekkäisyyksiä on ja koodaamaton arkkitehti on paperipainoon verrattavissa oleva kaveri, joku osuus työstä tulee olla koodausta edes satunnaisesti. Senior voi hyvin ottaa kantaa arkkitehtuuriin sekä ylätasolla, että tietysti itse toteutuksessa. Riippuu tietysti miten roolit on firmassa määritelty, mutta mitään hierarkista lokerointia ei harrasteta meillä. Itse toimin arkkitehtinä, mutta aiemmin tei samoja asioita myös ilman tätä nimikettä. Samoja asioita on molemmissa rooleissa, painotus on vain eri.

Arkkitehdin määritelmiä on yhtä monia kuin määrittelijöitä, missä se raja menee? Minkä jälkeen on arkkitehti? Mitä jätetään pois niin ei ole? Ovatko ne sellaisia asioita mitä Senior ei kategorisesti tee, vai onko päällekkäisyyksiä? Tämä on täysin tuote, projekti, firma, henkilö, tiimi -kohtaista että voisi kategorisesti määritellä yksiselitteisesti että ei ole "verrattavissa".
 
Työnkuva on eri, tai miten se nyt mielletään. Kyllä niissä päällekkäisyyksiä on ja koodaamaton arkkitehti on paperipainoon verrattavissa oleva kaveri, joku osuus työstä tulee olla koodausta edes satunnaisesti. Senior voi hyvin ottaa kantaa arkkitehtuuriin sekä ylätasolla, että tietysti itse toteutuksessa. Riippuu tietysti miten roolit on firmassa määritelty, mutta mitään hierarkista lokerointia ei harrasteta meillä. Itse toimin arkkitehtinä, mutta aiemmin tei samoja asioita myös ilman tätä nimikettä. Samoja asioita on molemmissa rooleissa, painotus on vain eri.

Arkkitehdin määritelmiä on yhtä monia kuin määrittelijöitä, missä se raja menee? Minkä jälkeen on arkkitehti? Mitä jätetään pois niin ei ole? Ovatko ne sellaisia asioita mitä Senior ei kategorisesti tee, vai onko päällekkäisyyksiä? Tämä on täysin tuote, projekti, firma, henkilö, tiimi -kohtaista että voisi kategorisesti määritellä yksiselitteisesti että ei ole "verrattavissa".

Koodaustaidot arkkitehdillä nyt on lähes itsestäänselvyys, valtaosa softa-arkkitehdeistä kun on työskennellyt ensin kehittäjänä monta vuotta. Mielestäni relevanttia tietotaitoa kuvastaa ehkä parhaiten se jos vaihdat konsulttipuolelle, ja sinut "myydään" asiakkaalle jonkun projektin arkkitehdiksi. Siinä ei pelkät koodaustaidot auta jos joudut yhtäkkiä suunnittelemaan asiakkaalle uutta kompleksia järjestelmää, jonka pitäisi integroitua jonkun legacy paskeen kanssa ja lisäksi N+1 muuta järjestelmää taustalla tyyliin SAP tai Salesforce.
 
Koodaustaidot arkkitehdillä nyt on lähes itsestäänselvyys, valtaosa softa-arkkitehdeistä kun on työskennellyt ensin kehittäjänä monta vuotta. Mielestäni relevanttia tietotaitoa kuvastaa ehkä parhaiten se jos vaihdat konsulttipuolelle, ja sinut "myydään" asiakkaalle jonkun projektin arkkitehdiksi. Siinä ei pelkät koodaustaidot auta jos joudut yhtäkkiä suunnittelemaan asiakkaalle uutta kompleksia järjestelmää, jonka pitäisi integroitua jonkun legacy paskeen kanssa ja lisäksi N+1 muuta järjestelmää taustalla tyyliin SAP tai Salesforce.

Mun kokemus arkkitehdeistä on ettei ne ehdi ikinä tekemään sitä mitä arkkitehdin pitäisi tehdä. Sen sijaan niiden aika menee samaan kuin (senior) devareiden, eli koodaamiseen/säätämiseen. Eli harvemmin ehtivät mitään isomman skaalan suunnittelua tekemään. Pahimmillaan niiden hatuissa saattaa olla sitten lisäksi mm. PO natsat joka vaikeuttaa hommia entisestään.
 
Mun kokemus arkkitehdeistä on ettei ne ehdi ikinä tekemään sitä mitä arkkitehdin pitäisi tehdä. Sen sijaan niiden aika menee samaan kuin (senior) devareiden, eli koodaamiseen/säätämiseen. Eli harvemmin ehtivät mitään isomman skaalan suunnittelua tekemään. Pahimmillaan niiden hatuissa saattaa olla sitten lisäksi mm. PO natsat joka vaikeuttaa hommia entisestään.

Noinhan se käytännössä menee usein, mutta jos on tottunut siihen että arkkitehtinä teet lähinnä kehittäjän hommia ja sitten joudutkin "oikeasti" arkkitehtihommiin (eli esim. tuo mainitsemani konsulttiprojekti) niin voikin mennä sormi suuhun. Paljon on alalla porukkaa erilaisilla arkkitehtinimikkeillä jotka eivät osaa oikein mitään. Koodaustaidot ovat jo vanhentuneet ja arkkitehtuuritaitoja ei ole ehkä koskaan ollutkaan. Varsinaisina työtehtävinä siis lähinnä käsienheiluttelu.
 
Viimeksi muokattu:
Mun kokemus arkkitehdeistä on ettei ne ehdi ikinä tekemään sitä mitä arkkitehdin pitäisi tehdä. Sen sijaan niiden aika menee samaan kuin (senior) devareiden, eli koodaamiseen/säätämiseen. Eli harvemmin ehtivät mitään isomman skaalan suunnittelua tekemään. Pahimmillaan niiden hatuissa saattaa olla sitten lisäksi mm. PO natsat joka vaikeuttaa hommia entisestään.
Kannattaa kerätä laajemmin kokemuksia :)
 
Mun kokemus arkkitehdeistä on ettei ne ehdi ikinä tekemään sitä mitä arkkitehdin pitäisi tehdä. Sen sijaan niiden aika menee samaan kuin (senior) devareiden, eli koodaamiseen/säätämiseen. Eli harvemmin ehtivät mitään isomman skaalan suunnittelua tekemään. Pahimmillaan niiden hatuissa saattaa olla sitten lisäksi mm. PO natsat joka vaikeuttaa hommia entisestään.

Product Owner itsessään on täysipäiväinen rooli, ja nuo tehtävät eivät osu Senior/Architect roolille juuri mitenkään. Päällekkäisyyksiä on vähän jos ollenkaan. Arkkitehdillä tulisi olla aikaa sekä tehdä sitä ylemmän tason suunnittelua sekä myös jalkauttaa näitä tiimiin. Vanhan maailman tiimin ulkopuolelta-ylhäältä-alas saneltu arkkitehtuuri ei toimi käytännössä. Arkkitehtuuria tehdään myös eri tasoilla, joten tuommoinen rooli missä hämmennetään vähän siellä-täällä ei vain toimi.

Enterprise Architect sitten roolina erikseen, siellä perspektiivi on eri ja tarpeet erilaiset. Kovasti kyseenalaistan sellaiset klassiset "PPT arkkitehdit" joilla ei ole kosketuspintaa tekemiseen tai tuovat omaa näkymystään yli tiimirajojen liian voimakkaasti, tiimin tulisi olla kykenevät osaamisiltaan tekemään tarvittavat päätökset siinä kontekstissa. Ylemmältä tasolta voidaan ohjata tekemistä laveammin ja pitää huolta kokonaisarkkitehtuurista.
 
Product ownerin isoin työ (perinteisesti) on olla asiakkaan ääni. Mä en mitenkään ymmärrä mitä haittaa siitä voi olla että arkkitehti ymmärtää asiakkaita? Mulla on pari semmosta arkkitehtia ja hyvien arkkitehtuurien lisäksi he osaavat ehdottaa tosi hyviä ideoita jotka onnistuisivat jo olemassa olevan arkkitehtuurin pienillä muutoksilla. Kun näiltä kysyy ”saisko tätä tehtyä” he osaavat usein vastata myös kysymykseen ”kannattaako tätä tehdä”.

Mun painajainen on arkkitehti joka vaan odottaa tilaisuutta päästä suunittelemaan jotain monimutkaista häkkyrää, ja vastuu siitä onko se hyödyllistä jää muilla. Mitä isompi haaste sitä houkuttelevampi projekti. Lyhytnäköinen tuoteomistaja ja tämmönen arkkitehti on varmin tapa sitoa iso määrä resursseja toteuttamaan tulevaisuuden painajaista.
 
Product Owner itsessään on täysipäiväinen rooli, ja nuo tehtävät eivät osu Senior/Architect roolille juuri mitenkään. Päällekkäisyyksiä on vähän jos ollenkaan. Arkkitehdillä tulisi olla aikaa sekä tehdä sitä ylemmän tason suunnittelua sekä myös jalkauttaa näitä tiimiin. Vanhan maailman tiimin ulkopuolelta-ylhäältä-alas saneltu arkkitehtuuri ei toimi käytännössä. Arkkitehtuuria tehdään myös eri tasoilla, joten tuommoinen rooli missä hämmennetään vähän siellä-täällä ei vain toimi.

Enterprise Architect sitten roolina erikseen, siellä perspektiivi on eri ja tarpeet erilaiset. Kovasti kyseenalaistan sellaiset klassiset "PPT arkkitehdit" joilla ei ole kosketuspintaa tekemiseen tai tuovat omaa näkymystään yli tiimirajojen liian voimakkaasti, tiimin tulisi olla kykenevät osaamisiltaan tekemään tarvittavat päätökset siinä kontekstissa. Ylemmältä tasolta voidaan ohjata tekemistä laveammin ja pitää huolta kokonaisarkkitehtuurista.

Tietysti pitäisi olla mutta aina ei todellakaan ole näin. Hyvän PO:n kanssa hommia on paljon mukavampi tehdä kuin semmoisessa sekametelisopassa jossa joillakin on liian monta hattua. Pahimpia on skrummarit jotka eivät osaa hommiansa, häiritsee vaan tekemistä, toisaalta taas hyvä skrummari tuo mittaamattoman määrän hyötyjä tiimeihin.
 
imho. teknisellä puolella on helpompi löytää töitä.

Urakehityksen kannalta se on paras mitä osaat ja jaksat tehdä parhaiten. Paperit ei tee urakehitystä. Urakehitys tulee kovasta duuninteosta, itsensä myymisestä, suhdeverkoston kasvattamisesta ja jossain määrin myös "tuurilla". Jos homma maistuu puulta niin eteneminen jää näkemättä ja tilalle tulee burnout ja vitutus. Tuuria saa lisättyä kovalla sykkimisellä, kun ei kukaan tule kotiin töitä tarjoamaan. Yllättäviäkin mahdollisuuksia tulee suhdeverkoston kautta. Toki kylmillä hakemuksillakin voi onnistaa, mutta helpommalla pääsee, jos kontaktit suosittelee ja rekryää sua.

Kiitos vastauksesta!
Kumpi on työllisyyden ja urakehityksen kannalta parempi? Tekninen vai kaupallinen osaaminen. Vaiko ottaa tutkintoon molempien kursseja?

FinWeazel tuossa aikalailla vastasikin. Kyllä teknisellä puolella työt on helpommin saatavilla. Koodauksen peruskurssi ja jatkokurssi ja siihen ehkä joku UX tai Frontend kurssi lisäksi niin työpaikka on jo 90% varma. Siis jos noissa pärjää edes joten kuten. Mutta kyllä se siinä opiskelujen aikana selkiytyy mihin suuntaan haluat lähteä. Kyberturvallisuus vois olla myös aika varma suuntautuminen tällä hetkellä. Siitä tosin valmistuu FM eikä KTM.
 
Product ownerin isoin työ (perinteisesti) on olla asiakkaan ääni. Mä en mitenkään ymmärrä mitä haittaa siitä voi olla että arkkitehti ymmärtää asiakkaita? Mulla on pari semmosta arkkitehtia ja hyvien arkkitehtuurien lisäksi he osaavat ehdottaa tosi hyviä ideoita jotka onnistuisivat jo olemassa olevan arkkitehtuurin pienillä muutoksilla. Kun näiltä kysyy ”saisko tätä tehtyä” he osaavat usein vastata myös kysymykseen ”kannattaako tätä tehdä”.

Mun painajainen on arkkitehti joka vaan odottaa tilaisuutta päästä suunittelemaan jotain monimutkaista häkkyrää, ja vastuu siitä onko se hyödyllistä jää muilla. Mitä isompi haaste sitä houkuttelevampi projekti. Lyhytnäköinen tuoteomistaja ja tämmönen arkkitehti on varmin tapa sitoa iso määrä resursseja toteuttamaan tulevaisuuden painajaista.

Missään ei sanottu sitä, että asiakasta ei tulisi ymmärtää. PO rooli on vain eri kuin arkkitehdin. Ehdottomasti arkkitehdin tulee ymmärtää asiakasta, ja ymmärtää tarpeet. Ei arkkitehtuuri suunnitella tyhjiössä tai tekki edellä, tämä ei ollut ollenkaan oma pointtini. Oma pointti oli se, että näitä kahta roolia ei pysty hoitamaan samaan aikaan (olla sekä PO & arkkitehti). Itse toimin arkkitehtinä ja se on ensiarvoisen tärkeää ymmärtää asiakasta ja niitä tarpeita, usein kun näitä käydään läpi todetaankin että ensimmäiset oletukset nyt ainakin olivat täysin vääriä. Olen 100% samaa mieltä siitä että asiakasta ja businessta tulee ymmärtää, ja olen itse myös sitä mieltä että on iso kuilu sen ymmärryksen välillä business että software engineering puolella. Ei osata ostaa ATK:ta, ei ymmärretä mitä asiakas haluaa ja miten business toimii. Näissä kipuillaan jatkuvasti, ja etenkin arkkitehdillä on tässä painava vastuu kasvattaa sitä ymmärrystä molemminpuolin. Asiakkaille tämä ATK osaaminen leviää hiljallee, nyt on trendinä että rekrytään taloon sisään se kovin osaaminen eikä osteta konsulteilta. Matka on kuitenkin pitkä että tuossa mittasuhteet kääntyisivät (konsultti-% v. inhouse-%), tässä on toki eroja näiden modernien tuotetalojen suhteen, jotka ymmärtävät molempia mutta hieman värittynein silmin.

Itse olen Lean (& DevOps) ajattelun vahva kannattaja, ja sen että tiimi on kyvykäs tekemään kaiken tarvittavan tuotteen eteen - tai ainakin hankkimaan sen ymmärryksen muualta jos sitä ei tiimissä ole. Vaatii kyllä tiimiltä paljon, ei voi olla niin että joku tuo ns. "speksin pöytään" ja sitten vähän pseudo-ketterästi tiketöidään päämärkänä kunnes naputetaan tiketti kerrallaan. Ei, näin ei toimi varmasti mikään hyvin toimiva tiimi.
 
FinWeazel tuossa aikalailla vastasikin. Kyllä teknisellä puolella työt on helpommin saatavilla. Koodauksen peruskurssi ja jatkokurssi ja siihen ehkä joku UX tai Frontend kurssi lisäksi niin työpaikka on jo 90% varma. Siis jos noissa pärjää edes joten kuten. Mutta kyllä se siinä opiskelujen aikana selkiytyy mihin suuntaan haluat lähteä. Kyberturvallisuus vois olla myös aika varma suuntautuminen tällä hetkellä. Siitä tosin valmistuu FM eikä KTM.
Mistähän näitä varmoja työpaikkoja löytää noilla opinnoilla?

Itsellä Tampereen yliopistolla kesään mennessä kolme ohjelmointikurssia, haskell ja ansi c-kurssit, speksin teon kurssi, tietokantojen peruskurssi, 5op myös kyberturvallisuutta ja yksi ux-kurssi. Parhaimmat työnäkymät kesäksi tällä hetkellä ovat terveydenhoitoalalla, it-alalle kaikki hakemukset ovat tähän mennessä bumerangina takaisin :beye:
 
Mistähän näitä varmoja työpaikkoja löytää noilla opinnoilla?

Itsellä Tampereen yliopistolla kesään mennessä kolme ohjelmointikurssia, haskell ja ansi c-kurssit, speksin teon kurssi, tietokantojen peruskurssi, 5op myös kyberturvallisuutta ja yksi ux-kurssi. Parhaimmat työnäkymät kesäksi tällä hetkellä ovat terveydenhoitoalalla, it-alalle kaikki hakemukset ovat tähän mennessä bumerangina takaisin :beye:

Kesätyöpaikka on helpompi tapa saada jalkaa oven väliin kuin "normaali" työpaikka. Kesätyöpaikkojenkin hakijoilla voi nykyään olla työkokemusta ainakin Helsingissä, joten kilpailu on aika kovaa. Laadukkaalla omalla projektilla voi kyllä kompensoida hyvin sitä, että puuttuu aiempi työkokemus, joten jossain vaiheessa kaikilta puuttuu.

Tosin, kesätyöhaku alkaa olla kohta takanapäin. Mutta kannattaa vielä kysellä. Yleensä kannattaa hakea ennen vuodenvaihdetta.
 
Niin, olen hakenut, kaikki on tullut bumerangina takaisin. Ilmeisesti akuutein työvoimapula on it-alalla takanapäin. Sopisi kyllä hyvin teemaan, että työvoiman kysyntä muuttuu sopivasti alaa vaihtaessa.
 
Niin, olen hakenut, kaikki on tullut bumerangina takaisin. Ilmeisesti akuutein työvoimapula on it-alalla takanapäin. Sopisi kyllä hyvin teemaan, että työvoiman kysyntä muuttuu sopivasti alaa vaihtaessa.

Työvoiman kysyntä on kasvamaanpäin, ongelma on juuri tuossa se ensimmäisen työpaikan saaminen ja sitä kautta kokemuksen kerryttäminen. Suurin paine puuttuvista tekijöistä on siellä kokeneemmassa päässä, mutta alalle tulijoita tarvitaan lisää jotta alalle voi kasvaa lisää kokeneita osaajia, mutta tämä vie vuosia.

Älä lannistu, tuossa @Paapaa antoi ylempänä hyvän vinkin millä voi erottua joukosta, kun linkittää oman projektin mukaan jo hakemukseen. Kannattaa korostaa sitä halua oppia, todellisuus on se että kourallinen kursseja ei vielä osaajaa tee. Siinä mielessä kannattaa hyväksyä sekin, että voi joutua aloittamaan hieman alempaa. Katsoisin vielä oman työssäkäyntialueen ATK-firmoja läpi, ja katsoisin läpi niitä siitä kulmasta mikä itseä kiinnostaa tällä hetkellä eniten. Bumerangeista voisi myös kysyä palautetta, että miten voisi erottua paremmin jatkossa.

Alalla on kuitenkin, mielestäni, hyvät tulevaisuuden näkymät ja töitä kyllä riittää. Samoin työolot sekä palkkaus ovat moneen muuhun alaan verrattuna erinomaiset. Kuitenkin alussa on iso kynnys, etenkin jos opinnot ovat vielä kesken. Jos ainoa kokemus on yliopistosta, niin se ei yksinään vielä avaa ovia, onko teillä mahdollisuutta tehdä joku työelämäprojektikurssi siellä? Yleensä tuonkaltaisten kurssien kautta voi osoittaa firmoille osaavansa tehdä asioita, ja noista usein rekrytään parhaimmat asiakasfirmoihin suoraan.
 
Niin, olen hakenut, kaikki on tullut bumerangina takaisin. Ilmeisesti akuutein työvoimapula on it-alalla takanapäin. Sopisi kyllä hyvin teemaan, että työvoiman kysyntä muuttuu sopivasti alaa vaihtaessa.

Onko se GitHub-profiili priimaa, vai voisiko parantaa? Jos on alan tutkinto käynnissä ja jos et ole ihan mulkku, niin sitten se oma harrastuneisuus on ehkä paras tapa osoittaa taitonsa ja päästä haastatteluun. Monessa paikassa screenataan hakijat ensin hakukirjeen ja CV:n perusteella ja sitten katsotaan omia projekteja GitHubista. Jos näistä vihreää valoa, saattaa hakija päästä haastatteluun.

Mikä on sitten hyvä harrasteprojekti? Siihen on lukematon määrä oikeita vastauksia. Mutta tässä vähän vinkkejä:
  • Se toimii ja tekee jotain :)
  • Koodia on helppo seurata ja siinä ei ole pahoja sudenkuoppia. Sitä on sopivasti kommentoitu järkevissä paikoissa.
  • Käytät ohjelmointikielen suositeltuja käytäntöjä ja koodin formatointia.
  • Koodissa on kattavat testit joissa on joku pointti.
  • Sitä voi kokeilla helposti, esim. laita projekti nettiin testattavaksi. Toki jos kyse ei ole web-ohjelmoinnista, niin sitten tämä ei ole relevanttia.
  • Sen pystytys on dokumentoitu. Eli joku joka haluaa laittaa sen omalla koneellaan pyörimään, voi sen helposti tehdä.
  • Se on muutoinkin hyvin dokumentoitu. Pari screenshotia, kuvaus ohjelman toiminnasta/arkkitehtuurista jne. Kehityskohteiden ja puutteiden listaus.
  • Jos webbiappis, niin toimii hyvin eri laitteilla - on siis responsiivinen.
  • Hyödyntään GitHub Actionsejä, eli ajaa testit automaattisesti, deployaa automaattisesti kun pusket masteriin, jos projekti on sellainen.
  • Projekti käyttää jotain sellaista tech stackiä, jolle on todellista kysyntää markkinoilla.
  • Projekti näyttää mahdollisimman laajasti osaamistasi. Ei siis vain simppeli, React appis, vaan ehkä myös siihen liittyvä bäkkäri, ehkä joku integraatio ulkoiseen APIiin, ehkä infra AWS:ssä Terraformin avulla, kunnon CI/CD-putki, tietoturva kunnossa jne. jne.
  • Olet tehnyt kaiken ihan itse. Ei siis koulun projektityö, jossa teit 5% commiteista ja joku muu loput. Eikä forkattu projekti, johon muutit vähän värejä. Kunnia sille, jolle se kuuluu jos käytät muiden koodia.
  • Tee sellainen, josta olet ylpeä ja josta voit jutella haastattelussa lisää vaikka kuinka paljon!
  • Järkevät commitit, joissa kuvaava message. Ei siis liian isoja commiteja.
Jos näistä suurin osa on kunnossa, niin on jo tosi hyvä lähtökohta mielestäni. Mainitse hakemuksessa, että tämä on se projekti, jota kannattaa katsoa ja johon olet panostanut.
 
Viimeksi muokattu:
Eipä tässä 1. vuoden aikana resursseja ole ollut muuhun kuin opiskeluiden saamiseen hyvin käyntiin. Omat projektit ovat pois opiskeluun käytetystä ajasta, ja omista projekteista ei saa noppia eikä kurssisuorituksia. Aiempi sanomani oli lähinnä ihmettelyä FinWeazelin väitteelle, että jo parilla ohjelmointikurssilla saisi töitä. Totuus taitaa olla lähempänä kahtakymmentä nykyään, ja sittenkin vaaditaan tuuria tai suhteita.
 
Eipä tässä 1. vuoden aikana resursseja ole ollut muuhun kuin opiskeluiden saamiseen hyvin käyntiin. Omat projektit ovat pois opiskeluun käytetystä ajasta, ja omista projekteista ei saa noppia eikä kurssisuorituksia. Aiempi sanomani oli lähinnä ihmettelyä FinWeazelin väitteelle, että jo parilla ohjelmointikurssilla saisi töitä. Totuus taitaa olla lähempänä kahtakymmentä nykyään, ja sittenkin vaaditaan tuuria tai suhteita.

Ok, sitten en ihmettele. Jos ei ole kuin 1. vuosi menossa ja ei omia projekteja/työkokemusta, niin ei ole kovin helppo saada töitä. Mutta silti, kun aikaa löytyy, niin kannattaa satsata johonkin omaan harrasteprojektiin. Helpottaa varmasti työllistymistä.
 
Ok, sitten en ihmettele. Jos ei ole kuin 1. vuosi menossa ja ei omia projekteja/työkokemusta, niin ei ole kovin helppo saada töitä. Mutta silti, kun aikaa löytyy, niin kannattaa satsata johonkin omaan harrasteprojektiin. Helpottaa varmasti työllistymistä.
Allekirjoitan itsekin tämän, että jonkinlainen proggis on hyvä tapa edesauttaa työllistymistä vähän myöhemmässä vaiheessa opintoja. Monet toki päätyy jatkamaan harjoittelupaikassa jos osoittautuu sopivaksi työntekijäksi.

Projektiksi kannattaa miettiä jotain sellaista, josta voisi olla itsellesi iloa tai hyötyä, silloin sitä tulee tehtyä vähän eri tavalla kuin jotain pakkopullaa ja saattaa olla muillekin avuksi tai hyödyksi. Itsellä ainakin kimmoke tekemiseen tulee yleensä silloin kun jonkun asian manuaalinen tekeminen koneella alkaa käydä vaivalloiseksi tai sitä ei muista tehdä kun pitäisi.
 
Onko se GitHub-profiili priimaa, vai voisiko parantaa? Jos on alan tutkinto käynnissä ja jos et ole ihan mulkku, niin sitten se oma harrastuneisuus on ehkä paras tapa osoittaa taitonsa ja päästä haastatteluun. Monessa paikassa screenataan hakijat ensin hakukirjeen ja CV:n perusteella ja sitten katsotaan omia projekteja GitHubista. Jos näistä vihreää valoa, saattaa hakija päästä haastatteluun.

Mikä on sitten hyvä harrasteprojekti? Siihen on lukematon määrä oikeita vastauksia. Mutta tässä vähän vinkkejä:
  • Se toimii ja tekee jotain :)
  • Koodia on helppo seurata ja siinä ei ole pahoja sudenkuoppia. Sitä on sopivasti kommentoitu järkevissä paikoissa.
  • Käytät ohjelmointikielen suositeltuja käytäntöjä ja koodin formatointia.
  • Koodissa on kattavat testit joissa on joku pointti.
  • Sitä voi kokeilla helposti, esim. laita projekti nettiin testattavaksi. Toki jos kyse ei ole web-ohjelmoinnista, niin sitten tämä ei ole relevanttia.
  • Sen pystytys on dokumentoitu. Eli joku joka haluaa laittaa sen omalla koneellaan pyörimään, voi sen helposti tehdä.
  • Se on muutoinkin hyvin dokumentoitu. Pari screenshotia, kuvaus ohjelman toiminnasta/arkkitehtuurista jne. Kehityskohteiden ja puutteiden listaus.
  • Hyödyntään GitHub Actionsejä, eli ajaa testit automaattisesti, deployaa automaattisesti kun pusket masteriin, jos projekti on sellainen.
  • Projekti käyttää jotain sellaista tech stackiä, jolle on todellista kysyntää markkinoilla.
  • Projekti näyttää mahdollisimman laajasti osaamistasi. Ei siis vain simppeli, React appis, vaan ehkä myös siihen liittyvä bäkkäri, ehkä joku integraatio ulkoiseen APIiin, ehkä infra AWS:ssä Terraformin avulla, kunnon CI/CD-putki, tietoturva kunnossa jne. jne.
  • Olet tehnyt kaiken ihan itse. Ei siis koulun projektityö, jossa teit 5% commiteista ja joku muu loput. Eikä forkattu projekti, johon muutit vähän värejä. Kunnia sille, jolle se kuuluu jos käytät muiden koodia.
  • Tee sellainen, josta olet ylpeä ja josta voit jutella haastattelussa lisää vaikka kuinka paljon!
  • Järkevät commitit, joissa kuvaava message. Ei siis liian isoja commiteja.
Jos näistä suurin osa on kunnossa, niin on jo tosi hyvä lähtökohta mielestäni. Mainitse hakemuksessa, että tämä on se projekti, jota kannattaa katsoa ja johon olet panostanut.

Alleviivasin tuosta olennaisimmat. Muotoseikat on toki tärkeitä ja niillä on arvoa, mutta ainakin omassa lähipiirissä aika harva on jaksanut harrasteprojektejaan tehdä ihan samalla pieteetillä, kun päivätyötä. Se projekti on kuitenkin ensisijaisesti mua itseäni (ja kavereitani varten) eikä sitä kehitä kukaan muu kuin minä. Mullakin siis puuttuu omasta softasta testit kokonaan ja koodin tukiympäristö loistaa poissaolollaan. Commititkin on huonoja tai tosi huonoja. Itse koodi on kyllä luettavaa ja ylläpidettävää - paljon pahempaan spagettiin olen törmännyt työelämässä.

Työhaastattelussa halusivat kuulla tuosta projektistani. Se sattuu olemaan mobiiliapplikaatio (SPA), joten sain aika helposti demottua sen ominaisuudet ja pääpointit haastattelun aikana. Koodia tarjosin luettavaksi jälkeenpäin (repo suljettu), mutta eivät sitä kaivanneet ja seuraava kontakti olikin jo sopmiuksen allekirjoittaminen. Toki näyttöä työelämästä löytyi jo muutenkin (mutta aika vähäisesti ja hieman eri IT-sektorin osa-alueelta). Jos se harrasteprojekti on ainoa käyntikortti, niin ehkä siihen kannattaa nähdä hieman enemmän vaivaa.
 
Muotoseikat on toki tärkeitä ja niillä on arvoa, mutta ainakin omassa lähipiirissä aika harva on jaksanut harrasteprojektejaan tehdä ihan samalla pieteetillä, kun päivätyötä.

Joo, mä kirjoitin tuon listan siitä näkökulmasta, että on pari tasavahvaa kandidaattia ja pitäisi erottautua. Silloin erottautuu luultavasti se kandi, joka on jaksanut kirjoittaa testit, tehnyt kaikesta vähän nätimpää jne. Tässä siis haettiin juuri sitä, että miten buustaa omia mahdollisuuksia jos nyt tulee bumerangia.

Joku toinen kandi ei tarvitse mitään omia projekteja, jos hänellä onkin takana jo työkokemusta. Mutta jos ja kun ei ole, niin sitten tuo satsaaminen voi maksaa itsensä korkojen kera takaisin. Monta kandia hylätään koska ei ole mitään konkreettista näyttöä koodaustaidoista.
 
Itse sain aikoinaan ensimmäisen it-alan työpaikan vuoden opiskelujen jälkeen. Käytin tosin suurimman osan vapaa-ajastani opiskeluun kun olin huomannut että koulussa opitut asiat eivät tunnu kattavan kuin todella pienen murto-osan oikeista työelämän vaatimuksista.

Näin jälkeenpäin katsottuna sanoisin että hyvä tuuri taisi käydä, sillä tuolla osaamisella pystyin hädin tuskin kannattelemaan omaa painoani oikeissa koodihommissa, jos sitäkään. Kuvitelmat olivat tietty suuret, niin kuin tuoreena osaajana pitääkin olla. :D Työnantajan näkökulmasta opiskelija ilman mitään harrastuneisuutta on riski, sillä ei tiedä kehittyykö siitä mitään ja pysyykö työntekijä edes talossa niin kauaa että alkaa tuottamaan arvoa. Eri tasoisia töitä on tietenkin paljon, enkä sano etteikö olisi sellaisia hommia joissa aika pienellä osaamisellakin voisi olla arvokas työntekijä, mutta suurin pula on tekijöistä joilla on taito tehdä kunnollista ja toimia tiimissä.
 
Joo, mä kirjoitin tuon listan siitä näkökulmasta, että on pari tasavahvaa kandidaattia ja pitäisi erottautua. Silloin erottautuu luultavasti se kandi, joka on jaksanut kirjoittaa testit, tehnyt kaikesta vähän nätimpää jne. Tässä siis haettiin juuri sitä, että miten buustaa omia mahdollisuuksia jos nyt tulee bumerangia.

Joku toinen kandi ei tarvitse mitään omia projekteja, jos hänellä onkin takana jo työkokemusta. Mutta jos ja kun ei ole, niin sitten tuo satsaaminen voi maksaa itsensä korkojen kera takaisin. Monta kandia hylätään koska ei ole mitään konkreettista näyttöä koodaustaidoista.

Näinhän se on. Voin kuvitella että nyt ainakin laskeviin markkinoihin sen erottautumisen rooli kasvaa. Silloin kun sitä itse haki töitä, niin vakuuttamiseen riitti vähempikin.

edit. Jos/kun sitä harrasteprojektia muuten miettii, niin itse suosittelen hakemaan sellaista aihepiiriä, mikä kiinnostaa muistakin syistä. En mä olisi voinut kuvitella käyttäväni kymmeniä/satoja tunteja jonkun listalta pieraistun idean toteuttamiseen.
 
Eipä tässä 1. vuoden aikana resursseja ole ollut muuhun kuin opiskeluiden saamiseen hyvin käyntiin. Omat projektit ovat pois opiskeluun käytetystä ajasta, ja omista projekteista ei saa noppia eikä kurssisuorituksia. Aiempi sanomani oli lähinnä ihmettelyä FinWeazelin väitteelle, että jo parilla ohjelmointikurssilla saisi töitä. Totuus taitaa olla lähempänä kahtakymmentä nykyään, ja sittenkin vaaditaan tuuria tai suhteita.

En minä yrittänyt väittää, että parilla kurssilla saisi töitä. Yritin väittää, että jos voi harrasteprojektien kautta todistaa osaavansa ohjelmoida hyvin niin saa töitä ilman kursseja/tutkintoa tai vaihtoehtoisesti pääsee jonon kärkeen kun haetaan harjoittelijapaikkoja. Tutkinto ei it-alalla ole mikään pakko poislukien muodollisesti pätevät asiat kuten julkinen puoli ja erilaiset viisumihärdellit. Amerikkaan vaikka on hyvin vaikea päästä enää töihin ilman tutkintoa, kun trump veti vaatimukset tappiin. Teoriassa voi yrittää kokemuksella kompensoida puuttuvaa tutkintoa, mutta käytännössä enää ei voi.

Koodaamaan oppii koodaamalla. Kotikoodit voi laittaa esille helpottamaan työnhakua.

edit. Ennen kuin joku kimmastuu en väitä koulua tarpeettomaksi. Otin kantaa vain tuohon pieneen osaan it-alan työstä joka on koodausta. Onhan siinä koodauksen ympärillä paljon muutakin ja siihen muuhun saa paljon koulusta ymmärrystä mitä ei yksin kotona puurtaessa välttämättä opi/tule ajatelleeksi.
 
Viimeksi muokattu:
Eli kesätyöt on mun osalta ohi tänä vuonna. Kiitos vinkeistä. Haen hoitoalan kesätöitä seuraavaksi. Testauksesta ym ei ole puhuttu sanaakaan vielä, ja mulla ei tosiaankaan ole nyt resursseja extraan koulun lisäksi. Palataan ensi jouluna asiaan.
 
Eli kesätyöt on mun osalta ohi tänä vuonna. Kiitos vinkeistä. Haen hoitoalan kesätöitä seuraavaksi. Testauksesta ym ei ole puhuttu sanaakaan vielä, ja mulla ei tosiaankaan ole nyt resursseja extraan koulun lisäksi. Palataan ensi jouluna asiaan.

Ei kannata luovuttaa etukäteen. Huonoimmassakin tapauksessa saa kokemusta haastatteluista ja osaa sitten seuraavalla kerralla valmistautua paremmin.
 
Joo itsekin laitoin ihan raakasti näin 1. vuoden IT-alan opiskelijana hakemuksia menemään Tietoon, Koneelle, UPM jne. Tuleepahan samalla pistettyä CV kuntoon, LinkedIn naftaliiniin ja tosiaan sitä projektia alulle. Itsellä tällä hetkellä omasta mielenkiinnosta menossa projektina euribor-laskuri, joka käy läpi viime vuosien euribor-dataa ja ilmoittaa mikä on ollut halvin annetulla ajanjaksolla (vuosi = n >= 0)
 
Onhan esim. noita ekan tason support-paikkoja vähän väliä haussa, just passeleita kesätöitä vähän aikaa opiskelleelle niin näkee mitä kaikkea tapahtuu siellä oikeassa työssä.
 
Eli kesätyöt on mun osalta ohi tänä vuonna. Kiitos vinkeistä. Haen hoitoalan kesätöitä seuraavaksi. Testauksesta ym ei ole puhuttu sanaakaan vielä, ja mulla ei tosiaankaan ole nyt resursseja extraan koulun lisäksi. Palataan ensi jouluna asiaan.
Käyhän haastatteluissa kiinnostavissa firmoissa. Ole utelias ja oma itsesi. Jätä hyvä kuva ja firmalle muistikuva tulevasta hyvästä työkavereista. Jos paikka natsaa, niin voitat heti ja jos ei natsaa olet ehkä saanut tehtyä hyvän vaikutelman ja pynnön hakea uusiksi kun osaaminen karttuu. Ei ole kuin voitettavaa.

Edit:
Todennäköisimpia kesätyöpaikkoja on isot talot joilla on resursseja ottaa junioreita. Tyyliin CGI, Tieto jne
 
Bumerangi siis tarkoittaa sitä, että hakemus tulee suoraan takaisin ilman haastattelukutsua. Noh ei nyt vielä kaikista ole tullut, mutta suurimmasta osasta mihin olen keksinyt hakea. Jotenkin vaan ei ole luottoa enää muuhun lopputulokseen :beye: Ehkä Tiedon tai CGI:n kohdalla sitten tärppää...
 
Kesätöistä on helppo aloittaa ja edetä uralla. Itse IT-alan opiskelijana olin ekan kesän asiakaspalveluhommissa ja sen jälkeen kaksi vuotta Helpdeskissä. Yhden projektin kautta pääsin hetkeksi muihin hommiin ja siitä poiki seuraavalle kesälle työpaikka, joka oli jo "isojen poikien hommia". Tästä kesätyöpaikasta löytyi asiantuntijahomma opintojen ohelle ja on paikoin aika haastaviakin tehtäviä. Nyt pitäisi taas etsiä uusi kesätyöpaikka ja toki valmistuminenkin on jo lähellä. Nykyisestä työpaikasta tarjottiin jo alustavasti yhtä paikkaa ja kattavalla CV:llä olen varma, että pääsisin jonnekin muullekin. Nyt on vielä muutaman viikon kovin kesätyöbuumi menossa ja viljelin kaiken varalta hakemuksia menemään.

En ole mikään koodari, mutta perustaidot useilla ohjelmointikielillä löytyy ja se tuntuu auttavan paljon. Nykyisessä työssä pitää ohjelmoida jonkun verran, ja vaikka alkuun on pulassa, niin jossain vaiheessa alkaa väkisin sujumaan. Tuntuu kuitenkin, että työkokemus on merkittävässä osassa monen työpaikan saamista. Pari kaveria ei ollut alusta asti kesätöissä ja nyt huomaa, että niiden on vaikea saada oman alan vaativampia hommia ja ei välttämättä edes tyydytä perus Contact Center -hommiin. Jos taas on alusta asti painanut kovasti hommia kesällä ja edennyt "paskaduuneista" ylöspäin, on jo opintojen loppupuolella valmistuneen maisterin tasoa vastaavissa töissä. Mitään himokoodareita en tunne. Jos on todella taitava ohjelmoimaan ja voi todistaa sen, niin se toki varmasti muuttaa asiaa :D
 
Yksi tapa erottautua massasta kesätöitä hakiessa voi olla rakentaa ci putki hello worldin päälle. Tyylin github hello world projekti joka kääntyy muutoksen tullen kontissa ja ajaa automaatiolla jonkin yksikkötestin ja tarjoaa jonkinsortin raportin. Ei tarvi välttämättä niin paljon koodailla, mutta joutuu jonniinverran legoja kasaan, että saa automaation siististi tehtyä. Paljon tuollaista automaatio/ci/devops yms. hommaakin on tarjolla. Se puoli voi viedä mennessään tai sitten siirtyy sieltä muihin juttuihin oman mielenkiinnon mukaan.
 
Mistähän näitä varmoja työpaikkoja löytää noilla opinnoilla?

Itsellä Tampereen yliopistolla kesään mennessä kolme ohjelmointikurssia, haskell ja ansi c-kurssit, speksin teon kurssi, tietokantojen peruskurssi, 5op myös kyberturvallisuutta ja yksi ux-kurssi. Parhaimmat työnäkymät kesäksi tällä hetkellä ovat terveydenhoitoalalla, it-alalle kaikki hakemukset ovat tähän mennessä bumerangina takaisin :beye:
Toki alkaa olla noista hauista 5-6 vuotta aikaa ja varmasti ala ja työpaikkatarjonta on muuttunut tässä ajassa jonkin verran. Vaikuttaahan noissa myös asiat x, y ja z, että ei sitä nyt toki voi sanoa mitään varmaksi.
 
Arvaan että taloustilannekin vaikuttaa nyt. Aikamoinen maailmanlaajuinen irtisanomisaalto on menossa alalla. Lähes kaikki merkittävät kansainväliset yritykset ovat vähintäänkin laittaneet rekryn kiinni. Olisi ihme jos tilanne ei mitenkään heijastuisi kotimaan työmarkkinaan.

Vastaava tilanne on tainnut olla viimeksi yli kymmenen vuotta sitten.

Tuossa usein linkattu "yt-trackeri". Aika synkältähän se näyttää. Layoffs.fyi - Tech Layoff Tracker and Startup Layoff Lists
 
Viimeksi muokattu:
Arvaan että taloustilannekin vaikuttaa nyt. Aikamoinen maailmanlaajuinen irtisanomisaalto on menossa alalla. Lähes kaikki merkittävät kansainväliset yritykset ovat vähintäänkin laittaneet rekryn kiinni. Olisi ihme jos tilanne ei mitenkään heijastuisi kotimaan työmarkkinaan.

Jep, alkusyksystä kesäloman loputtua paukkasi vielä LinkedInissä joka viikko headhuntterien yhteydenottoja, mutta nyt ei ole kolmeen kuukauteen tullut mitään.

Itse työskentelen suuressa globaalissa teknologiayrityksessä ja meilläkin on rekrykielto päällä. Joitain pois lähteneitä on pystytty korvaamaan poikkeusluvalla. Tarkoitus oli palkata Suomen yksikköön kaksi kesätyöntekijää, mutta saatiin lupa palkata vain yksi. Irtisanomisista ei sentään ole vielä ollut puhetta (ei edes USA:n yksiköissä).
 
Jep, alkusyksystä kesäloman loputtua paukkasi vielä LinkedInissä joka viikko headhuntterien yhteydenottoja, mutta nyt ei ole kolmeen kuukauteen tullut mitään.

Itse työskentelen suuressa globaalissa teknologiayrityksessä ja meilläkin on rekrykielto päällä. Joitain pois lähteneitä on pystytty korvaamaan poikkeusluvalla. Tarkoitus oli palkata Suomen yksikköön kaksi kesätyöntekijää, mutta saatiin lupa palkata vain yksi. Irtisanomisista ei sentään ole vielä ollut puhetta (ei edes USA:n yksiköissä).

Itse työskentelen ihan kotimaisessa julkisella, silti jaksaa headhunterit pommittaa vielä jollain 6k palkkaa maksavilla koodipaikoilla. Näitä mua ahdistelevia on tosin vain muutama, ja vuoden tasolla en saa välttämättä useampaan kuukauteen yhtään yhteydenottoa.
 
Ehtoota. Olisi tiedossa pari haastattelua summer trainee paikkoihin. Molemmissa on tiedossa tekninen osuus paikanpäällä. En ole sellaisessa aikaisemmin ollut, niin tuo vähän jännittää. Onko ideoita että mitä siellä kyseltäisiin tälläiselta kesähessulta?
 
Ehtoota. Olisi tiedossa pari haastattelua summer trainee paikkoihin. Molemmissa on tiedossa tekninen osuus paikanpäällä. En ole sellaisessa aikaisemmin ollut, niin tuo vähän jännittää. Onko ideoita että mitä siellä kyseltäisiin tälläiselta kesähessulta?
Riippuu todella paljon paikasta. Koodarilla voi olla vaikkapa kielen teoriaan liittyviä monivalintakyssäreitä tai tyyliin "mitä funktio tulostaa?" tai "miten pääset käsiksi arvoon X?" -tehtäviä. Sitten voi olla jotain bugisen funktion korjailua tai mitä vain hieman isompaakin rakentelua. Ajatus taitaa lähinnä olla tutkailla sinun suhtautumista tehtäviin ja sitä miten lähdet lähestymään/ratkomaan ongelmaa. Oikea vastaus ei siis aina ole se pääkriteeri.
 
Web devausta olisi tiedossa. Kerrottiin että siinä olisi tekninen osuus, johon liittyy "alan sanastoa" tjms.
 
Viimeksi muokattu:
Pienellä disclaimerilla, koska haastattelijoita ja yrityksiä on hyvin erilaisia..

Oma lähestymistapani on kysellä teknisiä CV:n perusteella ja yrittää saada irti löytyykö kenties osaamista jota ei voisi CV:n perusteella olettaa. Hyvä haastattelija selvittää miten lähestyt ongelmia, uskallatko myöntää kun et osaa jotain ja yrittää saada selville kuinka pitkälle osaat eri osa-alueita.

Mielestäni tärkeimmät mukaan otettavat ovat mahdollisimman vähän ennakkoluuloja ja oma itsensä. Haastattelijan tehtävä on osata kysyä juuri sinulle sopivia kysymyksiä, mutta siinäkin voi auttaa esim. kertomalla minkälaiseen osaamiseen on keskittynyt ja mikä tällä hetkellä kiinnostaa.

Se on ainakin varma että vastaan tulee kysymyksiä joihin et osaa vastata, se on väistämätöntä kun haastattelija yrittää saada kuvaa taidoistasi. Varaudu siihen positiivisella asenteella ja jos kysymyksen vastaus kiinnostaa voi sitä kysyä haastattelijalta.
 
Itse olen joutunut kesähessu hommaan vetämään fläppitaululla linketyn listan inserttiä, jossa on useampi kaveri hengittää niskaan. Tälläistä tuskin kyllä joutuu tekemään enää. Codility sivulta olen myös joutunut tekemään tehtäviä monessa paikkaa. Codilityä itseasiassa olen ihan normi työpaikkaa hakiessa joutunut tekemään. Ehkä ekat 5 lessonista kandee chekata.

Web devaus voi olla jotain string manipulaatiota. Itse en kyllä web devausta tee, mutta olen ollut web devaukseen haastiksessa joskus.

Paras neuvo jonka voin antaa haistatteluun on, että ei se maailma kaadu jos ei saa mitään aikaseksi siellä. Eli ei kannata ottaa paineta.

Codility:
 
Itse olen joutunut kesähessu hommaan vetämään fläppitaululla linketyn listan inserttiä, jossa on useampi kaveri hengittää niskaan. Tälläistä tuskin kyllä joutuu tekemään enää. Codility sivulta olen myös joutunut tekemään tehtäviä monessa paikkaa. Codilityä itseasiassa olen ihan normi työpaikkaa hakiessa joutunut tekemään. Ehkä ekat 5 lessonista kandee chekata.

Web devaus voi olla jotain string manipulaatiota. Itse en kyllä web devausta tee, mutta olen ollut web devaukseen haastiksessa joskus.

Paras neuvo jonka voin antaa haistatteluun on, että ei se maailma kaadu jos ei saa mitään aikaseksi siellä. Eli ei kannata ottaa paineta.

Codility:

On kyllä todella kyrpämäistä laittaa kesäharjoittelijaksi hakeva tekemään jotain binääripuu tai linked list paskaa taululle. Tuolla tasolla ei pitäisi edellyttää muuta kuin kiinnostusta ohjelmointiin, sillä ei ole perseenkään väliä osaatko jotain 30+ vuotta vanhoja algoritmiharjoituksia mitä ei modernissa softakehityksessä käytetä muutenkaan enää.
 
On kyllä todella kyrpämäistä laittaa kesäharjoittelijaksi hakeva tekemään jotain binääripuu tai linked list paskaa taululle. Tuolla tasolla ei pitäisi edellyttää muuta kuin kiinnostusta ohjelmointiin, sillä ei ole perseenkään väliä osaatko jotain 30+ vuotta vanhoja algoritmiharjoituksia mitä ei modernissa softakehityksessä käytetä muutenkaan enää.

Taisin ekat binääripuut ja linkitetyt listat tehdä opiskellessa 90-luvulla. Muistan ne hyvin ja odotan vieläkin päivää että pääsen sellaista hyödyntämään työelämässä! Eiku hetkinen, yhdessä työhaastattelussa taisi joskus olla tehtävänä luoda binääripuu haku tjms.
 
Kyllä algoritmiharjoituksillekin paikkansa on, mutta en ehkä kysyisi sellaista tyypillisessä webbikehittäjähaastattelussa. Jos työnkuvaan kuuluu pelkästään React komponenttien lätkiminen valmiista kirjastosta, ei ehkä ole tarpeen tuollaisia kysellä.
 
Kyllä algoritmiharjoituksillekin paikkansa on, mutta en ehkä kysyisi sellaista tyypillisessä webbikehittäjähaastattelussa. Jos työnkuvaan kuuluu pelkästään React komponenttien lätkiminen valmiista kirjastosta, ei ehkä ole tarpeen tuollaisia kysellä.

Toki hyödyllisiäkin algoritmiharjoituksia on, mutta en silti pyytäisi kesäharjoittelijaksi hakevaa tekemään niitä.
 
en ehkä kysyisi sellaista tyypillisessä webbikehittäjähaastattelussa. Jos työnkuvaan kuuluu pelkästään React komponenttien lätkiminen valmiista kirjastosta, ei ehkä ole tarpeen tuollaisia kysellä.

Ja vaikka työnkuvaan kuuluu kompleksin webbiaplikaation toteuttaminen alusta loppuun, ei silti noilla linkitetyillä listoilla ja punamustapuilla tee yhtään mitään ikinä milloinkaan. Tavallaan ymmärrän niiden takana olevan ajatuksen, mutta musta on paljon järkevämpi pyytää kandidaattia toteuttamaan joku komponentti kuin noita TRAK-kurssien harjoitustehtäviä.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
258 579
Viestejä
4 501 006
Jäsenet
74 226
Uusin jäsen
Tober

Hinta.fi

Back
Ylös Bottom