🥇Vabane hirmust esimese töö leidmise ees

Kader filmist «Harry Potter ja Azkabani vang»

Selle maailma probleem on see, et haritud inimesed on täis kahtlusi, samas kui idioodid on täis kindlust.
Charles Bukowski

Hiljuti viisime läbi ühe individuaalse programmeerimisseansi. Erinevalt tavalistest tundidest ei olnud teema mitte keele struktuur ega probleemi lahendamine. Üliõpilane jagas oma muret tuleviku töö leidmise üle. Ta ise oli üsna arvestatav. Üks neist, kes tuleb kursustele, läbib kogu programmi kiiremini kui keegi teine ja leiab originaalseid lahendusi, kuid alahindab end pidevalt. Minu arvates tekivad sellised kahtlused ainult teabe puudumisest. Püüdsin selle lünga täita ettevalmistamata rääkides tunni jooksul.

Küsimused olid umbes sellised:

Igal aastal lõpetab ülikooli palju tudengeid ja nad kõik hakkavad töö otsima. See on ju väga palju inimesi. Kindlasti palgatakse parimad ja mulle ei jätku kohta.
Mis juhtub, kui ma teen vea ja mind kohe vallandavad?
Mis juhtub, kui nad töötamise käigus aru saavad, et ma olen tobe ja nad mind välja viskavad?

See üliõpilane ei olnud esimene, kes esitas mulle sarnaseid küsimusi. Need tekivad paljudel ja tavaliselt tuleb rääkida ettevalmistamata. Seekord otsustasin oma monolooge märkmikusse kirja panna. Arvasin, et saan kokku paar lõiku, aga kokku tuli terve artikkel.

Artiklis on kirjeldatud minu vaatenurka ja minu kogemust. Kuid meie maailm on väga mitmekesine ja seal juhtuvad uskumatud asjad. Kui te millegagi ei nõustu või teie kogemus erineb, siis palun kirjutage kommentaar.

Artikkel on kirjutatud arendajatelt arendajatele. Kuid kui plaanite tegeleda testimise, haldamise või millegi muuga IT-s, siis on mõned näpunäited teile samuti kasulikud.

Üldse ei palgata.

Kuidas kujutada ette, et igal aastal lõpetab mitusada ülikooli tudengeid, siis muutub see ebamugavaks. Kuidas sellise tohutu rahvaga konkureerida?

Kahjuks ei ole kõik lõpetajad omandanud piisavat tehnilist ettevalmistust. Proovige küsida mõnelt tuttavalt üliõpilaselt ülikoolist: kuidas saavad inimesed tema grupis eksamiteks nõudeid täita ainetes nagu "andmebaasid" või "alusteadmised algoritmis ja programmeerimises"? 30 liikmest grupis on kõige paremas seisus 3-5 "edukamat" inimest, kes on kõik ise reaalselt teinud. Ülejäänud lihtsalt kopeerivad neist, õpivad vastuseid küsimustele ja teevad eksami.

Nii oli ka siis, kui mina õppisin. Siiski võis minu kogemus olla ebatäpne. Seetõttu küsisin sellest küsimusest mitmelt erinevalt üliõpilaselt. Vastus oli enam-vähem sarnane. Vastajad olid erinevatest kõrgkoolidest ja kolledžitest. Arutlused põhjustest jätan selle artikli raames väljapoole. Täieliku uurimistöö jaoks ei piisa mulle, seega teen järelduse olemasolevatest faktidest.

Saja lõpetaja seas vaid paarikümnel on tööandjate jaoks tõeline huvi.

Väga vähesed lõpetajad saavad tõeliselt konkureerida andeka üliõpilasega, kellel on hea ettevalmistus. Siiski, isegi kui olete kohusetundlikult õppinud, siis pärast esimest intervjuud ei pruugita teid tõenäoliselt palgata. Teise järel tõenäoliselt samuti mitte. Kõik võib minna hästi, kuid on parem valmistuda mitte rünnakuks, vaid piiramiseks. Ebaõnnestunud katse tööle saada on lihtsalt võimalus teha veidi kodutööd ja proovida uuesti. Ma ei hakka rääkima intervjuudeks ettevalmistumisest. Internetis on juba palju sellest kirjutatud. Ütlen vaid, et intervjuudeks valmistumisel on nüansse, mille selgitamiseks ei pruugi teie õppekavas olla aega. Otsige seda teavet ise, see võib vähendada katsete arvu.

