IT-alan työpaikat

[Incredible Buff]

Sivuhuomiona, itse olen aina luullut että CV ei muutu, sehän on aina sama koska historiasi on sama. Mutta hakemus-kirje muokataan tai kirjoitetaan aina lähetettävään paikkaan.

Kyllähän CV:ssäkin voi korostaa paikkakohtaisesti tärkeitä asioita, jos katsoo sen tarpeelliseksi.

Ei tässä tarvitse paljon CV:ssä korostaa mitään kun työt näkyy hakevan minua eikä minä töitä, mutta ei kiinnosta.

 

[akir0]

Sivuhuomiona, itse olen aina luullut että CV ei muutu, sehän on aina sama koska historiasi on sama. Mutta hakemus-kirje muokataan tai kirjoitetaan aina lähetettävään paikkaan.

Itse taas olen sitä mieltä, että jos liittää CV:n osaksi hakemusta niin se muokataan sopivasti jotta sieltä nousee esille oikeat asiat suhteessa haettavaan tehtävään.

 

[FireFly Renaissance]

Sivuhuomiona, itse olen aina luullut että CV ei muutu, sehän on aina sama koska historiasi on sama. Mutta hakemus-kirje muokataan tai kirjoitetaan aina lähetettävään paikkaan.

CV:ssähän on (ainakin nykyään) yleensä paljon muutakin tietoa kuin pelkkä työhistoria aikajärjestyksessä, esimerkiksi ohjelmointikieliä ja työkaluja, luottamustehtäviä yms. Niiden tietojen järjestystä tai esilläoloakin voi muuttaa sen perusteella minkä kuvittelee kiinnostavan lukijaa.

Jos hakee useisiin samansisältöisiin töihin, ei sitä kyllä silloin yleensä tarvi miettiä.

 

[FireFly Renaissance]

Periaatteessa noin ainakin mun aikana annettujen ohjeistusten mukaan, mutta jos taustalla paljon eri työpaikkoja/positioita, niin CV:täkin voi stilisoida haettavan paikan mukaan. CV:n pitäisi aina olla yhden sivun pituinen, jotta siitä voidaan nopeasti silmäillä sun tausta läpi, ja jos kaikki ei mahdu selkeästi ja järkevästi yhdelle sivulle, niin sitten kannattaa pistää relevanteimmat vain näkyviin.

Mulla ei ole ikinä ollut yhden sivun CV:tä vakitöitä hakiessa, enkä kyllä keksi mitään järkeä sellaisen lähettämisessä, kun joutuu karsimaan hirvittävästi asioita pois tai tekemään ulkoasusta todella tylsän ja sekavan. Toki asioiden järjestys kannattaa laittaa sellaiseksi, että työnantajaa kiinnostaa lukea pidemmälle sen ensimmäisen sivun jälkeen. Yli 3s pitkäksi en ole viitsinyt venyttää.

Sehän on vain itseään jalkaan ampumista, jos on osaamista, mutta ei näytä sitä.

 

[calm]

F-securen liikevaihto on luokkaa 150 miljoonaa samalla kun Nokian liikevaihto on 23 miljardia. Nokialla on toki jonkin verran konsultointi ja service-businesta, mutta suurin osa siitäkin liittynee sen omien softatuotteiden integrointiin ja ylläpitoon asiakkaille. Sen oma ohjelmistotuotannon arvo on moninkertainen F-secureen verrattuna. Iso osa siitä tuotannosta on tietty Suomen ulkopuolella.

Oisko se puolihumoristinen heitto ollut, että suurin pelkästään omaa ohjelmistotuotetta tekevä talo työntekijämäärällä mitattuna. Silloinkin se toki oli jo puolitotuus, kun rautatuotteita oli tulollaan ja silkkaa tietoturvakonsultointiakin jo oli tarjolla.

 

[kjns]

Mulla ei ole ikinä ollut yhden sivun CV:tä vakitöitä hakiessa, enkä kyllä keksi mitään järkeä sellaisen lähettämisessä, kun joutuu karsimaan hirvittävästi asioita pois tai tekemään ulkoasusta todella tylsän ja sekavan. Toki asioiden järjestys kannattaa laittaa sellaiseksi, että työnantajaa kiinnostaa lukea pidemmälle sen ensimmäisen sivun jälkeen. Yli 3s pitkäksi en ole viitsinyt venyttää.

Joo tää on tietenki totta, että jos sinne laittelee jotain kieliä ja frameworkkeja työtehtävien ja vastuiden lisäksi niin siinä alkaa sivu olemaan tiukassa. Tai jos on vaihtanut duunipaikkaa vuoden välein. Mulle on ainakin kaikissa työnhakua koskevissa "koulutuksissa" ja opastuksissa neuvottu 1) pitämään se CV yhden tai maksimissaan kahden sivun pituisena ja 2) listaamaan sinne tiivistetysti missä olet ollut töissä ja mimmoisessa tehtävässä. Sitten hakemuskirjeessä (tai nettilomakkeessa nykyään varmaan enemmän) tuodaan tarkemmin sitä omaa osaamista ja relevanttia kokemusta esiin kirjoitetussa muodossa.

Tiedä sitten mikä on "virallinen totuus" asiassa nykyään, alakohtaisestikin* voi toki olla eroa että mitä halutaan nähdä CV:ssä. Jos IT-alan rekryhemmot ensin katsoo CV:n läpi ja lukee hakemuksen jos kiinnostuu niin silloin toki CV:ssä kannattaa tuoda enemmän asioita esiin kuin puhtaassa referenssilistassa millainen CV:n on mulle aina opetettu olevan.

*Itse en ole koskaan hakenut puhtaasti IT-alan paikkoja, mun työhistoria on ICT:n/teollisuuden/automaation puolelta

 

[FireFly Renaissance]

Joo tää on tietenki totta, että jos sinne laittelee jotain kieliä ja frameworkkeja työtehtävien ja vastuiden lisäksi niin siinä alkaa sivu olemaan tiukassa. Tai jos on vaihtanut duunipaikkaa vuoden välein. Mulle on ainakin kaikissa työnhakua koskevissa "koulutuksissa" ja opastuksissa neuvottu 1) pitämään se CV yhden tai maksimissaan kahden sivun pituisena ja 2) listaamaan sinne tiivistetysti missä olet ollut töissä ja mimmoisessa tehtävässä. Sitten hakemuskirjeessä (tai nettilomakkeessa nykyään varmaan enemmän) tuodaan tarkemmin sitä omaa osaamista ja relevanttia kokemusta esiin kirjoitetussa muodossa.

Tiedä sitten mikä on "virallinen totuus" asiassa nykyään, alakohtaisestikin* voi toki olla eroa että mitä halutaan nähdä CV:ssä. Jos IT-alan rekryhemmot ensin katsoo CV:n läpi ja lukee hakemuksen jos kiinnostuu niin silloin toki CV:ssä kannattaa tuoda enemmän asioita esiin kuin puhtaassa referenssilistassa millainen CV:n on mulle aina opetettu olevan.

*Itse en ole koskaan hakenut puhtaasti IT-alan paikkoja, mun työhistoria on ICT:n/teollisuuden/automaation puolelta

Niin CV:ssä on se etu, että siinä sitä voi tuoda vähän tarkemmin esille kun hakemus on kuitenkin kaunokirjoitettua jaarittelua, ja sitä tuskin kukaan ainakaan jaksaa lukea tolkuttoman pitkästi.

Tässä on sellainenkin jippo, että CV ja ansioluettelo ovat tuolla englanninkielisessä maailmassa (ja moni työnhakuilmoitus IT-alalla on englanniksi) kaksi eri asiaa, ja CV:n pitäisi olla se pidempi. Toinen juttu on, ymmärtääkö ne rekrytoijatkaan tätä pyytäessään liitteeksi CV:n eikä resumen.

CV vs. Resume: The Difference and When to Use Which

 

[dropadrop]

En kyllä näkisi moniakaan noista firmoista toistensa kilpailijoina. Jos joku haluaa etsiä sidechannel hyökkäyksiä ja muistivuotoja jostain kernel-ajureista, niin se on aika eri kamaa kuin shader-koodin vääntäminen remedyllä tai joidenkin json-api:ien koodaaminen jossain webbipajassa.

