Bli kvitt frykten for din første jobb

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

Problemet med denne verden er at utdannede mennesker er fulle av tvil, men idioter er fulle av selvtillit.

Charles Bukowski

Jeg underviste nylig en annen en-til-en programmeringstime. I motsetning til vanlige timer var ikke temaet språkkonstruksjon eller problemløsning. Studenten delte bekymringene sine for fremtidig ansettelse. Studenten selv var ganske smart. En av de som kommer på kurset gjennomfører hele programmet raskere enn noen andre og med originale løsninger, men hele tiden undervurderer han seg selv oppriktig. Etter min mening oppstår slik tvil kun på grunn av mangel på informasjon. Jeg prøvde å fylle dette gapet improvisert i løpet av leksjonen.

Spørsmålene var omtrent slik:

• Hvert år uteksamineres mange studenter fra universiteter, og de søker alle etter arbeid. Det er mange mennesker. De vil nok ansette de beste, men jeg får ikke plass.
• Hva om jeg roter til og får sparken med en gang?
• Hva om de i løpet av arbeidet innser at jeg er dum og sparker meg ut?

Denne studenten var ikke den første personen jeg svarte på slike spørsmål. Mange har dem, og som regel må de bli fortalt uten forberedelse. Denne gangen bestemte jeg meg for å skrive ned monologen min i en notatbok. Jeg trodde det skulle bli et par avsnitt, men det endte opp med å være nok til en hel artikkel.

Artikkelen beskriver synet fra mitt ståsted og basert på min erfaring. Imidlertid er verden vår veldig mangfoldig og fantastiske ting skjer i den. Hvis du er uenig i noe eller din opplevelse er annerledes, vennligst skriv en kommentar.

Artikkelen er skrevet av en utvikler for utviklere. Men hvis du planlegger å gjøre testing, administrasjon eller noe annet innen IT, vil noen av rådene også være nyttige for deg.

De vil ikke ansette deg i det hele tatt

Når du ser for deg at mange universiteter uteksaminerer hundrevis av studenter hvert år, blir det ubehagelig. Hvordan konkurrere med et så stort publikum?

Dessverre har ikke alle nyutdannede tilstrekkelig teknisk opplæring. Prøv å spørre en universitetsstudent du kjenner: hvordan får folk i gruppen hans opptak til eksamen i disipliner som "databaser" eller "grunnleggende om algoritmisering og programmering"? I en gruppe på 30 personer vil det i beste fall være 3-5 "avanserte" karer som faktisk gjorde alt selv. Resten bare kopiere fra dem, stappe svar på spørsmål og sende inn.

Slik var det da jeg studerte på egenhånd. Imidlertid er min erfaring kanskje ikke representativ. Så jeg stilte dette spørsmålet til flere forskjellige elever. Svaret var stort sett det samme. Respondentene var fra ulike universiteter og høyskoler. Jeg vil legge igjen diskusjoner om årsakene utenfor rammen av denne artikkelen. Jeg har ikke nok tid til en fullverdig studie, så jeg vil trekke en konklusjon fra tilgjengelige fakta.

Blant hundrevis av nyutdannede er det bare et par dusin som er av interesse for arbeidsgivere

Få nyutdannede kan gi reell konkurranse om en dyktig student med gode forberedelser. Men selv om du studerte samvittighetsfullt, vil du sannsynligvis ikke bli ansatt etter det første intervjuet. Etter den andre, sannsynligvis også. Alt kan gå bra, men det er bedre å forberede deg ikke på et angrep, men på en beleiring. Et mislykket forsøk på å få jobb er bare en grunn til å jobbe med feilene dine og prøve igjen. Jeg vil ikke snakke om å forberede meg til intervjuer. Det er allerede skrevet mye om dette emnet på Internett. Jeg vil bare si at det er nyanser i intervjuer som treningsprogrammet ditt sannsynligvis ikke vil ta deg tid til å forklare. Se etter denne informasjonen selv, det kan redusere antall forsøk.

Galskap er den nøyaktige gjentakelsen av den samme handlingen. Gang på gang, i håp om forandring

Albert Einstein

