🥇Fjern frygten for at få dit første job

Scene from the movie 'Harry Potter and the Prisoner of Azkaban'

The problem with this world is that educated people are full of doubts, while idiots are full of confidence.
Charles Bukowski

Recently, I conducted another individual programming session. Unlike regular classes, the topic was not the language's structure or problem-solving. The student shared his concerns about future employment. The student was quite intelligent. One of those who comes to the courses, completes the entire program faster than anyone, and with original solutions, but constantly underestimates himself. In my opinion, such doubts arise only from a lack of information. I tried to fill this gap spontaneously during the session.

The questions were roughly like this:

Every year, numerous students graduate from universities and all go looking for jobs. That's a lot of people. Surely, they will hire the best, and I won't get a place.
What if I mess up and get fired immediately?
What if they realize I'm not good at my job and they kick me out?

This student was not the first person to whom I answered such questions. They arise for many, and usually, I have to recount without preparation. This time, I decided to write down my monologue in a notebook. I thought it would result in a couple of paragraphs, but it turned into a whole article.

The article presents my perspective based on my experience. However, our world is very diverse and amazing things happen in it. If you disagree with something or your experience is different, please leave a comment.

This article was written by a developer for developers. However, if you plan to engage in testing, administration, or anything else in IT, some of the advice will still be useful for you.

They won’t hire at all.

When you imagine that every year many universities graduate hundreds of students, it becomes uncomfortable. How can one compete with such a huge crowd?

Desværre har langt fra alle kandidater tilstrækkelig teknisk forberedelse. Prøv at spørge en bekendt studerende fra universitetet: hvordan får folk i hans gruppe adgang til eksamener i fag som "databaser" eller "grundlæggende algoritmisk tænkning og programmering"? I en gruppe på 30 personer er der i bedste fald 3-5 "fremskredne" fyre, som virkelig har gjort det hele selv. De andre bruger bare deres svar til at kopiere, lærer svarene udenad og består.

Det var sådan, det var, da jeg selv studerede. Men min erfaring kunne være ikke-repræsentativ. Derfor stillede jeg dette spørgsmål til flere forskellige studerende. Svaret var nogenlunde det samme. Respondenterne kom fra forskellige universiteter og colleges. Jeg lader overvejelserne om årsagerne forblive uden for denne artikel. Jeg har ikke ressourcerne til en fuld undersøgelse, så jeg vil konkludere på baggrund af de tilgængelige fakta.

Blandt hundredvis af kandidater repræsenterer kun et par dusin en interesse for arbejdsgiverne.

Få kandidater kan udgøre reel konkurrence for en dygtig studerende med godt forberedelse. Selvom du har studeret flittigt, vil du sandsynligvis ikke blive ansat efter det første interview. Måske heller ikke efter det andet. Alt kan gå godt, men det er bedre at indstille sig på belejring snarere end stormangreb. Et mislykket forsøg på at få et job er kun en anledning til at reflektere over fejlene og prøve igen. Jeg vil ikke tale om forberedelse til interviews. Der er allerede skrevet meget om det på internettet. Jeg vil kun sige, at der er nuancer i interviewprocessen, som der næppe er afsat tid til i dit undervisningsprogram. Søg denne information selv, det kan reducere antallet af forsøg.

Vanvid er at gentage den samme handling igen og igen, i håbet om forandring.
Albert Einstein

For at gennemføre interviews uden at det bliver vanvittigt, skal du efter hvert nyt forsøg blive bedre. Husk eller skriv spørgsmålene ned, som blev stillet under interviewet. Når du kommer hjem, gennemgå denne liste og tjek dig selv med hjælp fra internettet. Så vil du forstå, hvor du fejlede, og hvor intervieweren fejlede. Det sker også. Gennemgå eller studere de emner, hvor du svarede dårligt, og prøv igen.

