IT-alan työpaikat

[yero]

Tälläinen kysymys olisi että onko IT-alan työpaikkoihin minkäänlaista mahdollisuutta päästä työskentelemään oppisopimuksella, vai onko ajatus ihan tuhoontuomittu?
[...]
Tietokoneiden ja erilaisten softien kanssa on tullut näperrettyä koko ikä, mutta itse koodaamisesta osaan parhaimmillaankin alkeet. Motivaatio on korkea ja opin nopeasti, mutta riittääkö se?

No joo yleensä vaaditaan jotain alan opintoja. Näköjään joku kouluttaa oppisopimuksella datanomiksi.

Oppisopimuskoulutus - Sulava

www.sulava.com

Meillä on ollut juuri datanomiopiskelija oppisopimuksella, (ihan oppilaitoksesta, ei tuolta Sulavalta). Opiskelija oli kovin tyytyväinen, vaikka suuntautuikin sitten vähän muulle alalle eikä jäänyt firmaan. Kovasti oli sitä mieltä, että ilman datanomin tutkintoa ei olisi työllistynyt unelmapaikkaansa.

Yrityksen kannalta nämä ovat vähän hankalia, kun yksi opettelee ja toinen neuvoo, niin kummankaan työtä ei voi laskuttaa.

Mutta periaatteessa toisenkin kerran voisi ottaa, kriteerit hakijalle täytyy kyllä laittaa korkealle ja ihan nollatasosta ei voi lähteä, jos aikoo oikeasti olla kelpo koodari koulutuksen jälkeen. Vaikka motivaatio olisi korkea ja oppisi nopeasti, niin sitä opittavaa on oikeasti paljon, ennenkuin osaaminen on sellaisella tasolla, että pystyy asiakasprojektissa suhteellisen itsenäisesti tekemään jotain, mistä asiakas suostuu maksamaan. Toki on aina muutakin tunkkausta kuin koodausta.

Jos joku on oikeasti kiinnostunut, niin mulle voi laittaa yv. Pirkanmaa.

En tiedä miksi, mutta saksankielisessä Euroopassa oppisopimuksella IT-opiskelu on ihan normaalia toimintaa. Firmoilla on paljon omia sisäisiä ohjelmia tuohon.

Tuolla käsittääkseni oppisopimus on muutenkin suosiossa. Pidän kyllä tuollaista mestari - kisällimallia lähtökohtaisesti erinomaisena tapana organisoida koulutus, erityisesti ammatikoulutuksessa.

 

[qtba]

Mutta periaatteessa toisenkin kerran voisi ottaa, kriteerit hakijalle täytyy kyllä laittaa korkealle ja ihan nollatasosta ei voi lähteä, jos aikoo oikeasti olla kelpo koodari koulutuksen jälkeen. Vaikka motivaatio olisi korkea ja oppisi nopeasti, niin sitä opittavaa on oikeasti paljon, ennenkuin osaaminen on sellaisella tasolla, että pystyy asiakasprojektissa suhteellisen itsenäisesti tekemään jotain, mistä asiakas suostuu maksamaan. Toki on aina muutakin tunkkausta kuin koodausta.

Tämä on kyllä totta. Pelkkään versionhallinnan käyttöön voi vierähtää aika pitkä tovi, jos konseptin joutuu opettelemaan ihan puhtaalta pöydältä. Noissa voi kuitenkin olla mahdollisuus sotkea asioita ihan kunnolla ja merge/virhetilanteet/yms voi tuntua välillä aika kryptisiltä.

 

[kaarlos]

Tämä on kyllä totta. Pelkkään versionhallinnan käyttöön voi vierähtää aika pitkä tovi, jos konseptin joutuu opettelemaan ihan puhtaalta pöydältä. Noissa voi kuitenkin olla mahdollisuus sotkea asioita ihan kunnolla ja merge/virhetilanteet/yms voi tuntua välillä aika kryptisiltä.

Aika huonosti on järjestetty versiohallinnan push-oikeudet, jos devaajalla on suora mahdollisuus sotkea mitään muuta kuin omaa kehityshaaraansa ilman pull requestia.

 

[qtba]

Aika huonosti on järjestetty versiohallinnan push-oikeudet, jos devaajalla on suora mahdollisuus sotkea mitään muuta kuin omaa kehityshaaraansa ilman pull requestia.

Kyllähän ihan vasta-alkajalla riittää siinä omassakin haarassa sotkettavaa, lähinnä siihen viittasin. Mutta olen itse myös kokenut yhden tapauksen, jossa masteriin sai puskea ihan vapaasti ilman pullareita tai push-hookeja. Ei mikään iso projekti tai työnantaja, mutta tuskin aioa laatuaan maailmalla.

 

[yero]

Aika huonosti on järjestetty versiohallinnan push-oikeudet, jos devaajalla on suora mahdollisuus sotkea mitään muuta kuin omaa kehityshaaraansa ilman pul
l requestia.

Jos tuo on kriteeri, niin lähes aina on oikeudet "aika huonosti".

Mutta olen itse myös kokenut yhden tapauksen, jossa masteriin sai puskea ihan vapaasti ilman pullareita tai push-hookeja. .

"ei saa" ja "ei pysty" on eri asioita, hyvin usein tyydytään "ei saa" ilman, että rakennetaan jotain oikeuksien rajoituksia devaajille.

 

[chrisekh]

No meilla on ainakin niin eri repoa ja ei niihin pienempiin mitaan saantoja tehda. Mina vasailen omia valppia ja pyyttoni tyokaluja omaan repoon ja ei siella ole kuin toivomus etta multa kysytaan review ennen pushia masteriin. Sitten ne isommat projektit on erikseen missa vaaditaan pari henkiloa + arkkitehti katselmoimaan.

Mutta takaisin aiheeseen niin nuo versihallinta tyokalut ja ajatusmaailma on kylla hyva kayda lavitse kaikkien kanssa jotka tulevat taloon. Varsinkin jos kokemus on vain SVN jossa kaikki pokkivat trunkkiin vuoron peraan. En muista pariin vuoteen ketaan taloon tullutta jota ei olisi tarvinnut kouluttaa ihan perus feature branchi malliin.

 

[kaarlos]

"ei saa" ja "ei pysty" on eri asioita, hyvin usein tyydytään "ei saa" ilman, että rakennetaan jotain oikeuksien rajoituksia devaajille.

Rakentaminen kuulostaa paljon työläämmältä kuin mitä se on, kun todellisuudessa voi käydä klikkaamassa pelkän Bitbucketin / vastaavan versiohallintakilkkeen puolelta whitelistiin pelkän järjestelmäkäyttäjän.

