🥇Vi blir av med rädslan för första jobbet

Frame från filmen "Harry Potter och fången från Azkaban"

Problemet med den här världen är att uppfostrade människor är fulla av tvivel, medan idioter är fulla av självförtroende
Charles Bukowski

Nyligen höll jag en individuell programmeringslektion. Till skillnad från vanliga lektioner handlade temat inte om språkets struktur eller problem med att lösa uppgifter. Studenten delade sina bekymmer om framtida anställningsmöjligheter. Själv var eleven ganska skarp. En av dem som går på kurserna, slutför hela programmet snabbast och med originella lösningar, men underskattar sig själv hela tiden. Enligt min åsikt uppstår sådana tvivel endast på grund av brist på information. Jag försökte fylla detta gap spontant under lektionen.

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

Varje år examineras många studenter från universitet och de går alla ut för att söka jobb. Det är mycket människor. Det är säkert att de kommer att ta de bästa, och jag kommer inte att få något jobb.
Vad händer om jag gör ett misstag och blir avskedad direkt?
Vad händer om de under arbetets gång inser att jag är dum och sparkar mig?

Den här studenten var inte den första personen jag svarade på liknande frågor. De kommer upp hos många, och vanligtvis måste jag berätta utan förberedelse. Den här gången beslöt jag mig för att skriva ner mitt monolog i en anteckningsbok. Jag trodde att det skulle bli några stycken, men det blev en hel artikel.

Artikeln beskriver synpunkten från mitt perspektiv och utifrån min erfarenhet. Men vår värld är mycket mångfaldig och det händer fantastiska saker. Om du inte håller med eller om din erfarenhet skiljer sig på något sätt, vänligen skriv en kommentar.

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

De kommer överhuvudtaget inte att anställa

När man föreställer sig att hundratals studenter examineras varje år från många universitet, blir det obekvämt. Hur ska man konkurrera med en så stor mängd?

Tyvärr har inte alla studenter tillräcklig teknisk kunskap. Försök att fråga en studiekamrat från universitetet: hur får folk i deras grupp tillgång till examinationer i ämnen som "databaser" eller "grundläggande algoritmer och programmering"? I en grupp med 30 personer finns det i bästa fall 3-5 "avancerade" killar som faktiskt har gjort allt själva. De andra kopierar bara från dem, memorerar svar på frågor och klarar sig.

Så var det när jag studerade själv. Men min erfarenhet kan ha varit icke-representativ. Därför ställde jag denna fråga till flera olika studenter. Svaret var ungefär detsamma. De som svarade kom från olika universitet och högskolor. Anledningar till detta lämnar jag utanför denna artikel. Jag har inte tid eller resurser för en fullständig studie, så jag kommer att dra slutsatser från de nuvarande fakta.

Bland hundratals utexaminerade är det bara ett par dussin som intresserar arbetsgivare.

Få utexaminerade kan verkligen konkurrera med en duktig student med god förberedelse. Men även om du har studerat flitigt kommer du troligtvis inte att anställas efter den första intervjun. Kanske inte heller efter den andra. Allt kan gå bra, men det är bättre att förbereda sig för en belägring snarare än för ett stormande anfall. Ett misslyckande är bara en anledning att reflektera över sina misstag och försöka igen. Jag kommer inte att tala om förberedelser inför intervjuer, det finns redan mycket skrivet om det på internet. Jag kan bara säga att det finns detaljer i intervjuprocessen som troligen inte får tillräckligt med tid i ditt utbildningsprogram. Sök denna information själv, den kan minska antalet försök.

Galenskap är att upprepa samma handling gång på gång, i hopp om att få en förändring.
Albert Einstein

För att intervjuer inte ska bli en galenskap, måste du efter varje nytt försök bli bättre. Kom ihåg eller skriv ner frågorna som ställdes under intervjun. När du kommer hem, gå igenom denna lista och kontrollera dig själv med hjälp av internet. Då kommer du att förstå var du gjorde fel och var intervjuaren kan ha haft fel. Det händer också. Upprepa eller studera ämnen där du svarade dåligt och försök igen.

Dessutom finns en tydlig säsongsvariation på arbetsmarknaden. Kloka företag planerar rekrytering med hänsyn till examensdatum från utbildningsinstitutioner. På våren finns det fler lediga tjänster för nykomlingar än under resten av året. Men konkurrensen är också högre under denna tid.

Trubbig - kommer att bli avskedad

När man anställer någon utan erfarenhet finns det åtaganden kopplade till detta.

Från en nyanställd förväntas:

Kunskaper om den allmänna tekniska basen
Studera företagets ämnesområde
Behärska de verktyg och metoder som används

