En software engineering overlevelses guide

Ressourcer, der hjælper dig i begyndelsen af ​​din karriere

De første par år af min karriere var en tid med intens læring.

Jeg stødte på virkeligheden ved at være softwareingeniør og måtte tilegne mig mange færdigheder, som jeg ikke vidste, jeg havde brug for. Når jeg ser tilbage, ville det helt sikkert have været rart at kende de ting, jeg kender nu.

Så jeg skrev denne vejledning for at hjælpe andre baseret på erfaringerne fra udviklere, som jeg vejledte i deres første par år som professionelle, og de af mig selv og nogle af mine kolleger.

Jeg vil dække:

  • Sådan får du det bedste ud af interviews,
  • Sådan overlever du (og trives) i dit arbejde som softwareingeniør,
  • Og hvilke ressourcer man skal se på, når man overvejer løbende forbedringer.

Interviews

Når du starter din karriere inden for softwareingeniør, skal du stå over for en ubestridelig kendsgerning. Interviews suger.

De kan være forfærdelige for alle involverede. Efter at have været både en interviewer og en interviewperson kan jeg bevidne, at interviews er et stort tidsfald, ekstremt stressende og en virkelig dårlig indikator for fremtidig jobpræstation. Ikke desto mindre er de et nødvendigt onde, som du og dit CV bedre er forberedt på.

Forbereder sig på kamp

Hvis du overvejer en karriere inden for Software Engineering, skal du sørge for at lære nogle af de mest stillede spørgsmål om programmeringsinterview, såsom 'FizzBuzz':

“Skriv et program, der udskriver tallene fra 1 til 100. Men for multipler af tre udskriver 'Fizz' i stedet for tallet og for multiplerne af fem udskriver 'Buzz'. For tal, der er multipla af både tre og fem, udskriver 'FizzBuzz'. ”(Coding Horror)

Det lyder enkelt nok, ikke?

Nå, langt de fleste interviewpersoner fejler denne enkle test, endsige dens mere komplekse varianter.

Jeg har personligt set mange kandidater til seniorstillinger mislykkes denne test, mens jeg har fuld internetadgang . Så sørg for at hvis et programmeringssprog er anført på dit cv, ved du hvordan man i det mindste gør FizzBuzz i det. Ellers spilder du bare alles tid, inklusive din.

Selvfølgelig skal du vide mere end bare FizzBuzz for at overleve dine interviews. Du skal også sørge for, at du ved:

  • Grundlæggende datastrukturer og algoritmer: såsom sammenkædede lister, arrays, træer og sorter.
  • Almindelige “gotchas” på dit valgte sprog, f.eks. Om strenge er uforanderlige, og hvordan hukommelse styres.
  • Objektorienteret programmeringskoncepter som klasse versus objekt og arv.

I begyndelsen af ​​din karriere bliver du nødt til at skinne på denne slags spørgsmål, da du ikke har erfaringerne til at bevise, at du vil være god til jobbet. Der er to ressourcer, som jeg altid anbefaler, når jeg forbereder mig til interviews:

  • “Cracking the Coding Interview”, en fantastisk bog, der indeholder mange kodningsproblemer og deres løsninger samt resuméer af, hvad du har brug for at vide for at løse dem
  • CodeWars, et websted, der har en stor samling af kodningsproblemer, som du kan løse i browseren ved hjælp af et bredt udvalg af sprog. Den mest nyttige del er at se, hvordan andre brugere løste det samme problem. Du får vist forskellige tilgange til det samme problem og lærer nye værktøjer på det sprog, du vælger.

Giv dig selv den ekstra kant

Der er flere ting, du kan gøre, der giver dig det lille ekstra.

Først lærer at kommunikere dine oplevelser . Du skal have en elevatorhøjde, der opsummerer dit CV til en sammenhængende og engagerende fortælling.

Derudover skal du kende dit eget CV! Det lyder fjollet, men jeg har set mange interviewpersoner kæmpe for at forklare et bestemt emne på deres cv. Du skal være i stand til at besvare spørgsmål om enhver oplevelse, du angiver på dit cv, og forklare, hvordan det har gjort dig til en bedre kandidat til jobbet.

Dernæst har kodeeksempler, der skal vises på GitHub (eller et andet offentligt arkiv).

