🥇 Bli av med rädslan för ditt första jobb

Stillbild från filmen "Harry Potter and the Prisoner of Azkaban"

Problemet med den här världen är att utbildade människor är fulla av tvivel, men idioter är fulla av självförtroende.

Charles Bukowski

Jag undervisade nyligen en annan en-mot-en programmeringslektion. Till skillnad från vanliga lektioner var ämnet inte språkkonstruktion eller problemlösning. Studenten delade med sig av sin oro för framtida anställning. Eleven själv var ganska smart. En av dem som kommer till kursen genomför hela programmet snabbare än någon annan och med originella lösningar, men hela tiden underskattar han sig själv uppriktigt. Enligt min mening uppstår sådana tvivel endast på grund av bristande information. Jag försökte fylla denna lucka improviserat under lektionen.

Frågorna var ungefär så här:

Varje år tar många studenter examen från universitet och de söker alla jobb. Det är många människor. De kommer förmodligen att anställa de bästa, men jag får ingen plats.
Vad händer om jag stökar till och får sparken direkt?
Tänk om de under arbetets gång inser att jag är dum och sparkar ut mig?

Den här eleven var inte den första personen som jag svarade på sådana frågor. Många människor har dem, och vanligtvis måste de berättas utan förberedelser. Den här gången bestämde jag mig för att skriva ner min monolog i en anteckningsbok. Jag trodde att det skulle bli ett par stycken, men det slutade med att det räckte till en hel artikel.

Artikeln beskriver synen ur min synvinkel och utifrån min erfarenhet. Men vår värld är väldigt varierad och fantastiska saker händer i den. Om du inte håller med om något eller om din upplevelse på något sätt är annorlunda, skriv gärna en kommentar.

Artikeln skrevs av en utvecklare för utvecklare. Men om du planerar att göra testning, administration eller något annat inom IT, kommer några av råden också att vara användbara för dig.

De kommer inte att anställa dig alls

När man föreställer sig att många universitet tar examen hundratals studenter varje år blir det obehagligt. Hur kan man konkurrera med en så stor publik?

Tyvärr har inte alla akademiker tillräcklig teknisk utbildning. Försök att fråga någon universitetsstudent som du känner: hur får människor i hans grupp tillträde till prov inom discipliner som "databaser" eller "grunderna för algoritmisering och programmering"? I en grupp på 30 personer kommer det i bästa fall vara 3-5 ”avancerade” killar som faktiskt gjort allt själva. Resten kopierar helt enkelt från dem, fyller på svar på frågor och skickar in.

Så här var det när jag pluggade på egen hand. Min erfarenhet kanske inte är representativ. Så jag ställde den här frågan till flera olika elever. Svaret var ungefär detsamma. Respondenterna var från olika universitet och högskolor. Jag kommer att lämna diskussioner om orsakerna utanför ramen för denna artikel. Jag har inte tillräckligt med tid för en fullfjädrad studie, så jag kommer att dra en slutsats från tillgängliga fakta.

Bland hundratals utexaminerade är bara ett par dussin av intresse för arbetsgivare

Få utexaminerade kan ge verklig konkurrens om en duktig student med goda förberedelser. Men även om du studerade samvetsgrant, kommer du med största sannolikhet inte att bli anställd efter den första intervjun. Efter den andra förmodligen också. Allt kan bli bra, men det är bättre att förbereda dig inte för ett angrepp, utan för en belägring. Ett misslyckat försök att få ett jobb är bara en anledning att arbeta på dina misstag och försöka igen. Jag ska inte prata om att förbereda mig för intervjuer. Mycket har redan skrivits om detta ämne på Internet. Jag ska bara säga att det finns nyanser i intervjuer som ditt träningsprogram förmodligen inte kommer att ta sig tid att förklara. Leta efter denna information själv, det kan minska antalet försök.

Galenskap är den exakta upprepningen av samma handling. Gång på gång i hopp om förändring

Albert Einstein

