Hvordan man nærmer sig ethvert kodningsinterview uden panik

Lad os være ærlige, algoritmeproblemer er stadig meget en del af jobsøgningen. Mens der er en stadigt voksende liste over virksomheder, der ikke får dig til at hoppe gennem kodningsslynge, vil den gennemsnitlige udvikler støde på en live algoritmeudfordring engang i deres jobjagt. Især hvis du vil arbejde for en Big Four eller en etableret opstart. Så gennem hoops hopper vi.

Jeg behøver ikke at tale om, hvor stressende tekniske interviews kan være. Jeg er sikker på, at de fleste af os kender frustrationen over at gå ud af et interview, vi lige bombede og cykle gennem alle måder, vi kunne have vendt det på. Det er ikke en sjov følelse.

Det er derfor, jeg skriver dette. For dem af jer, der ender med en algoritmeudfordring, hvordan du nærmer det, kan gøre hele forskellen. Er du den type person, der dykker i hovedet og finder det ud undervejs? Eller har du en proces, du følger for at opdele problemet i håndterbare stykker? Mens den førstnævnte metode muligvis fungerer for nogle, udøver jeg sidstnævnte.

For mig er det afgørende at have et sæt trin, der skal bruges til at nedbryde et problem. Selvom det ikke garanterer mig en løsning eller et jobtilbud, giver det mig mulighed for at styre min stressrespons. At holde min panik på et acceptabelt niveau hjælper mig med at fokusere. Tekniske interviews skal jo dreje sig om at demonstrere din evne til at løse problemer - ikke din evne til at håndtere flere mennesker lydløst at dømme dig uden at gå ud.

I denne artikel vil jeg vise dig den proces, jeg har slået igennem gennem flere tekniske skærme og snesevis af dårlige interviews. Det er stærkt påvirket af Launch School's PEDAC-system. Jeg bruger det hver eneste gang, og det har tjent mig godt.

”Forelsket i processen, og resultaterne vil komme.” - Eric Thomas

Den bedste måde at vise min proces er at demonstrere den i handling. Så lad os arbejde gennem et problem sammen. Og for at gøre dette så autentisk som muligt vælger jeg et problem, jeg aldrig har løst før. Skønt du bliver nødt til at tage mit ord for det.

Ifølge Leetcode er String to Integer-algoritmen et populært interviewspørgsmål. Det har også den laveste færdiggørelsesgrad for ethvert Medium-rankingproblem. Dette burde være en god udfordring.

Jeg valgte også dette problem, da det er noget praktisk. Dette er en faktisk algoritme, der er implementeret i de fleste programmeringssprog. I modsætning til mange andre interviewudfordringer (ser på dig Coin Change) har ingeniører faktisk brugt denne algoritme i det virkelige liv.

Med det sagt, lad os dykke ind. Føl dig fri til at følge med på det sprog, du ønsker. Jeg vil bruge JavaScript. Du kan prøve min tilgang eller bruge din egen. Se om du endda kan løse det, før jeg gør det i slutningen af ​​dette indlæg. Du ender muligvis et skridt tættere på at oprette vores eget sprog.

Trin 1: Omformulér problemet med dine egne ord

For mig er dette det vigtigste skridt. Dette er min chance for at stille spørgsmål til min interviewer for at afklare kravene og analysere alle de vigtige oplysninger. Endvidere omskrivning af problemet til mine ord giver mig chancen for at danne en mental model og fordøje problemet.

For dette problem er et spørgsmål, jeg vil stille, om jeg har tilladelse til at bruge type casting. Mens beskrivelsen ikke specificerer den, vil jeg kun bruge JavaScript's native type-casting til at konvertere et tegn ad gangen. Det er den slags begrænsning, jeg ville forvente at finde i en faktisk samtale.

Efter at have læst beskrivelsen er dette de vigtigste detaljer, jeg kom med.

// Givet en streng, returner den passende talværdi.
// Ignorer alt hvidrum i begyndelsen af ​​strengen.
// Antallet kan begynde med et negativt eller positivt.
// Alle tegn, der kommer efter nummeret, skal ignoreres.
// Streng er ugyldig, hvis et tegn, der ikke er et hvidrum eller tegn, kommer foran nummeret.
// Hvis streng ikke indeholder nogen heltalværdier, er den ugyldig.
// Returneringsværdien for en ugyldig streng er 0.
// Det resulterende heltal kan ikke være større end (2 ^ 31) - 1 eller mindre end - (2 ^ 31).

Bare ud fra disse krav begynder jeg allerede at forestille mig, hvordan jeg vil oprette denne algoritme. Det vil sandsynligvis kræve en vis looping og en hel del betinget logik.

