Jeg har lige fået et udviklerjob hos Facebook. Sådan forberedte jeg mig til mine interviews.

Jeg er lige færdig med syv interviews på stedet hos Silicon Valley tech-virksomheder. Jeg accepterede i sidste ende et tilbud om et softwareingeniørjob fra Facebook.

Sådan forberedte jeg mig på disse interviews, og hvad jeg lærte undervejs.

Min flerårige rejse mod Silicon Valley

Da jeg studerede datalogi på mit universitet i Australien, forestillede jeg mig altid min fremtid som softwareingeniør i Silicon Valley.

Jeg elskede ideen om at være i hjertet af al teknologiindustriens innovation - såvel som dens fejl. Dette mål holdt mig motiveret. Det holdt mig fokuseret.

Jeg forlod min stilling som Lead iOS Engineer hos et fantastisk firma i Melbourne og vendte tilbage til min hjemby Perth for at studere. Der ville jeg forberede mig på interviewprocessen foran mig i Silicon Valley. Jeg vidste, at det ville være utroligt vanskeligt og besværligt.

Hvis du nævner den tekniske interviewproces i et rum med softwareingeniører, vil mange tale imod almindelig interviewpraksis. Meget af argumentet kommer fra ræsonnementet om, at løsning af algoritmer på en tavle ikke faktisk repræsenterer eller oversætter til de daglige opgaver for en softwareingeniør.

Af hensyn til denne artikel går jeg ikke ind i den samtale. I stedet vil jeg udforske disse forskellige typer interviewpraksis fra en kandidats perspektiv, og jeg vil også fokusere på det, jeg lærte af processen.

Interview er en færdighed

Under min forberedelse vidste jeg altid, at interview ville være udfordrende. Men jeg havde ærligt talt ingen anelse om, hvor svært det ville være, før jeg var knæ dybt ind i mit første interview.

I forløbet af interviews havde jeg brugt både betalte og gratis tjenester, som simulerede kodning og whiteboarding-interviews over telefon med folk, der havde erfaring i at interviewe kandidater. Disse øvelsessamtaler var afgørende for at give mig et pres for det involverede pres. Men som jeg senere indså, udgjorde de kun en brøkdel af, hvad et rigtigt interview består af.

Jeg vil fraråde at interviewe på dit drømmejob uden at have et par mock eller rigtige interviews under dit bælte. Nervøsiteten kan være utrolig overvældende, og den kan kun sløves gennem praksis.

Som med mange andre ting i livet, vil praksis forbedre din selvtillid.

De forskellige typer interviews jeg stødte på

Hvis du forbereder dig og klarer dig godt nok i de indledende telefonskærme, får du muligheden for at komme på stedet og gennemføre interviews med hele dage. Disse interviews varer typisk fire til seks timer afhængigt af det firma, du interviewer med.

Under min tur til Silicon Valley lykkedes det mig at stille op til syv interviews på stedet i alt. Dette gav mig et unikt perspektiv af det aktuelle landskab til interview.

Typisk vil en on-site dække tre hovedemner: algoritme, arkitekturdesign og adfærd, hvilket er det, jeg havde studeret og forberedt mig på. Der er dog nogle virksomheder, der ser ud til at bukke denne tendens og udvide deres interviews til at dække mere praktiske færdigheder.

Jeg vil kort gennemgå hvert af de emner, jeg stødte på.

Algoritme Interviews

Den mest almindelige type interview, du vil støde på. Intervieweren vil bede dig om at løse et problem på en tavle, som vurderer din viden om datastrukturer, sorteringsalgoritmer, rekursion, tid / rum-kompleksitetsanalyse samt mønster- og edge-case-genkendelse. I dette interview vil du typisk komme med en brute-force-løsning og derefter prøve at forbedre den løsning og diskutere kompromiser, hvis der er nogen, med de forskellige løsninger, du foreslår.

Dette var brød og smør i min forberedelse, hver dag i seks uger, jeg løste algoritmer på et billigt ophængt tavle, analyserede deres tid / rum kompleksitet samt virkelig forsøgte at forstå, hvad der sker på hver linje kode.

Personligt nyder jeg virkelig whiteboard-algoritmer, fordi jeg ikke nødvendigvis behøver at bekymre mig om at skrive kompilerbar syntaks (det meste af tiden), hvilket lader mig kun fokusere på det aktuelle problem. Andre mennesker kan ikke lide whiteboarding, men til dem vil jeg sige at øve det konsekvent, og det kan ændre deres mening.

Interviews om arkitekturdesign

Dette er et interessant interview og en, som jeg meget undervurderede. Intervieweren vil bede dig om at designe et system (naturligvis på en tavle) såsom et billetsystem til parkeringspladser, chat-messenger, twitter-feed, blandt andre almindelige systemer.