I vissa organisationer anordnas utbildningskurser för nykomlingar om de teknologier, verktyg och lokala normer som används. Till exempel god ton vid användning av företags-e-post, rutiner för ändring av dokument i wikin, lokala särdrag i arbetet med VCS och bug tracking.

Det finns också tekniska introduktionskurser, men deras användbarhet är tveksam. Om det har kommit till en anställning har arbetsgivarna övertygat sig om att du har en tillräcklig nivå av kunskap. Det är bäst att helt enkelt genomgå dessa kurser som en liten formalitet. Det kan faktiskt finnas något användbart i dem.

När du börjar arbeta, kom ihåg att en nykomling absolut inte kommer att få i uppdrag att lösa en brådskande, komplex och samtidigt viktig uppgift. Det kommer sannolikt bara att finnas en av dessa egenskaper. Antingen något enkelt men brådskande: justera layouten, vidarebefordra en fil till någon, återskapa ett problem. Eller komplext men utan hopp om att slutföras - bara så att nykomlingen kan samla på sig så många misstag som möjligt. Eller viktigt men experimentellt. Till exempel ett projekt som alla länge har velat ha men inte har kunnat avsätta tid för att genomföra.

Uppgifterna för att bemästra verktygen kommer att vara "komplexa" och konstgjorda. Det kommer sannolikt att vara en förenklad version av det huvudsakliga systemet. I sådana uppgifter används samma teknikstack och samma termer från ämnesområdet som i hela projektet. Samtidigt kommer resultaten av arbetet inte att levereras till slutanvändaren. Detta kan demotiviera, men det är bättre att motstå den här känslan. Den konstgjorda uppgiften bör göras noggrant, som om projektets öde berodde på den.

Resultatet av att lösa din första uppgift kommer att ge ett första intryck av dig hos kollegor som inte var med på intervjun.

Ett annat alternativ för att lära sig verktygen är att "starta ett projekt på den lokala maskinen/testmiljön". Ibland beskrivs denna process i instruktionerna. Men de är oftast gamla och delvis föråldrade. Man kan tillföra verklig nytta till projektet genom att skriva en ny instruktion med klargöranden om uppkomna problem. Du har säkert behövt skriva en laborationsrapport för något ämne på universitetsnivå. Det är nästan detsamma. Dokumentet bör återspegla de åtgärder som behövs för att starta.

Vanligtvis är stegen för att starta en produkt i testmiljön ungefär följande:

klona repositoriet, byta till en viss gren eller tagg
ställa in någon konfigurationsfil
förbereda databasstrukturen
fylla den med testdata
genomföra byggandet eller kompileringen av projektet,
köra en uppsättning konsolskript i en viss ordning

Under processen att starta systemet lokalt kommer det ofrånkomligen att uppstå oväntade problem.

Lösningar på de problem som upptäcks bör skrivas in i instruktionen för distribution. Då kommer dessa problem inte att uppstå nästa gång instruktionen följs. När du fyller i konfigurationsfiler och anropar skript bör du vara uppmärksam på vilket värde som används var, och vad det ska matcha. Till exempel, om projektet byggs med ett CI-system och sedan startas med ett skript, är det viktigt att förstå var man ska ange namnet på grenen eller commitnumret. Det kan hända att skriptet förutsätter att du anger IP-adresser eller DNS-namn på databasen, dess inloggning och lösenord. I det här fallet måste du veta vilken adress som ska användas för testmiljön, vilka inloggningar som finns där och vilka lösenord som ska anges för dem.

Vissa uppgifter kan verka enkla för erfarna utvecklare och orsaka svårigheter för praktikanter. Det är en normal förekomst.

Utvecklare står dagligen inför tekniska problem. Erfarn personal har redan löst många problem tidigare, medan nykomlingar fortfarande har mycket kvar att hantera. Den bästa taktiken är att dokumentera alla mötande fel i dokumentet "problemhantering för ${nazvanie zadachi}". För varje problem bör en hypotes om orsaken formuleras, alternativ för lösning bör sökas på internet och testas i tur och ordning. Resultatet av varje försök bör också dokumenteras.

Att dokumentera dina insikter i ett dokument kommer att:

frigöra huvudet från små detaljer. Till exempel konfigurationsparametrar, DNS/IP-adresser, kommandoradsikoner och SQL-frågor.
hjälpa dig att komma ihåg "vad gjorde jag igår" när uppgiften sträcker sig över flera dagar.
hindra dig från att gå i cirklar. Du kommer alltid att kunna läsa vad du gjorde tidigare och förstå om du har återgått till det ursprungliga problemet.
ge ett tydligt svar på frågan: "vad har du gjort idag?" även om det färdiga svaret ännu inte finns.

Du behöver kunna rapportera status på dina uppgifter till dina kollegor.