För att inte intervjuer ska bli galenskaper måste du förbättra dig efter varje nytt försök. Memorera eller skriv ner frågorna du fick under intervjun. När du kommer hem, titta igenom den här listan och kontrollera dig själv med hjälp av Internet. På så sätt kommer du att förstå var du och intervjuaren gjorde ett misstag. Detta händer också. Gå igenom eller studera de ämnen som du presterade dåligt på och försök igen.

Dessutom finns en uttalad säsongsvariation på arbetsmarknaden. Smarta företag planerar anställning baserat på examensdatum. Det finns fler lediga platser för nyanlända under våren än vid andra tider. Konkurrensen är dock högre vid denna tidpunkt.

Dumt - få sparken

När en person utan erfarenhet anställs finns motsvarande förväntningar på honom.

En nykomling i jobbet förväntas:

Kunskaper om allmän teknisk grund
Studera detaljerna i företagets ämnesområde
Bemästra de verktyg och metoder som används

Vissa organisationer tillhandahåller utbildningar för nykomlingar om de teknologier, verktyg och lokala rutiner som används. Till exempel, bra uppförande när du använder företags e-post, proceduren för att ändra dokument i en wiki, lokala funktioner för att arbeta med VCS och en buggspårare.

Det finns också tekniska introduktionskurser, men deras användbarhet är tveksam. Om det kommer till anställning är arbetsgivarna övertygade om att du har en tillräcklig kunskapsnivå. Det är bäst att helt enkelt ta sådana kurser i god tro, som en liten formalitet. Kanske kommer det faktiskt att finnas något användbart i dem.

När du börjar arbeta, kom ihåg att en nybörjare definitivt inte kommer att bli anförtrodd att lösa en brådskande, komplex och samtidigt viktig uppgift. Troligtvis kommer det bara att finnas en av dessa fastigheter. Eller enkelt men brådskande: fixa layouten, skicka en fil till någon, återskapa problemet. Eller svårt, men utan något hopp om avslut – så att nybörjaren samlar på sig mer rake. Eller viktigt, men experimentellt. Till exempel ett projekt som alla har velat ha länge, men inte har tid att genomföra.

Uppgifter för att bemästra verktygen kommer att vara "svåra" och konstgjorda. Troligtvis kommer detta att vara en förenklad version av huvudsystemet. Sådana uppgifter använder samma teknikstack och samma domäntermer som hela projektet. I det här fallet kommer exekveringsresultatet inte att ges till slutanvändaren. Detta kan vara demotiverande, men det är bättre att motstå denna känsla. En konstgjord uppgift måste utföras samvetsgrant, som om projektets öde beror på det.

Resultatet av att lösa ditt första problem kommer att bilda det första intrycket av dig bland kollegor som inte var närvarande vid intervjun.

Ett annat alternativ för verktygsmästaruppgiften är "kör projektet på en lokal maskin/testmiljö." Ibland beskrivs denna process i instruktionerna. Men de är oftast gamla och på sina ställen föråldrade. Du kan tillföra verkliga fördelar för projektet om du skriver nya instruktioner med förtydliganden om de problem som har uppstått. Visst på universitetet var man tvungen att skriva en RGR för en rapport om vissa discipliner. Det är nästan likadant här. Dokumentet bör återspegla de åtgärder som måste utföras för att starta.

Vanligtvis är stegen för att köra en produkt i en testmiljö ungefär så här:

klona ett arkiv, byta till någon gren eller tagg
skapa någon konfigurationsfil
förbereda databasstrukturen
fyll den med testdata
bygga eller sammanställa projektet,
kör en uppsättning konsolskript i en viss sekvens

Under processen att köra ett system lokalt kommer oväntade problem oundvikligen att uppstå.

Hittade lösningar på problem måste läggas till i installationsinstruktionerna. Nästa gång du följer instruktionerna kommer dessa problem inte längre att uppstå. När du fyller i konfigurationsfiler och anropar skript måste du vara uppmärksam på vilket värde som används var och vad det ska matcha. Till exempel, om ett projekt sätts ihop med ett CI-system och sedan startas av ett skript, är det viktigt att förstå var man ska skriva filialnamnet eller commit-numret. Det händer att skriptet innebär att IP-adressen eller DNS-namnet för databasen, dess inloggning och lösenord överförs. I det här fallet behöver du veta vilken adress du ska använda för testmiljön, vilka inloggningar som finns och vilka lösenord du behöver ange för dem.