At se er at tro, og interviewere, der kan se din kode, vil gøre underværker. Plus det viser, at du har en forståelse af versionskontrolsystemer.

Kodeprøverne behøver ikke at være noget for komplekse, men de skal være rene og vise god kodningspraksis. Dette er din chance for at vise, hvordan du koder uden tidspres fra et kodningssamtale.

Når du har gjort alt ovenstående, er det tid til at overveje at deltage i et open source-projekt . Det viser, at du kan arbejde i en eksisterende kodebase og samarbejde med andre programmører.

Dette vil være det tætteste, du kan komme til programmering i et industrimiljø uden faktisk at være i et industrimiljø. Dette er langt den hårdeste og tidskrævende vare hidtil, så reserver det, indtil du har gennemført den lavere hængende frugt, jeg har diskuteret ovenfor.

Interview med din interviewer

I jagten og stresset på jobjagten glemmer mange kandidater, at interview er en tovejsgade. Da virksomheden forsøger at finde ud af, om du er den rigtige person til jobbet, skal du finde ud af, om virksomheden passer til dig.

Sørg for, at du kommer til at stille nogle af nedenstående spørgsmål, selvom det er i en opfølgende e-mail. Vær opmærksom på, at virksomheder ofte prøver at dreje uden at følge bedste tekniske praksis som en fordel, så læs mellem linjerne.

Her er nogle eksempler på spørgsmål, du kan stille:

"Hvordan ville en typisk arbejdsdag se ud for mig?"

Det er vigtigt at vide, hvad man kan forvente af en bestemt position, fordi job inden for softwareingeniør varierer ret meget. Det kan f.eks. Forventes, at du vedligeholder servere eller taler direkte med klienter.

Rødt flag: " Jeg er ikke sikker." → Betyder, at de personer, der interviewer dig, ikke vil være på dit team, eller at de ikke har en klar idé om, hvorfor de ansætter dig.

"Hvordan tester du din software?"

Ideelt set bør en kombination af enhedstest, manuel test og automatiseret test bruges til at kontrollere kvaliteten af ​​koden.

Rødt flag: " Vi skriver bare ikke bugs, haha." → Disse mennesker er nøjagtigt dem der skriver bugs.

"Hvilket versionskontrolsystem bruger du?"

Versionskontrolsystemer er yderst nyttige til samarbejde, og der er ingen grunde til ikke at bruge en i professionelle omgivelser.

Rødt flag nr. 1: "Uh, versionskontrolsystem?" → Kør langt, langt væk.

Rødt flag nr. 2: gt; ” → Angiver, at de sandsynligvis ikke holder trit med tiden og ikke har opdateret deres infrastruktur i lang tid.

“Gør du peer reviews?”

Peer reviews eller at få en anden til at se på din kode, før den går ind i kodebasen, er en fantastisk måde at få øje på dumme fejl på og er en vigtig træningsmulighed, når du starter din karriere.

Rødt flag: "Vi stoler bare på hinanden!" → Meget sandsynligt, at seniorudviklerne er meget beskyttende over for deres kode og ikke gode til at modtage feedback.

"Hvilke programmer har du til kontinuerlig uddannelse?"

At være softwareingeniør betyder konstant at lære, når teknologier vises, modnes og bliver forældede i en svimlende hastighed. Som sådan har mange virksomheder et uddannelsesbudget, som de bruger til at betale for universitets- og online-klasser, konferencer eller interne samtaler.

Rødt flag: "Du mener at læse ting online i din fritid?" → Virksomheden er enten spændt på kontanter eller ser udviklere som udskiftelige og ikke som langsigtede investeringer.

"Hvad er den softwareudviklingsproces, du bruger?"

Processen er afgørende for softwareteknik, uanset de faktiske detaljer. Oplysningerne om, hvad der er optimal proces, er genstand for intens debat, men den blotte eksistens af en aftalt måde at arbejde på et projekt på minimerer kaos og sikrer, at alle er på samme side.

Rødt flag: "Vores proces er inspireret af jazz i fri form." → Mest sandsynligt er hele afdelingen i brandslukningstilstand og hopper fra nødsituation til nødsituation uden noget klart mål.

"Hvordan tackler du teknisk gæld?"

Teknisk gæld er en ophobning af forældede teknologier og hurtige men snavsede løsninger i kodebasen. Adressering af det er vigtigt for kodens langsigtede sundhed og bør ske løbende.

