Hvordan man skiller sig ud under det tekniske interview

Laurence blev for nylig bedt om at lære at kode med mig om at give nogle råd om en artikel, de sammensætter om, hvordan man hjælper kandidater med at skille sig ud under den tekniske samtale. Mange af mine svar kom ind i den sidste artikel, men jeg troede, at jeg ville dele mine fulde svar her, i tilfælde af at de er nyttige for nogen anden.

Spørgsmål 1: Hvad er de specifikke måder, som en kandidat ikke bare kan få succes, men * skiller sig ud * under det tekniske interview?

A1: Kom til interviewet med et projekt for at tale om, men sørg for, at det er på det rigtige kompleksitetsniveau.

En masse mennesker vil råde jobjægere til at bygge et projekt og vise det under interviewet. Dette er en fantastisk taktik, fordi det giver kandidaten mulighed for at vende samtalen fra at blive grillet til at vise deres evne. Samtalen bevæger sig også fra en potentielt antagonistisk frem og tilbage til en mere afstemt idé om brainstorming, næsten som kolleger, der arbejder på et projekt sammen.

Hvis du imidlertid ønsker at imponere, vil den nøjagtige type projekt variere afhængigt af den jobrolle, som du ansøger om. En god generel regel ville være at opbygge projekter, der mindst matcher kompleksiteten af ​​arbejde til det job, du ansøger. Potentielle arbejdsgivere vil derefter være i stand til at se, at du ikke kun kan, men faktisk har gjort arbejde på det niveau, de har behov for.

De fleste starter den modsatte måde. De vil følge nogle tutorials eller opbygge en idé, der synes interessant, og derefter tage det, de producerede for at se, om nogen arbejdsgiver finder det imponerende. Normalt imponerer projekterne ikke gode arbejdsgivere, og kandidater er nødt til at bede potentielle arbejdsgivere om at forestille sig, hvad de kunne gøre, hvis kun med lidt vejledning eller hjælp.

I stedet for at bede arbejdsgivere om at bygge bro over kløften, skal smarte kandidater målrette mod specifikke roller. Undersøg kravene til rollen og den type projekter, som rollen forventes at arbejde på. Kortlæg derefter en måde til uafhængigt at producere projekter med tilnærmelsesvis lige så kompleks. Du skiller dig ud, hvis du bringer den type projekt til interviewet.

A2: Forstå grundlæggende forhold.

Gode ​​interviewere forsøger at undersøge kanten af ​​en kandidats evne. Dette betyder, at de fleste spørgsmål ikke vil være baseret på gotcha-viden, såsom specifik syntaks for et sjældent anvendt API. I stedet undersøger samtalen din evne til at dekonstruere komplekse begreber og se, om du kan skrælle lagene tilbage. Dette kræver ikke kun forståelse af, hvordan man bygger en funktion, men hvordan man dekonstruerer funktionen. For eksempel kan en interviewer i løbet af samtalen spørge ”Hvis du havde en side, der oplever præstationsproblemer, hvordan ville du gå ud på at finde ud af flaskehalsen?”. Dette åbne spørgsmål vurderer samtidig en kandidats viden om grundlæggende elementer og tillader samtidig kandidaten at vise deres dybde af forståelse på tværs af forskellige domæner. Svaret her kan variere fra front-end aktivkompilering, cache-teknikker til webserver, optimering af databasepræstation osv. Det er disse åbne spørgsmål, hvor interviewere kan adskille dem, der kan opbygge enkle funktioner fra dem, der kan arbejde på en dybere teknik niveau. Den eneste måde at skille sig ud på er at forstå de grundlæggende begreber, der understøtter den pågældende funktion.

A3: Tal klart og præcist.

Selvom det måske ikke ser ud som det i starten, er langt de fleste programmeringsroller i kernen sociale roller. Da programmerere arbejder med abstrakte koncepter, er det klart og præcist at tale. De fleste gode arbejdsgivere lægger en ekstrem høj vægt på at ansætte klare og præcise talere. Vær opmærksom på ordforråd, selv på tilsyneladende enkle begreber. Henvis til et koncept med dets formelle navn og undgå tvetydighed. For eksempel, i stedet for at sige "det kalder den funktion, og resultatet er 5", siger "funktionen opkaldet add_numbers returnerer 5, som er tildelt den variable sum". Undgå pronomen og tvetydige ord som "resultat" (der er normalt ikke et "resultat", men noget output, bivirkning eller returværdi). Det andet eksempel viser sprogethedens klarhed og præcision, hvilket giver læseren en entydig redegørelse for, hvad koden gør.

Spørgsmål 2: Hvordan skal en kandidat forberede sig på det tekniske interview? (Eventuelle specifikke websteder eller ressourcer, de skal bruge til at studere?)

