🥇Opravičimo strah pred prvim zaposlitvijo

Kadr iz k/ф «Harry Potter in zapornik Azkabana»

Težava tega sveta je v tem, da so vzgojeni ljudje polni dvomov, neumni pa prepolni samozavesti.
Čarls Bukovski

Nedavno sem izvajal naslednjo individualno lekcijo programiranja. V nasprotju s običajnimi lekcijami tema ni bila struktura jezika ali težava pri reševanju naloge. Študent je delil svoje skrbi glede prihodnjega zaposlovanja. Sam učenec je bil kar pameten. Eden tistih, ki pridejo na tečaje, hitro preidejo celotno program in z izvirnimi rešitvami, vendar ves čas iskreno podcenjujejo sebe. Po mojem mnenju takšni dvomi izvirajo le iz pomanjkanja informacij. To vrzel sem poskušal zapolniti improvizirano med lekcijo.

Vprašanja so bila približno taka:

Vsako leto z univerz izide veliko študentov, ki gredo iskati delo. To je res veliko ljudi. Verjetno bodo vzeli najboljše, meni pa ne bo ostalo prostora.
Kaj če naredim napako in me takoj odpustijo?
Kaj če med delom ugotovijo, da sem neumen in me izločijo?

Ta študent ni bil prva oseba, ki sem ji odgovarjal na podobna vprašanja. Pojavljajo se pri mnogih, in običajno je potrebno brez priprave razložiti. Tokrat sem se odločil, da si svoj monolog zabeležim v zvezek. Mislil sem, da bo nastalo nekaj odstavkov, a je zraslo v celo članek.

V članku je opisan pogled z moje perspektive in temelji na mojih izkušnjah. Vendar je naš svet zelo raznolik in v njem se dogajajo neverjetne stvari. Če se s čim ne strinjate ali so vaše izkušnje drugačne, pišite, prosim, komentar.

Članek je napisan od razvijalca za razvijalce. Vendar, če načrtujete, da se boste ukvarjali s testiranjem, administracijo ali s čim drugim v IT, vam bo del nasvetov prav tako koristen.

Sploh te ne bodo najeli.

Ko si predstavljaš, da vsako leto veliko univerz izda na stotine študentov, postane nelagodno. Kako se konkurirati s tako ogromno množico?

Žal mi je, da ne vse diplomanje imajo zadostno tehnično znanje. Poskusite vprašati kakšnega študenta na univerzi: kako ljudje v njegovi skupini pridobijo dostop do izpitov iz predmetov, kot so "baze podatkov" ali "osnove algoritmizacije in programiranja"? V skupini, ki šteje 30 ljudi, se v najboljšem primeru najde 3-5 "naprednih" posameznikov, ki so vse res naredili sami. Ostali prepisujejo od njih, se učijo odgovore na vprašanja in izpite opravljajo.

Tako je bilo, ko sem se sam učil. Vendar se moj izkušnja morda ne odraža v splošni sliki. Zato sem to vprašanje postavil več različnim študentom. Odgovor je bil približno enak. Odgovarjajoči so bili iz različnih univerz in šol. Razpravljanje o razlogih bom pustil zunaj tega članka. Na celovito raziskavo nimam dovolj virov, zato bom naredil zaključek na podlagi razpoložljivih dejstev.

Med stotinami diplomantov le peščica dvajsetih predstavlja zanimanje za delodajalce.

Redki diplomanti lahko predstavljajo resno konkurenco sposobnemu študentu z dobrim znanjem. Kljub temu, tudi če ste se marljivo učili, vas najverjetneje po prvem razgovoru ne bodo zaposlili. Po drugem, verjetno tudi ne. Vse se lahko dobro izteče, vendar je bolje, da se ne pripravljate na napad, temveč na obleganje. Neuspešen poskus zaposlitve je le priložnost, da se osredotočite na napake in poskusite znova. O pripravi na razgovore ne bom govoril. Na to temo je že napisanih precej. Povem samo, da v postopki razgovorov obstajajo podrobnosti, za katere verjetno ne bo dovolj časa v vašem izobraževalnem programu. Poiščite te informacije sami, lahko zmanjšate število poskusov.