Rødt flag: "Vi fokuserer udelukkende på nye funktioner." → Deres kodebase er et rod, eller det bliver snart.

"Hvordan er din virksomhedskultur?"

Virksomhedskultur kan være et meget vagt koncept, men selv små ting som et åbent kontor i forhold til aflukker vil ændre din daglige interaktion med kolleger på betydelige måder. Der er ingen generelle røde flag, men sørg for, at deres svar er noget, du kan leve med i 40+ timer om ugen i årevis.

Arbejder som softwareingeniør

På dette stadium, hvis du klarede dig godt i dine interviews og kunne lide, hvordan interviewerne besvarede dine spørgsmål, vil du sandsynligvis blive ansat.

Tillykke, du er officielt ingeniør!

Hvad nu? Nå, det er tid til at genlære en masse ting om kodning og arbejde. Og da vi er programmører, skal vi starte med at diskutere kode.

God industri kode

God branchekode har følgende egenskaber i den rækkefølge:

  • Læsbar , fordi kode læses og vedligeholdes oftere, end den er skrevet. Hensigten med koden skal være klar for andre udviklere år efter, at du har skrevet den.
  • Defensiv, som i følgende bedste praksis for defensiv kodning. Defensiv kodning er et emne alene, men kernen i det er: Du skal sikre, at forkert brug af klasser og metoder, du har skrevet, ikke fører til, at din kode går ned på softwaren.
  • Optimeret , hvilket er sidst på denne liste, fordi du for det meste ikke behøver at bekymre dig om det. Det betyder ikke, at du skal skrive dårlig kode, der gør noget i O (n³), når der findes en lineær løsning. Men udviklere er generelt ivrige efter at prøve at overoptimere, når der ikke er behov for det, ofte på bekostning af kodens læsbarhed og forsvarlighed. Du skal altid være i stand til at bevise, at der faktisk er behov for en vis optimering, der ofrer disse egenskaber.

Nu hvor du ved, hvordan du skriver en god branchekode:

Du laver ikke meget kodning

Det kan komme som en overraskelse, men for det meste skriver du ikke ny kode, men i stedet vil du være:

  • Fejlfinding
  • Læsning af eksisterende kode
  • I møder eller ved at skrive e-mails
  • Undersøg, hvad du skal gøre, så du ikke skriver kode

Derfor er andre færdigheder end kodning lige så vigtige for din karriere.

Fejlfinding og læsningskode

  • Du har brug for meget mere end fejlretning ved hjælp af udskriftserklæringer. Alle udbredte sprog og tech stakke har en række kraftfulde værktøjer. Lær at bruge dem, da de gør fejlretning til en leg og sparer dig utallige timer.
  • Forstå kodebasen. De fleste teknologiske stakke har en slags værktøjer til generering af kodegraf, der hjælper dig med at forstå strukturen i kodebasen. Enterprise IDE'er har generelt den funktionalitet indbygget. Du kan også udforske koden ved hjælp af værktøjer som ReSharper, grep eller Sourcegraph.
  • Forstå produktet. Y ou'll blive overrasket, hvor mange udviklere ikke, hvordan softwaren er meningen at arbejde, før de forsøger at ”fix” det. Læs bare dokumentationen.

Organiser dine tanker

Da meget af din tid vil blive brugt på kommunikation, forskning og multi-tasking, har du brug for nogle værktøjer til at hjælpe med at holde alt i orden.

  • TODO-lister / opgaver : Din virksomhed skal allerede have tasking-software af en slags, men det hjælper også med at have et personligt system. Brug post-it-noter eller software som Trello eller Todoist.
  • Noter: Tag altid noter på møder, arbejd for at forbedre eksisterende dokumentation og opret en personlig vidensbase. Brug Evernote, OneNote eller en notesbog, som i gamle dage. Det kan virke som overkill, men du takker dig selv et år senere, når du besøger den obskure byggeproces, som det tog dig 3 dage at finde ud af første gang. Jeg har aldrig mødt en god softwareingeniør, der ikke tog omfattende notater.
  • Diagrammer / visualiseringer: Mennesker er visuelle væsner, og ved at oprette diagrammer over processer og arkitekturer kan du og andre forstå komplekse emner. Diagrammer er især nyttige, når de kommunikerer med ikke-tekniske kolleger. Brug Lucidchart, Visio eller en almindelig tavle.