Hvordan kandidaten skal forberede sig afhænger af typen af ​​interview. Nogle virksomheder, især dem, der er modelleret efter Google-stilen med interviews, bruger algoritmer og whiteboarding. Andre undgår imidlertid whiteboarding til parring eller kodeudfordringer. Atter andre gør det heller ikke og fokuserer i stedet mere på “fit”, så længe nogle grundlæggende tekniske evner er opfyldt.

Hvis det er et tavleorienteret interview, skal du sørge for at bruge ressourcer som Pramp og bøger som Cracking the Coding Interview. Hvis det er mere parring, skal du sørge for at vide, hvilket sprog de vil bruge og børste op på dens syntaks, så du ikke snubler rundt under parringssessionen. Hvis de følger specifik udviklingspraksis, som TDD eller Github Flow, skal du opdatere eller studere det op. Det er normalt ok og passende at spørge, hvilken type interview det vil være, og hvilke sprog der vil blive brugt.

Men generelt er der stadig et par ting, som kandidater kan gøre, uanset hvilken type virksomhed det er.

  1. Øve sig. Interview er en færdighed, og du bliver bedre til det over tid. Tag praksis alvorligt. Bed venner om at interviewe dig, optage dig selv (og se optagelsen) og øve, øve, øve. Dit 20. interview vil være dramatisk anderledes end dit 1., så prøv at komme til det 20. i en praksisindstilling, og din første "rigtige" samtale vil faktisk være din 21..
  2. Undersøg virksomheden og rollen og endda de mennesker, der interviewer dig. Bliv begejstret for virksomheden eller projektet, og den positivitet vil komme over i interviewet.

Spørgsmål 3: Hvad er nogle af de mest almindelige fejl, du ser kandidater lave? Hvordan kan man undgå disse fejl?

De mest almindelige fejl følger ikke det, jeg skrev tidligere, som at ikke forstå grundlæggende eller ikke tale klart. Men jeg vil prøve at nævne et par andre tip her, der kan være nyttige.

  1. Vær ikke arrogant eller for opmærksom. Dette sker undertiden, når folk lærer en ny proces eller teknik, som TDD, og ​​derefter bliver en evangelist for den teknik uden kontekst. For juniorudviklere eller dem med mindre års erfaring er det mere vigtigt at komme ud for at være bøjelig og ivrig efter at lære, så arbejdsgiveren kan forestille sig dig i en række projekter og roller. Selv tilsyneladende uskyldige udsagn som "Jeg skriver aldrig kode uden test" eller "Jeg elsker X og kan ikke lide Y" kan komme på tværs af alt for udtalte. Arbejdsgivere hører, at "jeg er begrænset i min evne til at arbejde på en bestemt måde, selvom vi virkelig har brug for at arbejde på den måde", hvilket sandsynligvis ikke er det budskab, kandidaten forsøger at formidle. I stedet skal en kandidat være tempereret i deres præference; for eksempel "Jeg foretrækker at skrive prøver med al min kode" eller "Jeg har haft X for nylig, men har også erfaring med Y".
  2. Vær ikke for genert. Jeg har set arbejdsgivere give undskyldninger for en kandidat, når de gik glip af et spørgsmål, og jeg har set arbejdsgivere kvikke den mindste fejl i et ellers fejlfrit interview. Hvad er forskellen? Det er den "følelse", en kandidat giver interviewerne. En samtale handler ikke kun om at besvare spørgsmål korrekt, men også om en samtale. Hvis din naturlige disposition er så indadvendt, at du kun kan samle nok ord til at besvare spørgsmålet og ikke mere, kan du øve dig på at tale. Det er vigtigt at holde strømmen af ​​samtalen gående. Grin og lav vittigheder ved passende knudepunkter. Stil gode spørgsmål. I slutningen af ​​interviewet, selvom du gik glip af et par spørgsmål, skal den samlede "følelse", som intervieweren havde af dig, være positiv. Hvis du ved, at du ikke er en god samtale, skal du sørge for at fokusere på at forbedre dette.
  3. Giv ikke op på et åbent spørgsmål. Mange kandidater synes så overvældede af åbne spørgsmål, at de opgav før de selv startede. En god samtale vil have nået grænsen for din evne og skubbet dig bare en smule ud over for at finde ud af et problem. Derfor vil du altid i en god samtale få dig til at føle dig utilpas og få et problem, som du ikke bare kan løse med det samme. Sørg for at have en proces inden samtalen, som du kan stole på for at dekonstruere spørgsmål. Hvis du ikke har en proces, er det ikke muligt at finde ud af det på farten. Tænk over, hvordan du gør dette på forhånd. For eksempel er en, som jeg anbefaler til folk, PEDAC.