Nogle mennesker vil sandsynligvis begynde at kode efter dette trin. For mig er det stadig lidt for tidligt at formulere konkrete planer - men mine gear drejer.

Trin 2: Input- og outputtyper

Mange mennesker vil se dette som et meningsløst trin, men jeg sørger altid for at få input og output fra algoritmen. Enten som en kodekommentar eller i hjørnet af tavlen.

Det tjener to funktioner. Først størkner det, hvad parametrene for min funktion vil være, og hvordan signaturen vil se ud. Leetcode har allerede oprettet funktionssignaturen til mig, men dette vil ikke være tilfældet i en faktisk samtale.

For det andet holder jeg en påmindelse om de typer, jeg arbejder med. Det er ikke uhørt for en kandidat at mislykkes i alle testsager, fordi de glemte at returnere en streng og ikke en matrix. Jeg taler måske eller ikke af erfaringer ...

For vores problem er input og output defineret pænt i titlen.

Input: streng
Output: 32-bit signeret heltal
Underskrift: myAtoi (str)

Trin 3: Eksempler og kanttilfælde

Nu hvor jeg er sikker på input og output, vil jeg komme med nogle testsager. Disse eksempler skal dække alle de kanter, jeg kan tænke på. Jeg kan kun forestille mig, hvor mange gange en kandidat har skabt en fungerende løsning, kun for at få intervieweren frem med en randsag, de har gået glip af - hvilket får deres løsning til at falde fra hinanden.

Det er muligt, at din interviewer leverer nogle, men jeg ville komme med endnu mere - især hvis de ikke er udtømmende. For eksempel har Leetcode givet mig nogle anstændige testsager.

I: “4193 med ord”
Ud: 4193
I: “ord og 987”
Ude: 0
I: “-91283472332”
Ud: -2147483648

Imidlertid mangler disse eksempler nogle muligheder. Hvad hvis nummeret starter med en +? Eller hvad hvis flere tegn kommer foran et tal, såsom - + - 50?

Lad os gøre nogle bedre.

Input: “+50.890”
Output: 50
Input: “- + 100”
Output: 0
Input: “! En anden ugyldig -10”
Output: 0

Trin 4: Datastruktur (er)

De fleste, hvis ikke alle, algoritme-kodeudfordringer involverer brug af en struktur til at holde styr på dine data. Det er vigtigt at overveje hvilken (e) datastruktur (er) du vil bruge, da det vil påvirke din implementering.

Jeg ved fra problembeskrivelsen, at jeg har at gøre med strenge og heltal. Men vil jeg bruge en anden datastruktur til at hjælpe med at konvertere fra den ene til den anden?

Et spørgsmål, som jeg allerede kan forudse, er at holde styr på stederne for hvert ciffer (titus, hundreder, tusinder osv.). Da jeg ikke ved længden på mit heltal på forhånd, vil jeg bruge en matrix til at holde styr på heltalets tegn. Arrayet fungerer som den midlertidige pladsholder for hvert tegn, før de konverteres til det endelige heltal.

Selvom der sandsynligvis findes en mere pladseffektiv løsning, kan jeg optimere min løsning senere. Lige nu vil jeg bare gå med det, der giver mest mening for mig. Det er bedre at få en fungerende naiv løsning end at skyde for månen og ikke afslutte noget.

Trin 5: Pseudokode

Mit næstsidste trin er at bruge lidt tid på at lægge min algoritme i pseudokode. Interviewere ønsker at se, hvordan du tænker og nærmer dig problemer. Pseudocode er perfekt til det.

En ekstra fordel er, at intervieweren vil vide, hvordan du kan hjælpe dig i forvejen. Der har været tidspunkter, hvor jeg kun har fået et problem med at få min interviewer til at give subtile antydninger til at holde mig i gang. Hvis du springer ind i kodning uden en plan, kan du ende med at forvirre både dig selv og din interviewer. Gør hver for dig en tjeneste og opret en handlingsplan.

Dette er hvad jeg kom frem til.

// Start med indeks = 0
// Mens karakter ved det aktuelle indeks er hvidrum
  // stigningsindeks
// Kontroller, om det næste tegn er ugyldigt
  // retur 0
// Kontroller, om næste tegn er et positivt eller negativt tegn
  // Hvis negativt tegn, skal du markere nummeret som negativt
  // stigningsindeks
// Gå igennem tegn, der starter ved det aktuelle indeks
  // Hvis det aktuelle tegn er heltal
    // Skift ud foran array
    // Forøgelsesindeks
  // Ellers, bryde ud af løkken