"Ei saa" on aina huono ratkaisu tämän tyyppisiin asioihin, koska se ei poista mahdollisuutta että joku asiaansa ymmärtävä tekijä vahingossa hääräilee väärässä branchissa. En ymmärrä miksi kellään pitäisi olla oikat pushata sinne pääkehityshaaraan, ellei sitten kyseessä ole joku yhden miehen projekti - ja itse asiassa miehen projektissakin on perusteltua tehdä muutokset (katselmoimattomilla) pull requesteilla ihan vaan että saa pakotettua kaikki commitit automaatiobuildin kautta. Muutoin buildit voivat olla punaisella kun itse työntelee random testaamattomia committeja sisään.

 

[yero]

"Ei saa" on aina huono ratkaisu tämän tyyppisiin asioihin, koska se ei poista mahdollisuutta että joku asiaansa ymmärtävä tekijä vahingossa hääräilee väärässä branchissa.

"Ei saa" on monesti parempi vaihtoehto kuin, että joku kokonaisuutta ymmärtämätön jantteri vääntelee rajoituksia päälle omien riskianalyysiensä pohjalta. Ite tässä yhdessä alihankintakeississä odotellut, että koska pääsee tekemään asiakkaan kesäkuun alussa kiireisenä toivomaa fiksausta, ilmeisesti elokuussa lomakauden jälkeen... Aiemassa proggiksessa yksi sankari väänsi asiakkaalle käyttöön ja ylläpitoon siirtyvästä softasta 2/3 admin ominaisuuksista kiinni, ainoastaan hänellä itsellään olevien tunnusten taakse.

 

[Wemps]

Rakentaminen kuulostaa paljon työläämmältä kuin mitä se on, kun todellisuudessa voi käydä klikkaamassa pelkän Bitbucketin / vastaavan versiohallintakilkkeen puolelta whitelistiin pelkän järjestelmäkäyttäjän.

"Ei saa" on aina huono ratkaisu tämän tyyppisiin asioihin, koska se ei poista mahdollisuutta että joku asiaansa ymmärtävä tekijä vahingossa hääräilee väärässä branchissa. En ymmärrä miksi kellään pitäisi olla oikat pushata sinne pääkehityshaaraan, ellei sitten kyseessä ole joku yhden miehen projekti - ja itse asiassa miehen projektissakin on perusteltua tehdä muutokset (katselmoimattomilla) pull requesteilla ihan vaan että saa pakotettua kaikki commitit automaatiobuildin kautta. Muutoin buildit voivat olla punaisella kun itse työntelee random testaamattomia committeja sisään.

"Ei saa" on monesti parempi vaihtoehto kuin, että joku kokonaisuutta ymmärtämätön jantteri vääntelee rajoituksia päälle omien riskianalyysiensä pohjalta. Ite tässä yhdessä alihankintakeississä odotellut, että koska pääsee tekemään asiakkaan kesäkuun alussa kiireisenä toivomaa fiksausta, ilmeisesti elokuussa lomakauden jälkeen... Aiemassa proggiksessa yksi sankari väänsi asiakkaalle käyttöön ja ylläpitoon siirtyvästä softasta 2/3 admin ominaisuuksista kiinni, ainoastaan hänellä itsellään olevien tunnusten taakse.

Meidän firma tekee eräälle toiselle firmalle alihankintana erästä asiakasprojektin osa-aluetta. Nyt neljä kuukautta on ollut yksi korjaustyö tekemättä, kun joku joskus on lukinnut eräät oikeudet johonkin narniaan ja lähtenyt sittemmin firmasta, eivätkä nykyisin töissä olevat IT-helpdeskin työntekijät tiedä mistä tai miten noita oikeuksia voisi antaa. Dokumentaatiota ei ilmeisesti ole lainkaan. Ongelmat ovat siis tämän yrityksen päässä jolle teemme alihankintaa, mutta sitten varsinainen asiakas valittaa meille kun ei asiaa ole saatu korjattua

 

[kaarlos]

"Ei saa" on monesti parempi vaihtoehto kuin, että joku kokonaisuutta ymmärtämätön jantteri vääntelee rajoituksia päälle omien riskianalyysiensä pohjalta. Ite tässä yhdessä alihankintakeississä odotellut, että koska pääsee tekemään asiakkaan kesäkuun alussa kiireisenä toivomaa fiksausta, ilmeisesti elokuussa lomakauden jälkeen... Aiemassa proggiksessa yksi sankari väänsi asiakkaalle käyttöön ja ylläpitoon siirtyvästä softasta 2/3 admin ominaisuuksista kiinni, ainoastaan hänellä itsellään olevien tunnusten taakse.

Ehkäpä väärä ketju aiheelle, mutta edelleen väitän että pushausoikeudet pääkehitysbranchiin on ainoastaan huono idea. Aika volatiilia kehitystä jos tosta vaan voi puskea oleellisen haaran punaiseksi tai pahimmassa tapauksessa force pushata jotain vanhaa versiota päälle - joten väittäisin että ainakin force pushaus on estettävä muualla kuin kehityshaaroissa.

Jos on tulossa lomakautta, niin sitten voi laskea tarvittavien katselmoijien määrän nollaan ja mergetä PR:t itse. Vaihtoehtoisesti voi pitää sitten vaikka ympäri vuoden katselmoijat nollassa ja sopia yhteisen pelisäännöstön katselmoijien määrille riippuen muutosten sisällöstä (bugifiksi vai feature).

Itse olen joutunut / saanut tuotetalossa CI-prosesseja rukkailla ja olen tullut siihen tulokseen, että kaikki pääsee helpoimmalla kun antaa vaan sen Jenkinsin tehdä mahdollisimman ison osan asioista jotka normaalisti voisi jättää devaajienkin tehtäväksi (code stylet / formatointi, automaatiotestien ajaminen, ...) Mikään ei ole niin turhauttavaa kuin kommentoida sadatta kertaa samasta muotoilu / tyylivirheestä pull requestista sen sijaan että buildi on punaisena ja devaaja voi itse setviä ongelmansa.

 

[Illotus]

Ehkäpä väärä ketju aiheelle, mutta edelleen väitän että pushausoikeudet pääkehitysbranchiin on ainoastaan huono idea. Aika volatiilia kehitystä jos tosta vaan voi puskea oleellisen haaran punaiseksi tai pahimmassa tapauksessa force pushata jotain vanhaa versiota päälle - joten väittäisin että ainakin force pushaus on estettävä muualla kuin kehityshaaroissa.

Samaa mieltä. Aika harvakseltaan sitä töissä tekee niin merkityksentöntä koodia, että masteriin pushaus olisi mitenkään mielekästä olla sallittua. Se on kerran useampaan vuoteen, että on jonkun sellaisen fiksin työntäminen edessä, että ei saisi pr approvea samaa kuumaa ja olisi pakko saada kama masteriin.