For å forhindre at intervjuer blir til galskap, må du forbedre deg etter hvert nytt forsøk. Husk eller skriv ned spørsmålene du ble stilt under intervjuet. Når du kommer hjem, se gjennom denne listen og sjekk deg selv ved å bruke Internett. På denne måten vil du forstå hvor du og intervjueren gjorde en feil. Dette skjer også. Se gjennom eller studer emnene du gjorde dårlig på, og prøv igjen.

I tillegg er det en uttalt sesongvariasjon på arbeidsmarkedet. Smarte selskaper planlegger ansettelse basert på eksamensdatoer. Det er flere ledige plasser for nyankomne på våren enn ellers. Imidlertid er konkurransen høyere på dette tidspunktet.

Dumt - få sparken

Når en person uten erfaring ansettes, er det tilsvarende forventninger til ham.

En nykommer i jobben forventes å:

• Kjennskap til generell teknisk basis
• Studerer spesifikasjonene til selskapets fagområde
• Mestre verktøyene og praksisene som brukes

Noen organisasjoner tilbyr opplæringskurs for nykommere om teknologiene, verktøyene og lokale prosedyrene som brukes. For eksempel god oppførsel når du bruker bedrifts-e-post, prosedyren for å endre dokumenter i en wiki, lokale funksjoner ved å jobbe med VCS og en feilsporer.

Det finnes også tekniske introduksjonskurs, men nytten er tvilsom. Hvis det gjelder ansettelse, så er arbeidsgiverne overbevist om at du har et tilstrekkelig kunnskapsnivå. Det er best å bare ta slike kurs i god tro, som en liten formalitet. Kanskje det faktisk vil være noe nyttig i dem.

Når du begynner å jobbe, husk at en nybegynner definitivt ikke vil bli betrodd å løse en presserende, kompleks og samtidig viktig oppgave. Mest sannsynlig vil det bare være én av disse egenskapene. Eller enkelt, men presserende: fiks oppsettet, send noen en fil, gjenskap problemet. Eller vanskelig, men uten håp om gjennomføring – slik at nybegynneren samler mer rake. Eller viktig, men eksperimentell. For eksempel et prosjekt som alle har ønsket seg lenge, men ikke finner tid til å gjennomføre.

Oppgaver for å mestre verktøyene vil være "vanskelige" og kunstige. Mest sannsynlig vil dette være en forenklet versjon av hovedsystemet. Slike oppgaver bruker samme teknologistabel og samme domenevilkår som hele prosjektet. I dette tilfellet vil ikke utførelsesresultatet bli gitt til sluttbrukeren. Dette kan være demotiverende, men det er bedre å motstå denne følelsen. En kunstig oppgave må gjøres samvittighetsfullt, som om prosjektets skjebne avhenger av det.

Resultatet av å løse ditt første problem vil danne førsteinntrykket av deg blant kolleger som ikke var til stede på intervjuet.

Et annet alternativ for verktøymestringsoppgaven er "kjør prosjektet på en lokal maskin/testmiljø." Noen ganger er denne prosessen beskrevet i instruksjonene. Men de er vanligvis gamle og noen steder utdaterte. Du kan gi reelle fordeler til prosjektet hvis du skriver nye instruksjoner med avklaringer på problemene som har oppstått. Sikkert på universitetet måtte du skrive en RGR for en rapport om noen disipliner. Det er nesten det samme her. Dokumentet skal gjenspeile handlingene som må utføres for å starte.

Vanligvis er trinnene for å kjøre et produkt i et testmiljø noe slikt:

• klone et depot, bytt til en gren eller tag
• lage en konfigurasjonsfil
• forberede databasestrukturen
• fyll den med testdata
• bygge eller kompilere prosjektet,
• kjøre et sett med konsollskript i en bestemt rekkefølge

Under prosessen med å kjøre et system lokalt, vil det uunngåelig oppstå uventede problemer.

Oppdagede løsninger på problemer må legges til i distribusjonsinstruksjonene. Neste gang du følger instruksjonene, vil disse problemene ikke lenger oppstå. Når du fyller ut konfigurasjonsfiler og kaller skript, må du være oppmerksom på hvilken verdi som brukes hvor og hva den skal matche. For eksempel, hvis et prosjekt er satt sammen ved hjelp av et CI-system og deretter lansert av et skript, er det viktig å forstå hvor du skal skrive filialnavnet eller forpliktelsesnummeret. Det hender at skriptet innebærer overføring av IP-adressen eller DNS-navnet til databasen, dens pålogging og passord. I dette tilfellet må du vite hvilken adresse du skal bruke for testmiljøet, hvilke pålogginger som finnes og hvilke passord du må angi for dem.