Ved, hvornår du skal bruge biblioteker

Kort svar: Næsten hele tiden.

Langt svar: 99% af tiden, skal du ikke genopfinde hjulet. I de fleste Software Engineering-stillinger er implementering af en bestemt slags slags fuldstændig spild af tid. Det betyder ikke, at du ikke skal vide, hvordan de algoritmer og datastrukturer, du bruger, fungerer, da det hjælper dig med at beslutte, hvad du skal bruge, og hvornår.

For at være en effektiv softwareingeniør skal du forstå de biblioteker, du har til din rådighed. Standardbibliotekerne på de mest populære sprog er yderst nyttige og er større end hvad du ville forvente. Derudover kan kodebasen muligvis også bruge yderligere specialiserede biblioteker. Læs deres dokumentation og ved, hvornår du skal bruge dem.

Du bør heller ikke være bange for at foreslå yderligere biblioteker, hvis de sparer tid. Du skal dog sikre dig, at du vælger et godt bibliotek til industribrug. Et godt bibliotek er:

  • Open source , så du selv kan kontrollere kvaliteten af ​​koden og muligvis rette fejl, der er kritiske for din applikation.
  • Licenseret under en tilladelig licens som MIT og BSD , så din virksomhed ikke løber ind i nogen problemer ved at bruge den. Vær forsigtig med GPL, så du ikke åbner hele din kodebase ved et uheld.
  • Moden , dvs. det har været ude i nogen tid og har et rigt sæt funktioner.
  • Vedligeholdt , med nye udgivelser, der ofte kommer ud.
  • Brugt af andre virksomheder eller projekter , der fungerer som et godkendelsesstempel og sikrer, at det har branchestøtte til fortsat vedligeholdelse.

Løbende forbedringer

Ud over at lære de færdigheder, der vil gøre dig bedre i dit daglige job, skal du også løbende forbedre dine færdigheder og lære nye for at skabe nye karrieremuligheder for dig selv.

Mulighederne for at lære er mange, og mange af dem er overkommelige:

  • Onlinekurser: Muligheden for at lære af de bedste professorer på området i et fleksibelt format bør ikke gå glip af. Tjek Coursera, Udacity og edX (blandt mange) for kurser, der kan supplere dine eksisterende færdigheder.
  • Online kandidatuddannelser: En nylig tendens blandt toprangerede universiteter, online kandidatuddannelser er en fleksibel måde at fortsætte din formelle uddannelse på. De er også generelt billigere tak på campus-grader, hvor de fleste programmer koster ~ $ 10.000 for hele graden. Georgia Tech, UT og UC San Diego er nogle af de universiteter, der tilbyder sådanne grader. Jeg personligt anbefaler Georgia Tech's Online Master, som jeg dimitterede fra i år.
  • Blogs: Blogs er en vigtig del af udviklerfællesskabet (ingen overraskelse her, da du læser en lige nu). Blogs som Coding Horror, Joel on Software eller endnu mere humoristiske websteder som The Daily WTF kan give dig en god idé om, hvad og hvad du ikke skal gøre som softwareingeniør. Browsing Medium, r / programmering, HackerNews eller andre feeds fører dig også til gode artikler og blogs.
  • Konferencer: Sidst, men ikke mindst, er konferencer en fantastisk læringsmulighed, og du bør helt sikkert udnytte din virksomheds træningsbudget ved at gå til dem. En meget ufuldstændig liste over gode konferencer at tjekke ud (ved siden af ​​deres emne): GOTO; (Generelt), Strange Loop (Generelt), PyCon (Python), CPPCon (C ++), DEF CON (Sikkerhed), Flydende (Webudvikling). Alle disse har også videoer af (de fleste) samtaler på YouTube, så du vil være i stand til at lære noget, selvom du ikke kan deltage!

Forhåbentlig har denne artikel bevæbnet dig med viden om, hvad du kan forvente fra begyndelsen af ​​din karriere som softwareingeniør og givet dig værktøjerne til at klare sig godt på denne spændende rejse! Tak for læsningen! Hvis du har spørgsmål eller forslag, bedes du efterlade en kommentar eller tweet @AlexievValeri.