Derudover er der en tydelig sæsonbestemthed på arbejdsmarkedet. Kyndige virksomheder planlægger ansættelserne med hensyntagen til udskrivningsdatoerne fra uddannelsesinstitutioner. Om foråret er der flere jobmuligheder for nybegyndere end på andre tidspunkter. Dog er konkurrencen også højere på dette tidspunkt.

Træt — man bliver fyret

Når man ansætter en person uden erfaring, er der visse forventninger til vedkommende.

Fra en nybegynder forventes:

Kendskab til den generelle tekniske basis
Studie af virksomhedens specifikke fagområde
Beherskelse af de værktøjer og praksisser, der benyttes

I nogle organisationer arrangeres der træningskurser for nybegyndere om de anvendte teknologier, værktøjer og lokale procedurer. For eksempel regler for god opførsel ved brug af virksomhedens e-mail, proceduren for ændring af dokumenter i wikis, lokale særheder ved arbejde med VCS og bug trackere.

Der findes også tekniske introduktionskurser, men deres nyttighed er tvivlsom. Hvis det er kommet til ansættelse, har arbejdsgiverne overbevist sig om, at du har et tilstrækkeligt vidensniveau. Det bedste er at gennemføre sådanne kurser ordentligt som en lille formalitet. Måske vil der faktisk være noget nyttigt i dem.

Når du starter dit arbejde, skal du huske, at en nybegynder bestemt ikke vil få til opgave at løse en hastesag, der er kompleks og samtidig vigtig. Der vil sandsynligvis kun være én af disse egenskaber. Enten en simpel, men hastesag: rette opsætningen, videresende en fil til nogen, reproducere et problem. Eller en kompleks, men uden nogen håb om afslutning — blot for at nybegynderen kan samle så mange erfaringer som muligt. Eller en vigtig, men eksperimentel. For eksempel et projekt, som alle længe har ønsket, men ikke kan finde tid til at realisere.

Opgaverne til at mestre værktøjerne vil være 'komplekse' og kunstige. Det vil sandsynligvis være en forenklet version af det primære system. I sådanne opgaver benyttes den samme teknologi stack og de samme termer fra fagområdet, som i hele projektet. Samtidig vil resultatet ikke blive afleveret til den endelige bruger. Dette kan være demotiverende, men det er bedst at modarbejde denne holdning. Den kunstige opgave skal udføres seriøst, som om projektets skæbne afhænger af den.

Resultatet af at løse din første opgave vil danne det første indtryk af dig hos kollegerne, der ikke var til samtalen.

En anden mulighed for at mestre værktøjet er at "køre projektet på en lokal maskine/testmiljø". Nogle gange er denne proces beskrevet i instrukser. Men de er som regel gamle og delvist uaktuelle. Man kan bringe reel værdi til projektet ved at skrive en ny instruktion med afklaringer på de opståede problemer. Det er næsten det samme som, når man i universitetet skrev rapporter om forskellige discipliner. Dokumentet skal indeholde de handlinger, der skal udføres for at køre projektet.

Handlingsforløbet for at køre produktet på testmiljøet er normalt omtrent som følgende:

klon repositoryet, skift til en bestemt gren eller tag
oprette en konfigurationsfil
forberede databasen
fylde den med testdata
udføre opbygningen eller kompileringen af projektet,
køre et sæt konsolskripter i en bestemt rækkefølge

I processen med at køre systemet lokalt vil der uundgåeligt opstå uventede problemer.

Løsninger på de fundne problemer skal tilføjes til installationsinstruktionen. Så næste gang man følger instruktionen, vil disse problemer ikke opstå. Når man udfylder konfigurationsfiler og kalder skripter, bør man være opmærksom på, hvilket værdi der bruges hvor, og hvad det skal stemme overens med. For eksempel, hvis projektet bygges med et CI-system og derefter køres med et skript, er det vigtigt at forstå, hvor man skriver navnet på grenen eller commit-nummeret. Det kan ske, at skriptet forudsætter overførsel IP-adresser eller DNS-navnet på databasen, dens login og adgangskode. I så fald skal man vide, hvilken adresse der bruges til testmiljøet, hvilke logins der findes der, og hvilke adgangskoder der skal angives for dem.

