🥇 At slippe af med frygt før dit første job

Still fra filmen "Harry Potter and the Prisoner of Azkaban"

Problemet med denne verden er, at uddannede mennesker er fulde af tvivl, men idioter er fulde af selvtillid.
Charles Bukowski

Jeg underviste for nylig en anden en-til-en programmeringslektion. I modsætning til almindelige timer var emnet ikke sprogkonstruktion eller problemløsning. Den studerende delte sine bekymringer om fremtidig ansættelse. Eleven selv var ret klog. En af dem, der kommer på kurset, gennemfører hele programmet hurtigere end nogen anden og med originale løsninger, men hele tiden undervurderer han oprigtigt sig selv. Efter min mening opstår sådan tvivl kun på grund af mangel på information. Jeg forsøgte at udfylde dette hul improviseret i løbet af lektionen.

Spørgsmålene lød sådan her:

Hvert år dimitterer mange studerende fra universiteter, og de søger alle arbejde. Det er mange mennesker. De vil nok ansætte de bedste, men jeg får ikke en plads.
Hvad hvis jeg roder og bliver fyret med det samme?
Hvad hvis de under arbejdet indser, at jeg er dum og sparker mig ud?

Denne elev var ikke den første person, jeg besvarede sådanne spørgsmål til. Mange mennesker har dem, og som regel skal de fortælles uden forberedelse. Denne gang besluttede jeg at skrive min monolog ned i en notesbog. Jeg troede, det ville være et par afsnit, men det endte med at være nok til en hel artikel.

Artiklen beskriver synspunktet fra mit synspunkt og baseret på min erfaring. Men vores verden er meget forskelligartet, og der sker fantastiske ting i den. Hvis du er uenig i noget eller din oplevelse er anderledes, så skriv en kommentar.

Artiklen er skrevet af en udvikler til udviklere. Men planlægger du at lave test, administration eller andet inden for IT, så vil nogle af rådene også være nyttige for dig.

De vil slet ikke ansætte dig

Når man forestiller sig, at mange universiteter uddanner hundredvis af studerende hvert år, bliver det ubehageligt. Hvordan konkurrerer man med så stort et publikum?

Desværre er det ikke alle kandidater, der har tilstrækkelig teknisk uddannelse. Prøv at spørge en universitetsstuderende, du kender: Hvordan får folk i hans gruppe adgang til eksamen i discipliner som "databaser" eller "grundlæggende om algoritmisering og programmering"? I en gruppe på 30 personer vil der i bedste fald være 3-5 "avancerede" fyre, som faktisk gjorde alt selv. Resten kopierer du blot fra dem, propper svar på spørgsmål og sender dem.

Sådan var det, da jeg studerede på egen hånd. Men min erfaring er måske ikke repræsentativ. Så jeg stillede dette spørgsmål til flere forskellige elever. Svaret var stort set det samme. Respondenterne var fra forskellige universiteter og gymnasier. Jeg vil efterlade diskussioner om årsagerne uden for rammerne af denne artikel. Jeg har ikke tid nok til en fuldgyldig undersøgelse, så jeg vil drage en konklusion ud fra de tilgængelige fakta.

Blandt hundredvis af kandidater er kun et par dusin af interesse for arbejdsgivere

Få kandidater kan give reel konkurrence om en dygtig studerende med god forberedelse. Men selvom du har studeret samvittighedsfuldt, vil du højst sandsynligt ikke blive ansat efter den første samtale. Efter den anden formentlig også. Alt kan vise sig godt, men det er bedre at forberede dig ikke på et overfald, men på en belejring. Et mislykket forsøg på at få et job er kun en grund til at arbejde på dine fejl og prøve igen. Jeg vil ikke tale om forberedelse til samtaler. Der er allerede skrevet meget om dette emne på internettet. Jeg vil bare sige, at der er nuancer i at interviewe, som dit træningsprogram nok ikke vil tage sig tid til at forklare. Søg selv efter disse oplysninger, det kan reducere antallet af forsøg.