Vissa uppgifter kan verka enkla för erfarna utvecklare men utmanande för praktikanter. Det här är normalt.

Utvecklare måste lösa tekniska problem varje dag. Erfarna medarbetare har redan löst många problem tidigare, medan nyanlända ännu inte har klarat av dem. Den bästa taktiken är att registrera alla fel som uppstår i dokumentet "löser problem med ${task name}". För varje problem måste du formulera en hypotes om orsaken, hitta lösningar på Internet och prova dem en efter en. Resultatet av varje försök måste också registreras.

Registrering av din forskning i form av ett dokument gör att du kan:

ladda ut små detaljer från ditt huvud. Till exempel konfigurationsparametrar, DNS/IP-adresser, konsolkommandon och SQL-frågor.
kom ihåg "vad gjorde jag igår" när uppgiften pågår i flera dagar
vandra inte i cirklar. Du kan alltid läsa vad du gjorde tidigare och förstå att du har återgått till det ursprungliga problemet
svara tydligt på frågan: "vad har du gjort idag?" även om det inte finns någon färdig lösning ännu.

Du behöver kunna kommunicera status på dina arbetsuppgifter till kollegor

Då och då kommer kollegor att vara intresserade av dina framgångar och dela med sig av sina. Avsätt lite tid för detta dagligen eller varje vecka.

Om du inte håller reda på problem som du stött på och löst, kommer att beskriva dina framgångar att se ut så här: "Jag försökte göra uppgiften, men jag kan inte göra det. Jag letar fortfarande efter en lösning." Av den här historien framgår det inte om praktikanten gjorde något eller bara satt och läste. Behöver han hjälp? Har läget förändrats sedan igår?

Om du håller ett dokument som letar efter lösningar kan du säga "Jag försöker göra den här uppgiften. Jag hade sådana här fel. Så här bestämde jag mig. Jag har inte tagit itu med den här än. Det finns dessa hypoteser och lösningar. Jag kollar dem nu."

Om uppgiften kan mätas på något sätt, bör statusen innehålla siffror. Till exempel, för uppgiften "skriva enhetstester för en modul", kan du säga "Jag planerar att göra 20 test, nu har jag skrivit 10."

Ju fler detaljer du anger, desto bättre förstår dina kollegor vad du gjorde. Detta kommer att skapa en positiv attityd till dig bland dina kollegor och göra det möjligt för dem att förstå om du behöver hjälp eller inte.

Be gärna om hjälp

Jag skrev ovan att när ett problem uppstår måste man formulera en hypotes om dess orsaker och möjliga lösningar. Det händer dock att hypoteserna inte är motiverade, och oberoende hittade lösningar på problemet fungerar inte. I det här fallet är det bättre att be om hjälp. För att inte missbruka dina kollegors uppmärksamhet måste du själv sitta på varje problem. Om du inte har kunnat hitta en lösning på ett par timmar är det dags att söka råd från mer erfarna kamrater.

Ett bra ställe att börja är genom att fråga, "har någon stött på det här problemet tidigare?" med en kort beskrivning av problemet. Det är lämpligt att bifoga en del av felmeddelandet eller en skärmdump. Det är bättre att skicka detta meddelande för första gången till någon allmän arbetschatt. På så sätt distraherar du inte de som verkligen är upptagna från jobbet. Gratis kollegor kommer att se ditt meddelande och kommer att kunna hjälpa till.

Om ingen hjälpte efter ett meddelande i den allmänna chatten, försök att fånga en erfaren kollega under en paus: lunch, gå på te/kaffe, en omgång tennis eller en rökpaus. Om detta inte fungerar, rapportera sedan dina svårigheter vid mötet eller stand-up.

Om kända problem löses kan allt detta sluta där. Om problemet är nytt kommer en utredning att påbörjas, där det blir nödvändigt att agera efter omständigheterna.