Periodiskt kommer kollegor att fråga om dina framsteg och dela sina egna. Detta avsätter lite tid dagligen eller veckovis.

Om du inte spårar de problem som uppstår och löses, kommer din beskrivning av framstegen att låta som: "Jag försökte göra uppgiften, men jag kan inte. Jag letar fortfarande efter en lösning." Utifrån denna berättelse är det oklart om praktikanten faktiskt arbetade på något eller bara satt och läste. Behöver de hjälp? Har situationen förändrats sedan igår?

Om du håller ett dokument om lösningar kan du säga "Jag försöker göra den här uppgiften. Jag har stött på sådana fel. Jag löste dessa på detta sätt. Jag har ännu inte lyckats med denna. Här är några hypoteser och lösningsalternativ. Jag kontrollerar dem just nu."

Om en uppgift på något sätt kan mätas bör status innehålla siffror. Till exempel för uppgiften "skriva enhetstester för modulen" kan man säga "jag planerar att göra 20 tester, jag har skrivit 10 hittills."

Ju fler detaljer du ger, desto bättre kommer dina kollegor att förstå vad du har gjort. Detta kommer att skapa en positiv inställning hos kollegorna och hjälpa dem att förstå om du behöver hjälp eller inte.

Tveka inte att be om hjälp.

Tidigare skrev jag att när ett problem uppstår behöver du formulera en hypotes om dess orsaker och möjliga lösningar. Men det händer att hypoteserna inte stämmer och att de självständigt hittade lösningarna inte fungerar. I så fall är det bättre att be om hjälp. För att inte missbruka kollegornas uppmärksamhet bör du först försöka lösa varje problem själv. Om du inte lyckas hitta en lösning inom ett par timmar är det dags att söka råd hos mer erfarna kollegor.

Bäst är att börja med frågan: "Har någon stött på 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äst att skicka detta meddelande första gången i en allmän arbetschatt. På så sätt stör du inte dem som verkligen är upptagna. Fria kollegor ser ditt meddelande och kan hjälpa till.

Om ingen hjälper efter meddelandet i den allmänna chatten, försök få tag på en erfaren kollega under en paus: lunch, när man går för att hämta te/kaffe, en tennismatch eller under en rökpaus. Om det inte går, informera om dina svårigheter under ett möte eller stand-up.

När det gäller kända problem kan allt stanna här. Om problemet är nytt börjar en utredning där du måste agera utifrån omständigheterna.

De "viktiga" uppgifterna för nybörjare som behövs av slutanvändaren kommer att vara tråkiga och små. Till exempel "lägga till en extra kolumn i rapporten" eller "rätta ett stavfel i utskriftsformatet" eller "implementera en metod i modellen för att ladda kundattributen från databasen". Målet 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 lösa uppgiften tekniskt utan också att utöka kunskapen inom ämnesområdet.

I beskrivningen av uppgiften, i chattarna och samtalen kommer termer att dyka upp. De kan se ut som välbekanta substantiv. Men inom ramen för informationssystemet får de en särskild, mer exakt betydelse. Betyderna av de upptäckta termerna bör bäst skrivas ner i ett särskilt dokument - en ordlista. När du lägger till i ordlistan är det tillräckligt att skriva din förståelse av ordet, men för den verkliga tolkningen är det bäst att vända sig till analytikern. Om han inte finns, så till veteranerna i projektet. Att upprätthålla en ordlista är ett av de enklaste sätten att knyta an till ämnesområdet för projektet.

Så snart du hittar ett gemensamt språk med kollegorna kommer de att börja se dig som en likvärdig specialist snarare än en nybörjare.

Det finns särskilda uppgifter, som "att skriva enhetstester för modulen". Det är osannolikt att du kan fastna länge med att söka efter lösningar på den. Den är dessutom tillräckligt seriös och ges inte bara för att utbilda praktikanter. De skrivna testen ökar stabiliteten i projektet genom att minska buggar i applikationen och minska den tid som människor lägger på testning. I en ideal värld skrivs enhetstesterna direkt under utvecklingen, men verkligheten är ofta annorlunda. Ibland håller modulent utvecklaren fullständigt i sinnet och ser ingen anledning att skriva dem. "Det är uppenbart vad som ska testas här?" Ibland skrivs moduler på ett bråttom sätt och det finns inte tid för enhetstester. Så i verkligheten kanske det inte finns några enhetstester. Därför överlämnas uppgiften att skriva enhetstester till nybörjaren. På så sätt kan praktikanten snabbt bekanta sig med projektet, och projektet kan spara tid från mera välbetalda specialister.

