Sådan forbereder du dig til et teknisk interview - tip og tricks, der hjælper dig med at yde dit bedste

Ah, det kodende interview.

"Frygt det. Kør fra det. Skæbnen ankommer alle de samme." - Thanos 2018

Ok, måske er det lidt dramatisk, men jeg kender ingen, der er begejstrede for at gennemgå interviewprocessen. Jobsøgning / interviewprocessen er i bedste fald udmattende og i værste fald mange andre ting.

Mange mennesker studerer tricks og taktikker til et interview (og jeg vil også give dig et par af dem), men de fleste mennesker tænker ikke på, at deres tankegang går ind i interviewet.

Din tankegang sætter tonen for, hvordan du skal se og forme din situation. Gå ind med den rigtige tankegang, så vil du være i stand til at forstå og navigere i alt, hvad der kastes mod dig. Gå ind med et spredt eller frygtsomt sind, så finder du dig selv rystet og voldsom.

Du er også intervieweren

En ting, som de fleste ofte glemmer, er at du også er intervieweren.

Ja, bliver du interviewet i dette firma, men du interviewer også virksomheden for at se, om de passer godt til dig.

Hvad er denne virksomheds værdier? Hvordan er deres arbejdsmoral? Hvad værdsætter folket?

Det er vigtigt at bestå interviewet, men vil du arbejde hos dette firma, hvis du består?

Nogle gange har vi bare brug for et job - ethvert job - og så vil jeg ikke minimere bare at få jobbet. Men hvis du kan, skal du tage et skridt tilbage og tænke, hvordan dette job vil påvirke din karriere på lang sigt. At sige ja til et job er at sige nej til et dusin andre - du betaler en stor mulighedomkostning ved at sige ja.

Så det er den første ting at huske: dette er ikke en envejs strømdynamik. Det kan måske føles som det til tider, men du har en vis kontrol her, og du har muligheder. Dette er bemyndigende.

Typer af interviews

OK, så er vi også vurdere virksomheden er baseret på de mennesker, vi interagerer med i interviewet processen, så hvad gør vi med disse oplysninger?

Der er et par forskellige typer tekniske interviews. Disse interviewtyper fortæller os meget om virksomhedens tankegang og hvordan det er at arbejde der. Jeg nedbryder de forskellige typer sådan:

  • Whiteboarding
  • Kodeudfordring (edb-spørgsmål eller algoritmer)
  • Kodeudfordring (rimeligt kodningsproblem)
  • Tag projekt hjem

Den frygtede tavle

Nogle af de første interviewøvelser, som teknologibranchen vedtog, var tavleøvelser. Du fik en opgave og bedt om at skrive koden på tavlen. Generelt ses denne tilgang ned på og fjernes i den tekniske industri i dag, men der er stadig mange virksomheder, der anvender denne praksis.

Det er ikke, at kodning på en tavle i sig selv er dårlig - men at en tavle er så langt væk fra det arbejde, vi faktisk udfører som programmører, der arbejder på computere hver dag. Whiteboardet er klodset at skrive på, redigere på, og det giver dig ingen feedback - der er ingen autofuldførelse, ingen syntaksfremhævning, og du kan ikke springe over til Google for at slå standardbibliotekets referencer op.

Derudover stiller mange steder, der ansætter whiteboard-interviews, også et bestemt sæt interviewspørgsmål, der ærligt talt er værdiløse for 99% af programmeringsjob derude. Disse er de frygtede datalogiske algoritmer: vende et binært træ, finde den korteste sti i en graf osv.

Problemet med disse spørgsmål er, at de bare ikke kommer op i det virkelige liv som programmør. Hvis du interviewer hos Amazon eller Facebook, er de sikker på, at de måske har en vis værdi der, men de fleste mennesker står aldrig over for dette problem i deres karriere. Og hvis de gør det, bruger de bare en pakke eller et bibliotek, der allerede har implementeret denne funktionalitet.

Så hvad kan vi gøre ved tavler? Nå, her er hvad jeg ville gøre: gør dit bedste, brug de tip og tricks, der er beskrevet nedenfor, og vurder seriøst, om denne interviewpraksis er et symptom på et større mentalitetsproblem i virksomheden.

Kodeudfordringer