Noen oppgaver kan virke enkle for erfarne utviklere, men utfordrende for praktikanter. Dette er normalt.

Utviklere må løse tekniske problemer hver dag. Erfarne medarbeidere har allerede løst mange problemer før, mens nykommere ennå ikke har taklet dem. Den beste taktikken er å registrere alle feil som oppstår i dokumentet "løsing av problemer med ${oppgavenavn}". For hvert problem må du formulere en hypotese om årsaken, finne løsninger på Internett og prøve dem en etter en. Resultatet av hvert forsøk skal også registreres.

Registrering av forskningen din i form av et dokument vil tillate deg å:

• losse små detaljer fra hodet. For eksempel konfigurasjonsparametere, DNS/IP-adresser, konsollkommandoer og SQL-spørringer.
• husk «hva gjorde jeg i går» når oppgaven varer i flere dager
• ikke vandre i sirkler. Du kan alltid lese hva du gjorde før og forstå at du har gått tilbake til det opprinnelige problemet
• svar tydelig på spørsmålet: "hva gjorde du i dag?" selv om det ikke er noen ferdig løsning ennå.

Du må kunne kommunisere status på oppgavene dine til kollegaer

Fra tid til annen vil kolleger være interessert i dine suksesser og dele deres. Sett av litt tid til dette daglig eller ukentlig.

Hvis du ikke holder styr på problemer du har møtt og løst, vil beskrivelsen av suksessene dine se slik ut: «Jeg prøvde å gjøre oppgaven, men jeg klarer det ikke. Jeg leter fortsatt etter en løsning." Fra denne historien er det ikke klart om praktikanten gjorde noe eller bare satt og leste. Trenger han hjelp? Har situasjonen endret seg siden i går?

Hvis du holder et dokument på jakt etter løsninger, kan du si "Jeg prøver å gjøre denne oppgaven. Jeg hadde slike feil. Slik bestemte jeg meg. Jeg har ikke forholdt meg til denne ennå. Det er disse hypotesene og løsningene. Jeg sjekker dem nå."

Hvis oppgaven kan måles på noen måte, bør statusen inneholde tall. For eksempel, for oppgaven "skriv enhetstester for en modul," kan du si "Jeg planlegger å gjøre 20 tester, nå har jeg skrevet 10."

Jo flere detaljer du oppgir, jo bedre vil kollegene dine forstå hva du gjorde. Dette vil skape en positiv holdning til deg blant kollegene dine og la dem forstå om du trenger hjelp eller ikke.

Spør gjerne om hjelp

Jeg skrev ovenfor at når et problem oppstår, må du formulere en hypotese om dets årsaker og mulige løsninger. Imidlertid hender det at hypotesene ikke er begrunnet, og uavhengig funnet løsninger på problemet ikke fungerer. I dette tilfellet er det bedre å be om hjelp. For ikke å misbruke oppmerksomheten til kollegene dine, må du sitte på hvert problem selv. Hvis du ikke har klart å finne en løsning på et par timer, er det på tide å søke råd fra mer erfarne kamerater.

Et godt sted å begynne er å spørre: "har noen vært borti dette problemet før?" med en kort beskrivelse av problemet. Det anbefales å legge ved en del av feilmeldingen eller et skjermbilde. Det er bedre å sende denne meldingen for første gang til en generell jobbprat. På denne måten distraherer du ikke de som virkelig har det travelt fra jobben. Gratis kolleger vil se meldingen din og vil kunne hjelpe.

Hvis ingen har hjulpet etter en melding i den generelle chatten, prøv å fange en erfaren kollega i en pause: lunsj, gå for te/kaffe, et slag tennis eller en røykpause. Hvis dette ikke fungerer, rapporter deretter om problemene dine på møtet eller stand-up.