Norost je natančno ponavljanje istega dejanja. Tisočkrat, v upanju na spremembo.
Albert Einstein

Da bi razgovori ne postali norost, se morate po vsakem novem poskusu izboljšati. Zapomnite si ali zapišite vprašanja, ki so vam jih postavili med razgovorom. Ko se vrnete domov, preglejte ta seznam in se preizkusite s pomočjo interneta. Tako boste razumeli, kje ste naredili napako, in kje - razgovarjalec. Tudi to se zgodi. Ponovite ali preučite teme, na katere ste slabo odgovorili, in poskusite znova.

Poleg tega obstaja izrazita sezonskost trga dela. Pametne podjetja načrtujejo zaposlovanje ob upoštevanju datumov zaključkov izobraževanja. Spomladi je več prostih delovnih mest za novince kot v preostalem času. Vendar pa je v tem času tudi konkurenca višja.

Neprimeren — odpravili bodo.

Ko zaposlijo osebo brez izkušenj, so pričakovanja glede nje ustrezna.

Od novinca na delovnem mestu se pričakuje:

Poznavanje osnovne tehnične baze.
Študij posebnosti predmetne dejavnosti podjetja.
Obvladovanje uporabljenih orodij in praks.

V nekaterih organizacijah za novince organizirajo izobraževalne tečaje o uporabljenih tehnologijah, orodjih in lokalnih uredbah. Na primer, pravila dobrega obnašanja pri uporabi korporativne elektronske pošte, postopek spremembe dokumentov v wiki, lokalne značilnosti dela z VCS in napakami.

Obstajajo tudi tehnični uvodni tečaji, vendar je njihova uporabnost vprašljiva. Če smo prišli do zaposlitve, so se delodajalci prepričali, da imate nek dovolj osnoven nivo znanja. Najbolje je, da takšne tečaje preprosto opravite vestno, kot majhno formalnost. Morda bo v njih res nekaj koristnega.

Ko boste začeli z delom, imejte v mislih, da novincu zagotovo ne bodo naložili reševanja nujne, kompleksne in hkrati pomembne naloge. Verjetno bo le eno od teh lastnosti. Bodisi enostavna, a nujna: popraviti postavitev, poslati komu datoteko, reproducirati problem. Bodisi kompleksna, a brez vsakega upanja na zaključek — da bi novinec nabral čim več izkušenj. Bodisi pomembna, a eksperimentalna. Na primer, projekt, ki si ga vsi dolgo želijo, a ne morejo nameniti časa za njegovo uresničitev.

Naloge za osvajanje orodij bodo 'zapleteni' in umetni. Verjetno bo to poenostavljena različica osnovnega sistema. V takšnih nalogah se uporablja ista tehnologija in iste terminologije iz predmetne dejavnosti, kot v celotnem projektu. Pri tem rezultat izvedbe ne bo predan končnemu uporabniku. To lahko demotivira, vendar se je bolje upreti temu občutku. Umetno nalogo je treba opraviti vestno, kot da je od nje odvisna usoda projekta.

Rezultat reševanja vaše prve naloge bo ustvaril prvi vtis o vas pri sodelavcih, ki niso bili na razgovoru.

Drug način dela z orodjem je "zagon projekta na lokalnem računalniku/testnem okolju". Včasih je ta postopek opisan v navodilih. Vendar so le-ta ponavadi zastarela in v nekaterih delih neaktualna. Lahko prinesete resnično korist projektu, če napišete nova navodila z dodatki o nastalih težavah. Verjetno ste na fakulteti pisali RGR za poročilo iz nekaterih predmetov. To je skoraj isto. V dokumentu morajo biti opisani koraki, ki jih je treba izvesti za zagon.

Običajno so koraki za zagon izdelka v testnem okolju približno taki:

klonirati repozitorij, preklopiti na neko vejo ali oznako
pripraviti kakšno konfiguracijsko datoteko
pripraviti strukturo podatkovne baze
jo napolniti s testnimi podatki
izvesti gradnjo ali prevajanje projekta,
zagnati niz konzolnih skriptov v določenem zaporedju