Ibland får praktikanter och nybörjare rollen som fullvärdiga testare. Vanligtvis behöver man först sätta upp produkten lokalt och läsa igenom kraven. Som resultat förväntas av den nya anställda:

Frågor som "om jag gör så här, så får jag så här. Det står inte i kraven. Hur ska det vara?"
Uppgifter i bugtracking-systemet "kraven säger så här, men i verkligheten är det annorlunda."

Testning är ett alltför omfattande område för denna artikel. Om du har fått en sådan uppgift, leta på internet efter hur du bäst utför den.

Om du gör fel får du sparken.

I en välordnad organisation, om en oerfaren anställd plötsligt får tillgång till något kritiskt och förstör något, så är det den som möjliggjort detta som bär ansvaret. Eftersom en nybörjare normalt sett inte har tillgång till kritisk infrastruktur. Med adekvat ledarskap kommer man inte att skylla allt på den oerfarna praktikanten.

Om något skulle hända, kommer man inte att avskeda för enstaka incidenter. Människor lär sig av sina misstag. Den som gjort fel har fått en värdefull läxa och skiljer sig därmed från andra praktikanter. Om man avskedar den som gjort fel, kommer en annan att komma på samma plats och göra samma misstag.

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

Om en person inte drar lärdom av sina misstag, kommer man försöka säga hejdå till dem. Men världen är mångfacetterad. I en gangsterorganisation kan man bli kastad ut genom fönstret för första misstaget. Men det är bättre att undvika sådana företag, vilket man kan göra genom att först ta reda på mer information innan en anställningsintervju.

Incidenter bör undvikas.

Även om du personligen inte blir avskedad för ett misstag, kommer en sådan händelse att orsaka oönskade problem för ditt team och projektet i stort. Så var särskilt försiktig med operationer som rör borttagning eller skapande av tabeller i databasen, filer, instanser av tjänster och dokument i projektets kunskapsdatabas. Om du stöter på en ny anslutningsadress, be minst två olika personer klargöra vad som är möjligt där. Kontrollera dina rättigheter på miljöer, inte genom trial and error, utan med lämpliga kommandon. Till exempel rättigheter för att ta bort filer med kommandot `ls`, rättigheter för att arbeta med tabeller i mysql med kommandot `SHOW GRANTS FOR ‘user’@’host’;` och så vidare. Nästan varje verktyg har denna möjlighet.

När du redigerar filer, spara alltid en kopia av originalet.

Det byggs upp flera barriärer mellan praktikanten och slutanvändaren.

Om du kunde leverera din produkt direkt till kunden skulle du kunna hoppa över att söka jobb och ge dig ut på "friblandning". Men eftersom du för närvarande inte har den möjligheten (och ansvarigheten), behöver du gå igenom flera kontrollsteg i projektet.
Den första är handledarens granskning. Hen bedömer nykomlingens lösning ur ett tekniskt perspektiv. Om ingen handledare har utsetts, behöver man hitta en. För att göra detta, välj någon av veteranerna i projektet och be hen att titta på lösningen under pausen: Har uppgiften lösts korrekt? Om hen börjar titta och svara, har du hittat en handledare. Om hen ignorerar dig, fråga någon annan.

Nästa steg är kvalitetssäkring. På ryska – testare. På sovjetisk – normalkontroll och OTK. De måste se till att praktikanternas arbetsresultat överensstämmer med den tilldelade uppgiften. De kommer sällan att läsa koden noggrant. Oftast kommer testarna att kontrollera det samlade projektet som utvecklaren sparar i versionshanteringssystemet.

Det tredje steget är release manager. Det kan hända att det inte finns en särskild person för denna uppgift, men någon kommer ändå att utföra rollen. Hen kontrollerar att testarna har bekräftat att projektet kan släppas. Efter det vidtar hen åtgärder för att leverera produkten till slutanvändarna.
I små organisationer kan dessa hinder av olika skäl saknas. Men nykomlingen kommer inte att få en uppgift för att ändra något viktigt. För risken är inte värd för någon.

Man måste först ge sig in i striden, sen får man se.
Napoleon Bonaparte

Jag hoppas att artikeln hjälper dig att övervinna din osäkerhet och skicka ditt första CV. Självklart måste du förbereda dig först. Men dra inte ut på det för länge. Du har förmodligen redan studerat i flera år på universitetet eller i college. Vad mer finns det att dra ut på? I slutändan är det bättre att höra "nej" från en specialist en gång och arbeta på dina misstag, än att varje dag säga "nej" till dig själv och stanna upp i din yrkesmässiga utveckling.

Efter anställningen är det viktigt att fokusera på att växa från praktikant till en fullvärdig medlem av teamet. En sådan tillväxt åtföljs oftast av en ökning av din lön.

Jag önskar dig tålamod och ihärdighet.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.