Lähtökohtaisesti mielestäni kaikki oikeudet on huomattavasti järkevämpää antaa vaikka rikkinäisen prosessin jälkeen viiveellä, kuin pitää normina tilannetta, jossa kuka tahansa devari saa sotkettua masterin. Tokihan turhauttaa kaikki odottelu, mutta yleensä firman näkökulmasta näin on huomattavasti järkevämpää.

 

[Trotor]

Samaa mieltä. Aika harvakseltaan sitä töissä tekee niin merkityksentöntä koodia, että masteriin pushaus olisi mitenkään mielekästä olla sallittua. Se on kerran useampaan vuoteen, että on jonkun sellaisen fiksin työntäminen edessä, että ei saisi pr approvea samaa kuumaa ja olisi pakko saada kama masteriin.

Lähtökohtaisesti mielestäni kaikki oikeudet on huomattavasti järkevämpää antaa vaikka rikkinäisen prosessin jälkeen viiveellä, kuin pitää normina tilannetta, jossa kuka tahansa devari saa sotkettua masterin. Tokihan turhauttaa kaikki odottelu, mutta yleensä firman näkökulmasta näin on huomattavasti järkevämpää.

Näistä keskustellessa kannattaa muista että ihan kaikki suomen devaajat ei ole töissä niin isoissa taloissa tai projekteissa että niitä laaduntarkkailijoita tai "niitä muita" olisi tarjolla tekemään mitään. Tai että olisi edes käytössä samat toolchainit tai edes määritellyt työkalut. Mulla on ollut vähän niin että Ite on säädettävä käytännössä kaikki jos haluaa että tulee tehtyä. Tekisivät edes jotain pusheja johonkin, mut jää perkele levylle jos ei vierestä kannusta.

 

[yero]

Lähtökohtaisesti mielestäni kaikki oikeudet on huomattavasti järkevämpää antaa vaikka rikkinäisen prosessin jälkeen viiveellä, kuin pitää normina tilannetta, jossa kuka tahansa devari saa sotkettua masterin. Tokihan turhauttaa kaikki odottelu, mutta yleensä firman näkökulmasta näin on huomattavasti järkevämpää.

Tätä juuri tarkoin, kun kirjoitin "joku kokonaisuutta ymmärtämätön jantteri vääntelee rajoituksia päälle omien riskianalyysiensä pohjalta".

Se odottelu ei ole pelkästään turhauttavaa, vaan maksaa yritykselle selvää rahaa mahdollisesti 100+ e/tunti ja asiakassuhteita, kun kriittisiä korjauksia ei vaan saada. Sen rinnalla se, että joudutaan joka kolmas vuosi hälyttämään seniori korjaamaan masteria, ei välttämättä maksa yhtään mitään. Asiakkaat ei lähde sen takia, että masteri hajoaa, vaan sen takia, että hommat ei etene, kun alihankkija odottaa kolmatta viikkoa oikeuksia.

Toki tilanteet on erilaisia riippuen puhutaanko pankin tuotantojärjestelmästä vai Villen kalakaupan nettisivusta.

 

[FireFly Renaissance]

Lähtökohtaisestihan mistään ei kannata tehdä yhtään monimutkaisempaa kuin on aivan pakko. Jokainen tekee omaa palikkaansa ja omia tiedostojansa ja kukaan ei koske kenenkään muun palikoihin ja tiedostoihin on se ideaalitilanne. Jos mahdollista, palikat on vielä itsenäisiä eikä tarvi kääntää muiden palikoiden kanssa. Vaikka siinä olisi minkälaista versionhallintaa tai robottia, niin ei tuosta ideaalista kannata silti poiketa yhtään enempää kuin on ihan pakko. Ja toisaalta niillä versiohallinnoilla ja muilla ei tule myöskään vaikeuttaa tuota ideaalia yhtään enempää kuin on pakko. Kaikki ylimääräinen on kuitenkin aina overheadia mitä jonkun(tm) pitää tehdä.

Dokumentaatiot on toki hyvä olla siltä varalta, että tarvittaessa voidaan myös vaihtaa vastuuhenkilöä, mutta sen ei pitäisi olla mikään jatkuva tilanne.

 

[Illotus]

Tätä juuri tarkoin, kun kirjoitin "joku kokonaisuutta ymmärtämätön jantteri vääntelee rajoituksia päälle omien riskianalyysiensä pohjalta".

Se odottelu ei ole pelkästään turhauttavaa, vaan maksaa yritykselle selvää rahaa mahdollisesti 100+ e/tunti ja asiakassuhteita, kun kriittisiä korjauksia ei vaan saada. Sen rinnalla se, että joudutaan joka kolmas vuosi hälyttämään seniori korjaamaan masteria, ei välttämättä maksa yhtään mitään. Asiakkaat ei lähde sen takia, että masteri hajoaa, vaan sen takia, että hommat ei etene, kun alihankkija odottaa kolmatta viikkoa oikeuksia.

Niin, lähtökohtaisestihan se riippuu siitä, että tarkoittaako tuotantohaaraan pushi sitä, että tavara menee tuotantoon. Jos menee ja prosessi on kunnossa, niin harvemmin myöskään tarvitaan niitä kakka tuulettimessa -korjauksia.

Odottelun kustannukset riippuvat myös pitkälti siitä mitkä ovat vastuut. Itse olen tottunut siihen, että odottelu on yleensä asiakaslähtöistä, jolloin siinäpä se maksajakin on. Toki alihankkijoissakin lienee moniongelmaisia, mutta harvenemaan päin.

Siis olen kyllä samaa mieltä, että jos oikeusia johonkin tarpeelliseen random-järjestelmään joutuu odottelemaan viikkotolkulla, niin jossain on vikaa, mutta yleisesti ottaen rajoittavampi kanta on järkevämpi kuin sallivampi.

 

[finWeazel]

Voihan sen masteriin suoraan puskemisen estää ja antaa kiertotien sillä, että valitut tai jopa kaikki saavat mergeta PR:nsa ilman katselmointia. Menee kuitenkin työkalun kautta niin kukaan ei vahingossa omalta koneelta puske jotain roskaa masteriin.

 

[poksi]

Onko ihan hassu idea hankkia esim. raspberry pi it-alan töiden ”harjoitteluun”? Eli perus linux konffausta, nodea, dockeria ym. Kait tuon kanssa voisi samalla treenailla kyberturvajuttujakin?

 

[chrisekh]

Onko ihan hassu idea hankkia esim. raspberry pi it-alan töiden ”harjoitteluun”? Eli perus linux konffausta, nodea, dockeria ym. Kait tuon kanssa voisi samalla treenailla kyberturvajuttujakin?

no eiko joku vanha lappari oli hauskempi aloittaa mutta ihan samat jutut saat raspilla tehtya.

 

[hjjm123]