Med lokalnim zagonom sistema se neizogibno pojavljajo nepredvidene težave.

Rešitve za ugotovljene težave je treba dopisati v navodila za namestitev. Tako naslednjič ob upoštevanju navodil te težave ne bodo več nastajale. Pri izpolnjevanju konfiguracijskih datotek in klicanju skriptov je treba biti pozoren, katera vrednost se kje uporablja in s čim se mora ujemati. Na primer, če se projekt gradi s CI-sistemom in nato zažene s skriptom, je pomembno razumeti, kam vnesti ime veje ali številko potrditve. Občasno se zgodi, da skript predvideva prenos IP-naslove ali DNS ime podatkovne baze, njenega uporabniškega imena in gesla. V tem primeru morate vedeti, kateri naslov uporabiti za testno okolje, kateri uporabniški imeni so tam in katera gesla je treba navesti.

Nekatere naloge se lahko zdijo preproste izkušenim razvijalcem in predstavljajo težave za pripravnike. To je normalno.

Razvijalci se vsakodnevno soočajo s tehničnimi težavami. Izkušeni zaposleni so že rešili številne težave, medtem ko se novinci še vedno morajo spopasti z njimi. Najboljša taktika je zapisovanje vseh srečanih napak v dokument "reševanje težav z ${naziv naloge}". Za vsak problem je potrebno oblikovati hipotezo o vzroku, poiskati rešitve na spletu in jih po vrsti preizkusiti. Rezultat vsakega poskusa je prav tako potrebno zabeležiti.

Oblikovanje vaših raziskav v obliki dokumenta omogoča:

izprazniti um od drobnih podrobnosti. Na primer parametri konfiguracije, DNS/IP naslovi, konzolne ukaze in SQL poizvedbe.
spomniti se "kaj sem počel včeraj", ko se naloga raztegne na več dni.
ne tavati v krogu. Vedno boste lahko prebrali, kaj ste prej počeli, in razumeli, da ste se vrnili k izvorni težavi.
jasno odgovoriti na vprašanje: "kaj si danes naredil?", tudi če predloga še ni.

Morate znati poročati o stanju svojih nalog sodelavcem.

Občasno vas bodo sodelavci spraševali o vaših uspehih in delili svoje. Na to se vsakodnevno ali tedensko nameni nekoliko časa.

Če ne spremljate srečanih in rešenih težav, bo vaše poročilo izgledalo takole: "Poskušal sem izvesti nalogo, vendar mi ni uspelo. Še vedno iščem rešitev." Iz takega poročila ni jasno, ali je praktikant kaj delal ali samo bral Habr. Ali potrebuje pomoč? Se je situacija spremenila od včeraj?

Če vodite dokument z iskanjem rešitev, boste lahko rekli: "Poskušam izvesti to nalogo. Imam take napake. Te sem rešil tako. Teh še nisem obvladal. Imam take hipoteze in možnosti rešitev. Trenutno jih preverjam."

Če je nalogo mogoče meriti, naj v stanju zvenijo številke. Na primer za nalogo "napisati enotne teste za modul" lahko rečete "namestim 20 testov, trenutno sem napisal 10."

Bolj kot boste podrobni, boljši bodo vaši sodelavci razumeli, kaj ste počeli. To bo ustvarilo pozitivno mnenje o vas in jim omogočilo, da razumejo, ali potrebujete pomoč ali ne.

Ne oklevajte in prosite za pomoč.

Prej sem omenil, da ob pojavu težave morate oblikovati hipotezo o njenih vzrokih in rešitvah. Vendar se zgodi, da hipoteze niso utemeljene, rešitve, ki jih najdete sami, ne delujejo. V takem primeru je bolje poiskati pomoč. Da ne bi zlorabljali pozornosti sodelavcev, je treba pri vsaki težavi najprej poskusiti sami. Če v dveh urah ne uspete najti rešitve, je čas, da poiščete nasvet pri bolj izkušenih kolegih.