Hullus on sama tegevuse pidev kordamine. Kord-korralt, lootuses muutusele.
Albert Einstein

Kuna intervjuud ei tohiks muutuda hulluseks, tuleb iga uue katse järel paremaks muutuda. Mäletage või kirjutage üles küsimused, mida teile intervjuul esitati. Kodus olles vaadake see nimekiri üle ja kontrollige end internetis. Nii saate aru, kus eksisite teie ja kus - intervjueerija. Seda juhtub ka. Korrake või uurige teemasid, milles vastasite halvasti, ja proovige jälle.

Lisaks on tööturul selgelt väljendunud hooajalisus. Nutikad ettevõtted planeerivad värbamist arvesse võttes koolide lõpetamise kuupäevi. Kevadel on algajatele vabu töökohti rohkem kui muul ajal. Siiski on sel ajal konkurents kõrgem.

Töötuks jääb — saadetakse minema

Kui inimesi, kellel pole kogemusi, tööle võetakse, siis on nende suhtes vastavad ootused.

Algjalt oodatakse tööl, et:

Üldiste tehniliste teadmiste omamine
Ettevõtte valdkonna eripärade uurimine
Kasutatavate tööriistade ja praktikate omandamine

Mõnes organisatsioonis korraldatakse algajatele koolituskursuseid kasutatavate tehnoloogiate, tööriistade ja kohalike kordade kohta. Näiteks korporatiivse e-posti kasutamise etikett, dokumentide muutmise protseduurid vikis, kohaliku VCS ja viga jälgiva süsteemi töö eripärad.

On ka tehnilisi sissejuhatavaid kursuseid, kuid nende kasulikkus on kaheldav. Kui asjad on jõudnud tööle kandideerimisele, siis on tööandjad veendunud, et teil on teatud vajalikud teadmised. Parim on selliseid kursuseid ausalt läbida, kui väike formaalsus. Võib-olla on seal tõesti midagi kasulikku.

Tööd alustades pidage meeles, et algajale ei usaldata kindlasti kiiret, keerulist ja samal ajal olulist ülesannet. Tõenäoliselt on see vaid üks neist omadustest. Kas lihtne, aga kiire: paigaldada kujundus, edastada kellegile fail või probleemi paljastamine. Või keeruline, kuid ilma lootuseta lõpetada — et algaja koguks rohkem kogemusi. Või oluline, kuid katsetav. Näiteks projekt, mida kõik ammu soovivad, kuid ei suuda sellele aega pühendada.

Tööriistade omandamise ülesanded on «keerulised» ja kunstlikud. Tõenäoliselt on see lihtsustatud versioon põhisisust. Sarnastes ülesannetes kasutatakse sama tehnoloogia paketti ja samu terminoloogiaid valdkonnast nagu kogu projektis. Selle tulemus ei jõua siiski lõppkasutajani. See võib demotiveerida, kuid sellele meeleolule on parem vastu seista. Kunstlikke ülesandeid tuleb lahendada ausalt, nagu oleks see projekti saatusest sõltuv.

Teie esimese ülesande lahenduse tulemus jätab kolleegidele, kes ei olnud intervjueerimisel kohal, esialgse mulje teist.

Teine ülesanne tööriistade omandamiseks on "projekt käivitada kohalikus masinas/katsekeskkonnas". Mõnikord on see protsess kirjas juhendis. Kuid need on üldiselt vanad ja osaliselt ebatäpsed. Projekti jaoks saab tõeliselt kasulikku panust anda, kirjutades uusi juhiseid, kus on täpsustatud tekkinud probleemid. Kindlasti olete ülikoolis pidanud kirjutama RGR-i mõne aine aruande jaoks. Siin on see peaaegu sama. Dokumendis peavad olema kajastatud tegevused, mida tuleb käivitamiseks teha.

Tavaliselt on toote käivitamise tegevused katsekeskkonnas umbes sellised:

kloneerida repositoorium, lülituda mõnele harule või sildile
koostada mõni konfiguratsioonifail
valmistada ette andmebaasi struktuur
täita see testandmetega
teha projekti kogumine või kompileerimine,
käivitada rida konsooliketreid kindlas järjekorras

Kohalikus süsteemi käivitamise protsessis on paratamatud ettenägematud probleemid.