Galskab er den nøjagtige gentagelse af den samme handling. Gang på gang i håb om forandring
Albert Einstein

For at forhindre, at interviews bliver til vanvid, skal du forbedre dig efter hvert nyt forsøg. Husk eller skriv de spørgsmål ned, du blev stillet under interviewet. Når du vender hjem, så se denne liste igennem og tjek dig selv ved hjælp af internettet. På denne måde vil du forstå, hvor du og intervieweren lavede en fejl. Dette sker også. Gennemgå eller undersøg de emner, du klarede dig dårligt på, og prøv igen.

Derudover er der en udtalt sæsonudsving på arbejdsmarkedet. Smarte virksomheder planlægger ansættelser baseret på eksamensdatoer. Der er flere ledige pladser til tilflyttere i foråret end på andre tidspunkter. Konkurrencen er dog højere på nuværende tidspunkt.

Dumt - bliv fyret

Når en person uden erfaring ansættes, er der tilsvarende forventninger til ham.

En nybegynder til jobbet forventes at:

Kendskab til generel teknisk basis
Studerer de særlige forhold i virksomhedens fagområde
Beherskelse af de anvendte værktøjer og praksis

Nogle organisationer tilbyder kurser for nytilkomne om de anvendte teknologier, værktøjer og lokale procedurer. For eksempel gode manerer ved brug af virksomheds-e-mail, proceduren for at ændre dokumenter i en wiki, lokale funktioner ved at arbejde med VCS og en fejlsporing.

Der er også tekniske introduktionskurser, men deres anvendelighed er tvivlsom. Hvis det kommer til beskæftigelse, så er arbejdsgiverne overbevist om, at du har et tilstrækkeligt vidensniveau. Det er bedst blot at tage sådanne kurser i god tro, som en lille formalitet. Måske vil der faktisk være noget brugbart i dem.

Når du begynder at arbejde, så husk, at en nybegynder bestemt ikke vil blive betroet til at løse en presserende, kompleks og samtidig vigtig opgave. Mest sandsynligt vil der kun være én af disse ejendomme. Eller simpelt, men presserende: Ret layoutet, send nogen en fil, genskab problemet. Eller svært, men uden håb om afslutning - så begynderen samler mere rake. Eller vigtigt, men eksperimenterende. Eksempelvis et projekt, som alle har ønsket sig længe, men ikke kan finde tiden til at gennemføre.

Opgaver til at mestre værktøjerne vil være "vanskelige" og kunstige. Mest sandsynligt vil dette være en forenklet version af hovedsystemet. Sådanne opgaver bruger den samme teknologistak og de samme domænevilkår som hele projektet. I dette tilfælde vil udførelsesresultatet ikke blive givet til slutbrugeren. Dette kan være demotiverende, men det er bedre at modstå denne følelse. En kunstig opgave skal udføres samvittighedsfuldt, som om projektets skæbne afhænger af det.

Resultatet af at løse dit første problem vil danne det første indtryk af dig blandt kolleger, der ikke var til stede ved samtalen.

En anden mulighed for værktøjsmastering-opgaven er "kør projektet på en lokal maskine/testmiljø." Nogle gange er denne proces beskrevet i instruktionerne. Men de er som regel gamle og nogle steder forældede. Du kan bringe reelle fordele til projektet, hvis du skriver nye instruktioner med afklaringer på de problemer, der er opstået. Sikkert på universitetet skulle du skrive en RGR for en rapport om nogle discipliner. Det er næsten det samme her. Dokumentet skal afspejle de handlinger, der skal udføres for at starte.

Typisk er trinene til at køre et produkt i et testmiljø noget som dette:

klone et lager, skift til en gren eller tag
oprette en konfigurationsfil
forberede databasestrukturen
udfyld den med testdata
bygge eller kompilere projektet,
køre et sæt konsolscripts i en bestemt rækkefølge

Under processen med at køre et system lokalt vil der uundgåeligt opstå uventede problemer.