Nogle opgaver kan virke enkle for erfarne udviklere og skabe vanskeligheder for praktikantene. Det er en normal hændelse.

Udviklere står dagligt over for tekniske problemer. De erfarne medarbejdere har allerede løst mange problemer, mens de nye endnu skal arbejde sig igennem dem. Den bedste taktik vil være at dokumentere alle de fejl, der opstår, i et dokument "problemhåndtering med ${opgave_navn}". For hvert problem skal man formulere en hypotese om årsagen, finde løsningsmuligheder på internettet og systematisk prøve dem. Resultatet af hver forsøg skal også dokumenteres.

At nedfælde dine overvejelser i et dokument giver mulighed for:

at frigøre dit sind fra små detaljer. For eksempel konfigurationsparametre, DNS/IP-adresser, konsolkommandoer og SQL-forespørgsler.
at huske "hvad gjorde jeg i går" når opgaven strækker sig over flere dage
at undgå at gå i ring. Du kan altid læse, hvad du har gjort tidligere og forstå, at du er vendt tilbage til det oprindelige problem
klart at svare på spørgsmålet: "hvad har du lavet i dag?" selvom der ikke er en endelig løsning endnu.

Du skal være i stand til at fortælle dine kolleger status på dine opgaver

Af og til vil kolleger være interesserede i dine fremskridt og dele deres egne. Til dette afsættes der dagligt eller ugentligt lidt tid.

Hvis du ikke holder styr på de problemer, du støder på og løser, vil din beskrivelse af dine fremskridt lyde som: "Jeg forsøgte at løse opgaven, men det lykkedes mig ikke. Jeg søger stadig et svar." Fra en sådan fortælling er det uklart, om praktikanten har lavet noget eller bare har læst på Habr. Har han brug for hjælp? Er situationen ændret siden i går?

Hvis du fører et dokument med løsningsforsøg, kan du sige, "jeg arbejder på denne opgave. Jeg stødte på disse fejl. Jeg har løst disse på den måde. Denne har jeg endnu ikke løst. Her er nogle hypoteser og løsningsmuligheder. Jeg tester dem lige nu."

Hvis opgaven kan måles på nogen måde, bør der være tal i status. For eksempel for opgaven "skrive unit tests for modulet" kan du sige "jeg planlægger at lave 20 tests, jeg har nu skrevet 10."

Jo flere detaljer du giver, desto bedre vil dine kolleger forstå, hvad du har lavet. Det vil skabe en positiv opfattelse hos kollegerne og lade dem forstå, om du har brug for hjælp eller ej.

Tøv ikke med at bede om hjælp

Jeg nævnte tidligere, at når et problem opstår, skal du formulere en hypotese om dets årsager og mulige løsninger. Men der kan være tilfælde, hvor hypoteser ikke holder, og de selvfundne løsninger på problemet ikke virker. I så fald er det bedst at bede om hjælp. For ikke at overbelaste kollegernes opmærksomhed bør du først prøve at finde en løsning selv. Hvis du ikke har fundet en løsning efter et par timer, er det tid til at søge råd fra mere erfarne kolleger.

Det bedste er at starte med spørgsmålet: "Har nogen oplevet problemet før?" med en kort beskrivelse af problemet. Det er ønskeligt at vedlægge en del af fejlmeddelelsen eller et screenshot. Denne besked bør første gang sendes til en fælles arbejdschat. På den måde forstyrrer du ikke dem, der faktisk er optaget. Frie kolleger vil se din besked og kunne hjælpe.