// Slyng igennem strengens heltalarray
  // Cast strengkarakter til heltal
  // Multipliser heltal med (10 ^ indeks) og tilføj til returværdien
// Hvis streng indeholdt negativt tegn, skal du multiplicere resultatværdien med -1
// Hvis resultatværdien er mindre end min, skal du tildele til min
// Hvis resultatværdien er større end max, skal du tildele til maks
// returværdi

Det kan se ud som om jeg kom med dette ud af intetsteds, men der var en masse overvejelser og prøve-og-fejl bag kulisserne. Dette er det mest tidskrævende trin, fordi det er her algoritmen oprettes.

Læs kravene, input / output og edge cases. Stil spørgsmål, afklar begreber og isoler områder med usikkerhed, man skal fokusere på. Find den enkleste løsning, du kan tænke på og arbejde derfra.

Har du brug for en dybdegående søgning? Skubvindue? Del og erobre? Noget andet?

Hvis dette er det trin, du kæmper mest med, skal du ikke bekymre dig. Det bliver lettere med praksis. Og praksis, du skal. Et grundigt algoritmedesign i pseudokode vil gøre det næste trin hurtigt og nemt.

Trin 6: Kode!

”Endelig!” Du tænker sandsynligvis. ”Det tog evigt!”

Faktisk bruger jeg meget tid på at planlægge humør. Hvis en interviewer giver mig 45 minutter til at afslutte, bruger jeg 15-30 minutter på at tænke og mentalt fordøje.

”Giv mig seks timer til at hugge et træ ned, og jeg vil bruge de første fire på at skærpe øksen.” - Abraham Lincoln

Faktisk er kodning det mindst vigtige trin for mig. Al den tunge løft er allerede gjort. Nu skal jeg bare fortolke min mentale model til kode.

Derudover vil ikke hvordan jeg kode denne løsning i en interviewindstilling være den samme som hvordan jeg koder den i det virkelige liv. Heck, en reel interviewløsning ville se anderledes ud end det svar, jeg kom med til denne artikel. Flere faktorer har indflydelse på, hvordan jeg koder i et interview, såsom tid og reaktionsevne hos intervieweren.

Uden adgang til Google eller tilstrækkelig tid til refaktor, vil jeg bare skrive noget, der fungerer. Og der er ingen garanti for, at jeg endda opnår det.

Men det er ikke pointen med dette indlæg. Ja, det er muligt, at jeg ikke ville have løst dette spørgsmål i et interview. Men indtil dette punkt har jeg de-struktureret udfordringen i dens centrale komponenter. Jeg ved, at jeg kan løse det, og jeg har sat mig i den bedste position til at gøre det. En god interviewer vil se det.

I en teknisk skærm eller på stedet handler det ikke om koden. Sådan kommer du på det.

Hvis du er interesseret i at sammenligne løsninger, er her den, jeg kom med:

Denne løsning er ikke den mest effektive. I følge Leetcode er det kun 25% af de andre indsendelser.

Imidlertid ville det bestå de fleste tekniske interviews. En interviewer beder mig muligvis om at optimere den til plads eller tid, men det er ting, der kan inkluderes i yderligere iterationer, hvis tiden tillader det. Du behøver ikke at komme med dem på første forsøg.

Pointen med at bruge en proces er at have en systemisk tilgang til at nedbryde enhver udfordring. Det fungerer, uanset om du bruger i dit job dagligt eller i en teknisk samtale. Ved at bruge det i et interview, kan du holde din panik i skak ved at fokusere på udfordringen og ikke dine følelser.

Hvis du ikke har en proces, skal du begynde at lave en. Du kan bruge PEDAC eller udvikle din egen. Bare sørg for, at det hjælper dig med at oprette løsninger, som du er sikker på.

For eksempel har du måske bemærket brugen af ​​konstanter, hjælperfunktioner og regex i min løsning. Det er alle tricks, som jeg har valgt, som hjælper mig med at isolere kompleksiteten i et interview. Jo mere min kode læser som engelsk, jo mindre forvirret bliver jeg, når jeg skriver den, og jo hurtigere arbejder jeg. Det er måske en smule ordret, men jeg kan godt lide det. Gør hvad der fungerer for dig.

Hvis der allerede er en procedure, du bruger, skal du praktisere og udføre den. Vent ikke til dit interview på stedet for at starte finjustering. Eksperimenter i dårlige interviews. Pramp og Interviewing.io er perfekte værktøjer til det.

Husk, hvis alt andet mislykkes, så stol på processen.

Hvis denne artikel har resoneret med dig, så lad nogle klapper ps!

Som altid glad kodning!