Jos pitäisi veikata, niin Remedy ja F-secure ovat omilla erikoisaloillaan halutuimpia paikkoja Suomessa, vaikka eivät varmaan palkkakunkkuja olekaan.

Jos seuraat vähän F-Securen avoimia työpaikkoja huomaat että murto-osa on labraan jossa työ vastais tuota kuvausta. Valtaosa paikoista on erinäisten hallintaan liittyvien portaalien tai taustapalveluiden koodaamista. Tuotteesta liittyen haetaan eniten node / java / python osaajia kun noi kerneli-devaajat lienee jossain C-akselilla.

 

[dropadrop]

Kuka haluaa agiiliutta ja moderniutta? En ymmärrä miten agile tai sen puute tekee työstä tervanjuontia. Eikö se on palkka mikä ratkaisee? Pienissä omaa juttuja tekevissä softataloissa voi vielä parhaassa tapauksessa saada kunnon potin jos firma myydään tai menestyy.Epätodennäköistä, mutta minullakin on moni tuttu saanut kuusinumeroisen kertapotin tuollaisissa tapauksessa.

Nämä nyt ovat varmaan makuasioita, mutta mulla on aina motivaatio lähtenyt siitä että teen töitä joissa opin mielenkiintoisia asioita, ja näen käytännössä miten oma työ on ratkaissut ongelmia. Mitä isompia ongelmia ratkaisee sitä upeampaa, eka kohta korjaantuu yleensä saman firman sisällä tehtävien vaihdolla.

Yleensä vaihdan työnantajaa silloin kun en voi enään vaikuttaa OMASTA näkökannasta isoimpiin ongelmiin, eli käytännössä ristiriita strategian kanssa.

Palkka on aina ollut sivuosassa, mutta jostain syystä tällä tavalla se on noussut nopeammin kuin kavereilla jotka keskittyvät sen nostamiseen. En toki väitä että tämä olisi mitenkään ainoa toimiva malli, ja kerran olen vaihtanut töitä kun muualla oli tarjolla 40% korkeampi palkka (tosin myös vähintään yhtä mielenkiintoisia töitä).

 

[Randomizer]

Omassa työssä tilanne on aika ristiriitainen. Työ on erittäinkin mielenkiintoista ja tiimi aivan huippu mutta organisaatio aivan perseestä ja hankaloittaa päivittäistäkin tekemistä aika paljon. Palkka ei oo ikinä ollut se juttu itsellä, kunhan tuntee että työnantaja arvostaa riittävästi. Periaatteessa tekisi mieli vaihtaa mutta pelkään että vastaavaa, yhtä mielenkiintoisia työtehtäviä ei muualta helposti löydy.

 

[FireFly Renaissance]

Omassa työssä tilanne on aika ristiriitainen. Työ on erittäinkin mielenkiintoista ja tiimi aivan huippu mutta organisaatio aivan perseestä ja hankaloittaa päivittäistäkin tekemistä aika paljon. Palkka ei oo ikinä ollut se juttu itsellä, kunhan tuntee että työnantaja arvostaa riittävästi. Periaatteessa tekisi mieli vaihtaa mutta pelkään että vastaavaa, yhtä mielenkiintoisia työtehtäviä ei muualta helposti löydy.

Oli sama tilanne. Lähdin menemään viime vuoden lopulla, eikä kaduta. Työ on vähemmän "high-tech", mutta edelleen mielenkiintoista.

Tuntuu, että lähes järjestäen se ongelma on "organisaatio" eikä ne lähimmät työkaverit paikassa kuin paikassa.

 

[Bladekill]

Näin taitaa olla vain Suomessa? Vai Euroopassa? Piilaaksossa halutuimmat työpaikat ovat Facebook, Google, Amazon, Netflix etc jotka tekevät omia tuotteita alihankinnan sijaan.

Suomesta puhuin. Muissa paikoissa lienee tapauskohtaista.

Euroopasta ei kai pahemmin tule mitään ohjelmistotuotantoa joka pärjäis edes jossain määrin noille jenkeille

En olisi yllättynyt vaikka Euroopasta tulisi keskimäärin parempaa ohjelmistokehitystä kuin USA:sta jos katsotaan kansalaisuuden perusteella. Monet menestyvät IT-lafkat vain tulevat jenkeistä ja piilaakso on ainakin toistaiseksi kovaa huutoa (vaikka on lähtenyt laskusuhdanteeseen) koska USA on aina ollut vapaamarkkina ja yrittäjyys-myönteinen valtio eikä pelkästään IT-alan osalta. Piilaaksokin on loppupeleissä käytännössä täysin ulkomaalaisten rakentama.

Kuka haluaa agiiliutta ja moderniutta? En ymmärrä miten agile tai sen puute tekee työstä tervanjuontia. Eikö se on palkka mikä ratkaisee?

Toivottavasti tämä ei ollut tosissaan kirjoitettu juttu. Jos kuitenkin oli niin veikkaisin että kaikki ne haluavat sitä agiliutta ja moderniutta, jotka ovat kokeilleen molempia ääripäitä. Olen itse tehnyt softaa (suht.) pienessä itseohjautuvassa agiilissa porukassa ja sitten ollut jättimäisen seniilipappakorporaation vesiputous-hierarkiapyramidissa hukkumassa kravaattimanagerien niskassaläähättämiseen, turhiin lupien kyselyihin yms micromanagerointiin.
Mikä sitten oli lopputulos? Agiilissa tiimissä tehtiin aivan 6/5 priimaa softaa kaikilla best practiseilla, releaset lensivät luukusta pihalle lähes aina reilusti etuajassa. Firma teki tuohta, asiakkaat olivat tyytyväisiä, serverit kehräsivät kuin kissanpennut, appstore arvosana oli aivan huippu ja jopa Apple halusi featuroida ko. appia heidän etusivullaan ja tiimi tuli toimeen paremmin kuin hyvin. Sitten taas siinä "perinteisessä" mallissa missä devaajat, designerit yms. pidetään tiukasti kaikkien ulkoisten managerien talutusnuorassa ja missä jokaiseen asiaan pitää kysyä joltain erilliseltä porukalta tai managerilta lupa ja missä ylipäätään koko softakehitys on torpedoitu kaikilla mahdollisilla tavoilla lopputulema oli se että about kaikki meni vituiksi. Arvosanat laskee kuin lehmän häntä, päivittäinen työ on aivan yhtä helvettiä, firma hukkuu sisäisiin riitoihin, softa on ylläpitokelvoton dokumointoimaton muistivuotomonoliitti ja siihen mitä agiilissa tiimissä saatiin kuukaudessa aikaiseksi meni tässä tiimissä 4kk ja kaikki on loppupeleissä rikki, ylläpitokelvotonta ja porukkaa vuotaa ulos muihin firmoihin kun kyllästyvät paskaan.

Kyse on siis loppupeleissä siitä tehdäänkö hommat hitaasti ja kalliisti päin vittua niin että puolet tiimistä joutuu stressisaikulle vai nopeasti, kevyesti ja hyvin hyvällä meiningillä. Itse olen ainakin sen oppinut IT-alalta että
a) Haluan tehdä jotain hyvää, mistä voin olla edes jossain määrin ylpeä ja mitä oikeasti tykkään tehdä
b) En halua tulla joka päivä kotiin vitutuksen, masennuksen ja päänsäryn kanssa enkä halua kiroilla kun aamuisin menen töihin
c) En halua pilata henkistä terveyttäni ja elämänlaatuani ripauksen paremman palkan takia varsinkin kun erotuksesta Suomen valtio varastaa kuitenkin puolet jo heti kättelyssä.

Toki olet tavallaan oikeassa palkasta ainakin jossain määrin. Kyllä minullakin on hintani, mutta en ole vielä koskaan törmännyt noiden "huonompia" hommia tarjoavien duunipaikkojen kohdalla 20-30k kuukausipalkkoihin. Muutenkin omassa urakehityksessäni olen siirtynyt sekä palkassa ylöspäin että samalla jäykästä legacysta agiiliin ja moderniin laatusoftaan. Eivät siis ole onneksi toisiaan poissulkevia asioita.