De "viktiga" nybörjaruppgifterna som slutanvändaren behöver blir tråkiga och små. Till exempel, "lägg till en extra kolumn i rapporten" eller "rätta ett stavfel i det tryckta formuläret" eller "implementera en modellmetod för att ladda klientattribut från DBMS." Syftet med sådana uppgifter är att nybörjaren ska bli bekant med ämnesområdet och integreras i det dagliga arbetet.

Det är viktigt att inte bara tekniskt lösa problemet, utan också utöka kunskapen om ämnesområdet.

Villkor kommer att visas i uppgiftsbeskrivningen, i chattar och konversationer. De kan se ut som bekanta substantiv. Men inom ramen för informationssystemet har de en speciell, mer precis innebörd. Betydelsen av upptäckta termer registreras bäst i ett speciellt dokument - en ordbok med termer. När du lägger till ordboken är det tillräckligt att skriva din förståelse av ordet, men för en riktig avkodning är det bättre att kontakta en analytiker. Om det saknas, gå sedan till projektets gamla tidtagare. Att underhålla en ordbok med termer är ett av de enklaste sätten att bli bekant med ämnesområdet för ett projekt.

När du väl hittar ett gemensamt språk med dina kollegor kommer de att börja se dig inte som en ny praktikant, utan som en jämställd specialist.

Det finns speciella uppgifter, till exempel "skriva enhetstester för en modul." Man kan knappast fastna på det länge och leta efter lösningar. Samtidigt är det ganska seriöst och ges inte bara för traineeträning. Skriftliga tester ökar stabiliteten i projektet genom att minska buggar i applikationen och minska tiden för mänskliga tester. I en ideal värld skrivs enhetstester direkt under utvecklingen, men verkligheten är alltid annorlunda. Det händer att utvecklaren av en modul håller den helt i huvudet och inte ser behovet av att skriva dem. "Allt är uppenbart, vad finns det att testa?" Ibland skrivs moduler i rusningsläge och det finns ingen tid kvar för enhetstester. Så i den verkliga världen kanske det inte finns enhetstester. Därför är uppgiften att skriva enhetstester tilldelad en nybörjare. På så sätt kommer praktikanten att kunna vänja sig vid projektet snabbare, och projektet kommer att kunna spara tid för högre betalda specialister.

Det händer att praktikanter och nykomlingar tilldelas rollen som fullvärdiga testare. Innan du gör detta måste du vanligtvis distribuera produkten lokalt och läsa kraven. Som ett resultat förväntas den nya medarbetaren:

frågor som ”om du gör så här kommer det att bli så här. Detta står inte i kraven. Det borde vara?"
uppgifter i felspåraren "kraven säger detta, men i verkligheten är det skrivet annorlunda."

Testning är ett för brett område för den här artikeln. Om du får en liknande uppgift, sök på Internet efter det bästa sättet att slutföra den.

Om du krånglar så får du sparken

I en normal organisation, om det plötsligt händer att en oerfaren anställd får tillgång till något kritiskt och förstör något, då får den som låtit detta hända att få skulden. Eftersom en nybörjare, som standard, inte har tillgång till kritisk infrastruktur. Med adekvat vägledning kommer de inte att låta alla hundar gå till spillo på en oerfaren praktikant.

Om något händer kommer de inte att sparka dig på grund av en incident. Människor lär sig av misstag. Praktikanten som trasslade till lärde sig en värdefull läxa och skiljer sig mycket från andra praktikanter. Om du sparkar någon som stökar till kommer någon annan i hans ställe och stökar till på samma sätt.

Det viktigaste är att lära av misstag och inte upprepa dem igen.

Om en person inte drar slutsatser från sina misstag, kommer de att försöka säga adjö till honom. Men världen är mångfaldig. I någon gangsterorganisation kan de omedelbart kasta ut dig genom fönstret för det första misstaget. Men det är bättre att undvika sådana företag genom att göra förfrågningar först eller ta reda på mer under intervjun.