Hvis ingen hjælper efter beskeden i den fælles chat, så prøv at fange en erfaren kollega under en pause: til frokost, når du skal hente te/kaffe, til en tenniskamp eller en rygepause. Hvis det ikke lykkes, så del dine vanskeligheder på et møde eller en standup.

Når det gælder kendte problemer, kan det være, at det stopper her. Men hvis problemet er nyt, vil der starte en efterforskning, hvor man skal handle efter omstændighederne.

De "vigtige" opgaver for nybegyndere, som er nødvendige for slutbrugeren, vil være trælse og små. For eksempel "tilføje en ekstra kolonne til rapporten" eller "rette en skrivefejl i formularen" eller "implementere en metode til at hente kundens attributter fra databasen". Målet med sådanne opgaver er, at nybegynderen skal blive bekendt med emneområdet og integrere sig i det daglige arbejde.

Det er vigtigt ikke kun at løse opgaven teknisk, men også at udvide sin viden om emneområdet.

I beskrivelsen af opgaven, i chats og samtaler vil der være termer. De kan se ud som velkendte substantiver. Men inden for informationssystemet får de en særlig, mere præcis betydning. Det er bedst at notere betydningen af de opdagede termer i et særligt dokument - et term dictionary. Når du tilføjer til ordbogen, er det tilstrækkeligt at skrive din forståelse af ordet, men for en autentisk forklaring bør du henvende dig til analytikeren. Hvis han ikke er til stede, så til de erfarne medlemmer af projektet. At føre en termordbog er en af de nemmeste måder at blive fortrolig med projektets emneområde på.

Så snart du finder fælles fodslag med kollegerne, vil de begynde at se dig som ikke en nybegynder, men som en ligestillet specialist.

Der er specielle opgaver, for eksempel 'at skrive unit-tests til moduler'. Det er usandsynligt, at man kan hænge fast i at finde løsninger på dem i længere tid. Samtidig er det en alvorlig opgave, der ikke kun er til for at træne praktikanten. De skrevne tests øger projektets stabilitet ved at reducere fejl i applikationen og forkorte tiden til manuel testning. I en ideel verden skrives unit-tests straks under udviklingen, men virkeligheden er som sædvanlig anderledes. Nogle gange har moduludvikleren hele modulen i hovedet og ser ikke behovet for at skrive dem. 'Det er alt sammen så indlysende, hvad skal der testes her?' Nogle gange skrives modulerne i en hast og der er ikke tid til unit-tests. Så i den virkelige verden kan unit-tests mangle. Derfor gives opgaven om at skrive unit-tests til nybegynderen. På den måde kan praktikanten hurtigere vænne sig til projektet, og projektet kan spare tid for de mere højtbetalte specialister.

Det sker, at praktikanter og nybegyndere får tildelt rollen som fuldgyldige testere. Normalt skal de først opsætte produktet lokalt og læse kravene. Som resultat forventes den nye medarbejder at have:

spørgsmål som 'hvis jeg gør det sådan, vil resultaterne være sådan. Det er ikke nævnt i kravene. Hvordan skal det være?'
opgaver i bug-tracker som 'det er skrevet sådan i kravene, men virkeligheden er en anden'.

Testning er et alt for omfattende område for denne artikel. Hvis du får tildelt en opgave som denne, så søg på internettet, hvordan du bedst udfører den.

Hvis du laver fejl - så vil du blive fyret.

I en normal organisation, hvis en uerfaren medarbejder pludselig får adgang til noget kritisk og ødelægger noget, så vil den, der muliggjorde det, være ansvarlig. Fordi en ny medarbejder som standard ikke har adgang til den kritiske infrastruktur. Med passende ledelse vil man ikke hive alt skylden ned over den uerfarne praktikant.

Hvis der skulle ske noget, vil man ikke fyre nogen for en enkelt hændelse. Mennesker lærer af deres fejl. Den praktikant, der begik en fejl, fik en værdifuld lektie og adskiller sig derfor fra andre praktikanter. Hvis man fyrede den, der lavede fejl, ville en anden komme ind på hans plads og lave det samme.