Hvad du bliver vurderet på er, hvordan du tager et bredt koncept og designer et system, der opfylder alle krav og begrænsninger. Men det er op til kandidaten at stille de rigtige spørgsmål, der definerer kravene og begrænsningerne. Dette interview er mere en samtale blandet med nogle tegningsdiagrammer og måske endda klassestrukturering. Alt er ret højt niveau, så du skriver ikke nogen egentlig implementeringskode.

Naturligvis skal du styre samtalen for at dække din viden om, hvordan systemer fungerer. Hvis du er en backendingeniør, ville du ikke rigtig gå ind i mekanikken i klientapplikationsoplysningerne, medmindre du havde noget tidligere ekspertise på dette område. Jeg er en iOS-ingeniør, så jeg talte om arkitekturmønstre, modulering af funktionalitet, designmønstre i stedet for, hvordan man skalerer API-slutpunkterne, tilføjer arbejdere, AWS og sådan.

Adfærdsmæssige interviews

Intervieweren vil stille dig spørgsmål om dig selv og hvordan du håndterer visse typer situationer. Forberedelsen til denne er ikke så vanskelig som de andre, men kræver en masse introspektion på dine egne vegne.

Spørgsmålene er typisk i retning af:

Hvordan håndterer du fiasko?

Hvad er din største svaghed?

Hvordan løser du konflikter?

Hvad ville du gøre anderledes?

Jeg føler, at det ville være ret svært at skrue denne op, men jeg har hørt mange mennesker gøre det. De forsøger at skjule deres styrker som svagheder, konstruere deres svar på noget, som de tror, ​​at intervieweren gerne vil høre eller endda bare give skylden for mislykkede projekter videre til andre mennesker.

“Min svaghed er, at jeg er for fokuseret”

”Det hele var Jerrys skyld, han var syg det meste af projektet”

Disse interviewere er uddannet og kalibreret til at identificere skøre mennesker og have akut opmærksomhed på lort. Det er en hurtig måde at få dit kandidatur kastet ud af vinduet. Bare vær ægte, vis lidenskab for dit arbejde, ej dine fejl, vis initiativ til forbedring, og du klarer dig fint.

Kultur Fit

Dette er normalt parret med adfærdssamtalen og er fokuseret på at finde ud af, om du er tilpasset virksomhedens værdier. For eksempel følger Facebook den hackerlignende kultur med at være dristig og sende nye ideer, prøve ved eksperimenter, ikke være bange for at bryde ting. Mens Airbnb ønsker at skabe en verden, hvor folk føler, at de hører hjemme hvor som helst de går, så de leder efter folk med store gæstfrihedsfærdigheder.

Mange af de store teknologivirksomheder lægger stor vægt på kulturen og ansætter folk baseret på den persons tilpasning til deres værdier. Hvis du interviewer hos en af ​​disse virksomheder, er det vigtigt, at du ser på deres værdier og finder tidligere erfaringer, som du er i stand til at relatere og kommunikere til din interviewer.

Par programmering

En interessant kategori, som du vil blive parret med en anden ingeniør foran en computer, der er oprettet med et udviklingsmiljø, ligesom hvad du vil bruge i den virkelige verden. Du får en grundlæggende opgave med en liste over krav, som du skal udføre, når du er færdig med hver opgave, beder intervieweren dig om at implementere mere funktionalitet, indtil fristen er nået. Du er fri til at bruge de ressourcer, du ønsker, såsom Stack Overflow eller online dokumentation.

Jeg har lyst til, at meget af en kandidats succes i dette interview vil blive bestemt af eksponering for virkelige oplevelser. I modsætning til whiteboarding er det nødvendigt at skrive syntaktisk korrekt kode, så du skal kende dit sprog og miljø indefra og ude, fordi du ikke vil bruge for meget tid på internettet eller dokumentation på at søge efter svar.

Under min tidligere rolle ville jeg skrive ren kode, mens jeg arbejdede på en opgave, efterfulgt af optimering, når jeg først følte, at opgaven var færdig. Denne form for workflow var ikke gavnlig for denne type interviews. Det lykkedes mig at rense-koden selv ind i et hjørne ved at optimere for tidligt, hvilket gjorde det vanskeligere at komme sig fra. Jeg fandt ud af, at det at skrive skrotkode og nævne til intervieweren, at jeg ville gøre det anderledes i produktionen, blev anset for tilstrækkeligt end at skrive rent og optimeret.

Find og patch patch

Meget af det, vi gør som ingeniører, handler om at finde og lappe bugs, der rapporteres til os fra forskellige kilder. I dette interview får du en liste over fejl at finde og patch samt identificere anden potentielt problematisk kode undervejs.

