En software engineering overlevelsesguide

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

“Tændt bærbar computer” af Fabian Grohs på Unsplash

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, at jeg havde brug for. Når jeg ser tilbage, ville det helt sikkert have været rart at vide de ting, jeg ved nu.

Så jeg skrev denne vejledning til at hjælpe andre baseret på erfaringerne fra udviklere, som jeg mentorede i deres første par år som professionelle, og dem 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 (og trives) i dit arbejde som softwareingeniør,
  • Og hvilke ressourcer man skal se på, når man overvejer kontinuerlig forbedring.

Interviews

Når du starter din karriere inden for software-teknik, bliver du nødt til at stå over for en uomtvistelig kendsgerning. Interviews sutter.

De kan være forfærdelige for alle involverede. Efter at have været både en interviewer og en interviewperson, kan jeg attestere, at interviews er en big time sink, ekstremt stressende og en rigtig dårlig indikator for fremtidig jobydelse. Ikke desto mindre er de et nødvendigt onde, som du og din CV bedre er forberedt på.

Forberedelse til slaget

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 til programmeringssamtale, såsom 'FizzBuzz':

”Skriv et program, der udskriver numrene fra 1 til 100. Men for multipla af tre udskrives 'Fizz' i stedet for tallet og for multiplerne af fem trykker 'Buzz'. For tal, der er multipla af både tre og fem, udskrives 'FizzBuzz'. ”
(Kodningshorror)

Lyder enkelt nok, ikke?

Det store flertal af de interviewede mislykkes i denne enkle test, hvad så det er dens mere komplekse varianter.

Jeg har personligt set mange kandidater til ledende stillinger fejle denne test, mens jeg har fuld internetadgang. Så sørg for, at hvis et programmeringssprog er angivet på dit cv, ved du, hvordan du mindst 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 linkede 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 over disse 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 en masse 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 se forskellige tilgange til det samme problem og lære nye værktøjer på det sprog, du vælger.

Giv dig selv den ekstra kant

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

Lær først at kommunikere dine oplevelser. Du skal have en elevatorstigning, der opsummerer dit CV til en sammenhængende og engagerende fortælling.

Derudover kender du dit eget cv! Det lyder fjollet, men jeg har set en masse 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, som du viser på dit cv og forklare, hvordan det har gjort dig til en bedre kandidat til jobbet.

Derefter skal du have kodeeksempler, der skal vises på GitHub (eller et andet offentligt lager).

At se er tro, og interviewere, der er i stand til at se din kode, vil gøre vidundere. Plus, det viser, at du har forståelse for versionskontrolsystemer.

Kodeprøverne behøver ikke være noget for kompliceret, men de skal være rene og vise god kodningspraksis. Dette er din chance for at vise, hvordan du koder uden tidspresset i en kodende samtale.

Når du har gjort alt det 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 programmerere.

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

Interview din interviewer

I travlheden og stresset med jobjagt glemmer mange kandidater, at interview er en tovejsgade. Da virksomheden prøver at finde ud af, om du er den rigtige person til jobbet, bør du finde ud af, om virksomheden er den rigtige pasform til dig.

Sørg for, at du får stillet nogle af spørgsmålene herunder, selvom det er i en opfølgende e-mail. Vær opmærksom på, at virksomheder ofte måske prøver at dreje og ikke følge bedste teknikpraksis som en frynsegod, så læs mellem linjerne.

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

”Hvordan ser en typisk arbejdsdag ud for mig?”

Det er vigtigt at vide, hvad man kan forvente af en bestemt position, fordi Software Engineering-job varierer ganske lidt. Det forventes, at du f.eks. Vedligeholder servere eller taler med klienter direkte.

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

"Hvordan tester du din software?"

Ideelt skal en kombination af enhedstestning, manuel test og automatiseret test bruges til at verificere kodens kvalitet.

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

"Hvilket versionskontrolsystem bruger du?"

Versionsstyringssystemer er yderst nyttige til samarbejde, og der er nul grunde til ikke at bruge et i en professionel indstilling.

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

Brug altid versionskontrol.

Rødt flag nr. 2: “” → Angiver, at de sandsynligvis ikke følger med tiden og ikke har opdateret deres infrastruktur i lang tid.

“Gør du peer reviews?”

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

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

”Hvilke programmer har du til kontinuerlig uddannelse?”

At være softwareingeniør betyder konstant læring, 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 onlinekurser, konferencer eller internt samtaler.

Rødt flag: “Du mener at læse ting online i din fritid?” → Virksomheden er enten bundet til 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 udgør optimal proces, er genstand for en intens debat, men blot eksistensen af ​​en aftalte måde at arbejde på et projekt minimerer kaos og sikrer, at alle er på samme side.

Rødt flag: “Vores proces er inspireret af fri-form jazz.” → Sandsynligvis er hele afdelingen i brandbekæmpelsestilstand og hopper fra nødsituation til nødsituation uden noget klart mål.

"Hvordan takler du teknisk gæld?"

Teknisk gæld er en ophobning af forældede teknologier og hurtig-men-beskidte løsninger i kodebasen. At tackle det er vigtigt for kodens langsigtede sundhed og bør ske kontinuerligt.

Rødt flag: ”Vi er udelukkende fokuseret på nye funktioner.” → Deres kodebase er et rod, eller det vil snart være.

"Hvordan ser din virksomhedskultur ud?"