Hvis du er heldig nok til at undvige tavlen, vil (og sandsynligvis burde) de fleste steder bede dig om at gøre en slags kodeudfordring. Igen kan dette virke som en envejs strømdynamik, men denne kodeudfordring er faktisk god for dig. Det er her, du kommer til at skinne og vise din tekniske kompetence, og efter min erfaring påvirker dette din forhandlingsstyrke drastisk, når det kommer til jobrangering og løn.

Før vi går ind i de specifikke tip, skal vi også være opmærksomme på, at bare fordi du har undgået tavlen, betyder det ikke, at du stadig ikke får spørgsmålet om datalogisk algoritme her - bare på en computer. Hvis det er tilfældet, skal du bare trække vejret dybt og bruge tip og tricks nedenfor. Du kommer igennem det.

I er du heldig nok til at undvige tavlen og CS-spørgsmålet, er du sandsynligvis blevet præsenteret for en rimelig kodningsudfordring. For mig er dette spørgsmål som:

Skriv en funktion, der optager et antal cent (USD) som et heltal mindre end eller lig med 100, og udskriver det mindste antal mønter, der er nødvendige for at repræsentere det.

50 => 2 kvartaler

11 => 1 krone og 1 krone

7 => 1 nikkel og 2 øre

Jeg har også modtaget spørgsmål, der ser ud som CS-spørgsmål, men som virkelig ikke er så dårlige. For eksempel "implementer en dobbeltkoblet liste." Ved første øjekast virker det som et CS-problem på grund af den "dobbeltkoblede liste" -del, men hvad intervieweren faktisk ønskede var kode, der implementerede den samme adfærd som en dobbeltkoblet liste - jeg brugte ikke pegepinde og adressering objekter i hukommelsen - bare efterligne den samme adfærd. I så fald blev det en ret simpel udfordring.

Og det bringer mig til mit første tip:

Tip nr. 1: Stil afklarende spørgsmål

I den dobbeltkoblede listeudfordring fik jeg en tom Ruby-fil (jeg interviewede for et Ruby-job) og en tom testpakke. Noget som dette:

class DoublyLinkedList end 

(Hvis du ikke er fortrolig med Ruby - skal du ikke bekymre dig. Koden her vil være enkel at forstå. Det er bare her for at illustrere de overordnede punkter.)

Så en dobbeltkoblet liste, ikke? Måske ved du hvad det er, eller måske gør du det ikke. Hvis du ikke gør det: Stil spørgsmål. Dette er den første faldgrube, der skal undgås. Hvis du ikke forstår problemet, eller hvad de beder om, skal du fortsætte med at stille spørgsmål, indtil du gør det.

Jeg har set interviewpersoner gå den forkerte kaninspor, og intervieweren lod dem bare - alt imens de i stilhed svigtede dem. Selvom jeg ikke er enig i denne praksis, skal du sørge for at arbejde med det rigtige problem.

Jeg kommer fra en datalogisk baggrund, så jeg vidste, at en dobbeltkædet liste betyder en liste, der har en markør til a headog en tailnode - hvor hver node også peger på sin nextog previousnode.

Nu selvom jeg vidste det, hvad gjorde jeg? Jeg sagde det højt og spurgte, om det var korrekt. Selvom jeg troede, jeg vidste, hvad jeg skulle gøre, sørgede jeg for, at jeg gjorde det.

Når du først tror, ​​du forstår problemet, skal du gentage din forståelse af intervieweren, så de kan rette eller guide dig.

Den næste ting jeg gjorde var at stille et andet spørgsmål: "Kan jeg bruge en matrix til noderne?" Og jeg skrev noget ud som dette:

class DoublyLinkedList def initialize @nodes = [] end end 

(Hvis du ikke er fortrolig med Ruby, er dette bare en initialisering eller konstruktør, hvor jeg laver en ny variabel kaldet @nodesindstillet til et tomt array.)

Men fortalte intervieweren mig, nej, det kunne jeg ikke - hvilket giver mening. Hvis jeg havde brugt en matrix, ville det have besejret hele formålet med øvelsen, der bygger de falske "pegepinde" mellem noderne.

Og dreng, er jeg glad for, at jeg spurgte. Jeg ville ikke tage chancen for, at intervieweren lod mig bruge arrayet og derefter svigtede mig.

Så ingen matrix - ja, hvad gør jeg nu? Her er tip nr. 2:

Tip nr. 2: Hardkodet -> Dumt -> Bedre

Når du står over for en kodningsudfordring, skal du løse problemet i følgende rækkefølge: hårdkodet -> dumt -> bedre -> endnu bedre (hvis tiden tillader det).

