Sådan gør du fremskridt, mens du studerer til kodningssamtaler

At sidde fast er aldrig sjovt. Især når du arbejder rigtig hårdt. Og alligevel finder jeg, at dette sker hele tiden med folk, der forbereder sig på kodningssamtaler.

Du arbejder konstant. Du har gennemgået hundreder af øvelsesproblemer og blokerer en time hver dag for at studere. Men du går bare ikke frem.

Selv efter alt dette forberedelsesarbejde føler du stadig, at hvert problem er en ny udfordring, som du ikke helt ved, hvordan du løser. Du kan løse problemerne det meste af tiden, men det føles ikke som det bliver meget lettere.

Når jeg arbejder med coachingklienter fra 1: 1, er det nøjagtigt den situation, som jeg ofte finder dem i. Og i næsten alle tilfælde, når vi først identificerer den ting (eller ting), der holder dem tilbage, oplever de store gennembrud. At løse disse problemer har fået mine klienters job hos Amazon, Bloomberg, Uber og meget mere!

Så hvad er det, der holder dig tilbage? Hvad forhindrer dig i at gøre de fremskridt, du ønsker? I denne artikel vil jeg vise dig de ti mest almindelige problemer, som folk kæmper med. En fair advarsel: Det kan være meget svært at identificere disse problemer i dig selv. Hvis du virkelig vil bryde igennem dine problemer, anbefaler jeg at arbejde med en coach.

1. Udvikl et stærkt fundament

Jeg har talt om dette spørgsmål før, men en af ​​de vigtigste nøgler til succes i kodning af interviews er at have et stærkt fundament af grundlæggende datalogi.

Over tid har jeg udviklet mange forskellige teknikker til at hjælpe mine studerende med at forbedre deres problemløsning i deres interviews, som FAST-metoden. Ingen af ​​disse teknikker er dog værdifulde, hvis du ikke har stærke fundamentale under dit bælte.

F.eks. Er FAST-metoden designet til at hjælpe studerende med dynamisk programmering. Det første trin i FAST-metoden er at finde en initial brute force rekursiv løsning. Dette er noget, du skal være i stand til at gøre alene, for at FAST-metoden kan være til nogen nytte for dig. Selvom du forstår metoden, hjælper det dig ikke, hvis du ikke ved, hvordan du får den oprindelige løsning.

Hvis du har stærke fundamentale forhold, er rekursion noget, der ikke burde være svært for dig. Det er et emne, der kommer ofte nok op til, at du skal være i stand til at piske det ud, når du vil.

Sådan er tilfældet med alle andre grundlæggende datastrukturer og algoritmer. Hvis du ikke ved, hvordan du implementerer en sammenkædet liste, er det ligegyldigt, hvor mange tricks du lærer til løsning af tilknyttede listeproblemer.

Hvis du mangler en formel datalogisk baggrund eller bare finder ud af, at de anbefalede problemløsningsteknikker til kodning af interviews ikke rigtig hjælper dig, skal dit første skridt være at dedikere dig til at lære alle de grundlæggende datastrukturer og algoritmer.

Den bedste måde at gøre det på er at tage enten MIT (Python) eller Princeton (Java) datastrukturer og algoritmeforløb. Køb bogen, udfør opgaverne, og tag prøverne. Hvis du lægger arbejde på, kan du nemt gennemføre kurset om 3 måneder eller derunder, og du vil have et stærkt fundament til at komme videre.

2. Få mere kodeoplevelse

Har du nogensinde prøvet at gøre noget for første gang? Da jeg først lærte at spille guitar, ville det tage mig 30 sekunder at få fingrene i en grundlæggende akkord. I teorien kunne jeg spille en hvilken som helst sang, hvis jeg havde tid nok og havde akkordlistene foran mig, men det lyder ikke særlig godt.

Nogle gange arbejder jeg med studerende, der er i en lignende position med deres kodning. De har simpelthen ikke nået et færdighedsniveau endnu, hvor de let kan skrive koden op i deres interview.