Det vigtigste er at lære af fejlene og ikke gentage dem.

Hvis en person ikke lærer af sine fejl, så vil man forsøge at tage afsked med dem. Verden er dog mangfoldig. I en eller anden banditorganisation kan man blive smidt ud af vinduet for den første fejl. Men det er bedre at undgå sådan nogle firmaer, så sørg for at lave dine undersøgelser eller få mere information under samtalen.

Incidencer bør undgås.

Selv hvis du personligt ikke bliver fyret for en fejl, vil hændelsen skabe uønskede problemer for dit team og projektet generelt. Så vær særligt forsigtig med operationer for at slette eller oprette tabeller i databasen, filer, instanser af tjenester og dokumenter i projektets vidensdatabase. Hvis du støder på en adresse til en ny forbindelse, så bekræft i det mindste med to forskellige personer, hvad der kan gøres der. Kontroller dine rettigheder i miljøerne ikke ved prøv-og-fejl, men med de korrekte kommandoer. For eksempel rettigheder til at slette filer med kommandoen `ls`, rettigheder til at arbejde med tabeller i MySQL med kommandoen `SHOW GRANTS FOR ‘user’@’host’;` og så videre. Næsten i ethvert værktøj vil du have en lignende mulighed.

Når du redigerer filer, så gem lige en kopi af originalen.

Der opbygges flere barrierer mellem praktikanten og den endelige forbruger.

Hvis du straks kunne give dit produkt til forbrugeren, ville du kunne undgå at få et job og i stedet kaste dig ud i "frilans". Men indtil du har den mulighed (og ansvar), skal du gennemgå flere kontrolfaser i projektet.
Den første er mentorvurderingen. Han vurderer nybegynderens løsning fra et teknisk synspunkt. Hvis der ikke er udnævnt en mentor, skal man finde en. For at gøre dette skal man vælge en af de erfarne medlemmer af projektet og i pausen bede dem kigge på løsningen: Er problemet løst korrekt? Hvis de begynder at se på det og svare, så er mentoren fundet. Hvis de ignorerer det, så er det værd at spørge en anden.

Næste fase er Quality Assurance. På dansk — testere. På gammeldansk — normal kontrol og kvalitetskontrol. De skal sikre, at praktikanternes arbejde svarer til den opgave, der er givet til dem. De vil sjældent læse koden grundigt. Ofte vil testerne tjekke det samlede projekt, som udvikleren gemmer i versionskontrolsystemet.

Den tredje fase er release manager. Der kan muligvis ikke være en specifik person til denne opgave, men nogen udfører stadig rollen. De kontrollerer, at testerne har bekræftet, at projektet kan frigives. Derefter udfører de handlinger for at levere produktet til slutbrugerne.
I små organisationer kan disse barrierer af forskellige grunde mangle. Dog vil de ikke give nybegynderen opgaven med at ændre noget vigtigt. Fordi denne risiko er unødvendig for nogen.

Man skal først kaste sig ud i kampen, så ser man, hvad der sker.
Napoleon Bonaparte

Jeg håber, at denne artikel hjælper dig med at overvinde din usikkerhed og sende dit første CV. Selvfølgelig skal du forberede dig først. Men du skal ikke trække den for længe. Du har sandsynligvis allerede studeret i flere år på universitetet eller højskolen. Hvad mere skal du vente på? I sidste ende er det bedre at høre "nej" én gang fra en specialist og arbejde med dine fejl end hver dag at sige "nej" til dig selv og stoppe din professionelle udvikling.

Efter ansættelsen skal du fokusere på at udvikle dig fra praktikant til et fuldt medlem af teamet. En sådan vækst følges normalt af en stigning i din løn.

Ønsker dig tålmodighed og vedholdenhed.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.