Efter min erfaring med at blive interviewet og interviewe andre udviklere finder jeg, at de fleste mennesker prøver at gøre for meget på én gang.

Når du gør for meget på én gang, er det let at lave fejl (som du ikke fanger på grund af at have InterviewBrain ™). Så start simpelt - det enkleste du faktisk kan - hardkodet - og arbejd dig op.

Så jeg har en tom Ruby-klasse, hvordan kan jeg kode noget for at komme videre? Jeg kiggede på min tomme testpakke og så, at der var en funktion kaldet, headder returnerede den første node på listen, så lad os prøve det:

class DoublyLinkedList def head 'A' end end 

Jeg lavede en headfunktion og hårdkodede store bogstaver "A" som en streng, og jeg kørte den test. Det gik forbi.

Er dette super simpelt? Er det for indlysende? Ja! Men denne kode gør to meget vigtige ting:

  • Det giver mig mulighed for at køre testene og teste, om min opsætning fungerer (eliminering af dumme eller syntaksfejl)
  • Det giver mig en hurtig sejr - hvilket øger min selvtillid

Der er utallige interviews, jeg har set, hvor nogen laver en lille fejl lige i begyndelsen, bliver forvirret og bruger derefter størstedelen af ​​interviewet på at gendanne og rette det, der er galt.

Undervurder ikke værdien af ​​hurtige gevinster for din selvtillid. Hvis du opsamler små gevinster, får du dig gennem interviewet.

Ok, vi har en strengkodet streng 'A'. Hvordan gør vi det nu til en stum løsning? Nå, hvad med at gøre det bogstav "A" til et hash (eller kort)?

class DoublyLinkedList def head { value: 'A' } end end 

Det er lidt bedre. Nu i stedet for en strengstreng med en karakter er vores "node" repræsenteret som hash med en valueegenskab. Vi er gået fra hårdkodet til dum. Hvordan kan vi nu gøre det bedre? Nå, hvad med at introducere vores headmarkør på listen?

class DoublyLinkedList def initialize @head = { value: 'A' } end def head @head end end 

Hvad ændrede vi her? Her tilføjer vi vores initializer tilbage og opretter en ny variabel kaldet @head, og vi bruger den nye variabel i vores headfunktion. Dette begynder at ligne en rigtig kode.

Nu kan denne tilgang virke rigtig fjollet, men jeg lover dig, den fungerer. Hver af disse ændringer foretages i sekunder med lille, iterativ kodning, og de stabler op for at producere en fungerende implementering på kort tid.

Hvis du tænker, at denne tilgang vil virke underlig for en potentiel interviewer, her er det næste tip, og denne er meget vigtig:

Tip nr. 3: Tal. Højt.

Hele tiden du laver en kodningsudfordring, skal du tale højt.

Sig alt, hvad du tænker - alt.

(Nå, alt programmeringsrelateret.)

Her er ting: at komme til en korrekt løsning er vigtige ja, men lige så hvis ikke vigtigere er viser din tankegang. Intervieweren vil vide, hvordan du tænker - hvordan du løser problemer. Du kan gøre dette ved at dele alt, hvad du tænker højt.

Hver interviewer har på et eller andet tidspunkt været interviewperson - de kender til InterviewBrain ™, og at selv enkle ting kan blive vanskelige i et interview. Gode ​​interviewere er ligeglade med, at du får løsningen 100% rigtig - de vil bare vide, at du har gode kritiske tænkningsevner. Den eneste måde at synliggøre disse interne tanker på er at sige dem højt.

Hvis du aldrig har gjort dette før, vil du måske øve det, fordi det er vigtigt for at sømme interviewet.

For at give dig nogle praktiske eksempler er her nogle ting, jeg siger hver eneste gang jeg interviewes:

"Ok, lad os bare kode denne værdi og sørge for, at vores opsætning fungerer." "Lad os få en dum version af dette, der fungerer først, og gøre det bedre." "Jeg gør det sådan her for nu, og hvis vi har tid, kommer tilbage og gør. "" Ok, så vi har brug for en funktion, der tager et array op, gør X og vender tilbage. "

I nogle scenarier kan disse interviews begynde at føles som par-programmeringssessioner.

Ok, så vi siger ting højt. Men nogle gange laver vi en fejl, eller vi sidder fast. Vi har talt vores tankeproces højt, men nu skal vi muligvis skifte og undersøge et potentielt problem eller en fejl.