Jeg så kun en forekomst af denne type samtaler, og jeg føler, at det ville være ret svært for nogen at virkelig forberede sig på, især hvis de er junior. Hvert kodemiljø har sine egne små finurligheder og nuancer, meget af det patchwork, jeg gjorde, kom fra tidligere erfaringer med IDE (Integreret udviklingsmiljø) og de relaterede rammer, som jeg havde samlet gennem årene.

Test af domæne viden

Programmering er grundlæggende den samme på de fleste af de almindelige sprog, vi ser i dag. Chancerne er, at hvis du kender objektorienteret programmering på et sprog, overføres disse færdigheder for det meste til et andet.

Imidlertid fokuserer dette interview på de aspekter, der ikke kan overføres mellem sprog eller rammer. Du vil blive interviewet om miljøspecificiteter relateret til API, hukommelsesadministration, kapaciteter, begrænsninger, historie osv.

Øvelse kan være udfordrende for netop dette emne. I lighed med interviewet med fejlfinding og patch, føler jeg, at mange af svarene stammer fra tidligere erfaringer. Afhængigt af niveauet for den rolle, du ansøger om, kan de svar, du giver, vægtes forskelligt. For eksempel, hvis nogen, der ansøger om en juniorrolle, ikke kender historien om, hvorfor en API er struktureret på en bestemt måde, kan de få en koncession. Men hvis en kandidat, der ansøger om en seniorrolle, ikke ved det, kan de blive markeret mere hårdt.

Forståelse af operativsystemer

Afhængigt af den rolle eller det team, du interviewer til, har du muligvis et interview, der udelukkende fokuserer på operativsystemer. I dette interview vil du blive stillet spørgsmål, som vurderer din forståelse af mekanikerne på et lavere niveau i en computers operativsystem.

Ganske vist fangede dette interview mig off-guard. Operativsystemer var noget, jeg havde lært i de tidlige år på universitetet, men min viden er siden blevet uklar om emnet, hvilket blev afspejlet i min præstation.

Hvordan du skal forberede dig

Som jeg skrev tidligere, er interview en egen færdighed. Selvom du allerede er en god programmør i dit daglige job eller får gode karakterer i dine studier, overføres disse færdigheder ikke nøjagtigt 1: 1, når du er i et lille interviewrum. Persistens, gentagelse og konsistens med interviewforberedelse og praksis vil være de vigtigste afgørende faktorer for dit resultat.

Minimum viden

Hvis nogen skulle spørge mig, hvad jeg følte ville være områder at fokusere på, ville jeg foreslå følgende:

  • Lær at skrive kode manuelt på papir og en tavle først og derefter smide den i en IDE til syntaksfremhævning, dette skal blive anden natur for dig.
  • Udvikle dyb viden om datastrukturer , deres styrker og svagheder i forhold til hinanden. Jeg opdagede, at implementering af datastrukturer og deres adfærd fra bunden lærte mig så meget mere end hvad jeg kendte fra deres abstrakte begreber.
  • Forstå fuldt ud Big O-notationen for både tid og rum kompleksitet, dette vil parre perfekt med din algoritme og sorteringsspørgsmål.
  • Tag fat i alle vigtige sorteringsalgoritmer, fordi forskellen i tid / rum-kompleksitet har potentialet til at afspore din optimale løsning til en algoritme, du prøver at løse.

Hvornår skal jeg starte?

Afhængigt af din tidslinje, kan du starte hurtigere end senere. Mange af de virksomheder, jeg interviewede med, havde en afkølingsperiode på 12 måneder, før en mislykket kandidat kunne genansøge. På bagsiden, hvis du ved, at du ikke vil være klar inden for et år, kan du lige så godt starte processen nu og få en lille smag af, hvordan det er at gennemgå interviewprocessen, så når du er klar, vandt den ' t være næsten lige så skræmmende.

Bare rolig

Du har det her.

Ressourcer

Mock Interviews

  • interviewing.io (beta), gratis
  • Pramp, gratis
  • CareerCup, betalt

Algoritmer

  • Cracking the Code Interview, bog
  • byte for byte, websted og YouTube
  • CS50, YouTube
  • Interviewkage, websted
  • HackerRank, websted
  • LeetCode, websted

Operativsystemer

  • Operativsystemkoncepter, bog

Arkitekturdesign

  • Introduktion til arkitektur og systemer, YouTube

Adfærdsmæssig

  • Introduktion til adfærdssamtaler, YouTube

Hvis du kan lide det, du har læst i dag, kan du tjekke vores mine andre artikler om iOS og Swift-udvikling, eller hvis du vil kontakte, så send mig en tweet eller følg mig på Twitter @andyyhope , det gør virkelig min dag.

Andyy Hope (@AndyyHope) | Twitter

iOS-ingeniør. Blogger / højttaler for Swift & iOS twitter.com