Najbolje je začeti s vprašanjem: „Ali se je kdo že srečal s to težavo?“ z kratkim opisom težave. Priporočljivo je priložiti del sporočila o napaki ali posnetek zaslona. To sporočilo je najbolje prvič poslati v nek skupni delovni klepet. Tako ne motite tistih, ki so dejansko zaposleni. Prosti sodelavci bodo ob tem videli vaše sporočilo in vam lahko pomagali.

Če po sporočilu v skupnem klepetu nihče ne pomaga, poskusite uloviti izkušenega kolega med odmorom: kosilom, poizkusom za čaj/kavo, tekmo v tenisu ali med odmori. Če to ne uspe, pa o svojih težavah obvestite na sestanku ali standupu.

Pri reševanju znanih težav je lahko to tudi vse. Če je težava nova, pa se začne preiskava, kjer bo treba ukrepati glede na okoliščine.

„Pomembne“ naloge novincev, ki jih potrebuje končni uporabnik, so lahko dolgočasne in majhne. Na primer „dodati dodatno stolpec v poročilo“ ali „popraviti tipkarsko napako v tiskani obliki“ ali „izvesti metodo modela za nalaganje atributov stranke iz SGBD“. Namen teh nalog je, da se novinec seznani s predmetno področje in vklopi v vsakodnevno delo.

Pomembno je ne le tehnično rešiti nalogo, temveč tudi razširiti znanje o predmetnem področju.

V opisu naloge, v klepetih in pogovorih se bodo pojavljali izrazi. Morda bodo videti kot dolgo znana samostalnika. Vendar pa v okviru informacijske sistemu pridobijo poseben, natančnejši pomen. Pomembnost odkritih izrazov je najbolje zapisati v poseben dokument — slovar izrazov. Pri dodajanju v slovar je dovolj, da zapišete svoje razumevanje besede, za pravo razlago pa se raje obrnite na analitika. Če ta ni na voljo, pa na starejše člane projekta. Voditi slovar izrazov je enostaven način, kako se seznaniti s tematsko področjem projekta.

Ko enkrat najdete skupen jezik s kolegi, vas bodo začeli videti ne kot novinca, temveč kot enakovrednega strokovnjaka.

Obstajajo posebne naloge, kot je 'napisati enotne teste za modul'. Na njej se verjetno ne morete dolgo zadrževali pri iskanju rešitev. Hkrati pa je dovolj resna in ni namenjena le izobraževanju novincev. Napisani testi povečujejo stabilnost projekta z zmanjšanjem napak v aplikaciji in zmanjšanjem časa, ki ga porabijo ljudje za testiranje. V idealnem svetu se enotni testi pišejo takoj med razvojem, a je resničnost vedno drugačna. Včasih razvijalec modula vse drži v glavi in ne vidi potrebe po pisanju testov. 'Vse je očitno, kaj naj testiram tukaj?' Občasno se moduli pišejo v naglici in za enotne teste ni več časa. Zaradi tega nalogo pisanja enotnih testov dodelijo novincu. Tako se bo novinec hitreje umeščal v projekt, projekt pa lahko prihrani čas bolje plačanih strokovnjakov.

Včasih novincem in začetnikom dodelijo vlogo popolnih testirnikov. Običajno je pred tem treba lokalno namestiti izdelek in prebrati zahteve. Od novega zaposlenega se običajno pričakuje:

vprašanja, kot so 'če to narediti tako, bo rezultat takšen. V zahtevah tega ni. Kako mora biti?'
naloge v sistemu za sledenje napakam 'v zahtevah je napisano tako, v praksi pa drugače'.

Testiranje je izjemno širok področje dejavnosti za ta članek. Če ste dobili takšno nalogo, poiščite na spletu, kako jo najbolje opraviti.

Če narediš napako — te odpustijo.

V normalni organizaciji, če se zgodi, da nepotrjen zaposleni dobi dostop do nečesa kritičnega in nekaj pokvari, je kriv tisti, ki je to omogočil. Ker novinec po definiciji nima dostopa do kritične infrastrukture. Pri ustreznem vodenju ne bodo vse krivde pripisali nepotehnemu praktikantu.