Virksomhedskultur kan være et meget vagt koncept, men selv små ting som et åbent kontor versus aflukke ændrer 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 tidspunkt, 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 læse en masse ting om kodning og arbejde igen. Og da vi er programmører, så lad os starte med at diskutere kode.

God industrikode

God branche-kode har følgende egenskaber i den rækkefølge:

  • Læsbar, fordi kode læses og vedligeholdes oftere, end den er skrevet. Kodens intention skal være klar for andre udviklere år efter, at du har skrevet den.
  • Defensivt, som ved at følge bedste praksis med defensiv kodning. Defensiv kodning er et emne helt alene, men kernen i det er: Du skal sikre dig, at forkert brug af klasser og metoder, du har skrevet, ikke fører til, at din kode går ned i softwaren.
  • Optimeret, som sidst er på denne liste, fordi du for det meste ikke behøver at bekymre dig om det. Det betyder ikke, at du skal skrive en 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 forsvarbarhed. Du skal altid være i stand til at bevise, at en bestemt optimering, der ofrer disse egenskaber, faktisk er nødvendig.

Nu hvor du ved, hvordan man skriver en god branche-kode:

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:

  • debugging
  • Læser eksisterende kode
  • I møder eller skrivning af e-mails
  • Undersøger, hvad du skal gøre, så du ikke skriver kode

Derfor vil andre færdigheder end kodning være lige så vigtige for din karriere.

Fejlsøgning og læsekode

  • Du har brug for meget mere end fejlsøgning ved hjælp af trykte udsagn. Alle vidt anvendte sprog og teknologiske stakke har en række kraftfulde værktøjer. Lær at bruge dem, da de får debugging til en leg og sparer dig utallige timer.
  • Forstå kodebasen. De fleste tech-stakke har en slags generering af kodegrafværktøjer, der hjælper dig med at forstå strukturen i kodebasen. Enterprise IDE'er har generelt denne funktionalitet indbygget. Du kan også udforske koden ved hjælp af værktøjer som ReSharper, grep eller Sourcegraph.
  • Forstå produktet. Du vil blive overrasket over, hvor mange udviklere ikke ved, hvordan softwaren skal fungere, før de prøver at "ordne" den. Læs 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 / opgave: Din virksomhed skal allerede have tasking-software af en eller anden art, men det hjælper også med at have et personligt system. Brug post-it-noter eller software som Trello eller Todoist.
  • Bemærkninger: Noter altid i møder, arbejd på at forbedre eksisterende dokumentation og skabe en personlig videnbase. Brug Evernote, OneNote eller en notesbog, som i de gamle dage. Det kan se ud som overdreven, men du vil takke dig selv et år senere, når du gennemgår den obskure opbygningsproces, der tog dig tre 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æsener, og at skabe diagrammer over processer og arkitekturer vil hjælpe dig og andre med at forstå komplekse emner. Diagrammer er især nyttige, når du kommunikerer med ikke-tekniske kolleger. Brug Lucidchart, Visio eller en almindelig tavle.

Ved hvornår man skal bruge biblioteker

Kort svar: Næsten hele tiden.

Langt svar: 99% af tiden, du skal ikke opfinde hjulet igen. I de fleste Software Engineering-stillinger er implementering af en bestemt slags slags et komplet spild af tid. Det betyder ikke, at du ikke skal vide, hvordan de algoritmer og datastrukturer, du bruger, fungerer, da det vil hjælpe 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 ekstremt nyttige og er større end hvad du kunne forvente. Derudover kan kodebasen også bruge yderligere, specialiserede biblioteker. Læs deres dokumentation og vide, hvornår du skal bruge dem.

Du skal 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 industriel brug. Et godt bibliotek er:

  • Open source, så du kan kontrollere kvaliteten af ​​koden selv og potentielt rette bugs, der er kritiske for din applikation.
  • Licenseret under en tilladt licens som MIT og BSD, så din virksomhed har ikke problemer med at bruge den. Vær forsigtig med GPL, så du ikke åbner kildekoden for hele kodebasen ved et uheld.
  • Ældre, dvs. den har været ude i nogen tid og har et rigt sæt funktioner.
  • Vedligeholdes, 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å kontinuerligt 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 ganske 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 kandidatgrader: En nylig tendens blandt de mest rangerede universiteter, online kandidatgrader er en fleksibel måde at fortsætte din formelle uddannelse. De er også generelt billigere tak på campus grader, med 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 anbefaler personligt Georgia Tech's Online Master, som jeg uddannede mig fra i år.
  • Blogs: Blogs er en vigtig del af udviklerfællesskabet (ingen overraskelse her, da du læser en lige nu). Blogs såsom Coding Horror, Joel on Software eller endda mere humoristiske websteder som The Daily WTF kan give dig en god idé om, hvad og hvad man ikke skal gøre som Software Engineer. Gennemsøgning af medium, r / programmering, HackerNews eller andre feeds fører dig også til gode artikler og blogs.
  • Konferencer: sidst, men ikke mindst, konferencer er en fantastisk læringsmulighed, og du bør bestemt drage fordel af din virksomheds træningsbudget ved at gå til dem. En meget ufuldstændig liste over gode konferencer til at tjekke ud (sammen med deres emne): GOTO; (Generelt), Strange Loop (Generelt), PyCon (Python), CPPCon (C ++), DEF CON (sikkerhed), Flydende (Web-dev). Alle disse har også videoer af (mest) foredrag på YouTube, så du kan lære noget, selvom du ikke kan deltage!

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