Leitud probleemide lahendused tuleb lisada juurutamisjuhendisse. Siis järgmisel korral juhendi järgimisel ei teki neid probleeme enam. Konfiguratsioonifailide täitmisel ja skriptide kutsumisel tuleb tähelepanu pöörata sellele, milline väärtus kuskil kasutatakse ja millega see peaks kokku langema. Näiteks, kui projekt kogutakse CI-süsteemi abil ja seejärel käivitatakse skripti poolt, on oluline mõista, kuhu kirjutada haru nimi või commit number. Tohiks juhtuda, et skript eeldab edastamist IP-aadressid või andmebaasi DNS nime, selle kasutajanime ja parooli. Sellisel juhul tuleb teada, millist aadressi testkeskkonna jaoks kasutada, millised kasutajanimesid seal on ja millised paroolid neile tuleb määrata.

Mõned ülesanded võivad tunduda kogenud arendajatele lihtsad ja tekitada praktikantidele raskusi. See on normaalne nähtus.

Arendajat peavad iga päev lahendama tehnilisi probleeme. Kogenud töötajad on paljusid probleeme juba varem lahendanud, samas kui uutel töötajatel on veel ees nende ületamine. Parim taktika on kirja panna kõik kohtatud vead dokumendis „probleemide lahendamine ${task_name}“. Iga probleemi korral tuleks formuleerida hüpotees põhjuse kohta, otsida internetist lahendusevariandid ja proovida neid järjestikku. Iga katse tulemus tuleks samuti fikseerida.

Teie uurimistöö dokumenteerimine võimaldab:

välja kanda väikeseid detaile. Näiteks konfiguratsiooni parameetreid, DNS/IP-aadresse, käsurea käske ja SQL päringuid.
meelde tuletada „mida ma eile tegin“, kui ülesanne venib päevade kaupa.
mitte rakkuda ringiratast. Saate alati lugeda, mida varem tegite, ja mõista, et olete tagasi algse probleemi juurde.
selgelt vastata küsimusele: „mida sa täna tegid?“ isegi kui valmislahendust veel pole.

Peate oskama rääkida oma ülesannete seisust kolleegidele.

Perioodiliselt küsivad kolleegid teie edusammude kohta ja jagavad oma. Selleks eraldatakse iga päev või nädal veidi aega.

Kui te ei jälgi kohtatud ja lahendatud probleeme, siis teie edusammude kirjeldus näeb välja nagu: "Ma püüdsin ülesannet teha, kuid mul ei õnnestunud. Praegu otsin lahendust." Sellisest jutust ei selgu, kas praktikant tegi midagi või lihtsalt luges Habra. Kas tal on abi vaja? Kas olukord on muutunud alates eilisest?

Kui pidada dokumenti lahenduste otsimiseks, siis saate öelda: "Ma püüan teha seda ülesannet. Mul olid sellised vead. Need sain lahendatud nii. Selle kohta ma veel ei ole suutnud. Mul on sellised hüpoteesid ja lahendusvariandid. Praegu kontrollin neid."

Kui ülesannet saab kuidagi mõõta, peaks seisukohas olema numbreid. Näiteks ülesande „kirjutada üksustestid mooduli jaoks“ puhul võib öelda: "plaanin teha 20 testi, praegu olen kirjutanud 10."

Mida rohkem detaile te jagate, seda paremini mõistavad teie kolleegid, mida te tegite. See loob kolleegides positiivse suhtumise teie suhtes ja võimaldab neil mõista, kas vajate abi või mitte.

Ärge kartke otsida abi.

Varem mainisin, et kui probleem ilmneb, peate formuleerima hüpoteesi selle põhjuste ja lahenduste kohta. Kuid juhtub ka, et hüpoteesid ei õigustu, ja iseseisvalt leitud lahendused ei tööta. Sel juhul on parem abi paluda. Et mitte üle koormata kolleege, tuleb iga probleemi üle mõelda iseseisvalt. Kui paar tunni jooksul ei ole lahendust leidnud, on aeg pöörduda kogenumate kaaslaste poole.

Parim on alustada küsimusest: "kas keegi on varem selle probleemiga kokku puutunud?" koos lühikese probleemi kirjeldusega. Soovitav on lisada veateate fragment või ekraanipilt. Seda sõnumit tasub esmakordselt saata mõnda üldisesse töökeskkonna chatti. Nii ei häiri te neid, kes on tõeliselt hõivatud. Vabad kolleegid näevad teie sõnumit ja saavad aidata.