I teorien skal kodningskomponenten i interviewet være den lette del. Så længe du har øvet dig på en tavle, skal den hårde del af dit interview være at udvikle en løsning i første omgang, før du nogensinde skriver en linje kode. Hvis dette ikke er sandt, skal du sandsynligvis forbedre dine kodningsfærdigheder.

Der er også nogle grupper, der er mere berørt af dette problem end andre. Primært dem, der har mindre erfaring med kodning. Jeg ser ofte bootcamp-grader, kandidatstuderende, der skiftede til datalogi for deres kandidater fra et andet felt, eller langsigtede ledere, der simpelthen ikke har kodet i et stykke tid, der kæmper mest med kodning.

Nøglen her er simpelthen at få mere øvelseskodning og ideelt set gøre det i et miljø, hvor du får god feedback på din kode. En af de bedste måder at gøre dette på er ved at bidrage til open source-projekter. Dette er ikke kun en fantastisk måde at vise din oplevelse på, men du vil få fordelen ved grundige kodevurderinger og lære at arbejde i et produktionsmiljø.

Hvis du ikke er begyndt at arbejde med open source, er First Timers Only en fantastisk ressource for dem, der ønsker at komme i gang. De deler tutorials om, hvordan man kan bidrage, og har samlet en liste over potentielle projekter, der ville være godt for begyndere.

3. Strategisk tilgang til hvert interview spørgsmål

Når man går i kamp, ​​har enhver general, der forventer at få succes, en detaljeret plan. Hvis du vil have succes i dit interview, skal du også have en detaljeret plan.

Den mest almindelige plan, jeg ser for at løse interviewproblemer, ser sådan ud som følgende:

  1. Se på problemet
  2. Tænk over problemet
  3. Finde en løsning
  4. Skriv løsningen
  5. Succes

Men bemærker du et problem her? Forhåbentlig var det første, du spurgte, "Hvordan finder jeg en løsning?" Denne plan mangler fuldstændigt enhver form for strategi til at komme med løsningen. Det forudsætter, at løsningen bare vises.

Og det er sådan, de fleste mennesker tænker på interviewproblemer. De husker masser af løsninger med håb om, at en af ​​dem vil være ens nok til det problem, de står over for i deres interview, at en løsning på magisk vis bliver til.

Dette er i bedste fald risikabelt.

En langt bedre måde at interviewe er at have en klar spilplan for, hvordan du skal nærme dig hvert interview og hvert problem i interviewet. Her er en grov oversigt over, hvordan du kan nærme dig et times langt interview:

[0: 00–0: 05] Bliv afgjort og sørg for, at du fuldt ud forstår det problem, de beder om. Arbejd igennem alle eksempler på input, der leveres.

[0: 05–0: 10] Find ud af en løsning på problemet med brute force. Ingen kodning på dette tidspunkt, bare tale igennem det og tegne billeder, hvis du finder det nyttigt. Hvis du sidder fast med en brute force-løsning, kan du prøve at arbejde igennem problemet manuelt og oversætte din proces til løsning af det til en algoritme.

[ 0: 10–0: 15] Optimer din løsning. Brug disse 5 minutter til at finde ud af den absolut bedste løsning, du kan i denne periode. Når du sammenligner løsninger, skal du overveje tidskompleksiteten.

[0: 15–0: 35] Kod din løsning. Selvom det ikke er optimalt, er det bedre at have en komplet, ikke-optimal løsning end en ufuldstændig, optimal løsning.

[0: 35–0: 50] Test din kode og løs eventuelle problemer. Dette er utroligt vigtigt. Det betyder ikke noget, om din kode ikke er perfekt første gang, men du havde bedre mulighed for at identificere fejlene.

[0: 50–1: 00] Spørgsmål til din interviewer.