Lainataas vähän tuota linux academy vinkkiä

Moro,

Kaveri valmistu tuossa vähään aikaa sitten datanomiks ja haluis siirtyä tietoturva-alalle ja ehkä vieläpä tarkemmin valkohattuhakkerin tehtäviin. Katsottiin nopeasti niin Suomesta ei oikein näyttäisi olevan alaan liittyvää AMK-koulutusta olevan tarjolla joten mietittiin että olisikohan parempi suorittaa jotakin näitä udemy / codeacamy / linuxacademy kursseja? Noissa vois saada käsiä saveen enemmän ku perus IT-tradenomikursseilla ja näyttää ainaki serteillä työnantajalle et on jotain relevanttia tehnyt. Toki varmaa parasta näyttöä olisi jos pystyisi esittämään että on jo löytänyt haavoittuvuuksia yritysten järjestelmistä, mutta varmaan serteilläkin pääsisi alkuun

Tässä pari nyt mitä tuli vastaan:

Complete Ethical Hackers Beginner - Advanced Training Course

Learn how to do ethical hacking, penetration testing, web testing, and wifi hacking using kali linux!

www.udemy.com

Online Courses - Learn Anything, On Your Schedule | Udemy

Udemy is an online learning and teaching marketplace with over 213,000 courses and 57 million students. Learn programming, marketing, data science and more.

www.udemy.com

Browse Training

Browse our 1,800+ instantly-deployable labs. Each lab puts learners in live environments that simulate real-world cloud challenges related to AWS, Azure, GCP, DevOps, Linux and more.

linuxacademy.com

Itse suosittelen tekemään port swiggerin labroja ja sitä kautta tutustua web-pentestaukseen ja tehdä vaikka H1 bug bountyjä, lisäksi Hack the box on hyvä alusta oppimiseen. Lisäksi voi suorittaa jonkun "hands on" kurssi ja sertti yhdistelmän esim: eCPPTv2 tai OSCP jos rahkeet riittää.

 

[Randomizer]

Onko ihan hassu idea hankkia esim. raspberry pi it-alan töiden ”harjoitteluun”? Eli perus linux konffausta, nodea, dockeria ym. Kait tuon kanssa voisi samalla treenailla kyberturvajuttujakin?

Virtuaalimasiinat ajaa saman asian jos haluat opetella Linux-konffailua, Dockeria jne. mutta jos haluat tutustua enemmän sulatettuihin nii Raspit ovat hyviä vehkeitä kyllä.

 

[91danger91]

Onko ihan hassu idea hankkia esim. raspberry pi it-alan töiden ”harjoitteluun”? Eli perus linux konffausta, nodea, dockeria ym. Kait tuon kanssa voisi samalla treenailla kyberturvajuttujakin?

Ite laitoin tänää just raspilla owncloudin pystyy, hyvin näyttäis pelittävän, pääsee ulkoverkostakin sisään Eli tosiaan kyl mä ehkä itekki käyttäisin raspia servulla leikkimiseen, devaukset sitten läppäril. Tosin uusin raspi 2-4 gigal muistia riittää kyl melkee webbiselailuunkin

 

[zomeone]

Onko ihan hassu idea hankkia esim. raspberry pi it-alan töiden ”harjoitteluun”? Eli perus linux konffausta, nodea, dockeria ym. Kait tuon kanssa voisi samalla treenailla kyberturvajuttujakin?

Olen monesti haastatteluissa tietoturvapuolelle suositellut kesätyöpaikkaa hakeneille raspin hankkimista, mikäli sellainen ei ole ollut ennestään tuttu.
Matalalla kynnyksellä (ja hankintakuluilla) pääsee puuhastelemaan.

Internetin ihmeellisestä maailmasta löytyy paljon step-by-step ohjeita tekemiseen. Kunhan vain oikeasti sisäistää asiat, eikä vaan päättömästi kliksuttele ja ajele komentoja.

Perushommat ml. jonkun verran vaikka Unix komentoja saa samalla haltuun. Erilaisia projektia vaan värkkäilemään ja ennenkaikkea sisäistää tekemänsä, niin on taas vähän paremmat lähtökohdat seuraaviin haasteisiin.

 

[oongee]

Jos ei ole erityistä intohimoa suunnata laiteläheiselle/embedded/jne. puolelle niin ennemmin suosittelisin free tier -tilin perustamista vaikkapa AWS:ään (tai Azure tai GCP) ja harjoittelua siellä, niin tulee myös se pilvi-puoli siinä ohessa tutuksi. Suuri osa potentiaalisista työnantajista tähyää kuitenkin sinne pilven suuntaan nykyaikana. Mutta on toki edelleen myös firmoja jotka haluavat omistaa rautaa (vähenevissä määrin).

Molemmat vaihtoehdot ovat toimivia.

 

[Paapaa]

Jos ei ole erityistä intohimoa suunnata laiteläheiselle/embedded/jne. puolelle niin ennemmin suosittelisin free tier -tilin perustamista vaikkapa AWS:ään (tai Azure tai GCP) ja harjoittelua siellä, niin tulee myös se pilvi-puoli siinä ohessa tutuksi. Suuri osa potentiaalisista työnantajista tähyää kuitenkin sinne pilven suuntaan nykyaikana. Mutta on toki edelleen myös firmoja jotka haluavat omistaa rautaa (vähenevissä määrin).

Molemmat vaihtoehdot ovat toimivia.

Tämä. Ihan riippumatta siitä, hommaako Raspberry Pi:n, kannattaa niitä taitoja harjoitella myös oikeassa pilvipalvelussa. AWS:n free tier antaa hyvän temmellyskentän harjoitella relevantteja taitoja pikkurahalla ja noille taidoille on varmasti kysyntää.

 

[poksi]

Kannattaako itseensä sijoittaa senverta että maksaisi aws ja azuren perus-sertit? Noihin kun vielä yhdistelisi jotain omia projekteja niin luulisi että töitä irtoaisi

 

[Macu]

Kannattaako itseensä sijoittaa senverta että maksaisi aws ja azuren perus-sertit? Noihin kun vielä yhdistelisi jotain omia projekteja niin luulisi että töitä irtoaisi

En usko, että niistä maksamisesta saat mitään hyötyä verrattuna siihen, että laitat githubiin jotain projektia, missä oikeasti käytät niitä tekniikoita.

Tai no, saat linkedIniin jotain postailtavaa todistuksista

 

[Paapaa]

Kannattaako itseensä sijoittaa senverta että maksaisi aws ja azuren perus-sertit? Noihin kun vielä yhdistelisi jotain omia projekteja niin luulisi että töitä irtoaisi