Kui pärast sõnumi saatmist üldises chatis ei ole keegi aidanud, proovige kogenud kolleegi kinni püüda lõuna ajal, tee/kohe, tennisemängu ajal või suitsetamise pausi ajal. Kui see ei õnnestu, siis teatage oma raskustest meeskonna koosolekul või standup'is.

Tuntud probleemide lahendamisel võib see kõik sellega lõppeda. Kui probleem on aga uus, algab uurimine, kus tuleb toimida vastavalt olukorrale.

Uute töötajate "olulised" ülesanded, mis on lõppkasutajale vajalikud, on igavad ja väikesed. Näiteks "lisada lisaveerg raportisse" või "parandada trükiviga printimisel" või "rakendada mudeli meetod kliendi atribuutide laadimiseks andmebaasist". Selliste ülesannete eesmärk on, et uus töötaja tutvub valdkonna sisuga ja integreerub igapäevasesse töövoogu.

Oluline on mitte ainult tehniliselt ülesanne lahendada, vaid ka oma teadmisi valdkonnast laiendada.

Ülesande kirjelduses, vestlustes ja aruteludes esinevad terminid võivad tunduda tuttavad nimisõnadena. Kuid informatsioonisüsteemi kontekstis omandavad need erilisi ja täpsemaid tähendusi. Leitud terminite tähendusi on kõige parem kirja panna spetsiaalsesse dokumenti – terminite sõnaraamatusse. Sõnastikku lisamiseks piisab oma arusaama kirja panemisest, ent õigete seletuste saamiseks on parem pöörduda analüütiku poole. Kui seda ei ole, siis vanade projektiliikmete poole. Terminite sõnaraamatu pidamine on üks lihtsamaid viise kaasamiseks projekti ainealasse.

Niipea kui leiate kolleegidega ühise keele, hakkavad nad nägema teid mitte kui algajat, vaid enda tasemel spetsialistina.

On eritingimusi, näiteks "kirjutada mooduli jaoks unit-testid". Sellise ülesandega ei saa pikalt kinni jääda lahenduste otsimisega. Samas on see tõsine ülesanne, mis ei ole mõeldud ainult algajate koolitamiseks. Kirjeldatud testid suurendavad projekti stabiilsust, vähendades rakenduses vigu ja vähendades inimeste testimisele kuluvat aega. Ideaalses maailmas kirjutatakse unit-testid kohe arendamise käigus, kuid reaalsus on alati erinev. Juhtub, et mooduli arendaja hoiab seda täielikult oma peas ega näe nende kirjutamise vajadust. "Kõik on ju ilmne, et mida siin testida?" Mõnikord kirjutatakse mooduleid kiirusel ja unit-testide jaoks ei jää aega. Seega ei pruugi reaalses maailmas unit-teste olla. Seetõttu antakse ülesanne unit-testide kirjutamiseks algajale. Nii saab praktikant kiiremini projekti sisse elada, samas kui projekt suudab säästa kõrgema palgaga spetsialistide aega.

Juhtub, et praktikantidele ja algajatele antakse ülesanne täita täieõiguslikke testija rolli. Enne seda tuleb tavaliselt toode kohalikult üles seada ja nõuded üle vaadata. Uuselt töötajalt oodatakse järgmisi tulemusi:

küsimused nagu "kui teha nii, siis on tulemus see. Nõuetes seda ei ole. Kuidas peaks olema?"
ülesandeid veakontrollis "nõuetes on kirjas nii, kuid tegelikkuses on teisiti."

Testimine on selle artikli jaoks ülemäära ulatuslik tegevusala. Kui teile on antud sarnane ülesanne, otsige internetist parimaid meetodeid selle täitmiseks.

Vale teed — saad peksa või vallandatakse.

Normaalses organisatsioonis, kui juhtub, et kogenematu töötaja pääseb ligipääsu millelegi kriitilisele ja midagi rikkuda, siis on süüdi see, kes nii lubas. Kogenematutel ei ole vaikimisi juurdepääsu kriitilisele infrastruktuurile. Õige juhtimise korral ei heideta kogu süüd kogenematule praktikantile.