Hvis kjente problemer løses, kan alt ende der. Hvis problemet er nytt, vil en etterforskning starte, hvor det vil være nødvendig å handle i henhold til omstendighetene.

De «viktige» nybegynneroppgavene som sluttbrukeren trenger vil være kjedelige og små. For eksempel, "legg til en ekstra kolonne i rapporten" eller "korriger en skrivefeil i det trykte skjemaet" eller "implementer en modellmetode for å laste klientattributter fra DBMS." Hensikten med slike oppgaver er at nybegynneren skal bli kjent med fagområdet og integrere seg i det daglige arbeidet.

Det er viktig ikke bare å teknisk løse problemet, men også å utvide kunnskapen om fagområdet.

Vilkår vil vises i oppgavebeskrivelsen, i chatter og samtaler. De kan se ut som kjente substantiv. Men innenfor rammen av informasjonssystemet har de en spesiell, mer presis betydning. Betydningen av oppdagede termer registreres best i et spesielt dokument - en ordbok med termer. Når du legger til ordboken, er det nok å skrive din forståelse av ordet, men for en ekte dekoding er det bedre å kontakte en analytiker. Hvis det mangler, gå til prosjektets gamle tidtakere. Å vedlikeholde en ordbok med begreper er en av de enkleste måtene å bli kjent med fagområdet til et prosjekt.

Når du finner et felles språk med kollegene dine, vil de begynne å se deg ikke som en ny praktikant, men som en likeverdig spesialist.

Det er spesielle oppgaver, for eksempel "skrive enhetstester for en modul." Du kan nesten ikke bli sittende fast på det i lang tid på jakt etter løsninger. Samtidig er det ganske alvorlig og gis ikke bare for trainee-trening. Skriftlige tester øker stabiliteten til prosjektet ved å redusere feil i applikasjonen og redusere tiden for menneskelig testing. I en ideell verden skrives enhetstester umiddelbart under utviklingen, men virkeligheten er alltid annerledes. Det hender at utvikleren av en modul holder den helt i hodet og ikke ser behovet for å skrive dem. "Alt er åpenbart, hva er det å teste?" Noen ganger skrives moduler i rushmodus og det er ikke tid igjen til enhetstester. Så i den virkelige verden er det kanskje ikke enhetstester. Derfor er oppgaven med å skrive enhetstester tildelt en nybegynner. På denne måten vil praktikanten kunne bli vant til prosjektet raskere, og prosjektet vil kunne spare tid til høyere betalte spesialister.

Det hender at praktikanter og nykommere blir tildelt rollen som fullverdige testere. Vanligvis, før du gjør dette, må du distribuere produktet lokalt og lese kravene. Som et resultat forventes det at den nye medarbeideren:

• spørsmål som «hvis du gjør det slik, vil det bli slik. Dette står ikke i kravene. Det bør være?"
• oppgaver i feilsporeren "kravene sier dette, men i virkeligheten er det skrevet annerledes."

Testing er et for bredt område for denne artikkelen. Hvis du får en lignende oppgave, søk på Internett for den beste måten å fullføre den.

Hvis du roter til, får du sparken

I en normal organisasjon, hvis det plutselig skjer at en uerfaren ansatt får tilgang til noe kritisk og ødelegger noe, så får den som lot dette skje skylden. Fordi en nybegynner, som standard, ikke har tilgang til kritisk infrastruktur. Med tilstrekkelig veiledning vil de ikke la alle hundene gå til spille på en uerfaren trainee.

Hvis noe skjer, vil de ikke sparke deg på grunn av én hendelse. Folk lærer av feil. Praktikanten som rotet til lærte en verdifull lekse og er veldig forskjellig fra andre praktikanter. Hvis du sparker en som roter, vil noen andre komme i hans sted og rote til på samme måte.

Det viktigste er å lære av feil og ikke gjenta dem igjen.

Hvis en person ikke trekker konklusjoner fra sine feil, vil de prøve å si farvel til ham. Imidlertid er verden mangfoldig. I en gangsterorganisasjon kan de umiddelbart kaste deg ut av vinduet for den første feilen. Men det er bedre å unngå slike selskaper ved å spørre først eller finne ut mer under intervjuet.

Det er bedre å unngå hendelser