At finde løsninger på problemer bør tilføjes til implementeringsvejledningen. Så vil disse problemer ikke opstå næste gang du følger vejledningen. Når du udfylder konfigurationsfiler og kalder scripts, skal du være opmærksom på, hvilken værdi der bruges hvor, og hvad den skal matche. Hvis et projekt f.eks. bygges ved hjælp af et CI-system og derefter køres af et script, er det vigtigt at forstå, hvor man skal indtaste branchnavnet eller commit-nummeret. Nogle gange kræver scriptet, at man sender det. IP-adresser eller DNS-navnet på databasen, dens login og adgangskode. I dette tilfælde skal du kende den specifikke adresse, der skal bruges til testmiljøet, hvilke logins den indeholder, og hvilke adgangskoder der skal angives til dem.

Nogle opgaver kan virke enkle for erfarne udviklere, men udfordrende for praktikanter. Dette er normalt.

Udviklere skal løse tekniske problemer hver dag. Erfarne medarbejdere har allerede løst mange problemer før, mens nyankomne endnu mangler at klare dem. Den bedste taktik er at registrere alle fejl, der er stødt på i dokumentet "løsning af problemer med ${opgavenavn}". For hvert problem skal du formulere en hypotese om årsagen, finde løsninger på internettet og prøve dem én efter én. Resultatet af hvert forsøg skal også registreres.

Registrering af din forskning i form af et dokument giver dig mulighed for at:

læs små detaljer ud af dit hoved. For eksempel konfigurationsparametre, DNS/IP-adresser, konsolkommandoer og SQL-forespørgsler.
husk "hvad gjorde jeg i går", når opgaven varer i flere dage
gå ikke i cirkler. Du kan altid læse, hvad du gjorde før og forstå, at du er vendt tilbage til det oprindelige problem
svar klart på spørgsmålet: "hvad lavede du i dag?" også selvom der ikke er en færdig løsning endnu.

Du skal kunne kommunikere status på dine opgaver til kollegaer

Fra tid til anden vil kolleger være interesserede i dine succeser og dele deres. Sæt lidt tid af til dette dagligt eller ugentligt.

Hvis du ikke holder styr på problemer, du støder på og løser, så vil beskrivelsen af dine succeser se ud som: “Jeg prøvede at udføre opgaven, men jeg kan ikke gøre det. Jeg leder stadig efter en løsning." Ud fra denne historie er det ikke klart, om praktikanten lavede noget eller bare sad og læste. Har han brug for hjælp? Har situationen ændret sig siden i går?

Hvis du opbevarer et dokument, der leder efter løsninger, kan du sige "Jeg prøver at udføre denne opgave. Jeg havde fejl som denne. Sådan besluttede jeg mig. Jeg har ikke beskæftiget mig med denne endnu. Der er disse hypoteser og løsninger. Jeg tjekker dem nu."

Hvis opgaven kan måles på nogen måde, så skal status indeholde tal. For eksempel, for opgaven "skriv enhedstest til et modul", kan du sige "Jeg planlægger at lave 20 test, nu har jeg skrevet 10."

Jo flere detaljer du giver, jo bedre vil dine kolleger forstå, hvad du gjorde. Dette vil skabe en positiv holdning til dig blandt dine kolleger og give dem mulighed for at forstå, om du har brug for hjælp eller ej.

Spørg gerne om hjælp

Jeg skrev ovenfor, at når et problem opstår, skal du formulere en hypotese om dets årsager og mulige løsninger. Det sker dog, at hypoteserne ikke er begrundede, og uafhængigt fundne løsninger på problemet virker ikke. I dette tilfælde er det bedre at bede om hjælp. For ikke at misbruge dine kollegers opmærksomhed, skal du selv sidde på hvert problem. Hvis du ikke har kunnet finde en løsning inden for et par timer, er det tid til at søge råd hos mere erfarne kammerater.

Et godt sted at starte er ved at spørge, "er nogen stødt på dette problem før?" med en kort beskrivelse af problemet. Det er tilrådeligt at vedhæfte en del af fejlmeddelelsen eller et skærmbillede. Det er bedre at sende denne besked for første gang til en generel arbejdschat. På denne måde distraherer du ikke dem, der har virkelig travlt fra arbejdet. Gratis kolleger vil se din besked og vil være i stand til at hjælpe.