Her er et vigtigt tip til dette:

Tip nr. 4: Bliv i et logisk flow

Nu indrømmer jeg: denne kan til tider være hård.

Hvis du er i et interview, og der er et problem eller en fejl med din kode, vil din hjerne desperat finde ud af, hvad der er galt - men vær ikke så desperat, at du begynder at smide din kode eller din tankeproces.

Ser du, ligesom intervieweren vil se, hvordan du nedbryder et problem, vil de også se, hvordan du debugger et problem. Dette er lige så vigtigt som at forklare din tankeproces. Prøv dit bedste for at være i en logisk strøm og undgå at smide koden eller dine ideer.

Hvis det går godt

Så udfordringen går godt, og du slår problemet ud og alle de lette ting.

Hvad nu? Hvordan går du fra videregivet til knust det?

Dette er en yderst vigtig del af interviewet, fordi det er her, du får størstedelen af ​​din gearing til jobniveau og kompensationsforhandling. Og tipet er:

Tip nr. 5: Vis hvad du ved

Du arbejder udfordringen, du taler højt, og du klarer dig godt. Den næste ting, du skal kigge efter, er muligheder for at vise din viden og ekspertise.

Er dette stedet i koden, hvor du muligvis sender en e-mail? Nævn, at det skal gøres i en baggrundsarbejder i stedet (du behøver sandsynligvis ikke engang at implementere det).

Arbejder du med valideringslogik i en model? Tal om, hvordan du også vil tilføje databasebegrænsninger for at sikre dataintegritet. Hvilke indekser vil du tilføje? Hvordan ville du udrulle migreringerne for at forhindre nedetid?

Når du først har fået din hardkodede -> dumme -> bedre løsning, skal du tale om, hvordan du ville omlægge det, hvis det fik mere tid. Vil du oprette et modul til dette? Hvad med et serviceobjekt? Hvad med at lægge noget af denne logik i et baggrundsjob? Diskuter kompromiserne.

Nu hvorfor er dette så vigtigt?

De fleste interviewspørgsmål er rettet mod den laveste fællesnævner - hvilket betyder de helt grundlæggende krav til jobbet. Selve udfordringen eller spørgsmålene er normalt ikke designet til at teste den øverste ende af nogens dygtighed . Interviewet vil sandsynligvis ikke trække oplysningerne ud af dig, så du er nødt til at give disse oplysninger.

Så mens du taler igennem din tankeproces, skal du nævne alle de ting, du ville indarbejde i en applikation eller codebase fra det virkelige liv, og diskutere dem.

Ekstra tip og tricks grab taske

Så det er sådan, du skal nærme dig dit interview og tackle den udfordring, du får.

Her er et par ekstra tricks, der nogle gange kan bruges til mindre fordele.

Trick nr. 1: Kend de almindelige problemer

Der er et par almindelige problemer, der ofte vises i interviews (især på whiteboards). Du burde være fortrolig med disse problemer, fordi de er ligesom spørgsmål, du ved, vil være på testen.

To af de vigtigste er FizzBuzz og løsning af Fibonacci-sekvensen (sørg for at kende disse).

Nu en advarsel: du ønsker ikke nogensinde at lægge en husket løsning i et interview. Det kan kun gå dårligt (og jeg har set det ske). Du ønsker dog at være fortrolig med løsningen - og være i stand til at genskabe den fra bunden.

Så brug dine interviewspørgsmålsforberedende bøger, ja, men sørg for, at du forstår løsningen, kan forklare den og kan genskabe den fra bunden. Et husket svar vil ikke føre dig overalt her.

Trick nr. 2: Det er normalt ok at se på dokumenterne

I alle de interviews, jeg har været i eller en del af, har ingen været ligeglad med, om du kigger på standardbiblioteket eller pakkedokumenterne. Interviewere er ikke i orden med, at du kigger efter svaret (så jeg ville undgå StackOverflow), men at konsultere referencerne er normalt fair spil. Hvis du er i tvivl, se tip nr. 1 og bede om afklaring.

Trick nr. 3: Se efter visuelle signaler

Dette er sandsynligvis mit yndlings tip / trick. Det er ikke det mest nyttige, men det er lidt sjovt. En af mine interviews gjorde jeg eksternt, og vi brugte et skærmdelingsprogram, og jeg kunne se interviewerens ansigt øverst til højre på min skærm.