Ilmeisesti porukka on kuitenkin keskimäärin tyytyväisiä alihankinta.. korjaan siis konsulttifirmoissa.

Ero on juuri tuossa. Ollaanko aivoton käsipari joka syöttää asiakkaalle vaikka kakkaa kunhan laskutuksesta sovitaan vai toimitaanko oikeasti konsulttifirmana joka auttaa asiakasta (kokonaisvaltaisesti) digitalisoitumaan.

 

[dropadrop]

Omassa työssä tilanne on aika ristiriitainen. Työ on erittäinkin mielenkiintoista ja tiimi aivan huippu mutta organisaatio aivan perseestä ja hankaloittaa päivittäistäkin tekemistä aika paljon. Palkka ei oo ikinä ollut se juttu itsellä, kunhan tuntee että työnantaja arvostaa riittävästi. Periaatteessa tekisi mieli vaihtaa mutta pelkään että vastaavaa, yhtä mielenkiintoisia työtehtäviä ei muualta helposti löydy.

Tässäkin on vielä se mahdollisuus, että:
- yrität selventää päässä mitkä organisaation isoimmat sun työskentelyyn liittyvät ongelmat ovat
- keksit mahdollisia ratkaisuja niihin ongelmiin
- mietit kuka / ketkä tekevät päätökset tuohon liittyen
- mietit millä argumenteilla myyt ne heille
- rupeat töihin

Tuolla tavalla olen saanut lukemattomia juttuja parannettua, ja sitä oppii tehdessä. Kandee kuitenkin huomioida että kolleegat / pomo / dirikka / VP / toimari tarvitsevat kaikki ihan erilaiset myynti-argumentit, ja mitä ylemmäksi mennään sitä todennäköisemmin idea kannattaa vaan istuttaa ajan kanssa ja hyväksyä että joku muu ottaa siitä kunnian.

 

[jokumuu]

Olen itse tehnyt softaa (suht.) pienessä itseohjautuvassa agiilissa porukassa ja sitten ollut jättimäisen seniilipappakorporaation vesiputous-hierarkiapyramidissa hukkumassa kravaattimanagerien niskassaläähättämiseen, turhiin lupien kyselyihin yms micromanagerointiin.

Olisikohan noissa lopputuloksissa ollut eroa myös organisaation koolla? Tottakai pieni alle 10 hengen tiimi voi toimia ketterästi jopa minimaalisella dokumentaatiolla. Iso organisaatio tarvitsee sitä läskiä ja palaveerausta, että saadaan projekti eteenpäin ja pysymään kasassa.

Itse olen ollut kummassakin, pienessä agiilissa tuotetiimissä (n 10 henkeä) ja isossa organisaatiossa, jossa yhtä ja samaa tuotetta väkersi useita satoja henkilöitä globaalisti. Myös muussa kuin tuotteen koossa oli luonnollisesti eroa, pieni tuote on yleisesti ottaen rajatulle markkinalle tai kuluttajamarkkinalle, jossa ei paljoa sertifikaateista, yhteensopivuuksista, sopimuksista, politiikasta, yms. tarvitse välittää. Isossa tuotteessa mukaan tulee pakosti eri sidosryhmien tarpeet (jotka todennäköisesti ovat keskenään ristiriidassa), sertifioinnit, yms. joka pakosti monimutkaistaa koko prosessia todella paljon.

Toki tässä isossakin organisaatiossa yritimme tehdä osaltamme (pikkutiimi) homma ketterästi, mutta kun se ei vain yleensä onnistu, kun niitä riippuvuuksia muihin on kuitenkin paljon. Ja toki myös projektijohto pyrki ketteryyteen, mutta aika heikolla menestyksellä.
Sanoisin että mainittu 1kk vs. 4kk oli oikeastaan aika hyvin.

Ja isossakin organisaatiossa voi olla ihan mukavaa. Se vaatii tosin lähiesimieheltä oikeasti taitoa, että se pystyy blokkaamaan prosessin itseensä ja minimoimaan sen vaikutukset peruskulin elämään.

 

[FireFly Renaissance]

Tuolla tavalla olen saanut lukemattomia juttuja parannettua, ja sitä oppii tehdessä. Kandee kuitenkin huomioida että kolleegat / pomo / dirikka / VP / toimari tarvitsevat kaikki ihan erilaiset myynti-argumentit, ja mitä ylemmäksi mennään sitä todennäköisemmin idea kannattaa vaan istuttaa ajan kanssa ja hyväksyä että joku muu ottaa siitä kunnian.

Nämä voi toimia ehkä keskikokoisissa organisaatioissa, mutta jos kyseessä on oikeasti iso organisaatio se on taistelu tuulimyllyjä vastaan ellei satu istumaan itse jo valmiiksi tarpeeksi lähellä päättäviä elimiä. Eikä sekään välttämättä auta, jos kulttuuri on pielessä eikä sitä haluta muuttaa tj tasolta alaspäin toiseen suuntaan se tuskin muuttuu.

 

[FireFly Renaissance]

Olisikohan noissa lopputuloksissa ollut eroa myös organisaation koolla? Tottakai pieni alle 10 hengen tiimi voi toimia ketterästi jopa minimaalisella dokumentaatiolla. Iso organisaatio tarvitsee sitä läskiä ja palaveerausta, että saadaan projekti eteenpäin ja pysymään kasassa.

Tuskin tässä on agiiliudella oikeastaan edes mitään tekemistä asian kanssa. Lähinnä kyse on siitä, onko päätösvalta ulkoistettu kaikenlaisille poliitikoille ja byrokraateille, jotka ovat aika päivää sitten kadottaneet kaiken otteen siihen todelliseen tuotekehitykseen. Tai se ohjaus on ulkoistettu businessporukalle, joilla ei ole siitä alunperinkään ollut minkäänlaista ymmärrystä.

Toimii myös toiseen suuntaan, ne byrokraatit ja poliitikot ovat lukeneet lehdestä, että agility on päivän sana millä vyffe taotaan, ja sitten pakotetaan kaikki toiminta "ketteräksi" riippumatta siitä onko sille minkään valtakunnan järkeä tai perustetta. Kirsikkana kakun päälle se "ketteryys" tietenkin toteutetaan niin, ettei yhdenkään poliitikon tai byrokraatin valta vähene tai positio vaarannu.

Isokin organisaatio voi varmaan toimia hyvin, mutta jos sinne johtoon päästetään alkuunkaan pesiytymään mitään prosessiuskovaisia "manageeraajia" tai organisaatiopelin pelaajia, niin peli taitaa olla menetetty.

 

[Bladekill]

Olisikohan noissa lopputuloksissa ollut eroa myös organisaation koolla? Tottakai pieni alle 10 hengen tiimi voi toimia ketterästi jopa minimaalisella dokumentaatiolla. Iso organisaatio tarvitsee sitä läskiä ja palaveerausta, että saadaan projekti eteenpäin ja pysymään kasassa.

Ei ollut. Molemmissa tapauksissa on kyse megakorporaatioista miljardiluokan vuosittaisella liikevoitolla. Kyse oli ihan puhtaasti vain siitä että ymmärrettiinkö miten moderni softakehitys toimii ja rakennettiinko dedikoitu RnD yksikkö joka vastaa itse itsestään vai työnnetäänkö softa johonkin määrittelemättömään välimalliin jota repivät, rajoittavat ja häiriköivät kaikki osastot ja managerit markkinoinnista, IT:n, brändingiin yms.
Kumpikaan näistä ei ole softatalo eikä kummankaan tuote ole ollut perinteisesti inherenttisesti digitaalinen. Ensimmäisessä tapauksessa vain asiakas itse ymmärsi heikkoutensa ja siksi palkkasi ja rekrytoi mahdollisimman kovan luoka tekijöitä johtamaan ja rakentamaan tätä puolta. Jälkimmäisessä taas kompetenssittomat kravaattivirnuilijat itse alkoivat mikromanageroimaan asiaa mistä eivät ymmärrä pätkääkään ja yllättäen lopputuloksena oli täydellinen katastrofi.