Det är bättre att undvika incidenter

Även om du personligen inte får sparken för ett misstag, kommer en sådan incident att orsaka oönskade problem för ditt team och projektet som helhet. Var därför särskilt försiktig med operationerna för att ta bort eller skapa tabeller i databasen, filer, tjänsteinstanser och dokument i projektets kunskapsbas. Om du stöter på adressen till en ny anslutning, kolla med minst två olika personer vad som kan göras där. Kontrollera dina rättigheter i miljöer, inte genom att trial and error, utan genom att använda lämpliga kommandon. Till exempel, rättigheter att ta bort filer med kommandot `ls`, rättigheter att arbeta med tabeller i mysql med kommandot `SHOW GRANTS FOR 'user'@'host';` och liknande. I nästan alla verktyg kommer du att ha en liknande möjlighet.

När du redigerar filer, behåll en kopia av originalet för dig själv, för säkerhets skull.

Flera barriärer byggs upp mellan praktikanten och slutanvändaren.

Om du omedelbart kunde ge din produkt till konsumenten skulle du inte kunna få ett jobb, utan ge dig ut på ett "fritt dopp". Men medan du inte har en sådan möjlighet (och samtidigt ansvar), måste du gå igenom flera stadier av kontroll på projektet.
Den första av dessa är verifiering av en mentor. Han utvärderar nybörjarens beslut ur en teknisk synvinkel. Om en mentor inte har tilldelats måste du hitta en. För att göra detta måste du välja en av de gamla i projektet och under en paus be honom titta på lösningen: löstes problemet korrekt? Om han börjar leta och svara, då har en mentor hittats. Om han ignorerar det är det värt att fråga någon annan.

Nästa steg är kvalitetssäkring. På ryska - testare. I sovjetisk stil - standardkontroll och kvalitetskontrollavdelning. De måste se till att praktikantens prestation överensstämmer med den uppgift han tilldelats. De kommer sällan att läsa koden. Oftast kommer testare att kontrollera det byggda projektet, som utvecklaren lagrar i versionskontrollsystemet.

Det tredje steget är release manager. Det kanske inte finns en separat person för denna uppgift, men någon spelar fortfarande rollen. Han kontrollerar att testare har bekräftat att projektet kan släppas. Efter detta utför den aktiviteterna för att leverera produkten till slutanvändare.
I små organisationer kanske dessa hinder inte existerar av olika anledningar. Men de kommer inte att ge en nybörjare uppgiften att ändra något viktigt. För ingen behöver denna risk.

Du måste engagera dig i striden först, och sedan får vi se.
Napoleon Bonaparte

Jag hoppas att den här artikeln hjälper dig att övervinna din osäkerhet och skicka in ditt första CV. Självklart måste du förbereda dig först. Men det finns ingen anledning att översträcka. Du har med största sannolikhet redan studerat på ett universitet eller högskola i flera år. Vart ska man gå härnäst? I slutändan är det bättre att höra "nej" en gång från en specialist och arbeta med misstag än att säga "nej" till dig själv varje dag och sluta växa professionellt.

När du väl har anställts måste du fokusera på att växa från praktikant till en fullfjädrad teammedlem. Denna typ av tillväxt kommer vanligtvis med en ökning av din lön.

Jag önskar dig tålamod och uthållighet.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vilka var dina första uppgifter i ditt första jobb inom IT?

Komplex
Viktig
Brådskande
Inget av ovanstående

75 användare röstade. 20 användare avstod från att rösta.

Vad behövde du göra först på ditt första jobb?

Installera produkten lokalt
Testa en befintlig produkt
Genomför en utbildning, falsk uppgift
Gör ett experimentellt, verkligt projekt för en kund

63 användare röstade. 25 användare avstod från att rösta.

Hur många elever i din grupp kunde självständigt utföra uppgifter i tekniska ämnen under utbildningen?

1 från 10
1 från 5
Varje sekund
Allt, med sällsynta undantag

70 användare röstade. 19 användare avstod från att rösta.

Källa: will.com

Att bli av med rädslan för ditt första jobb