Jeg bemærkede ud af hjørnet af mit øje, da jeg kodede, at intervieweren nikkede på hovedet. Ah ha! Lidt visuelt signal om at vide, at jeg var på rette vej.

Igen er det ikke meget, men det kan være nyttigt. :)

Trick nr. 4: Hvis du er fjernbetjent, skal du have en god opsætning

Taler om at være fjern, hvis du er fjern, så prøv at have den bedste opsætning, du kan. Dette betyder kamera tændt (hvis muligt opsætning, hvor du kigger lige ind i det), godt internet, computer tilsluttet strøm, et stille rum, et glas vand i nærheden osv.

Disse ting bør ikke påvirke dit interviewresultat, men der er ingen grund til at irritere intervieweren eller give dig selv ekstra stress fra internet- eller støjproblemer.

Trick nr. 5: Vær personuel!

Mit sidste trick for dig er at være nacn.

I dit interview skal du være en, som du gerne vil arbejde med. Vis dem dit bedste selv.

Interviews kan være skræmmende, og udviklere er generelt mere støjsvage og mere reserverede mennesker, men du skal vise de mennesker, du interagerer med, "Hej, jeg er en sjov og dejlig person at arbejde med."

Jeg beder dig ikke om at være en, du ikke er. Men du vil ikke være, ifølge en af ​​mine nære venner, der hele tiden interviewer folk, en "havdyr".

Bonustrik nr. 6: Gør alle de andre interviewforberedelser (hvis du vil)

Hvis du føler dig underforberedt, eller dette er dit første tekniske interview, skal du lave noget forberedelsesarbejde, indtil du har det godt.

Læs bøger som Cracking the Coding Interview eller øv algoritmer og gåder på HackerRank.

Læs de andre fantastiske indlæg på Developer News om interviews.

Hvis du interviewer for en fuld stack-rolle, skal du være klar til at konfigurere et nyt projekt eller en testfil med testpakken fra bunden.

Undersøg virksomheden, vær klar med gode spørgsmål om virksomheden eller det daglige arbejde osv. Osv.

I sidste ende: det er bare et interview.

I sidste ende er det, hvad det er.

Du udfører, hvordan du presterer.

Du bliver interviewet af den person, du vil blive interviewet af.

Deres interviewproces vil være deres interviewproces.

Måske havde du en fridag - måske havde intervieweren en fridag.

Bagefter, hvis du føler dig flov, besejret eller noget andet - træk vejret dybt og lad det gå! Lad ikke din Lizard Brain veje dig ned. Et dårligt interview er ikke verdens ende. Din karriere er ikke ødelagt, dit omdømme er ikke ødelagt, og dit liv er ikke ødelagt.

Det er bare et interview. Lær af det, tilpas dig og bliv bedre næste gang.

Det er ok at være nervøs

De fleste mennesker (inklusive mig selv) bliver nervøse før ting som interviews, foredrag eller præsentationer.

Jeg tænkte på nervøsitet som en dårlig ting - en ting, jeg ikke ønskede. Og uanset hvor mange gange jeg sagde til mig selv "vær ikke nervøs" - gæt hvad: det gjorde mig bare mere nervøs!

Jeg har lært at genoverveje, hvordan jeg ser nerver. Nervøsitet er min krop, der forbereder sig på en kamp - den oprindelige kamp eller flyrespons.

Men som vi sagde før: dette er bare et interview. Der er ingen tiger, der sniger sig ind i mig i interviewrummet. Dette primære svar er ikke nødvendigt.

Jeg er begyndt at omskole mig for at se nervøsitet som en god ting. Det betyder, at min krop og sans øges, så jeg kan levere den bedste præstation, jeg kan mønstre.

Så omfavn nerverne. De forbereder dig bare til at yde dit bedste.

Interview er en færdighed

I sidste ende er interview en færdighed. Det tager lidt at studere og en masse øvelse at mestre.

Så slå ikke dig selv, hvis du ikke udfører, som du havde håbet. Bliv ved med at lære, og fortsæt med at øve - du kommer derhen!

Hvis du har spørgsmål eller kommentarer, er du velkommen til at kontakte mig på Twitter, og hvis du ønsker mere information om, hvordan du forbereder dig på en udviklingskarriere, skriver jeg ting som dette på min blog.

Tak for læsningen!

John