Hvis ingen hjalp efter en besked i den generelle chat, så prøv at fange en erfaren kollega i en pause: frokost, gå til te/kaffe, en omgang tennis eller en røgpause. Hvis dette ikke lykkes, så rapporter dine vanskeligheder ved mødet eller stand-up.

Hvis kendte problemer løses, kan det hele ende der. Hvis problemet er nyt, så påbegyndes en undersøgelse, hvor det vil være nødvendigt at handle efter omstændighederne.

De "vigtige" begynderopgaver, som slutbrugeren har brug for, vil være kedelige og små. For eksempel, "tilføj en ekstra kolonne til rapporten" eller "ret en tastefejl i den udskrevne form" eller "implementer en modelmetode til indlæsning af klientattributter fra DBMS." Formålet med sådanne opgaver er, at begynderen bliver fortrolig med fagområdet og integrerer sig i det daglige arbejde.

Det er vigtigt ikke kun at løse problemet teknisk, men også at udvide kendskabet til fagområdet.

Vilkår vil fremgå af opgavebeskrivelsen, i chats og samtaler. De kan ligne velkendte navneord. Men inden for informationssystemets rammer har de en særlig mere præcis betydning. Betydningen af opdagede termer registreres bedst i et særligt dokument - en ordbog over termer. Når du tilføjer til ordbogen, er det nok at skrive din forståelse af ordet, men for en rigtig afkodning er det bedre at kontakte en analytiker. Hvis det mangler, så gå til projektets oldtimere. Vedligeholdelse af en ordbog over termer er en af de enkleste måder at blive fortrolig med emneområdet for et projekt.

Når du har fundet et fælles sprog med dine kolleger, vil de begynde at se dig ikke som en ny praktikant, men som en ligeværdig specialist.

Der er specielle opgaver, for eksempel "skrive enhedstest til et modul." Man kan næsten ikke sidde fast i det i lang tid på udkig efter løsninger. Samtidig er det ret seriøst og gives ikke kun til trainee-træning. Skriftlige test øger projektets stabilitet ved at reducere fejl i applikationen og reducere tiden til menneskelig testning. I en ideel verden skrives enhedstests umiddelbart under udviklingen, men virkeligheden er altid anderledes. Det sker, at udvikleren af et modul holder det helt i hovedet og ikke ser behovet for at skrive dem. "Alt er indlysende, hvad er der at teste?" Nogle gange skrives moduler i hastetilstand, og der er ingen tid tilbage til enhedstests. Så i den virkelige verden er der muligvis ikke enhedstests. Derfor er opgaven med at skrive enhedstest betroet til en begynder. På denne måde vil praktikanten hurtigere kunne vænne sig til projektet, og projektet vil kunne spare tid for højere lønnede specialister.

Det sker, at praktikanter og nytilkomne tildeles rollen som fuldgyldige testere. Før du gør dette, skal du normalt implementere produktet lokalt og læse kravene. Som følge heraf forventes den nye medarbejder at:

spørgsmål som "hvis du gør det sådan, bliver det sådan her. Dette er ikke i kravene. Det bør være?"
opgaver i fejlsporeren "kravene siger dette, men i virkeligheden er det skrevet anderledes."

Test er et for bredt område til denne artikel. Hvis du får en lignende opgave, skal du søge på internettet efter den bedste måde at fuldføre den på.

Hvis du roder, bliver du fyret

I en normal organisation, hvis det pludselig sker, at en uerfaren medarbejder får adgang til noget kritisk og spolerer noget, så er det den, der lod det ske, være skyld i det. Fordi en begynder som standard ikke har adgang til kritisk infrastruktur. Med tilstrækkelig vejledning vil de ikke lade alle hundene gå til spilde på en uerfaren elev.