Kyllä varmaan osoitus osaamisesta omien projektien muodossa plus serti on ihan positiivinen asia työnantajalle. Vaikea sanoa, paljonko kannattaa maksaa. Kurssi maksaa $10 (esim. Stephane Maarekin kurssit Udemyssä) - $50 (Adrian Catrillin kurssit omilla sivuillaan) ja itse serti $100-$150 (AWS) - jos tekee useamman niin vain ensimmäisestä maksetaan täysi hinta, muista 50%. SAA-C02 on hyvä perusserti, jolla osoittaa että AWS:n perusteet on hanskassa, eikä mene sormi suuhun ihan heti. Ei se toki mitään työkokemusta anna, joten oma projekti on hyvä lisä. Free tierilläkin saa jo jotain pystyyn.

Azure ei ole mulle tuttu.

 

[zepi]

Kannattaako itseensä sijoittaa senverta että maksaisi aws ja azuren perus-sertit? Noihin kun vielä yhdistelisi jotain omia projekteja niin luulisi että töitä irtoaisi

Itse rekrytoinneissa mukana olevana näkisin, että noista alkupään serteistä voi olla apua sen ensimmäisen botin / headhunterin / HR-ihmisen läpäisyssä kun haluat sen CV:si päätyvän jonkun oikeasti rekrytoinnista päättävän luettavaksi.

Missään fiksummassa firmassa pidetään kuitenkin tekninen haastattelu, jossa kysellään tarkemmin osaamisesta (yleensä asiasta tietävien toimesta) + monessa paikassa arvostetaan varmasti jos githubissa on toimivat esimerkit siitä miten olet AWS:ää käyttänyt.

Ellei sitten tosiaan haeta aivan junioria jolloin oletus on, ettei juurikaan käytännön osaamista ole. Silloinkin toki osaamisen oikea näyttäminen helpottaa erottautumaan muiden serttien heiluttelijoiden joukosta.

 

[Paapaa]

Toisaalta, sertin tekemällä myös oppii. Pilvipalvelut mahdollistavat saman asian tekemisen aika monella eri tavalla, kalliisti tai halvalla, tietoturvallisesti tai -turvattomasti, vikasietoisesti tai sietämättä jne. Hyvä sertikurssi opettaa paitsi läpäisemään sen sertikokeen, myös ihan oikeita asioita ja parhaita käytäntöjä - ja suodattaa valtavasta infomassasta jonkun hallittavan kokonaisuuden. Musta serti voi olla ihan hyvä tapa oppia pilvipalvelua. Itse töhöilemällä voi tehdä monta asiaa päin persettä.

 

[Randomizer]

AWS Certified Developer – Associate (DVA-C01)

You will learn how to develop, deploy and debug cloud-based applications using AWS. By the end of this path, you will have mastery and experience with all of the major services in AWS.

www.pluralsight.com

Ton läjän käy esimerkiksi AWS:stä niin saa jo mukavan raapaisun perusjutuista.

 

[Paapaa]

AWS Certified Developer – Associate (DVA-C01)

You will learn how to develop, deploy and debug cloud-based applications using AWS. By the end of this path, you will have mastery and experience with all of the major services in AWS.

www.pluralsight.com

Ton läjän käy esimerkiksi AWS:stä niin saa jo mukavan raapaisun perusjutuista.

Mä voisin suositella puolestani tämän jampan kursseja (oli aiemmin Linux Academyllä, ei enää), kattavat enemmän kuin tarvitaan ja jotenkin niistä näkyy myös oma kokemus alalta:

Homepage

learn.cantrill.io

Ja jos on budjetti tiukoilla, niin nämä (ovat Udemyssä, luokkaa $10):

Courses Datacumulus

courses.datacumulus.com

Ja harjoitustentit täältä:

Home

Welcome to the Tutorials Dojo PortalWe offer the best AWS, Azure and other IT certification exam reviewers in different training modes to help you pass

portal.tutorialsdojo.com

 

[zepi]

Toisaalta, sertin tekemällä myös oppii. Pilvipalvelut mahdollistavat saman asian tekemisen aika monella eri tavalla, kalliisti tai halvalla, tietoturvallisesti tai -turvattomasti, vikasietoisesti tai sietämättä jne. Hyvä sertikurssi opettaa paitsi läpäisemään sen sertikokeen, myös ihan oikeita asioita ja parhaita käytäntöjä - ja suodattaa valtavasta infomassasta jonkun hallittavan kokonaisuuden. Musta serti voi olla ihan hyvä tapa oppia pilvipalvelua. Itse töhöilemällä voi tehdä monta asiaa päin persettä.

Tottakai sertin tekemällä voi oppia. Toisaalta etenkään ne alkupään sertit eivät anna takuuta hyvästä osaamisesta ja arkkitehtuurin ymmärryksestä.

Sen takia pidetään se tekninen haastattelu ja sinne sen kyseisen tekniikan kanssa enemmän pelanneita grillaamaan, että miten olet asioita tehnyt ja etenkin, että miksi päädyit niihin ratkaisuihin kuin päädyit.

Edes huonoihin tai epäideaalisiin ratkaisuihin päätyminen ei ole huono juttu, kunhan hakija tietää itse, että tämä nyt ei ole se paras ratkaisu, mutta silloin kun tehtiin se oli riittävän hyvä + osaa kertoa, että näin sen se oikeasti kannattaisi tehdä syistä xyz.

 

[hsalonen]

Olen siellä toteuttajien joukossa, mutta jos olisi kolme kaveria, joilla olisi:

1. Kolme vuotta kokemusta teknologiasta X
2. Yksi vuosi kokemusta teknologiasta X ja keskitason sertti aiheesta (AWS Associate)
3. Kaikki sertit aiheesta X ja ne on suoritettu itsenäisesti ja työkokemusta ei ole

..niin ottaisin mieluiten sen tyypin #2. Numero #1 on nysvännyt omaa pientä palaansa ja voi olla näistä kaikista se, jolla on vähiten yleispätevää kokemusta. Numero #3 on tehnyt ehkä sertin valmennuskurssin jälkeen tai pahimmassa tapauksessa kaveri on tehnyt sen hänen puolestaan ja mitään takeita ei ole, että hän sopii tiimiin tai osaa soveltaa oppimaansa käytännössä. Tietenkin numero #3:ista on juniorit tehty..

@zepi ehdottamissa grillaussessioissa on se huono puoli, että käytännössä tuskin kellään on oikeasti koko tulevan firman teknologiastackki hallussa ja liian tekniseksi meneminen voi tappaa muuten hyvän kokelaan. Esim. teidän firmassa tehdään Pythonilla ja tuo kaveri on tehnyt AWS:n mikropalveluita pelkästään Javalla ja pystyy kuitenkin koulutuksensa avulla sisäistämään uuden kielen helposti. Ja jotkut meistä tekee ratkaisuja, joista ei saa NDA:n takia kertoa kenellekään. Tähän kyllä puree, että teillä on esimerkkiskenaario, ja se pitäisi purkaa ratkaisuksi.