Ymmärrän kyllä täysin "red tape":n ja muun bullshitit mitä isoissa organisaatioissa on pakko joskus sietää enkä ole sitä vastaan edes kaikissa tapauksissa, mutta jos minkäänlaista joustoa tai uudistumishalua ei ole millään puolella vaan kaikessa vedetään hommat 50-luvun tyylillä niin sitten loppu häämöttää.

 

[Randomizer]

Tässäkin on vielä se mahdollisuus, että:
- yrität selventää päässä mitkä organisaation isoimmat sun työskentelyyn liittyvät ongelmat ovat
- keksit mahdollisia ratkaisuja niihin ongelmiin
- mietit kuka / ketkä tekevät päätökset tuohon liittyen
- mietit millä argumenteilla myyt ne heille
- rupeat töihin

Tuolla tavalla olen saanut lukemattomia juttuja parannettua, ja sitä oppii tehdessä. Kandee kuitenkin huomioida että kolleegat / pomo / dirikka / VP / toimari tarvitsevat kaikki ihan erilaiset myynti-argumentit, ja mitä ylemmäksi mennään sitä todennäköisemmin idea kannattaa vaan istuttaa ajan kanssa ja hyväksyä että joku muu ottaa siitä kunnian.

Neuvomiasi seikkoja on kyllä tehty rajusti koko tiimin voimalla, työtunteja ja resursseja on käytetty hurja määrä erilaisten esitysten tekemiseen ja POC:aamiseen mutta lopullinen päätösvalta on valitettavasti ihan muualla kuin Suomessa joten toi on ollut käytännössä tuulimyllyjä vastaan taistelemista + organisaatioiden välistä taistelua joihin suomalaisella pertti-perusinsinöörillä ei ole minkään luokan vaikutusmahdollisuuksia.

 

[Randomizer]

Nämä voi toimia ehkä keskikokoisissa organisaatioissa, mutta jos kyseessä on oikeasti iso organisaatio se on taistelu tuulimyllyjä vastaan ellei satu istumaan itse jo valmiiksi tarpeeksi lähellä päättäviä elimiä. Eikä sekään välttämättä auta, jos kulttuuri on pielessä eikä sitä haluta muuttaa tj tasolta alaspäin toiseen suuntaan se tuskin muuttuu.

Se on pitkälti nimenomaan näin. Ennenkuin huipulla ei ihmiset vaihdu ja ajatusmallit muutu, taistelu on turhaa.

 

[Jorsetti]

Jos ketuttaa lähteä aamulla tunkkaamaan sitä kasaa, niin vaihda paikkaa. Siinähän vanhenee vuodessa vähintään viiden vuoden verran, jos perus stressin lisäksi vielä ketuttaa aamulla ja unta ei tule yöllä. Perus stressitasolla sentään vanhenee samaa tahtia muiden kanssa. Suurissa firmoissa oma kokemuksen perusteella on aika turhaa heitellä hyviä ideoita. Toisaalta joku jääräpäinen johtaja pienessäkin firmassa on yhtä huono.

 

[yannara]

Omassa työssä tilanne on aika ristiriitainen. Työ on erittäinkin mielenkiintoista ja tiimi aivan huippu mutta organisaatio aivan perseestä ja hankaloittaa päivittäistäkin tekemistä aika paljon. Palkka ei oo ikinä ollut se juttu itsellä, kunhan tuntee että työnantaja arvostaa riittävästi. Periaatteessa tekisi mieli vaihtaa mutta pelkään että vastaavaa, yhtä mielenkiintoisia työtehtäviä ei muualta helposti löydy.

Ne, jotka hakee ja lähtee itse, saavat valita, lähtevätkö vai jäävätkö, ovat yleensä jälkeenpäin tyytyväisiä tilanteeseen. Harva palaa takaisin. Pitää vaan olla pelisilmää haastattelussa että osaat kysyä oikeat kysymykset ja haistella ilmaa. Hakemisessa ja haastetteluissa käymisessä et vielä menetä mitään.

 

[Stephen Elop]

... mutta lopullinen päätösvalta on valitettavasti ihan muualla kuin Suomessa ...

Tuollaisessa konsulttifirmassa ei tuottava osa pääse yhtään vaikuttamaan. Ainoastaan silloin, jos se Suomen osaston pomo on kova luu ja iskee kunnolla nyrkin pyötään niiden Intialaisten/Amerikkalaisten pomojen kanssa.

Vaihda paikkaa, koska johtoa ei kiinnosta pätkääkään asioiden kehittäminen täällä. Ainoastaan mahdollisimman vähällä vaivalla mahdollisten rahojen kerääminen.

 

[Paapaa]

Mitkähän nykyään on vaatimuserot/odotukset koodareille aloittelevan junior-position ja siitä korkeampien välillä?

Noita junnupaikkojen hylsymaileja saadessa ja omaa koodihistoriaa tarkastellessa tajusin, että koodasin jo vuonna 2002 OpenGL:ää C++:lla ja esim. OpenCL:ää C++ path tracerille 2010. Vaikka työkokemusta ei olekaan, junnuilla tuskin tyypillisesti on yhtä paljon harrastelua taustalla, joten mietin, että kannattaisikohan suoraan asettaa omat työllistymistavoitteet (ja itseopiskelu) sitä korkeammalle ja positioihin joihin on vähemmän tunkua.

Musta sulla on tosi nopealla vilkaisulla sinänsä ihan kiinnostava GitHub-profiili, joka osoittaa, että saat jotain toimivaa aikaan, osaat dokumentoida sitä ainakin kevyesti. Varmaan nyt kannattaisi katsoa, että omat taidot ja harrastuneisuus kohdistuu siihen, mitä työnantaja haluaa. Jos siis haet konsulttitaloon, joka myy lähinnä web/React-osaajia, ei välttämättä C++ kauheasti lohduta. Eli päivitä osaaminen siihen, mitä haluat tehdä ja sitten haet sellaista paikkaa.

Millaisia paikkoja nyt hait, joista tuli hylsy? Millaista palautetta sait? Mistä jäi kiikastamaan? Miksi tuli hylsyä, pääsitkö haastatteluun kertaakaan? Kannattaa ehdottomasti kysyä tarkennuksia hylsyihin positiivisella ja rakentavalla tulokulmalla. Ikä tuskin on ongelma, ellet nyt yli 50v ole. Eikä toivottavasti sittenkään. Vaatimustasoakin ja odotuksia kannattaa kysyä reippaasti työnantajalta. Siellä on se paras tieto.

 

[Randomizer]

Mitkähän nykyään on vaatimuserot/odotukset koodareille aloittelevan junior-position ja siitä korkeampien välillä?

Noita junnupaikkojen hylsymaileja saadessa ja omaa koodihistoriaa tarkastellessa tajusin, että koodasin jo vuonna 2002 OpenGL:ää C++:lla ja esim. OpenCL:ää C++ path tracerille 2010. Vaikka työkokemusta ei olekaan, junnuilla tuskin tyypillisesti on yhtä paljon harrastelua taustalla, joten mietin, että kannattaisikohan suoraan asettaa omat työllistymistavoitteet (ja itseopiskelu) sitä korkeammalle ja positioihin joihin on vähemmän tunkua.

Jos et ole opetellut vielä ketteriä menetelmiä, continuous integrationia ja deliveryä, niin ne kannattaa teoriapuolelta opetella. Yleensä työnantajat olettavat että noi on edes auttavasti hanskassa. Toisekseen, jos et ole ollut vielä Open Source projekteissa mukana, kannattaa kokeilla sitä. Ne projektit tehdään usein prosessimielessä samaan tapaan kuin projektit työelämässä.

Olet kuitenkin ilmeisesti koodannut vain itseksesi? Tiimissä työskentely vaatii kuitenkin vähän erilaisia lähtökohtia työhön. Voi olla yksi syy miksi työnantaja saattaa katsoa hieman kieroon.

 

[Paapaa]

Olet kuitenkin ilmeisesti koodannut vain itseksesi? Tiimissä työskentely vaatii kuitenkin vähän erilaisia lähtökohtia työhön. Voi olla yksi syy miksi työnantaja saattaa katsoa hieman kieroon.