Če se zgodijo incidenti, nekoga ne bodo odpustili zaradi enega samega dogodka. Ljudje se učijo na napakah. Napačno delujoči praktikant je prejel dragoceno lekcijo in se tako močno razlikuje od drugih praktikantov. Če odpustite nekoga, ki je naredil napako, bo na njegovo mesto prišel nekdo drug in bo naredil enako napako.

Pomembno je, da se učimo iz napak in jih ne ponavljamo.

Če pa oseba ne potegne zaključkov iz svojih napak, se bodo z njo verjetno poslovili. Vendar pa je svet raznolik. V kakšni kriminalni organizaciji te lahko vržejo skozi okno zaradi prve napake. Bolje je, da se izogibate takšnim podjetjem, zato je dobro predhodno raziskati ali izvedeti več med razgovorom.

Incidentov je bolje ne dopuščati.

Tudi če vas osebno ne odpustijo zaradi napake, bo tak incident povzročil nezaželene težave vaši ekipi in projektu kot celoti. Zato bodite še posebej previdni pri operacijah brisanja ali ustvarjanja tabel v podatkovni bazi, datotek, instanc storitev in dokumentov v bazi znanja projekta. Če naletite na naslov nove povezave, se vsaj pri dveh različnih osebah pozanimajte, kaj tam lahko počnete. Preverjajte svoje pravice v okolju ne z metodo poskušanja in napak, ampak z ustreznimi ukazi. Na primer pravice za brisanje datotek s pomočjo ukaza `ls`, pravice za delo s tabelami v mysql s pomočjo ukaza `SHOW GRANTS FOR ‘user’@’host’;` in podobno. V praktično katerem koli orodju boste imeli podobno možnost.

Pri urejanju datotek, za vsak primer shranite kopijo izvirnika.

Med praktikantom in končnim uporabnikom je postavljenih več preprek.

Če bi lahko takoj posredovali svoj izdelek končnemu uporabniku, se ne bi potrebovali zaposliti, temveč bi se podali v 'prosto plavanje'. Toda dokler te možnosti (in odgovornosti) nimate, morate preiti skozi več kontrolnih stopenj v projektu.
Prva stvar je provjera od strane mentora. On procjenjuje rješenje novaka s tehničkog stajališta. Ako mentor nije bio imenovan, treba ga pronaći. Da biste to učinili, odaberite nekoga od iskusnih članova projekta i na odmoru ga zamolite da pogleda rješenje: je li zadatak pravilno riješen? Ako počne gledati i odgovarati, mentor je pronađen. Ako ignorira — potražite još nekoga.

Sljedeća faza je Quality Assurance. Na slovenščini — testerji. Sovjetski rečeno — normokontrola i OTK. Oni moraju osigurati da rezultat rada pripravnika odgovara postavljenoj zadaći. Rijetko će se posvetiti analizi koda. Često će testerji provjeravati gotov projekt koji programer sprema u sustav kontrole verzija.

Treća faza je menadžer za izdanje. Posebna osoba za ovaj zadatak možda ne postoji, ali ulogu ipak netko obavlja. On provjerava jesu li testerii potvrdili da se projekt može izbaciti. Nakon toga, izvršava radnje za isporuku proizvoda krajnjim korisnicima.
U malim organizacijama ti se barijere iz raznih razloga mogu izostaviti. Međutim, ne daju se pripravniku zadatci vezani za promjenu nečega važnog. Jer taj rizik nikome nije potreban.

Prvo se treba upustiti u borbu, a onda će se vidjeti.
Napoleon Bonaparte

Nadam se da će vam članak pomoći da prevladate svoju nesigurnost i pošaljete svoj prvi životopis. Naravno, prethodno se morate pripremiti. Ali nemojte previše odugovlačiti. Vjerojatno ste već neko vrijeme studirali na fakultetu ili u školi. Kuda dalje? Na kraju, bolje je jednom čuti "ne" od stručnjaka i učiniti analizu grešaka nego svaki dan sebi govoriti "ne" i stati u profesionalnom razvoju.

Nakon zapošljavanja, trebate se usredotočiti na to da iz pripravnika postanete punopravni član tima. Takav rast obično prati povećanje vaše plaće.

Želim vam strpljenje i upornost.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite se, molim vas.