Q4: Hvad leder du specifikt efter under tavlen / kodning udfordringen?

Whiteboarding-interviews er unikke, idet det handler mere om dygtighed og mindre om viden (det er alligevel målet). Derfor er der virkelig ikke noget sted at skjule, og det er svært at vende dig ud af det. Arbejdsgivere leder efter en kandidats evne til at løse problemer på en struktureret og systematisk måde. Undervejs forventer de også, at kandidater demonstrerer kendskab til ydeevne og optimering afvejninger mellem rum og tidskompleksitet. Dette kræver anvendelse af algoritmer og datastrukturer til det aktuelle problem.

En anden komponent i hvide boarding-interviews er omkring design af et system, hvor kandidater bliver bedt om at zoome ud af applikationskoden til et større system og tænke over, hvordan data kan flyde mellem systemer og større infrastrukturpåvirkning. Spørgsmål kan køre spektret her fra webserver-proxyarkitektur til afvekslinger mellem forskellige databaseshardningsteknikker. Spørgsmål er også meget åbne og kan være så enkle som "hvordan ville du designe Youtube?". Målet er ikke at se, om kandidaten kender et specifikt stykke viden, men om de forstår, hvordan systemer interagerer og konsekvenserne af infrastrukturbeslutninger. Der er ingen rigtige svar, men der er bestemt forkerte svar. Arbejdsgivere vil se, om kandidater forstår udvekslingen mellem de ikke-forkerte valg.

Hvad angår kodningsudfordringen, er dette typisk meget mindre stringent end tavlen, og mange virksomheder giver kandidater en dag eller mere til at arbejde på det. Arbejdsgivere er på udkig efter kodning af flytning, begår hygiejne, testvaner og hvordan kandidaten tænker på et problem. Det er almindeligt, at arbejdsgivere spørger om beslutninger, der træffes i udfordringerne med at tage hjemmefra under opfølgning af live-interviews og undersøge kandidaten for at forklare, hvorfor der blev truffet visse valg. Det er derfor, det er bydende, at du ikke får hjælp til kodeudfordringen; Hvis du gør det, vil du blive udsat for under opfølgende samtale.

Spørgsmål: Hvad skal en kandidat gøre, hvis de ikke ved svaret på et kodningsspørgsmål?

Kandidater skal have en proces til at dekonstruere spørgsmål, som de ikke forstår. Først skal du stille spørgsmål omkring antagelser om spørgsmålet, og prøv at resonnere om spørgsmålet fra et bottom-up-perspektiv. Denne tilgang kræver naturligvis, at du har grundlæggende viden. Foretag derefter dine egne antagelser ved at isolere dele af spørgsmålet. For eksempel kan du sige "Jeg ved ikke svaret på dette specifikke scenarie, men hvis vi f.eks. Fjerner databasen," og så kan du barbere et stort stykke spørgsmål og zoome ind på det, du ved. Dette fungerer ikke altid, men det giver dig en chance for at stabilisere dig selv i det, der kan være en anspændt live-interviewindstilling. Det køber dig også nogen tid til at tænke igennem spørgsmålet, mens du også fjerner dele af problemet, der forvirrer dig.

Øv dig på at bruge en proces i god tid før eventuelle interviews (igen, se https://medium.com/launch-school/solving-coding-problems-with-pedac-29141331f93f)

I nogle tilfælde er der bare "enten ved du det eller ikke" type spørgsmål, og du kan bare sige "Jeg ved det ikke". Gode ​​arbejdsgivere vil typisk undgå disse typer spørgsmål, da det er temmelig let at slå dokumentation op, men det er et dårligt tegn, hvis det er dit svar, selv for de grundlæggende spørgsmål.

Spørgsmål 6: Hvad er dit råd nr. 1 til kandidater, der gennemgår en tech-interviewproces (især for første gang)?

Find ud af, hvilken type interview det er, og øve, øve, øve!

Spørgsmål 7: Eventuelle andre tip / tricks, du gerne vil dele?

  • Iterere på forskellige øvelsesteknikker, som at tale foran venner eller optage dig selv.
  • Hold følelsesmæssig stabilitet. Forvent at blive afvist meget, og det er vigtigt at ikke se det som personlig dømmekraft.
  • Hold det positivt, altid. Sig aldrig noget dårligt om en tidligere arbejdsgiver, kollega osv. Under interviewet.
  • Hav det sjovt. Husk, at du dybest set beder om penge, så prøv at holde det lyst og sjovt, og du kommer på tværs af en mere behagelig person, som andre kan forestille sig at arbejde.