Ved at følge disse trin opnår du to ting samtidigt. For det første budgetterer du din tid effektivt. Den mest frustrerende ting i verden løber tør for tid, når du helt ved, hvordan du løser problemet.

For det andet hjælper disse trin dig med at sikre, at du altid når frem til en løsning. Ved at starte med brute force-løsningen og optimere, kan du næsten garantere, at du i det mindste kommer med en eller anden løsning. Ofte er den mest optimale løsning ikke nødvendig, hvis du klarer dig godt i resten af ​​interviewet.

4. Overvej forskellige mulige løsninger

Vidste du, at de fleste interviewspørgsmål har mere end en korrekt løsning? Jeg ved, chokerende, ikke? Men mange mennesker finder en løsning, og så stopper de bare der uden at kigge længere.

Dette skuffer mig altid. Ofte er der en anden løsning, der ville have været endnu bedre, og de var så tætte. Eller måske var der sammenlignelige løsninger, der havde forskellige kompromiser.

Overvej for eksempel dette problem:

  • En løsning har O(n)tidskompleksitet og O(1)rumkompleksitet
  • En anden løsning har O(log n)tidskompleksitet og O(log n)rumkompleksitet

Hvilken af ​​disse løsninger er bedre?

Nå, det afhænger af, hvad vi faktisk leder efter. Hvis vi har et enormt datasæt og ikke meget hukommelse, kan den første løsning være bedre. Men hvis hukommelse ikke er et problem, så vil vi naturligvis gå med den anden løsning.

Nøglen her er, at mens der i nogle tilfælde kan være en "bedste" løsning, er der langt flere problemer, hvor du kan foretage forskellige afvejninger, og du skal beslutte, hvilke der skal foretages. Som interviewer elsker jeg at se kandidater, der afvejer de forskellige muligheder.

Når du kommer med løsninger, skal du tage et øjeblik på at tænke på andre måder, du kan løse det samme problem på. Kunne du foretage afvejninger, der ville forbedre pladsforbruget i forhold til tid eller omvendt?

Endelig skal du altid overveje plads og tidskompleksitet for hver løsning, du kommer med. Dette giver dig en objektiv måde at evaluere, hvilke løsninger der er bedre end andre, og hjælper med at tage en mere informeret beslutning om, hvilken løsning du skal vælge. Hvis du har flere løsninger, der er sammenlignelige, skal du diskutere med din interviewer og beslutte i fællesskab, hvilken der ville være den bedre tilgang.

5. Start med brute force-opløsningen

Jeg har allerede nævnt dette i forbifarten i tip 3, men en af ​​de største fejl, som folk laver, når de prøver at løse interviewproblemer, er at de straks forsøger at finde den mest optimale løsning på problemet.

Men lad mig spørge dig dette: Hvilket er bedre, en brute force-løsning eller ingen løsning?

Jeg vil fortælle dig, at det er 1000% bedre at finde en løsning med brute force end slet ikke at finde en løsning. Og hvis du begynder med straks at prøve at finde den optimale løsning, er det let at sidde fast og ende uden en komplet løsning ved afslutningen af ​​interviewet.

Mens du faktisk ikke behøver at kode det, anbefaler jeg i det mindste at nævne kort, hvordan du kunne løse problemet med en brute force-løsning, inden du fortsætter med at forsøge at optimere din løsning. Dette udfører to vigtige ting:

  1. Det giver dig en reserveplan. Hvis du prøver at optimere din løsning og fejler, kan du stoppe efter 5 eller 10 minutter og bare kode din brute force-løsning. Du bestå muligvis stadig interviewet. Ikke alle problemer har optimale løsninger.
  2. Det hjælper dig med at afklare problemet. Definition af en brute force-løsning kan hjælpe dig med at forstå nøjagtigt, hvad der er involveret i at komme med en løsning på dette problem. Det er nøglen. At forstå problemet på denne dybe måde vil gøre det lettere at optimere.