Ensimmäistä työpaikkaa hakevalla junnulla ei voi ollakaan kokemusta tiimityöskentelystä. Lähinnä rajoittuu muutamaan projektiin esim. yliopistossa. En usko, etä se sinänsä aiheuttaa mitään kieroon katsomista kun nimeomaan junioripaikkaa tai kesätyöpaikkaa täytetään.

 

[shams]

Veikkaisin että junior-paikkoihin katsellaan nykyään enemmän "soft skillsejä", potentiaalia ja sitä millainen tyyppi on, eikä niinkään teknisiä näyttöjä (kunhan ohjelmointiteorian perusasiat on kunnossa). Tai ainakin näin sen pitäisi olla.

 

[FireFly Renaissance]

Mitkähän nykyään on vaatimuserot/odotukset koodareille aloittelevan junior-position ja siitä korkeampien välillä?

Noita junnupaikkojen hylsymaileja saadessa ja omaa koodihistoriaa tarkastellessa tajusin, että koodasin jo vuonna 2002 OpenGL:ää C++:lla ja esim. OpenCL:ää C++ path tracerille 2010. Vaikka työkokemusta ei olekaan, junnuilla tuskin tyypillisesti on yhtä paljon harrastelua taustalla, joten mietin, että kannattaisikohan suoraan asettaa omat työllistymistavoitteet (ja itseopiskelu) sitä korkeammalle ja positioihin joihin on vähemmän tunkua.

Ohjelmistosuunnittelijan työ on kuitenkin lähes poikkeuksetta paljon muutakin kuin vain koodausta, vaikka koodaaminen onkin yleensä se suurin osa-alue. Ilman mitään kokemusta kaupallisesta/teollisesta ohjelmistotuotannosta on varmaan kova kynnys palkata ketään muuhun kuin junior rooliin. Ellei sitten ole muulta alalta jo valmiiksi vahva kokemus tuotekehityksessä / projektitehtävissä työskentelystä.

Mutta, jos on teknistä osaamista voi toki hakea teknisesti haastavampiin ja ehkä mielenkiintoisempiin tehtäviin.

 

[Bladekill]

Vaikka työkokemusta ei olekaan, junnuilla tuskin tyypillisesti on yhtä paljon harrastelua taustalla, joten mietin, että kannattaisikohan suoraan asettaa omat työllistymistavoitteet (ja itseopiskelu) sitä korkeammalle ja positioihin joihin on vähemmän tunkua.

Riippuu ihan millaisia hommia haet ja minkälaisista yrityksistä. Yleensä jos jotain C++ hommia lähtee hakemaan niin siellä tulee kielen hallinnan perään kilometrin lista jotain hyvin spesiifisiä ja tiukkoja vaatimuksia jostain tietystä osa-alueesta esim juuri grafiikkaohjelmointi/pelimoottorit tai vaikka x86 assemblyn ja käyttöjärjestelmien toiminnan syvällinen tunteminen. En totta puhuen muista nähneeni työpaikkailmoituksissa vuosiin junior paikkoja C++ hommille.

Tosin pakko sanoa että itselläni oli todella vaikeaa päästä aikoinaan kesätöihin vaikka tekninen kompetenssi oli suhteellisesti kova ja selvästi parempi kuin keskimääräisellä ikäluokan/saman aseman jäsenellä. Yleensä en edes päässyt siihen asti että olisin päässyt face-2-face puhumaan firman devaajien tai managerien kanssa vaan HR tyrmäsi jo alkukarsinnassa kun en tehnyt innovatiivista CV-videota jossa soitan kitaraa ja leikin kissanpentujen kanssa yms paskaa. Lopulta sitten hain samasta firmasta juniorpaikkaa kesän jälkeen ja pääsin sisään. Eli tuo mitä esitit tavallaan toimi ehkä itselleni, mutta nämä ovat aika tapauskohtaisia.

 

[Randomizer]

Kyllähän se valitettavasti niin on että soft-skillit ovat yhä isommassa roolissa IT-alalla(kin). Hiljainen koodariautisti ei välttämättä pääse alkuportista sisään, ellei sitten tunne oikeita henkilöitä yrityksissä.

 

[idkf]

Jätin suosiolla C++-paikkojen hakemisen tuohon yhteen haastateltuun. Vaatimukset tosiaan oli kohtuudella korkeat jos nyt ei valtavat ("oletko löytänyt bugeja GCC:stä?" taisi olla ensimmäisiä kysymyksiä). Nyt olen katsellut jotain kevyempää päättämättä vielä selkeästi mitään, ja varmaan senkin takia hakemukset ei tuota selkeitä tuloksia. Tuntuu että kun taustalla on pitkä C++-harrastelu niin haastavuuden osalta moni muu kieli on opettelua alaspäin. Valinnanvaraa on paljon siis ja käytännössä kaikki stäkkiyhdistelmät on jollain tasolla edustettuina työilmoituksissa. Kokemusta muista kielistä ei kuitenkaan ole paljon, ja kunnes sitä kertyy enemmän niin homma on vähän siirtyvien maalitolppien jahtailua.

En ole parhaimmillani haastatteluissa, joten siinä mielessä tuo haastattelukutsujen vähyys ei ole ihan paras juttu. Tuskin vedän korkealla prosentilla kotiin päin niitä, joten tällä vauhdilla hommassa saattaisi mennä hetki.

Ei tuon C++ suhteen nyt välttämättä kannata noin helpolla luovuttaa. Qt on nostanut suosiotaan jatkuvasti ja vaikka fronttia tehdään tuon puhtaan C++ Qt -widget tyylin lisäksi paljon nuiden omalla javascriptin tapaisella QML:llä, niin viewien controllerit jne. datan virtaus koodataan kuitenkin ihan C++:lla ja frameworkki on kuitenkin pohjimmiltaan C++. Jos katsot tällä hetkellä auki olevia C++ paikkoja, niin aika monessa avoinna olevassa C++ paikassa puhutaan Qt:sta, ja tuo nyt ei ole mitään ajureiden/ sulautetun koodaamista.

Edit. Lisäksi kannattaa lukea arkkitehtuurin peruskäsitteet, kestää maksimissaan 5h ja sitten kun noista omista projekteista kysellään niin yksityiskohtien lisäksi esittelet aluksi, että tietorakenteena toimiva luokka on singleton ja ylipäätänsä toteuttamasi rakenne vastaa esim. MVC:tä tai MVVM.

 

[dropadrop]

Luulis että joka firmaan ja positioon on omat vaatimukset, eli jos kiinnostus on C++’aan ei kannata heti luovuttaa.

Sikäli kun olen seurannut meillä junnu-koodaajien valintoja niin kokemus kyllä huomioidaan. On odotuksia että pystyy esittelemään tekemiään töitä, ja että kuvaus omista taidoista on linjassa koodin laadun kanssa. Kun kysytään vaikeita kysymyksiä esim. siitä oletko löytänyt bugeja GCC’stä voi tarkoitus olla testata kuinka suhtaudut niihin vaikeisiin kysymyksiin, tai siihen ettet osaa jotain eikä suinkaan vaan saada aina kuittausta että on hanskassa. Ainakin mulla parin kymmenen vuoden kokemuksella on valtavasti asioita joita en osaa, ja nykysin suhtaudun asiaan niin että yleensä on tärkempää tietää mitä ei tiedä kuin osata kaikki. Toki tuo toimii vasta jos on avoin oppimaan uusia asioita.

Meillä on jonkun verran C++ devaajia ja erityisesti Linux-devaajilla yleisimmät valitukset (siis tuotehallinnan puolelta) on haluttomuus koodata käyttöliittymiä tai ylipäätänsä miettiä asioita asiakkaan näkökannasta, haluttomuus muuttaa tottumuksia ja ruveta esim tuottamaan telemetriaa ja parempaa logitusta joka voisi auttaa asiakkaita jne. Sen perusteella voisin olettaa, että sillä puolella olisi tilaa tuoreille käsille, erityisesti jos vaikka yhdistää C++ osaamisen javascriptin tms kanssa. Toinen kulma olisi sitten laajentaa osaamista Linux / Mac puolella koska niihin paikkoihin on paljon vaikeampi löytää tekijöitä kuin Windowsiin.