Selv om du personlig ikke får sparken for en feil, vil en slik hendelse føre til uønskede problemer for teamet ditt og prosjektet som helhet. Vær derfor spesielt forsiktig med operasjonene med å slette eller opprette tabeller i databasen, filer, tjenesteforekomster og dokumenter i prosjektets kunnskapsbase. Hvis du kommer over adressen til en ny forbindelse, sjekk med minst to forskjellige personer hva som kan gjøres der. Sjekk rettighetene dine i miljøer, ikke ved prøving og feiling, men ved å bruke de riktige kommandoene. For eksempel rettigheter til å slette filer ved å bruke `ls`-kommandoen, rettigheter til å jobbe med tabeller i mysql ved å bruke `SHOW GRANTS FOR 'user'@'host';`-kommandoen og lignende. I nesten alle verktøy vil du ha en lignende mulighet.

Når du redigerer filer, hold en kopi av originalen for deg selv, for sikkerhets skyld.

Det bygges flere barrierer mellom trainee og sluttbruker.

Hvis du umiddelbart kunne gi produktet ditt til forbrukeren, ville du ikke fått jobb, men å legge ut på en "gratis svømmetur". Men mens du ikke har en slik mulighet (og samtidig ansvar), må du gå gjennom flere stadier av kontroll på prosjektet.
Den første av disse er verifisering av en mentor. Han vurderer nybegynnerens beslutning fra et teknisk synspunkt. Hvis en mentor ikke er tildelt, må du finne en. For å gjøre dette, må du velge en av de gamle i prosjektet og i en pause be ham se på løsningen: ble problemet løst riktig? Hvis han begynner å lete og svare, så er en mentor funnet. Hvis han ignorerer det, er det verdt å spørre noen andre.

Neste trinn er kvalitetssikring. På russisk - testere. I sovjetisk stil - standard kontroll- og kvalitetskontrollavdeling. De skal sørge for at praktikantens prestasjoner er i samsvar med oppgaven som er tildelt ham. De vil sjelden lese koden. Oftest vil testere sjekke det bygde prosjektet, som utvikleren lagrer i versjonskontrollsystemet.

Det tredje trinnet er release manager. Det er kanskje ikke en egen person for denne oppgaven, men noen spiller likevel rollen. Han sjekker at testere har bekreftet at prosjektet kan slippes. Etter dette utfører den aktivitetene for å levere produktet til sluttbrukere.
I små organisasjoner kan det hende at disse barrierene ikke eksisterer av ulike årsaker. De vil imidlertid ikke gi en nybegynner oppgaven med å endre noe viktig. For ingen trenger denne risikoen.

Du må involvere deg i kampen først, og så får vi se.
Napoleon Bonaparte

Jeg håper denne artikkelen vil hjelpe deg med å overvinne usikkerheten din og sende inn din første CV. Selvfølgelig må du forberede deg først. Men det er ingen grunn til å overlenge. Du har mest sannsynlig allerede studert ved et universitet eller høyskole i flere år. Hvor skal du dra videre? Til slutt er det bedre å høre "nei" en gang fra en spesialist og jobbe med feil enn å si "nei" til deg selv hver dag og slutte å vokse profesjonelt.

Når du først er ansatt, må du fokusere på å vokse fra en praktikant til et fullverdig teammedlem. Denne typen vekst kommer vanligvis med en økning i lønnen din.

Jeg ønsker deg tålmodighet og utholdenhet.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Hva var dine første oppgaver i din første jobb innen IT?

• Kompleks

• Viktig

• Som haster

• Ingen av de ovennevnte

75 brukere stemte. 20 brukere avsto.

Hva måtte du gjøre i første omgang?

• Installer produktet lokalt

• Test et eksisterende produkt

• Gjennomfør en opplæring, falsk oppgave

• Gjør et eksperimentelt, ekte prosjekt for en klient

63 brukere stemte. 25 brukere avsto.

Hvor mange elever i gruppen din var i stand til å utføre oppgaver i tekniske fag selvstendig under opplæringen?

• 1 av 10

• 1 av 5

• Hvert sekund

• Alt, med sjeldne unntak

70 brukere stemte. 19 brukere avsto.

Kilde: www.habr.com