Forsøg på straks at finde en optimal løsning kan virke som den rigtige tilgang, fordi det sparer værdifuld tid. Imidlertid finder jeg, at den forvirring, der følger af at tage denne tilgang, ofte spilder meget mere tid, end du får.

At starte med en brute force-løsning giver dig klarhed og et udgangspunkt for at gøre alt andet lettere.

6. Planlæg den fulde løsning, inden du kode

Der er nogle super fancy whiteboards derude. Men chancerne er, at det tavle, du vil bruge, ikke har en mulighed for at kopiere og indsætte. Det betyder, at du vil have en god oversigt over din kode, før du skriver den.

Ofte dykker folk lige ind i at skrive kode, så snart de bliver bedt om et problem i deres interview. Nu er det helt fint, hvis du vil gå videre og definere din metode på forhånd, men det skal være omfanget af den kode, du skriver, indtil du har udarbejdet løsningen fuldt ud. At skrive mere kode end det er en kritisk fejl af to grunde.

For det første, som jeg sagde, har whiteboards ikke copy-paste funktionalitet. Det betyder, at hvis du vil flytte kodelinjer rundt, skal du enten slette og omskrive dem eller tegne pile overalt. Du ønsker ikke rigtig, at dit tavle skal se sådan ud:

At holde tavlen organiseret er lettere for både dig og din interviewer. Det er lettere for dem at forstå din løsning, og det er meget lettere for dig at holde styr på, hvad der foregår. Og hvis du beslutter dig for bare at omskrive ting i stedet, spilder du masser af værdifuld tid.

Det andet problem med at begynde at kode lige uden for flagermusen er, at det kan låse dig ind i en bestemt måde at tænke på problemet på. Vi vil tale mere om dette i punkt 7, men dette kan være utroligt skadeligt for din samtaleoptræden.

Forestil dig, at du ser et problem, og en løsning straks kommer til at tænke på dig. Du begynder at kode det op, men du indser, at det ikke længere er optimalt. Det er usandsynligt, at du vil slette alt og starte forfra. Og selv hvis du gør det, vil du blive låst fast i den tankegang.

Der er problemer, hvor den optimale løsning er fuldstændig uafhængig af brute force-løsningen, og forsøg på at optimere brute force-løsningen mislykkes. Hvis du venter på at starte kodning, undgår du at låse dit sind ind i den ene måde at se problemet på.

Disse bekymringer er grunden til, at jeg altid foreslår, at du forstår den løsning, du vil kode op, inden du skriver koden. Tegn billeder, skriv pseudokode, gør hvad du skal gøre for at forstå løsningen. Når du begynder at kode, skal det være trivielt, fordi du allerede ved præcis, hvad du skal skrive.

7. Husk det store billede

Et af de største problemer, som jeg ser for mere erfarne udviklere, er at de sidder helt fast i ukrudtet med et problem. De begynder at besætte, om sløjfen skal være <; N or &lt; = N og kan ikke finde ud af, hvad der er den rigtige tilgang.

Dette er et perfekt eksempel på at miste skoven for træerne. Spørgsmålet, de prøver at løse, bliver et af "Hvordan skriver jeg denne loop korrekt?" i stedet for "Hvilket formål tjener denne sløjfe i den større sammenhæng med min kode?"

Et perfekt eksempel på dette er et problem, hvor du prøver at bruge den forkerte datastruktur. Lad os sige, at du gemmer de indekserede værdier fra, 1-Nog du beslutter, at du vil bruge en HashMap. Du kan indsætte 1 -> value- 1, 2 ->værdi2 osv.

Men nu når du vil gentage dem i rækkefølge, bliver det en smerte, fordi du er nødt til at hente alle elementerne fra HashMap og sortere dem. Men hvis du tog et skridt tilbage og kiggede på, hvad du faktisk prøver at gøre, vil du bare gemme værdien ved hvert indeks og gentage dem. Et array ville være en meget lettere datastruktur at bruge.