Junior pestien lisäksi voi kannattaa kattoa työharjoittelijoiden paikkoja isommissa taloissa. Näin kesän alla voi laittaa hakemuksia kesäpaikkoihin vaikkei avointa rekryä olisikaan. CV’tä ja hakemusta kannattaa hioa jokaiseen paikkaan koska voi viedä aikansa ennen kuin se on oikeasti hyvä.

 

[Paapaa]

Tuntuu että kun taustalla on pitkä C++-harrastelu niin haastavuuden osalta moni muu kieli on opettelua alaspäin.

Mitä tällä mainasit? Että on ankeaa aloittaa nollista muiden kielien kohdalla vai?

En ole parhaimmillani haastatteluissa, joten siinä mielessä tuo haastattelukutsujen vähyys ei ole ihan paras juttu. Tuskin vedän korkealla prosentilla kotiin päin niitä, joten tällä vauhdilla hommassa saattaisi mennä hetki.

Tätä kannattaa harjoitella! Pyydä vaikka kaveria haastattelemaan. TEK:llä taitaa olla joku appis, jolla voi harjoitella yleistä työhaastattelua. Kyllä/ei-vastaukset eivät tosiaan välttämättä haastattelijaa kauheasti inspiroi, joten yritä muistella kysymyksiä ja kotona lätiset ääneen uudet pidemmät vastaukset niihin. Haastattelijaa ei välttämättä kiinnosta ns. oikea vastaus, vaan tapasi ajatella, ratkoa ongelmia kun ET tiedä niihin vastauksia jne. Tuossa debuggerikysymyksessä olisi ollut juurikin hyvä kertoa, että assembly on tuttua kauraa ja olet sitä debuggerillä kahlannut läpi. Ja nyt tiedät, miten voit C++:n kohdalla parantaa tietämystäsi.

Eikä ole ollenkaan poikkeuksellista jännittää. Kaikki jännittävät haastatteluja ja alussa kun kokemusta niistä ei ole, niin ne jännittävät vielä enemmän. Sen voi ihan hyvin sanoa haastattelijalle vaikka heti kärkeen: "Moi, olen kokematon työnhakija ja jännittää tämä haastattelu, mutta yritän parhaani!"

 

[FireFly Renaissance]

Toisaalta pitää kysyä, mitä ensiodotuksia työnantajalle sinusta syntyy kun haet junnupositiota. Luultavasti ei sitä, että huomattava itsenäisesti hankittu kokemus pohjanasi oppinet nopeasti tavoille. Luultavammin luovit sitä enemmän negatiivisia oletuksia vastaan mitä enemmän olisit oletetun ryhmäsi perustason yläpuolella.

Skaala lienee ylipäätään aika iso, jos kaikki suvereenisti softakaaren hallitsevan alapuolella on entry-leveliä, joten kai muita askelmia väkisinkin on? Ja vaikka kaupallisessa softakehityksessä on oma maailmansa opittavaksi, ei ymmärtääkseni kyse silti ole jumalrakennelmista joiden opettelu lähtee kokonaisuutena nollista kun työllistyy. Ei edes taida olla mahdotonta päätyä hoitamaan huonommin väsättyä softaa kuin mitä itse on joskus huvikseen tehnyt.

Laitoin nuo tiimimenetelmät opeteltavien listalle, kiitos vinkistä.

Se oleellinen tuossa on, että pitää oppia tavoille. Ei tarvi osata suvereenisti, mutta pitää kyetä ymmärtämään ja tuottamaan dokumentaatiota (mikä kaikki ei välttämättä ole varsinaista softadokumentaatiota), olla kokemusta ainakin jostain työkaluista ja prosesseista ja ylipäänsä tietää miten saadaan toimiva lopputuote aikaiseksi kun sitä väännetään täysipäiväisesti porukalla vuosi. Harrasteprojekteissa nämä kaikki jäävät usein vähän silleen ja tälleen. Jos olisin rekrytoija ja haluan täyttää ns. senior kehittäjän paikan olettaisin, että ne tavat osataan suoraan (yleisellä tasolla, firmoissa toki eroja). Kannattaa muistaa, että keskimäärin sen yliopistokoulutetunkin arvostetuimmat ja kiinnostavimmat kurssit työnantajan kannalta ovat projektikurssit ja ohjelmistotuotannon kurssit. Matemaattinen / algoritminen yms. osaaminen tulee suurimmassa osassa tehtäviä vasta näiden jälkeen. Ykkösprioriteetti kun lähes poikkeuksetta on saada toimiva softa pihalle, ja mielellään jotenkuten aikataulussa. Ns. "junioripaikoissa" oletus on, että joku katselee vähän perään ja sinulle riittää, että saat tehtyä koodia. Seniori paikoissa sitten oletetaan, että ylläolevat asiat tulevat vähän niinkuin automatic. Tämä oma IMHO.

Mutta, jos on kova luu koodaamaan ja oppii nopeasti tavoille voi mennä nopeammin kyselemään sitä seuraavaa tasoa tai hakea uutta työpaikkaa kun on saanut sitä kokemusta ns. teollisuudesta. Sen ensimmäisen paikan saaminen on haastavinta, sen jälkeen se on oravanpyörässä ravaamista. Ensimmäisenä kannattaa vain yrittää jotenkin päästä sinne pyörään sisään.

 

[dropadrop]

Junnujen haastatteluissa muhun on myös tehnyt vaikutuksen ne ihmiset, jotka ovat jo jollain tasolla ymmärtäneet ryhmädynamiikkaa, ja omaa itseään. Ei ole harvinaista että junnu / työharjoittelija sanoo että ”hyvä ryhmä on semmoinen jossa kaikki tekevät paljon työtä”, kun taas muhun tekee isomman vaikutuksen ihminen joka on ymmärtänyt että hyvässä ryhmässä eri jäsenillä on eri vahvuuksia ja he osaavat hyödyntää niitä. Joku voi olla järjestelmällinen ja huolehtia aikatauluista, toinen voi olla kekseliäs ja kolmas on hyvä tuottamaan tekstiä ja puhumaan. Jos ryhmä ymmärtää omat vahvuutensa, kunnioittaa toisiaan ja pystyy sparraamaan syntyy ihan eritasoisia tuloksia. Jostain syystä tuntuu, että tytöt ovat tajunneet tuon jo koulussa kun taas jätkillä menee paljon pidempään (erityisesti oman itsensä tuntemiseen), mullakin.

Mäkin kannatan haastatteluihin harjoittelemista, mut kannattaa muistaa että liian selvät treenatut vastaukset paistavat läpi. Kukaan ei ole täydellinen ja jos joku itsepintaisesti antaa semmosta vaikutelmaa niin mulla soi ainakin vahvasti hälytyskellot.

 

[SampoTexaa]

Ei liity koodaamiseen mutta kerron kuitenkin että muutama IT management tason haastattelu tullut viime kuukausina koluttua lävitse ihan vain markkina-arvon mittaus periaatteella. Huomio näistä on puhtaasti se että nykypäivän IT managerin tulisi olla jonkinlainen kaiken tietävä orja joka painaa kaikkien hommat 24/7.

Yhdessä paikassa olisi tullut 5 alaista johdettavaksi. Ehdotin että voisin valjastaa nämä tyypit tekemään osan näistä managerille langetetuista hommista esim. koodausta. Rekrytoiva esimies totesi ettei niistä ole mihinkään ja nauroi päälle. Kaiken huipuksi rekrytoiva esimies ei ole uskaltanut soittaa päätöksistä tähän päivään mennessä. En varmaan ole jatkossa

 

[dropadrop]

Kuullostaa siltä, että organisaatiossa arvostetaan teknistä porukkaa.

 

[Paapaa]

Mäkin kannatan haastatteluihin harjoittelemista, mut kannattaa muistaa että liian selvät treenatut vastaukset paistavat läpi. Kukaan ei ole täydellinen ja jos joku itsepintaisesti antaa semmosta vaikutelmaa niin mulla soi ainakin vahvasti hälytyskellot.

