Ei se kyllä minustakaan ole.
Jos ollaan vähän isommassa organisaatiossa kyllä sillä on aika paljon väliä käyttääkö 100 kehittäjää yhtä samaa työkalua vai sataa eri työkalua. Toki on sitten eri asia sanellaanko ne työkalut ylhäältä alas tai paljonko niihin saa vaikuttaa, mutta jos oikeasti tehdään isoa niin kyllä silloin pitää olla jotain yhteisiä käytäntöjä. Siinä on sitten veteen piirretty viiva mikä on tarpeellista ja mikä vittuilua. Se, että kaikki kaatuu siihen montako entteriä tai välilyöntiä mihinkin kirjoitetaan on toki ihan pelleilyä.
Jees, jos sulla on 100 kehittäjää joista jokainen ylläpitää sitä omaa tiettyä työkalusettiään devaamisen ohella niin siinä tuhlautuu aika perkeleesti aikaa ja rahaa sen sijaan että siellä on parin tyypin tiimi joka ylläpitää kaikille niitä kahta tai kolmea "virallista" settiä.
No niin no, nykyaikaisilla koodin formatointityökaluilla tämän ei pitäisi olla mikään ongelma. Siinä nyt menee se sekunti kun ajaa sen formatterin ennen kun survoo committia sisään.
Mihin se aika oikein menee? Nykyiset devaustyökalut vaativat käytännössä muutaman minuutin (ehkä joskus tunnin) kuukaudessa jos sitäkään ellei puhuta joistain todella nicheistä FPGA IDE:stä mistä suurin osa ei ole kuullutkaan. Toiseksi en näe sillä suurta merkitystä onko firmassa 30 devaajaa vai 3000 kun kuitenkaan ainakaan jälkimmäisessä tapauksessa kaikki 3000 eivät hankaa sitä samaa softaa vaan firmassa on useita tuotteita/projekteja tulilla yhtäaikaa. Sitten kun ne softa tiimit ovat käytännössä 2-50 henkilöä niin en näe kovin suurta arvoa sillä että jokin tekemiselle sokea keskushallinto määrää työkalut. Todennäköisesti siitä tulee enemmän haittaa kun joku IT-osasto määrää käyttöön hitaat, raskaat ja vanhanaikaiset työkalut jotka nimenomaan vaativat sitä säätämistä ja ylläpitoa devaamisen sijasta.
Niinpä. Meillä on entry level positioihin joskus käytetty tuollaista ajastettua tehtävää ja se on ollut ohjelmointikielellä jota harva osaa ja ihan yleisen tason tehtävä kuten algoritmi eikä odotusarvokaan ole ollut, että kukaan sitä saisi annetussa ajassa ratkaistua. Kyse ei ole ollut mitata ko. kielen osaamista vaan jotain ihan muuta, mutta saahan noista kieltäytyä, mutta ei tartte sitten ihmetellä miksei töitä löydy.
Tämä. Vielä erityisesti projekteissa/tuotekehityksen elinkaarilla olisi parasta olla standardit työkalut/ympäristöt käytössä. Valitettavasti näissä hommissa (DevOps) on tullut nähtyä vaikka ja minkälaista viritystä eri projektien välillä. Pahinta on se että käytetään erilaisia työkaluja, mutta kukaan ei ota omistajuutta niistä. Sitten arvotaan kuka niiden ylläpitoa jne. hoitaa. Samaan asiaan voi pahimmillaan olla käytössä monta erilaista työkalua vaikka hommat voisi hoitaa yhdellä keskitetyllä resurssilla ja/tai käyttämällä kontitettuja ympäristöjä standardiseteillä.
No riippuu mitä tekee. Jos kyseessä on joku Javascript toteutus jossa kaikki riippuvuudet tulee npm:n yli ja lopulta devaajalla on valittavana että käyttääkö siihen koodin editointiin VS Codea, Emacsia, Atomia vai Notepad++:aa ja gitin käyttöön komentoriviä, gitk:ta, SourceTreetä tai mitä ikinä niin joo, sitten devaaja voi huoletta valita omat työkalunsa. Ihan devauskoneen käyttiksestä lähtien.
Yritin tuossa nyt lähinnä selventää niiden testien tarkoitusta. Se ei ilmeisesti auennut niin yritetään vielä. Sen yleisluontoisen testin tarkoituksena, kuten nyt vaikka algoritmi, ei ole useinkaan mitata juuri sitä spesifiä osaamista, kuten nyt vaikka backend tai frontti kuten tuolla esimerkkinä mainitsit vaan muita asioita. Siksi noista ei sen perusteella kannata kieltäytyä, että kiinnostus on jossain tietyssä teknologiassa.
Aikamoista spekulointia. Sen sijaan, että kokemattomana yrität vetää johtopäätöksiä siitä, mitä todellinen työnteko olisi, olisit tietenkin voinut kysyä, millaisiin projekteihin sinut voitaisiin palkata?
Siis oikeasti, sä olet kertonut kuinka sulla ei ole oikeastaan mitään käytännön työkokemusta alalta ja valitat kuinka et saa hommia mutta silti sulla on pokkaa kieltäytyä rekrytehtävistä?
Kuvaamasi rekry ei ole mikään neuvottelu vaan sopivien hakijoiden karsinta. Neuvotteluja käydään sitten myöhemmin niiden kanssa, joiden katsotaan sopivan parhaiten ko. tehtävään.
Juu ei. Aika monotonista hommaa pitää olla, jos ei koskaan tarvitse mitään uutta softaa koskaan. Virtuaaliväkkärän ja natiivijärjestelmän välisessä liikenteessä on lisäksi aina jos jonkinlaista ongelmaa liittyen polkuihin, tiedosto-oikeuksiin, reititykseen, käyttäjänimiin ja ties mihin. Mieluummin pieni skripti, joka potkaisee kehitysympäristön välttämättömät palat ylös, ja loput saa kehittäjä asentaa itse mielensä mukaan.
Rehellisesti sanottuna mahdoton yhtälö. Joko haluat mennä tekemään sitä software engineeringiä insinöörien kanssa tai sitten et halua alalle. Suomessa Hervantavakiolla laskettuna n.90 % ohjelmoijista on insinöörikoulutuksen käyneitä, joten käytännössä joka ainoassa paikassa on myös insinööritaustaisia ohjelmoijia, todennäkösesti enemmistönä ja käytetään insinöörimäistä työotetta, koska tuotteita pitää tehdä taloudellisten raamien rajoissa.
No sitten et halua koodariksi.
No kerro nyt sitten minkälaisia hommia sä koodarina haluat jos haluat välttää "insinöörimäisiä positioita"?
No sitten ilmainen neuvo jolla säätät paljon aikaa:
Kuulostaa siltä että sun pitäisi ensin olla pitkä koodauskokemus että pystyt nopeasti omaksua stäkin, työkalut ja koodin ja sen jälkeen toimia projektipäällikkö/asiakkuuspäällikkönä tasolla ja tiketöidä koodaritiimiä asiakkaan toiveilla.
Missään tosiaan ei ole täydellistä ja samaa kakkaa on tarjolla eri paketeissa. Kun on asuntolainaa ja muuta pikku vikaa itsessäänkin, niin parannusehdotuksiakin joutuu annostelemaan pienissä paloissa. Jännästi ajallakin on parantava vaikutus moneen asiaan, tämän päivän stara on huomisen symbianjäte.
Tai sitten kyse on siitä että täällä on useita henkilöitä jotka ovat olleet tällä alalla useita vuosia, jopa vuosikymmeniä. Henkilöitä jotka ovat olleet useammissa työpaikkahaastatteluissa niin haastateltavina kuin haastattelijoina. Henkilöitä jotka ovat joutuneet tekemään noita koodaustestejä ja henkilöitä jotka ovat suunnitelleet noita koodaustestejä. Ja arvioineet niiden lopputuloksia ja tehneet päätöksiä siitä että kuka rekrytään ja ketä ei rekrytä.
Sinulla on jotenkin hirveän pitkä aika siihen, kunnes pääset tekemään tuottavaa työtä. Firman sisäänajo maksaa, firman sinulle tarjoama koulutus maksaa, etkä sinä aikana tuota firmalle mitään - maksat vaan enemmän, kun joku joutuu kädestä pitämään kiinni (= viet hänen työaikaansa). Sen takia haastatteluissa kysytään näitä teknologioita joilla firma tekee töitä, ettei niitä tarvitse erikseen opettaa. Koodaustestikin olisi todennäköisesti pyrkinyt osoittamaan, että voit tehdä yhden palasen itsenäisesti, varsin nopeasti ja riittävällä laadulla. Tai kestät paineita ja osaat pilkkoa vaikean tehtävän helppoihin osiin, jne..
Ei vaan softa-alalla on epänormaalia käytöstä että juniorihommaa hakeva tyyppi kieltäytyy tekemästä jotain yksinkertaista ohjelmointiharjoitusta rekryprosessin aikana. Aiemmin mainitsit jotain linkitetystä listasta, jos kyse oli siitä niin sehän on aikalailla niin perusohjelmointitehtävä kuin vain voi olla ja jota voi käyttää käytännössä kaikissa juniorikoodari haastatteluissa selvittämään että osaako se tyyppi oikeasti koodauksen perusteita vai ei.
No mitä kysymyksiä siinä sitten kysyttiin? Ja mikä oli sen position kuvaus mihin olit hakemassa? Siis sillai pääpiirteittäin.
Kaikesta paistaa läpi, ettet kysynyt, millaista työtä olisit alkanut tehdä. Tai millaisia projekteja siellä tehdään, vaan teit oletuksia aika hatarin perustein. Yhä edelleen: et voi testistä päätellä työn sisältöä.
Mainittiinhan artikkelissa että euroopassa on tehty vähemmän offshorehommaa ja myös:
Ja sehän on hyvä kysymys onko 50 vuotta vanhan koneen retrofit nähty niin "tärkeäksi hommaksi", ettei esim. näytön koodausta ei voisi ulkoistaa...
Nyt kun Boeingin matkustajakone on laskeutunut vain pari kertaa epäsuotuisasti tonttiin, niin herääkin kysymys kuinka kaukana ollaan sotilaskoneiden koodin toteutuksen ulkoistamisessa?
Näin sivusta seuraajana rupesi mietityttämään että jos olet usein kieltäytynyt kooditestistä, niin montako työpaikkaa olet tällöin saanut,
Voi olla että jatkuu vielä tovin. Rekrytointi on neuvottelu kuten itse sanoit joku hetki sitten, mutta kun on uran alkuvaiheessa ilman työkokemusta niin ne omat neuvottelutpanokset ovat suht. ohuet.
Vähän riskaabeleilla vesillä kyllä liikut jos oikeasti ajatuksena on hankkia se kokemus hyödyllisemmistä stäkeistä kotona (jos nyt luin oikein rivien välistä). Ennemmin hakeutuisin itse niihin bäkkärihommiin ensin jos niitä paremmin on tarjolla ja vaikka siellä sitten yrittää sisäisesti päästä tekemään fronttia.
No jos sun portfoliossa on pelkästään C++:aa ja Assemblya niin et ole fronttipuolen devaaja. Voi olla että sua kiinnostaa fronttipuolen hommat mutta kerta sulla ei ole mitään varsinaista koulutusta alalle eikä myöskään sun pitkän ajan harrasteprojektit sovi niihin hommiin mitä haluat tehdä niin lopputuloksena on että tulet kyllä varmaan junnaamaan paikoillasi pitkään.
Kun ei devaa kotona vaan tekee työkseen niin siinä tulee paljon muutakin kaupan päälle kuin pelkästään koodia. Sitä varten työkokemusta arvostetaan ja sillä puolella on varmaan nyt enemmän opittavaa kuin siinä varsinaisessa "devaamisessa". Varsinkin kun on itseoppinut ja jäänyt kaikki (ryhmä)harjoitustyöt ja ohjelmistotuotannon ymv. kurssit käymättä, jotka ovat osa koulutusta. (Ja aika tärkeä osa)
Jos on omasta mielestä mahdollista että kaupallinen devaus ei sovi, niin kannattaisi mahdollisimman pian hankkia se kokemus kaupallisesta devaamisesta että osaa sanoa. Niinkuin tuossa yllä jo oikeastaan totesin.
Ei, mutta jos ne haastattelut ovat kerran kiven alla suosittelen ottamaan jokaisesta kaiken irti mihin pääsee. Työsopimuksen kirjoittamiseen asti saa peruutella ihan rauhassa, ja kelaa lukuunottamatta senkin jälkeen.
Itsehän sinä sanoit ettei tiedä onko kaupallinen devaaminen sinua varten, ei se ollut minun spekulaatiota. Noi jutut mitä tossa kerrot on sitä harrastamista, eikä kaupallista devaamista eli töiden tekemistä palkkaa vastaan