--

Jotain AWS-serttejä on minullakin suoritettuna ja ei ne Associate-tason sertit mitään läpihuutojuttuja ole. Lisäksi ulkoaopettelu ja nippelitiedon kysely on vähentynyt; enemmän on semmoista käytännön skenaariota ja kysymyksiä, joissa on monta oikeaa ratkaisua - ja niistä pitää valita parhaiten sopiva.

 

[Paapaa]

Jotain AWS-serttejä on minullakin suoritettuna ja ei ne Associate-tason sertit mitään läpihuutojuttuja ole. Lisäksi ulkoaopettelu ja nippelitiedon kysely on vähentynyt; enemmän on semmoista käytännön skenaariota ja kysymyksiä, joissa on monta oikeaa ratkaisua - ja niistä pitää valita parhaiten sopiva.

Sanoisin melkeinpä, että Associate-tasolla on usein selkeä oikea vastaus ja muut ovat vääriä/toteuttamiskelvottomia. Pro-tasolla on sitten lähinnä pelkkiä "oikeita" vastauksia (eli periaatteessa vastauksia, jotka toimivat ja toteuttavat halutun asian), mutta joku on joltain kantilta paremmin sopiva, esim. on muita edullisempi. Ja samaa mieltä, eivät ole läpihuutojuttuja, vaan pitää opetella ja käyttää aikaa asioiden läpikäyntiin. Jopa kaikkein helpoin eli Cloud Practitioner vaatii jonkin verran pänttäämistä ihan jo puhtaasti siksi, että AWS:llä on iso liuta palveluja ja lyhenteitä, joita ei voi loogisesti vain päätellä.

 

[dropadrop]

Musta certit ovat aina olleet turhia, tosin olen aikojen saatossa niitä ottanut (jos vaikka olis hyötyä). Käytännössä _kaikki_ ovat olleet niin simppeleitä että en ole oppinut mitään niitä harjoitellessa. Olen siis henkilökohtaisesti ihan eri mieltä tosta aikasemmasta listasta. Muutaman viikon työkokemus opettaa jo paljon enemmän kuin ”advanced” certti jos olet aiheesta innoissasi.

 

[Paapaa]

Käytännössä _kaikki_ ovat olleet niin simppeleitä että en ole oppinut mitään niitä harjoitellessa.

Ihan uteliaisuuttani kysyisin, että mitä sertejä olet tehnyt (näitä, mistä et ole mitään kokenut oppineesi).

 

[dropadrop]

Ihan uteliaisuuttani kysyisin, että mitä sertejä olet tehnyt (näitä, mistä et ole mitään kokenut oppineesi).

Pikaisesti muistellen:
- Solaris network admin (en muista mikä Solaris)
- BEA Tuxedo
- BEA Weblogic
- Netapp Data Admin
- Comptia Security+
- Architecting in AWS (tms)

En nyt erityisesti sano että aiheet ovat turhia. Kuitenkaan en ole alottanut mitään aihetta kurssilla, eli tuossa vaiheessa alla on ollut jo paljon työtä, ja kummasti siinä työssä on oppinut enemmänkin kuin mitä certeissä tarvitsee.

Ehkä poikkeuksena Security+, mutta se ei varsinaisesti koske mitään yksittäistä aihetta.

Tämä oli siis ennenkaikkea liittyen tuohon ”mielummin vuosi kokemusta ja certti kuin 3v kokemusta”. Oman kokemuksen mukaan olettaisin että se 3v kokemus on paljon arvokkaampi asia, tai sitten hakija on jo lähtökohtaisesti väärä.

 

[mopnex]

Sanoisin melkeinpä, että Associate-tasolla on usein selkeä oikea vastaus ja muut ovat vääriä/toteuttamiskelvottomia. Pro-tasolla on sitten lähinnä pelkkiä "oikeita" vastauksia (eli periaatteessa vastauksia, jotka toimivat ja toteuttavat halutun asian), mutta joku on joltain kantilta paremmin sopiva, esim. on muita edullisempi. Ja samaa mieltä, eivät ole läpihuutojuttuja, vaan pitää opetella ja käyttää aikaa asioiden läpikäyntiin. Jopa kaikkein helpoin eli Cloud Practitioner vaatii jonkin verran pänttäämistä ihan jo puhtaasti siksi, että AWS:llä on iso liuta palveluja ja lyhenteitä, joita ei voi loogisesti vain päätellä.

Näinhän se tuppaa menemään. En silti aliarvioisi sitä määrää mitä oikeasti pitää tietää että saa edes "Associate" -tason AWS sertin. Itse nappasin associate -tason ilman aktiivista käytännön kokemusta (on-premise tuolloin). Silti siinä vaaditaan aika kattava ymmärrys enemmänkin VPC -puolesta ja suurimmasta osasta AWS-palveluista hyvin korkealla tasolla. Allekirjoitan täysin kyllä sen, että voi päätellä paljon helpommin nuo "Associate" -väärät vastaukset vs. mitä vaatii Pro-tasolla. Silti se oikea käytännön kokemus opettaa eniten, silti olisin vähän kahden vaiheilla jos ei ymmärrä sen laajemmin AWS tarjontaa kuin sen minkä parissa on työskennellyt. Esimerkiksi VPC/SG/NACL/IAM -puoli on monella "vähän sinnepäin".

 

[nbzero]

Pikaisesti muistellen:
- Solaris network admin (en muista mikä Solaris)
- BEA Tuxedo
- BEA Weblogic
- Netapp Data Admin
- Comptia Security+
- Architecting in AWS (tms)

En nyt erityisesti sano että aiheet ovat turhia. Kuitenkaan en ole alottanut mitään aihetta kurssilla, eli tuossa vaiheessa alla on ollut jo paljon työtä, ja kummasti siinä työssä on oppinut enemmänkin kuin mitä certeissä tarvitsee.

Ehkä poikkeuksena Security+, mutta se ei varsinaisesti koske mitään yksittäistä aihetta.

Tämä oli siis ennenkaikkea liittyen tuohon ”mielummin vuosi kokemusta ja certti kuin 3v kokemusta”. Oman kokemuksen mukaan olettaisin että se 3v kokemus on paljon arvokkaampi asia, tai sitten hakija on jo lähtökohtaisesti väärä.

Ootko oppinut noiden serttien asiat itse, vai ootko pystynyt kysymään tarvittaessa apua senioritekijöiltä? Jos vaikka esim pieni yritys tai iso organisaatio, josta valmista osaamista ei löydy, lähtee tekemään alueelle, josta ei ole valmiiksi vahvaa kokemusta, niin en uskoisi noiden kelvottomia olevan. Vaikkakaan ei juuri kyseisistä koulutuksista ole kokemusta.