Hvis der sker noget, fyrer de dig ikke på grund af én hændelse. Folk lærer af fejl. Praktikanten, der rodede med, lærte en værdifuld lektie og er meget anderledes end andre praktikanter. Hvis du fyrer en, der roder, kommer en anden i hans sted og roder på samme måde.

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

Hvis en person ikke drager konklusioner fra sine fejl, så vil de forsøge at sige farvel til ham. Men verden er forskelligartet. I en gangsterorganisation kan de straks smide dig ud af vinduet for den første fejl. Men det er bedre at undgå sådanne virksomheder ved først at foretage forespørgsler eller finde ud af mere under interviewet.

Det er bedre at undgå hændelser

Selvom du personligt ikke bliver fyret for en fejl, vil en sådan hændelse forårsage uønskede problemer for dit team og projektet som helhed. Vær derfor særlig forsigtig med operationerne med at slette eller oprette tabeller i databasen, filer, serviceforekomster og dokumenter i projektets videnbase. Hvis du støder på adressen på en ny forbindelse, så tjek med mindst to forskellige personer, hvad der kan gøres der. Tjek dine rettigheder i miljøer, ikke ved at prøve og fejle, men ved at bruge de relevante kommandoer. For eksempel rettigheder til at slette filer ved at bruge `ls` kommandoen, rettigheder til at arbejde med tabeller i mysql ved at bruge `SHOW GRANTS FOR 'user'@'host';` kommandoen og lignende. I næsten ethvert værktøj vil du have en lignende mulighed.

Når du redigerer filer, skal du beholde en kopi af originalen for dig selv, for en sikkerheds skyld.

Der bygges flere barrierer mellem praktikanten og slutbrugeren.

Hvis du straks kunne give dit produkt til forbrugeren, ville du være i stand til ikke at få et job, men at tage afsted på en "gratis svømmetur". Men selvom du ikke har en sådan mulighed (og samtidig ansvar), skal du gennemgå flere stadier af kontrol på projektet.
Den første af disse er verifikation af en mentor. Han vurderer nybegynderens beslutning ud fra et teknisk synspunkt. Hvis en mentor ikke er blevet tildelt, så skal du finde en. For at gøre dette skal du vælge en af projektets oldtimere og i en pause bede ham om at se på løsningen: blev problemet løst korrekt? Hvis han begynder at kigge og reagere, så er der fundet en mentor. Hvis han ignorerer det, så er det værd at spørge en anden.

Næste fase er kvalitetssikring. På russisk - testere. I sovjetisk stil - standardkontrol- og kvalitetskontrolafdeling. De skal sikre, at praktikantens præstation er i overensstemmelse med den opgave, som er pålagt ham. De vil sjældent læse koden. Oftest vil testere tjekke det byggede projekt, som udvikleren gemmer i versionskontrolsystemet.

Den tredje fase er release manager. Der er måske ikke en separat person til denne opgave, men nogen spiller stadig rollen. Han tjekker, at testere har bekræftet, at projektet kan frigives. Herefter udfører den aktiviteterne for at levere produktet til slutbrugerne.
I små organisationer eksisterer disse barrierer muligvis ikke af forskellige årsager. De vil dog ikke give en nybegynder opgaven med at ændre noget vigtigt. For ingen har brug for denne risiko.

Du skal først involveres i kampen, og så må vi se.
Napoleon Bonaparte

Jeg håber, at denne artikel vil hjælpe dig med at overvinde din usikkerhed og indsende dit første CV. Selvfølgelig skal du forberede dig først. Men der er ingen grund til at overstrække. Du har højst sandsynligt allerede studeret på et universitet eller college i flere år. Hvor skal man hen næste gang? I sidste ende er det bedre at høre "nej" én gang fra en specialist og arbejde på fejl end at sige "nej" til dig selv hver dag og stoppe med at vokse professionelt.

Når du først er ansat, skal du fokusere på at vokse fra en praktikant til et fuldgyldigt teammedlem. Denne form for vækst kommer normalt med en stigning i din løn.

Jeg ønsker dig tålmodighed og udholdenhed.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.