Mun kommenttini liittyi siihen kerrottuun 'jäätymiseen'. Vastauksia ei sinänsä kannata tai edes voi opetella etukäteen, mutta haatattelutilanteessa toimimista voi ja kannattaa harjoitella. Siis ihan puheviestinnän ja kommunikoinnin harjoittelua, jotta vältytään 'joo'/'en'-vastauksilta.

 

[Bladekill]

Ei liity koodaamiseen mutta kerron kuitenkin että muutama IT management tason haastattelu tullut viime kuukausina koluttua lävitse ihan vain markkina-arvon mittaus periaatteella. Huomio näistä on puhtaasti se että nykypäivän IT managerin tulisi olla jonkinlainen kaiken tietävä orja joka painaa kaikkien hommat 24/7.

Yhdessä paikassa olisi tullut 5 alaista johdettavaksi. Ehdotin että voisin valjastaa nämä tyypit tekemään osan näistä managerille langetetuista hommista esim. koodausta. Rekrytoiva esimies totesi ettei niistä ole mihinkään ja nauroi päälle. Kaiken huipuksi rekrytoiva esimies ei ole uskaltanut soittaa päätöksistä tähän päivään mennessä. En varmaan ole jatkossa

Ettei vain olisi sattunut erikoistapaus kohdalle? Omat kokemukset ovat sellasia etten ole vielä koskaan nähnyt IT/dev-manageria joka koodaisi. Lieneekö sitten kyseessä ollut arkkitehdin paikka?

Itselläni on useimmiten tullut vastaan seuraavanlaiset managerit:

Perusmanageri: Hoitaa hommansa hyvin, tekee useasti ylitöitä ja istuu 90% päivästään saharaa kuivemmissa palavereissa kommunikoimassa eri osastojen/yksiköiden edustajien kanssa. Hoitaa dailyt ja weeklyt.

Turha fätti manageri: Täysin turha tyyppi ja suhteellisen pihalla tekemisestä. Kontribuutio jotain nollan ja haitallisen väliltä. Forwardoi ylemmän johdon pyyntöjä devtiimille ja välillä jakaa jotain Vergen, TechCrunchin yms. linkkejä Slack:ssa. Päässyt asemaansa suhteiden kautta tai sitten ollut firmassa +10v tms. ja pakolla siirretty johtotehtäviin.

Turha fätti manageri joka haluaa olla tärkeä: Kuten edellinen tapaus, mutta haluaa kovasti näyttää tärkeältä, kiireiseltä ja siltä että olisi oikeasti puikoissa kiinni. Käytännössä siis tekee paljon haitallisia tai turhia aloitteita, mikromanageroi ja rasittaa devtiimiä turhalla paskalla.

 

[dropadrop]

Kyl ton perusmanagerin päällä vois olla myös hyvä manageri joka täyttäisi kaikki nuo vaatimukset, mutta samalla vahvistaa tiimin toimintaedellytyksiä, suojaa tiimiä paskalta ja korostaa tiimin arvoa ulospäin... Ja ehkä vielä välillä huolehtii siitä, että tiimin jäsenet eivät eksy tekemään turhaa työtä.

 

[dropadrop]

Ja vielä, tohon ”pääsee hommiin suhteilla” teoriaan on vaihtoehto, eli on joskus onnistunut hyvin jossain ihan muissa hommissa ja ylennetty esimieheksi jossa tarvittaiskin ihan toisenlaisia taitoja.

Joku selitti joskus teoriaa siitä, miten kaikki hyvät työntekijät yritetään ylennetää yhden kerran liikaa, ja jos suostuvat muuttuvat turhiksi.

 

[Bladekill]

Kyl ton perusmanagerin päällä vois olla myös hyvä manageri joka täyttäisi kaikki nuo vaatimukset, mutta samalla vahvistaa tiimin toimintaedellytyksiä, suojaa tiimiä paskalta ja korostaa tiimin arvoa ulospäin... Ja ehkä vielä välillä huolehtii siitä, että tiimin jäsenet eivät eksy tekemään turhaa työtä.

Harvinaisempi näky, mutta ihan totta.

 

[JCSH]

Ettei vain olisi sattunut erikoistapaus kohdalle? Omat kokemukset ovat sellasia etten ole vielä koskaan nähnyt IT/dev-manageria joka koodaisi.

No tässä olis sulle yksi manageri joka myös koodaa

Tai oikeastaan olen koodari joka myös tekee managerin hommia.

 

[Bladekill]

Tai oikeastaan olen koodari joka myös tekee managerin hommia.

Pointti oli juurikin se että henkilö joka on virallisesti/päätoimisesti manageri koodaisi. Olen itse senior dev/arkkitehti, mutta teen nykyisessä hommassani vähän kaikkea projektimanagerin hommista myyntiin tarpeen tullen.

 

[JCSH]

Pointti oli juurikin se että henkilö joka on virallisesti/päätoimisesti manageri koodaisi. Olen itse senior dev/arkkitehti, mutta teen nykyisessä hommassani vähän kaikkea projektimanagerin hommista myyntiin tarpeen tullen.

Tuo mun viimeinen kommentti oli enemmänkin "state of mind" tyylinen heitto, i.e. jos pitäisi valita että alanko tekemään puhdasta teknistä hommaa vai puhdasta managerointia niin valkkaisin ensimmäisen.
Mutta virallisesti olen RnD manager softatiimissä, olen linjassa tiimin devaajien esimies. Ja istun juurikin noissa kaiken sorttisissa leadership/steering/whatnot palavereissa. Ja tuon lisäksi koodaan.
Edellisessä organisaatiossa jossa olin myös softa tiimin vetäjä niin myös mun oma esimies, jolla raportoi pari softa tiimiä + muutama erillinen "ekspertti", vielä aina välillä koodasi. Tai enemmänkin teki teknistä suunnittelutyötä ja konseptointia, ei nyt ihan sellaista peruskoodiapina työtä.

Jos organisaatio rakennetaan järkevästi niin noita kommunikaatiopalavereita ei ole niin hirveästi. Sanoisin että se että tekniset tyypit toimii myös tiimien johtajina oikeastaa auttaa siihen että kalenteri pysyy tyhjänä. Koska niiden ei tarvitse keksiä tekemistä väsäämällä turhia palavereita. Ja ne ei halua istua niissä.
Taaskin jos organisaatio rakennetaan huonosti niin sitten niitä turhia palavereita on kalenteri täynnä jo ihan siitä alimmalta manageritasolta lähtien.

Olen ollut organisaatioissa joissa on kolme tasoa managereita RnD:ssä (mukaan lukien se joka vetää koko business yksikön RnD:tä) siten että jokainen taso on teknisesti erittäin päteviä, pystyvät kontribuoimaan tekniseen työhön ja myös niin tekevät (luonnollisesti sitä vähemmän mitä korkeammalla olevat organisaatiopuussa).
Ja olen ollut organisaatioissa joissa jo alimmalla tasolla oleva tiimimanageri oli ihan puhdas PHB ja sille raportoi vielä toinen "RnD" manageri (ilman alaisia) joka oli teknisesti yhtä vitun turha.

 

[Incredible Buff]

Kyllähän se valitettavasti niin on että soft-skillit ovat yhä isommassa roolissa IT-alalla(kin). Hiljainen koodariautisti ei välttämättä pääse alkuportista sisään, ellei sitten tunne oikeita henkilöitä yrityksissä.

Juu tämähän on totta. Toisaalta niitä hiljaisia koodariautistejakin on monenlaisia. Itse olen toki töissä konsulttitalossa, jossa kaikenmaailman sosiaalinen hapatus on ehkä vielä keskimääräistä tärkeämmässä roolissa, mutta siinä vaiheessa, kun olet jutellut kymmenen minuuttia kaverin kanssa niitä näitä it-alasta ja devauksesta ilman katsekontaktia ja saamatta yli kahden sanan vastauksia niin alkaa olla selvää, että ei kannata mennä enää yhtään pidemmälle, vaikka kaverista saattaisi nähdäkin, että se ymmärtää asioista.

 

[FireFly Renaissance]