Kui juhtub midagi, ei hakata ühte juhtumit tõttu kedagi vallandama. Inimesed õpivad oma vigadest. Eksinud praktikant sai väärtusliku õppetunni ja erineb sellega teistest praktikantidest. Kui vallandada eksinud, tuleb selle asemele keegi teine, kes eksib täpselt sama moodi.

Oluline on õppida vigadest ja mitte kordama neid.

Kuid kui inimene ei tee oma vigadest järeldusi, proovib temaga lahku minna. Kuid maailm on mitmekesine. Mõnes kuritegelikus organisatsioonis võidakse esimese vea tõttu kohe aknast välja visata. Aga parem on selliseid firmasid vältida, selleks tasub enne uurida või intervjuu ajal rohkem teada saada.

Incidente on parem mitte lubada.

Isegi kui teid isiklikult ei vallandata eksimuse tõttu, toob selline juhtum teie meeskonnale ja projektile kaasa soovimatuid probleeme. Seetõttu olge äärmiselt ettevaatlikud andmebaasi tabelite kustutamise või loomise, failide, teenuste instantside ja projekti teadmistebaasi dokumentide operatsioonidega. Kui kohtate uut ühenduse aadressi, kinnitage vähemalt kahe erineva inimesega, mida seal teha tohib. Kontrollige oma õigusi keskkondades, mitte proovimise ja eksimise meetodil, vaid vastavate käskudega. Näiteks õigused failide kustutamiseks käsu `ls` abil, õigused MySQL tabelitega töötamiseks käsu `SHOW GRANTS FOR ‘user’@’host’;` abil ja nii edasi. Peaaegu igas tööriistas on teil sarnane võimalus.

Failide redigeerimisel hoidke igaks juhuks originaalkoopia.

Praktikandi ja lõppkasutaja vahel luuakse mitu barjääri.

Kui saaksite oma toote otse tarbijale anda, saaksite mitte tööle asuda, vaid heituda 'vabadusse'. Kuid kuniks teil pole sellist võimalust (ja vastutust), peate läbima mitu kontrolliastet projektis.
Esimene neist on juhendaja kontroll. Ta hindab algaja lahendust tehnilisest vaatenurgast. Kui juhendajat ei ole määratud, tuleb see leida. Selleks valige keegi projekti vanematest ning paluge tal tegemisi vaadata: kas ülesanne on õigesti lahendatud? Kui ta hakkab vaatama ja vastama, on juhendaja leitud. Kui ta ignoreerib, tasub küsida veel kedagi.

Järgmiseks on kvaliteedikontroll. Eesti keeles - testijad. Nõukogude ajal - normikontroll ja OTK. Nad peavad veenduma, et praktikandi töö tulemus vastab talle antud ülesandele. Nad harva loevad koodi. Enamasti kontrollivad testijad kogutud projekti, mille arendaja salvestab versioonihaldussüsteemis.

Kolmas etapp on väljaande juht. Selle ülesande jaoks ei pruugi olla eraldi inimest, kuid keegi ikka täidab seda rolli. Ta kontrollib, et testijad on kinnitanud, et projekt võib välja anda. Pärast seda viib ta läbi toote kohaletoimetamise lõppkasutajatele.
Väikestes organisatsioonides võivad need barjäärid erinevatel põhjustel puududa. Siiski ei anta algajale ülesannet millegi olulise muutmiseks. Sest see risk ei ole kellelegi vajalik.

Esiteks tuleb minna lahingusse ja siis vaadata, kuidas läheb.
Napoleon Bonaparte

Loodan, et artikkel aitab sul ületada oma ebakindlust ja saata oma esimese CV. Loomulikult pead sa ette valmistuma. Kuid ei tohi liialt venitada. Sa oled ilmselt juba mitu aastat õppinud ülikoolis või kolledžis. Kuhu veel edasi venitada? Lõppude lõpuks on parem üks kord kuulda "ei" spetsialistilt ja teha oma vigadest õppetunde, kui iga päev öelda endale "ei" ja jääda professionaalses kasvus pidama.

Töötamise ajal tuleb keskenduda sellele, et liikuda praktikandi staatusest täieõiguslikuks meeskonna liikmeks. Selline kasv kaasneb tavaliselt sinu palga suurenemisega.

Soovin sulle kannatlikkust ja visadust.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.