Nu tænker du måske, ”Jeg ville aldrig gøre noget dumt sådan,” men stol på mig, det sker hele tiden. Din tankeproces er ikke-lineær, når du løser problemer, så du har måske troet, at du havde brug for et HashMap på grund af en anden tankegang, som du siden har forladt.

Det er derfor, det er så vigtigt at stoppe med jævne mellemrum, især hvis du begynder at gøre noget, der synes udfordrende og ser tilbage på det store billede af, hvad du prøver at gøre. Når du laver noget, der virker unødvendigt kompliceret, skal du se på dit slutmål og se, om du kan forenkle din tilgang.

8. Brug abstraktion til din fordel

Jeg elsker at spørge komplicerede interviewproblemer. Hvis et problem involverer flere forskellige komponenter, får du som interviewer så stor indsigt i, hvordan en kandidat styrer deres tænkning, når der er så meget at håndtere på én gang.

Nøglen til en vellykket løsning af disse problemer er at bruge abstraktion. Kernen betyder det at bryde din kode ud i mindre funktioner med mere specifikke formål.

Overvej et simpelt eksempel. Lad os sige, at vi ønskede at udskrive en sammenkædet liste i omvendt rækkefølge. Efter at have arbejdet igennem dette problem, indser vi, at der er en O(n)tid og plads-løsning på problemet ved hjælp af en stak (skub hvert element på stakken, når vi gentager listen, og pop derefter hvert emne og udskriv), men vi kan løse problemet i O(n)tid og O(1)rum ved at vende den sammenkædede liste.

Nu ville det være let nok at vende den linkede liste i vores kode, men hvad hvis vi havde en funktion til at gøre det for os? Det ville gøre vores liv lettere. Vi kalder bare funktionen på den linkede liste, gentager alt på listen og udskriver den og vender derefter listen igen, så vi vender vores input tilbage til den oprindelige tilstand.

Med den logik kan vi nu isolere processen med at vende en sammenkædet liste og tænke på, hvordan man gør det effektivt. Selvom dette problem er et meget simpelt eksempel, er det let at se, hvordan dette reducerer den mængde kompleksitet, vi skal tænke på til enhver tid.

Med mere komplicerede problemer anbefaler jeg, at du stiller dig selv spørgsmålet "Hvilken funktion, hvis den eksisterede, ville gøre mit liv lettere lige nu?" Hvis der er en eller flere klare funktioner, skal du skrive din kode, forudsat at de allerede findes. Derefter kan du gå tilbage bagefter og implementere disse funktioner, nu hvor resten af ​​din kode allerede fungerer.

Dette har flere fordele:

  1. Hvis du løber tør for tid, har du stadig en grundlæggende fungerende kode. Abstraktion giver dig mulighed for at fokusere på den overordnede struktur uden at skulle gå ned i detaljerne. Hvis du har ekstra tid, kan du bekymre dig om minutiae, men selvom du ikke gør det, er det klart for din interviewer, at du ved, hvad der sker.
  2. Tydelighed i tænkning og kode. De siger, at et klart skrivebord betyder et klart sind, og det samme gælder for kode. Jo bedre du organiserer din kode og opdeler den i håndterbare komponenter, jo lettere er det at tænke på.

Jeg finder ud af, at jo mere involveret problemet er, jo mere værdifuldt kan det være at opdele tingene i håndterbare komponenter.

9. Test din kode

Når vi laver noget nyt, har vi tendens til at glemme mange af de ting, som vi allerede kender. Vi antager, at de ting, som vi allerede ved, ikke finder anvendelse.

Overvej dette eksempel: Jeg har lært at spille guitar i min fritid. Jeg kæmpede for at gøre fremskridt, så jeg bad min lærer om hjælp, og han foreslog, at jeg skrev ned nogle mål om, hvad jeg ønskede at opnå. “DUH”. Jeg skriver om denne slags ting hele tiden, men det lykkedes mig ikke at skabe forbindelse mellem kodning af interviewpræparat og guitarpraksis.