Hyviä näkemyksiä, kiitos niistä. Sanoisin tuohon mainittuun että hain haastateltuun paikkaan yhdistelmällä C++/Qt ja kiinnostuksena käyttöliittymät. Ainakin tuon haastattelun perusteella vaikutti, että vastaavan kiinnostuksen omaavat saattaa karsiutua tehokkaasti pois, kun siellä pönöttää tekninen insinööri tenttaamassa assembly-debuggauksesta. Toki kuten sanoin niin en itsekään hoitanut haastattelua hyvin, mutta kuitenkin tällainen havainto.

Tentattiinko vai oliko se oma mielikuva? Oma protip olisi, että haastatteluun kannattaa suhtautua mielenkiintoisena keskusteluna toisen alan kollegan kanssa (Jos ei joudu juttelemaan jollekin HR:lle joka ei tiedä teknisistä asioista mitään). Kun on kiinnostunut ja kyselee ja kertoo omia näkemyksiä niin saa tuotua sitä omaa osaamista esiin ilman, että tilaisuus on kovin väkinäistä eikä tarvi alkaa valehtelemaan tai pätemään. Työhaastattelu ei ole koe. Paitsi, jos sen pitää joku rekrytointikonsultti tai muu "ammattilainen", jolloin se on todennäköisesti ihan pelleilyä, ja voit miettiä haluatko edes olla siellä töissä

Jos ymmärtää jotain assemblystä tai ei niin ymmärrä ja haastattelija siitä kysyy voi ihan hyvin alkaa omilla tiedoilla kyselemään mitä tarkoitetaan, mistä puhutaan ja mihin sitä esimerkiksi tässä tehtävässä tarvii. Sitä ei kannata pelätä. Käyttäydy kuin oikeastaan olisit jo osa tiimiä ja yhteinen halu on ratkaista ongelmia. Jos siinä samalla pääsee vielä vähän buffaamaan sitä missä on itse oikeasti hyvä niin se on bonusta päälle.

Tämä myös vähentää sitä jännitystä, ja tekee hommasta helpompaa ja luonnollisempaa.

 

[SampoTexaa]

Ettei vain olisi sattunut erikoistapaus kohdalle? Omat kokemukset ovat sellasia etten ole vielä koskaan nähnyt IT/dev-manageria joka koodaisi. Lieneekö sitten kyseessä ollut arkkitehdin paikka?

Vähän vaikutti että aikaisemmin ollut yhden miehen show ja halutaan jatkaa samalla kaavalla. Varmasti arkkitehdin hommatkin olisi kuulunut.

 

[Randomizer]

Tentattiinko vai oliko se oma mielikuva? Oma protip olisi, että haastatteluun kannattaa suhtautua mielenkiintoisena keskusteluna toisen alan kollegan kanssa (Jos ei joudu juttelemaan jollekin HR:lle joka ei tiedä teknisistä asioista mitään). Kun on kiinnostunut ja kyselee ja kertoo omia näkemyksiä niin saa tuotua sitä omaa osaamista esiin ilman, että tilaisuus on kovin väkinäistä eikä tarvi alkaa valehtelemaan tai pätemään. Työhaastattelu ei ole koe. Paitsi, jos sen pitää joku rekrytointikonsultti tai muu "ammattilainen", jolloin se on todennäköisesti ihan pelleilyä, ja voit miettiä haluatko edes olla siellä töissä

Jos ymmärtää jotain assemblystä tai ei niin ymmärrä ja haastattelija siitä kysyy voi ihan hyvin alkaa omilla tiedoilla kyselemään mitä tarkoitetaan, mistä puhutaan ja mihin sitä esimerkiksi tässä tehtävässä tarvii. Sitä ei kannata pelätä. Käyttäydy kuin oikeastaan olisit jo osa tiimiä ja yhteinen halu on ratkaista ongelmia. Jos siinä samalla pääsee vielä vähän buffaamaan sitä missä on itse oikeasti hyvä niin se on bonusta päälle.

Tämä myös vähentää sitä jännitystä, ja tekee hommasta helpompaa ja luonnollisempaa.

Tässä on se homman juju. Kun tämän aikanaan tajusi niin haastatteluihin on mennyt jopa ihan innolla keskustelemaan, meni syteen tai saveen, tai jos paikka ei paljastukkaan kovin mielenkiintoiseksi. Jos muuttaa asenteeksi että siellä keskustellaan ammattilaisten kanssa mielenkiintoisista aiheista, homma onnistuu automaattisesti paremmin. Joskus olen myös tohtinut jopa kyseenalaistamaan jotakin mitä ovat siellä sanoneet että miten heidän firmassa tehdään yleensä asioita. Toki tässäkin kokemuksien myötä harjaantuu.

 

[Keksi]

Ettei vain olisi sattunut erikoistapaus kohdalle? Omat kokemukset ovat sellasia etten ole vielä koskaan nähnyt IT/dev-manageria joka koodaisi. Lieneekö sitten kyseessä ollut arkkitehdin paikka?

Itselläni on useimmiten tullut vastaan seuraavanlaiset managerit:

Perusmanageri: Hoitaa hommansa hyvin, tekee useasti ylitöitä ja istuu 90% päivästään saharaa kuivemmissa palavereissa kommunikoimassa eri osastojen/yksiköiden edustajien kanssa. Hoitaa dailyt ja weeklyt.

Turha fätti manageri: Täysin turha tyyppi ja suhteellisen pihalla tekemisestä. Kontribuutio jotain nollan ja haitallisen väliltä. Forwardoi ylemmän johdon pyyntöjä devtiimille ja välillä jakaa jotain Vergen, TechCrunchin yms. linkkejä Slack:ssa. Päässyt asemaansa suhteiden kautta tai sitten ollut firmassa +10v tms. ja pakolla siirretty johtotehtäviin.

Turha fätti manageri joka haluaa olla tärkeä: Kuten edellinen tapaus, mutta haluaa kovasti näyttää tärkeältä, kiireiseltä ja siltä että olisi oikeasti puikoissa kiinni. Käytännössä siis tekee paljon haitallisia tai turhia aloitteita, mikromanageroi ja rasittaa devtiimiä turhalla paskalla.

Aika hyvä listaus, omalle kohdalle sattunut vielä näitä tapauksia:

Excel-manageri/johtaja: Johtaa alaisiaan sähköpostin välityksellä eikä edes tiedä ketkä kaikki hänen tiimiinsä/osastoon kuuluvat, mitä he tekevät työkseen, tai tuntisi kaikkia edes ulkonäöltä. Rekrytoi vanhoja tuttujaan ohi HR:n ja soveltuvuustestien, jotka eivät ao. positiossa mitenkään voi onnistua, kun eväät eivät heillä siihen riitä.

Kiinnostunut vain kustannuksista ja asioiden johtamisesta, eikä tiedä mitään ihmisten johtamisesta. Viihtyy enemmän asiakkaan luona polkemassa hintoja alaspäin kuin konttorilla johtamassa alaisiaan.

Työviihtyvyys alaisilla yleensä kovin huono, joten lähtijä-ja tulijakaruselli pyörii vinhasti, eikä siten ole kokeneita enää perehdyttämässä kunnolla uusia ja vika on aina alaisissa, kun systeemit ovat pitkään rikki ja asiakas reklamoi asiasta.

 

[jarhu]

Devauspuolen managereista en tiedä, mutta näin muuten IT-puolella yleisesti riippunee todella paljon tehtävästä työstä. Omassa työssä esimies istuu eri paikkakunnalla eikä puutu itse työhön juuri ollenkaan. Itse en koe tarvitsevani manageria muuhun kuin erilaisten esteiden raivaamiseen tarvittaessa ja hallinnollisiin asioihin.

Työ on itsenäistä asiantuntijatyötä ja homma on toiminut usean vuoden hyvin. Palveluiden/Tuotteiden asioita käydään sitten läpi kuukauden tai parin välein ryhmässä läpi etäpalavereissa. Esimiehen suunnalta tulee välillä ne curve ballit ja yksittäiset spesiaalikeissit jos tarvii panoksia tarvii keskittää johonkin tarpeen vaatiessa.

Näkisin asian niin, että erilaisissa työryhmissä tarvitaan myös erilaisia esimiehiä. Toisissa tiimeissä tarvitaan enemmän työnohjausta ja aktiivisempaa otetta.