Monessa keskustelussa tulee vastaan se, että katsotaan sen oman työpaikan koon ja resurssien vinkkelistä asioita, kun taas alalla hommat vaihtelee organisaation koon suhteen paljonkin.

 

[dropadrop]

Ootko oppinut noiden serttien asiat itse, vai ootko pystynyt kysymään tarvittaessa apua senioritekijöiltä? Jos vaikka esim pieni yritys tai iso organisaatio, josta valmista osaamista ei löydy, lähtee tekemään alueelle, josta ei ole valmiiksi vahvaa kokemusta, niin en uskoisi noiden kelvottomia olevan. Vaikkakaan ei juuri kyseisistä koulutuksista ole kokemusta.

Monessa keskustelussa tulee vastaan se, että katsotaan sen oman työpaikan koon ja resurssien vinkkelistä asioita, kun taas alalla hommat vaihtelee organisaation koon suhteen paljonkin.

Ekat kolme opin senioreilta, tosin meillä oli myös HP-UX, AIX ja Linux koneita... Jostain syystä tuli mahdollisuus certifioitua, varmaan palkankorotusten korvauksena tms.

Netapp tuli seuraavalle työnantajalle uutena juttuna. Se oli kasvava firma ja siinä tuli tosi paljon uusia asioita yhtä aikaa. Levyjärjestelmää käytti datawarehouse jolle piti pystyttää kuitu-verkko. Lisäksi rinnalle tuli dedikoitu iscsi verkko ja siirryttiin fyysisistä palvelimista vmwareen (tämä oli yli 10v sitten). Mä sain noi kaikki vastuulleni, ja kaikki oli uutta. Netapp koulutus oli aiheellinen, mutta olin jo oppinut sen kaiken ennen sitä kun oli kiire saada palvelut pystyyn.

Security+ oli pitkälti juttuja jotka ties jo. Vaikeinta oli, että en ollut kaikesta yhtä mieltä, mutta testissä pitää tietää mitä vastausta odotetaan. Luulin että olisin feilannut sen kun ehdin vaan selata kirjan läpi kerran, mutta läpi meni ihan hyvillä pisteillä.

Toi AWS juttu oli ihan läppä kun mulla on nyt devi tiimejä joiden työtä ohjaan. Konseptit ovat tuttuja kun on osana keskusteluja, ja kun oon ollut devaaja luen mielummin koodista kuin kysyn niin ymmärrän sitten paremmin. Eli en sinällään olis sitä tarvinnut, mut oletin oppivani siellä jotain.

Suurin osa kursseista ei tuntunut siltä, että siellä edes oltiin oppimassa jotain, vaan enemmän että testattiin osaako jo.

Toki firmoja on erilaisia, ja noiden ekojen aikana olin töissä isossa telco’ssa jossa ylipäätänsä kaikki ongelmat ratkaistiin rahalla. Siellä aika pitkälti odotettiin että osaa asiat, eikä niihin aikoihin ollut netissä kunnon resursseja ettiä tietoa unixeista ja järeistä palvelimista.

Seuraava firma oli pienempi, ja siellä oli tapana ratkaista ongelmat ajattelemalla. Samalla yritys kasvoi nopeasti joka mahdollisti rahan käytön jos se oli tarpeen, ja henkilökuntaa oli niin paljon että pystyi oikeasti testaamaan eri vaihtoehtoja ja valitsemaan mieleisimmän. Nyt oon vähän noiden sekotuksessa.

Mut nykyisin netissä on niin paljon tietoa että melkein mitä vaan voi oppia ilman kursseja. Toki kurssit voivat olla hyviä jos niitä vaan saa, mutta ainakin mulla 99% oppimisesta on tapahtunut muualla.

 

[dropadrop]

Ja nyt pitää vielä jatkaa tähän sitä alkuperäistä pointtia, eli miksi se certti ei välttämättä ole kuitenkaan hyvä indikaattori osaamisesta.

- Mulla on Certti Solariksesta, mutta olen työskennellut yhtä paljon monen muun Unixin kanssa. Suurin vahvuus olis kuitenkin Linux josta certtiä ei löydy, mutta olen kuitenkin erittäin hyvä (tai ainakin ~10v sitten kun vielä tunkkasin enemmän).
- Mulla on Certti Netapp levyjärjestelmistä, mutta pärjäisin varmaan yhtä hyvin EMC / EVA / 3par kanssa joista kaikista on paljon kokemusta

Tämä sama koskee suurinta osaa mun tuntemista ”tekijöistä”, eli ovat hyvin laajan alan osaajia, mutta vain muutama sattumanvarainen paperi. Poikkeus on sitten konsultit joista monet hiovat kattavat certit koska asiakkaat joskus vaativat niitä, ja yritystietoturva.

 

[Paapaa]

Architecting in AWS (tms)

Nykyään tuollaista ei ole. Lähin olisi Solutions Architect Associate ja Solutions Architect Professional, joista jälkimmäinen ilmeisen haastava. Ensimmäinen ei ehkä opettelematta läpi mene, mutta ei mitään rakettitiedettä.

 

[Paapaa]

Poikkeus on sitten konsultit joista monet hiovat kattavat certit koska asiakkaat joskus vaativat niitä, ja yritystietoturva.

Ja konsulttifirmat saattavat haluavat korkeammalle tierille APN:ssä (AWS Partner Network) syystä tai toisesta.

 

[Ratsia]

Ja nyt pitää vielä jatkaa tähän sitä alkuperäistä pointtia, eli miksi se certti ei välttämättä ole kuitenkaan hyvä indikaattori osaamisesta.

- Mulla on Certti Solariksesta, mutta olen työskennellut yhtä paljon monen muun Unixin kanssa. Suurin vahvuus olis kuitenkin Linux josta certtiä ei löydy, mutta olen kuitenkin erittäin hyvä (tai ainakin ~10v sitten kun vielä tunkkasin enemmän).

Olen läpikäynyt viimeisen viiden vuoden aikana ehkä 200-250 hakijan ceeveetä paikkoihin joihin ei ole ollut koulutusvaatimuksia. Sysadmin/backup/storage-hommaa jossa peruspalkka 3500-4000.
Käytännössä haastatteluihin on kutsuttu tyypit joilla on loppuun hoidetut opinnot, tuoreet sertit ja tuoteosaamista. 10 vuotta on hemmetin pitkä aika, ja Linuxin tapauksessa kuvio on muuttunut perinteisestä järjestelmänhallinnasta devops-suuntaan (python, k8s, kontit, virtual networking yms tauhka).
Yhtään ennestään tuttua ihmistä en muista hakijoiden joukosta, eikä suosittelijoita tai github/linkediä olla vielä tuossa vaiheessa tarkistamassa. Kenenkään aika ei riittäisi moiseen.