På samme måde finder jeg, at mange studerende glemmer at anvende de bedste fremgangsmåder, de kender fra kodning i den virkelige verden, til deres interviews. De antager, at kodningssamtaler er helt forskellige, så de ting, de gør normalt, gælder ikke.

En af de ting, som folk glemmer hele tiden, er at teste deres interviewløsning. Men ville du nogensinde begå kode i den virkelige verden uden først at teste den grundigt?

Du tester din kode, fordi du vil sikre dig, at den er korrekt, og at den gør, hvad du synes, den skal gøre. Dette er endnu vigtigere i det stressende miljø i et interview, fordi du er mere tilbøjelig til at lave fejl.

Nøglen til at teste dine løsninger er faktisk at gå gennem koden linje for linje, spore værdierne for hver variabel og effektivt "køre" koden. Hvis du bare læser koden på et højt niveau, kan du meget let gå glip af mindre problemer med din kode. Jeg optog en video, der demonstrerer nøjagtigt, hvordan man går igennem og tester din kode.

Jeg finder ud af, at mange studerende understreger, at deres kode skal være perfekt første gang, og selvom dette er en god ambition, sker det sjældent. Det sker næsten aldrig i den virkelige verden, så hvorfor skulle du forvente, at det skulle ske i det mere stressede miljø i interviewet? Men hvis du tester din kode grundigt, kan du rette eventuelle fejl og stadig ende med en A + -løsning.

10. Få god feedback

At lave interviews i den virkelige verden er en fantastisk måde at blive bedre på at interviewe. Du kan blive mere komfortabel med oplevelsen og give dig masser af muligheder for at få succes. En ofte anbefalet strategi er at planlægge masser af interviews med dem, du er mindst begejstret for først. På den måde kommer du til at øve dig i interviews, hvor du ikke er ligeglad med resultatet, så du er mere forberedt, når de vigtige interviews kommer rundt.

Selvom jeg synes, denne strategi har fordele, er der en fatal fejl: Virksomheder er notorisk dårlige til at give dig nogen meningsfuld feedback.

“Så”, siger du måske, “Hvem er ligeglad? Jeg kan bare bedømme min egen præstation. ”

Nå ja, det er sandt, men det kan være virkelig svært at bedømme dig selv. Du ved ikke, hvilke kriterier din interviewer leder efter (bare at få en optimal løsning på et problem klipper muligvis ikke det). Og hvis du kæmper for at få succes, er chancerne for, at der er noget, du ikke ser.

Dette er grunden til hånlige interviews og derudover ideelt at arbejde med en coach er så vigtige. Mock interviews giver dig mulighed for at få detaljeret feedback om din præstation. Intervieweren kan også fortælle dig, om der er ting, som du ikke har lagt mærke til

Hvis du virkelig seriøst med at klare dig godt i dine interviews, anbefaler jeg også at arbejde med en coach oven på de mock-interviews. Mock-interviews er individuelle datapunkter. De fortæller dig, at på et bestemt problem på et bestemt tidspunkt klarede du dig godt eller dårligt. En coach kan dog se på alle disse datapunkter og hjælpe dig med at oprette forbindelser. De kan hjælpe dig med at se de specifikke ting, du skal arbejde på for at forbedre forskellige aspekter af dit interview.

I sidste ende giver mock-interviews dig datapunkter, og trænere hjælper dig med at forbinde prikkerne. At få denne form for feedback er den bedst mulige måde at fremskynde dit interview fremskridt på.

Gang på gang ser jeg folk stoppe ud i deres interviews. Og det er næsten altid af en af ​​grundene beskrevet ovenfor. Hvis du ikke gør den slags fremskridt, du ønsker, skal du læse denne artikel nøje. Identificer dit eller dine problemområder og arbejd for at rette det. Med tiden vil du være i stand til at forbedre din samtale og begynde at modtage de opkald, du vil høre.