Itsellänikin on useampi melkein valmistunut insinööri ilman sertifiointeja työkaverina, mutta pidemmälle hakuprosessissa pääsee jos koulutusasiat on kuosissa.
Firman maksamat sertit kannattaa hommata, vaikka miten tuntuisi tyhjänpäiväiseltä, ei niitä kaikkia ole pakko ceeveessä mainita. Lisäksi luettakaa cv ja hakemus sellaisella, jolla ei ole mitään tietoa päivittäisestä työstäsi ja pyytäkää palautetta ikäänkuin lukija olisi sinua palkkaamassa. Useampi lappu on tullut vastaan missä 10 vuoden työkokemus on kuitattu merkinnällä Järjestelmäasiantuntijana firmassa nönnönnöö. Tämä selvä...

 

[freebie]

Nykyään tuollaista ei ole. Lähin olisi Solutions Architect Associate ja Solutions Architect Professional, joista jälkimmäinen ilmeisen haastava. Ensimmäinen ei ehkä opettelematta läpi mene, mutta ei mitään rakettitiedettä.

En usko tuollaista olleen missään vaiheessa, tai olen melko varma siitä. Kurssi löytyy kyllä samalla nimellä ja ehkä alkuperäisen lainattavan myöhempi kommentti oppimisesta siihen viittaakin.

Spoileri: Offtopic

Onhan kaikille selvää kurssin ja sertin ero kuitenkin? Ilman kynsiä ja hampaita.

 

[Paapaa]

En usko tuollaista olleen missään vaiheessa, tai olen melko varma siitä. Kurssi löytyy kyllä samalla nimellä ja ehkä alkuperäisen lainattavan myöhempi kommentti oppimisesta siihen viittaakin.

Spoileri: Offtopic

Onhan kaikille selvää kurssin ja sertin ero kuitenkin? Ilman kynsiä ja hampaita.

Joo, näin näyttää olevan. Tässä "Architecting on AWS - Accelerator", joka on siis kurssi ei serti. En tiedä, mitä tuo pitää sisällään, mutta pikavilkaisulla varmaan osajuokko Solutions Architect Associate -vaatimuksista. :shrug: Mutta ei tosiaan ole sertifikaatti.

AWS training and certification

www.aws.training

Täällä taas tuohon liittyvät sertit, ja siellä itseasiassa listattu yhtenä tuo yllä oleva kurssikin:

Architect

Learn how to design resilient, high-performing, secure, and cost-optimized architectures. Build your AWS Cloud skills with digital training courses, classroom training, and certifications. Learn more!

aws.amazon.com

(AWS:n omat kurssit eivät kyllä keskimäärin anna läheskään tarvittavia tietoja sertin läpäisyyn. Tai niitä pitää käydä läpi aikamoinen määrä, jotta saa haalittua oleelliset tiedot. Nopeammin oppii kun hommaa kunnon sertikurssin muualta...)

 

[dropadrop]

Joo, mulla meni sekaisin koulutus joka oli ennen koetta ja sitten se saatu brosyyri, kyseessä siis tuo Associate tason Solutions Architect.

 

[poksi]

Kiitos kaikille minua auttaneille tähänastisista kommenteista

Kun oma ajatus tulevaisuudesta it-alalla on vahvasti kyberturvan puolelle, niin mitä nostaisitte em. puolen taidoista esille? Python lienee selkeästi ohjelmointikielistä, samoin verkkoteknologioiden hallinta (?)

Toki kyberturvankin sisällä on paljon erilaista työtä, mutta jos ajatellaan tällaista junioria ja alalle haluavaa.

En oikein osaa ajatella onko suunta tuon fullstack opiskelun kanssa oikea. Tuo olisi itselle enemminkin sellainen ”nice-to-know” kuin klassinen eläkevirka

 

[jarhu]

Kiitos kaikille minua auttaneille tähänastisista kommenteista

Kun oma ajatus tulevaisuudesta it-alalla on vahvasti kyberturvan puolelle, niin mitä nostaisitte em. puolen taidoista esille? Python lienee selkeästi ohjelmointikielistä, samoin verkkoteknologioiden hallinta (?)

Toki kyberturvankin sisällä on paljon erilaista työtä, mutta jos ajatellaan tällaista junioria ja alalle haluavaa.

En oikein osaa ajatella onko suunta tuon fullstack opiskelun kanssa oikea. Tuo olisi itselle enemminkin sellainen ”nice-to-know” kuin klassinen eläkevirka

Sisään voi olla vaikea päästä, mutta tehtäviä löytyy useanlaisia eri osaamistasoille. Mitä laajempi taustaosaaminen, niin sitä helpompi on päästä sisään. Ohjelmointitaidot on tärkeää olla hallussa edes perustasolla. Taidoista tosiaan laaja-alainen tietämys on aikalailla se peruskivi. Verkot, palomuurit, salaus/vpn, tietojärjestelmät, tietokannat, api-rajapinnat, dns, active directory, pilvi jollain tasolla hallussa jne. Näin äkkiä jotain listattuna, vaikea laittaa yhtä tärkeää pointtia. Kaikki on olennaisia, mutta ei kaikkea tarvi osata kaikissa tehtävissä.

Alan kirjallisuutta varmaan kannattaa lähteä selaamaan ja miettimään jonkunlaista kotilabraa jos vain on mahdollista. Sillä voi ainakin näyttää motivaatiota ja ymmärrystä sekä ehkä voi saada ajatusta siihen mitä oikeasti haluaa tehdä. Voi olla ikävää ajautua johonkin tehtävään joka ei olekaan kiinnostavaa itselle. Tehtäviä on joka tapauksessa tosiaan erilaisia ja mediassa kiinnostavaa, mutta silti homma on lopulta työtä kuten muutkin työt.

 

[shams]

Tietoturvapuolelle olisi hyvä hahmottaa haluaisitko olla tutkija/analyytikko, valkohattuhakkeri vai yleisempi tietoturvakonsultti. Kahden ensimmäisen pitää olla todella päteviä reverse-engineerauksessa, eli ymmärtää miten eri laiteympäristöt, käyttöjärjestelmät ja ohjelmistot toimivat pinnan alla. Valkohattuhakkerit voivat tehdä ns. "red teamausta", jotka testaavat asiakasyritysten tietoturvaa yrittämällä murtautua niiden järjestelmiin. Jotkut tietoturvakonsultit taas työskelevät vähän laajempien ja yleisemmän tason kokonaisuuksien parissa, eli erilaiset verkko-, palvelin- ja pilviympäristöt, kehitettävien ohjelmistojen tietoturvamallinnus, käyttäjähallinta, APIen ja muiden käyttöliittymien tietoturva, ym.