Jeg vil ikke deltage i dit algoritmiske testinterview

Udgivet: Sidst opdateret:
Tomasz Nurkiewicz algoritmisk test

Hvordan ansætter den gennemsnitlige person en førsteklasses skrædder? De beder kandidaterne om at vise dem, hvad de har syet indtil nu, og måske beder de dem endda om at sy noget hurtigt. Derefter observerer de resultatet og noterer sig, hvor godt de betjener symaskinen, hvordan arbejdspladsen er organiseret, og vurderer skrædderens sans for detaljerne. Spilder de for meget stof eller gør de simpelthen ikke et godt stykke arbejde?

Hvordan ansætter softwareudviklere dygtige skræddere? Tja, det ville nok foregå lidt på denne måde: "Dette er et whiteboard. Tegn venligst forskellen mellem en Ghiordes og Senneh-knude. Udled trådlængden som en funktion af stoffets overfladeareal".

Jeg mener ærligt talt, at en dygtig skrædder bør kende forskellen, men hvad er det egentlig, vi kontrollerer her? Vil du have en elegant jakke eller en elegant ligning på et whiteboard?

Min erfaring med et searchfirma og en investeringsbank

Lad mig dele nogle erfaringer, som jeg har haft, da jeg var interviewperson i to store virksomheder. Det første solgte annoncer, der lejlighedsvis var indlejret i de egentlige organiske søgeresultater, og det andet var en stor bank. I førstnævnte brugte jeg adskillige timer på at finde løsninger på ikke-trivielle algoritmiske opgaver. I sidstnævnte var det på samme måde, men jeg beskrev mine algoritmer over telefonen til en person, der sad på den anden side af Atlanten ... og det blev endnu mere mærkeligt end det.

Algoritmisk test tweet

I søgefirmaet ledte jeg efter det længste suffiks i en linket liste, der gjorde... et eller andet. Jeg kan ærlig talt ikke huske meget. Ligesom jeg heller ikke kan huske sidste gang, jeg brugte en linked list. Ja, jeg forstår godt, at den er anderledes end et array - konsekvenser for ydeevnen, forskellige brugssituationer osv. Det ved jeg tilfældigvis også, fordi dette spørgsmål bliver stillet i alle forbandede interviews! Men i det virkelige arbejde har jeg simpelthen aldrig haft mulighed for at udnytte dem. Der var også et spørgsmål relateret til balancering eller traversering af et træ på en eller anden bizar måde. Helt ærligt, det var ikke en særlig mindeværdig oplevelse. Faktisk syntes jeg, at det ville være ærligt af mig at sige, at jeg kendte denne øvelse på forhånd. Ikke fra en bog om algoritmer, men fra en guide til hvordan man bliver ansat i netop dette firma. Mere om det senere.

I investeringsbanken blev jeg først bedt om at generere alle mulige permutationer af en liste af elementer. Husk på, at alt dette skete over et transkontinentalt telefonopkald. Okay, bare for sjov vil jeg forestille mig, at jeg stiller mig selv denne type spørgsmål. Her er de mulige svar, jeg forventede, fra det værste til det bedste:

  • Søg efter en løsning på internettet, hævder, at det er din, og tror, at jeg ikke kan høre tastaturet banke
  • Du kan recitere en løsning fra hukommelsen, linje for linje, fordi du har forberedt dig som en gal, og heldigvis kan du løsningen uden videre. Og ikke meget mere end det.
  • Ubetinget, indviklet kode, der itererer over input. Der skal fortrinsvis anvendes variabler som i, j, k
  • Ren, rekursiv løsning, fordi kandidaten indså, at dette problem kan nedbrydes.
  • Hvis du væmmes ved håndskrevet kode, så søg lidt længere og find et bibliotek, der gør præcis det (f.eks. Indsamlinger2 fra Guava)
Whiteboard-algoritmeprøver

Seriøst, du er nok på udkig efter en ny holdkammerat. Vil du hellere se en pull request med elegant, rekursiv kode eller et enkelt biblioteksopkald? Et bibliotek, der er gennemtestet af millioner af udviklere, baseret på Donald Knuths "Kunsten at programmere computere"? Det tog mig også et stykke tid at finde et bibliotek, mens håndlavede, indlejrede loops findes overalt på internettet. Hvilken holdning er du på udkig efter? At lære udenad og blindt kopiere kode fra internettet, eller rent faktisk at lave research for at finde kampafprøvede løsninger?

En anden øvelse, som jeg fik, gik ud på at blande en række tilfældigt, idet jeg kun havde et tilfældigt møntkast til rådighed. Dette er et interessant problem i sig selv, men det har intet med arbejdsvilkår at gøre. Jeg fandt på en eller anden måde frem til en algoritme (og det var ret underholdende), men efter et par måneder var det eneste, jeg lavede, at jeg sendte et stykke XML fra den ene side af banken til den anden. Hundredvis af banale transformationer i sekundet, og i øvrigt alle større sprog har shuffle-understøttelse: [1], [2], [3], [4], eller en pakke [5].

Interviewspørgsmål om algoritmiske test: rekrutteringens forbandelse

Da jeg har en uddannelse i datalogi, finder jeg ikke algoritmiske tests skræmmende eller meningsløse. De er faktisk tværtimod gode til at træne hjernen, ligesom at løse sudoku eller spille bridge. Jeg har deltaget i flere algoritmiske konkurrencer (f.eks. Kodeksens komme) og har altid fundet dem underholdende. Men det er bare min hobby, du vil måske foretrække at studere DDD eller avanceret SQL. Og jeg er ikke sikker på, at rene algoritmer og datastrukturer passer særligt godt til de fleste rekrutteringsprocesser. De verificerer en kandidats abstrakte analytiske evner samt en solid CS- og matematisk baggrund (som begge er vigtige egenskaber inden for software engineering), men de undlader at indfange andre vigtige egenskaber eller er for indviklede til at være afgørende.

I dag kræver det meste af arbejdet inden for IT at sammensætte API'er og frameworks. Vi er mere som skræddere end som producenter af stof. Algoritmiske færdigheder er nyttige, når du skalerer en enkelt funktion i dit system, men mere fokuseret erfaring med distribuerede systemer vil sandsynligvis bringe dig længere. Det er f.eks. værdifuldt at kende grafteori eller diskrete funktioner. Men praktisk erfaring med et stort netværk af replikerede databaser eller forståelse af, hvorfor nogle hash-funktioner er kompromitterede, har en langt større indvirkning på dit daglige arbejde.

Whiteboard-algoritmeprøver

Det er faktisk vigtigt at forstå, hvad rekursion er. Ligesom det er vigtigt at vide, hvorfor HashMap er så hurtig i Java. Men at forstå hvorfor Ordbog er endnu hurtigere i C# er det næste niveau. Hint: hukommelseslayout, noget, der ikke har noget med teoretisk beregningskompleksitet at gøre. Mange mener imidlertid, at det at stille rent algoritmiske spørgsmål er den enkleste måde at finde exceptionelle, veluddannede udviklere på. En sådan tro er meget romantisk, men ofte ekstremt naiv. Se blot, hvor mange bøger der hjælper dig med at lykkes specifikt i (famøst algoritmiske) Google-interviews. De underviser ikke i de grundlæggende CS-principper, de forklarer knap nok, hvordan man løser specifikke klasser af Google-agtige problemer.

Sortering er et af de mest almindeligt anvendte spørgsmål til algoritmiske interviews. At vide, hvordan Quicksort værker er værdifuld, selv om f.eks. Java har ikke brugt det i næsten et årti. Det kan også være nyttigt at forstå, hvad O(nlogn) er. Men langt oftere var det ikke algoritmisk kompleksitet, der fik mit system til at gå i stå. I stedet var det et N+1-problem - noget, som jeg blev ved med at støde på den hårde måde, men som jeg knap nok blev berørt af under min CS-uddannelse. Hvis du ikke kan modstå trangen til at spørge om sortering, så diskuter i det mindste hvad det betyder for en algoritme at være stabil. Du vil højst sandsynligt bruge en færdiglavet, hurtig algoritme. Stabil vs. ustabil er højst sandsynligt din eneste bekymring. Hint: sortering i Java er stabil, i C# er den det ikke.

Whiteboard-algoritmeprøver

Husk, at algoritmiske spørgsmål er gode, hvis det virkelig er det, du har brug for i det daglige. Maskinlæringseksperter skal forstå, hvad gradient nedstigning er, og det kræver en betydelig matematisk baggrund. Desuden kræver statistik, forskning, computergrafik og spiludvikling ofte en vis grad af it-baggrund. Ellers skal du bruge dit tidsrum til rekruttering klogt og stille de rigtige spørgsmål.

En bedre tilgang til en algoritmisk test: design og arbejde sammen

Jeg har interviewet tonsvis af mennesker i løbet af min karriere, og jeg betragter det som en del af mit job, især i højere stillinger. Mange af samtalerne var forglemmelige, men nogle gange var kandidaterne meget tilfredse, selv om de ikke fik jobbet. Det skaber et godt forhold og et brand for din virksomhed. Hvordan skabte jeg en så god oplevelse?

  • Foretrækker problemløsning i det virkelige liv. Design Twitter-lignende arkitektur eller udbyg et Instagram-lignende websted - øvelser som disse er langt sjovere end at finde den korteste vej eller det længste palindrom.
  • Foretrækker parprogrammering frem for skitsering på whiteboard. At se, hvordan en kandidat arbejder, hvordan han eller hun navigerer i koden, søger efter svar, nærmer sig forhindringer - det burde fortælle dig en masse. Desuden reducerer samarbejde stress og gør processen mere menneskelig.
  • Foretrækker eksisterende kodebase frem for en tom editor. Vi elsker greenfield-projekter, men at ændre en eksisterende kodebase er meget tættere på det virkelige arbejde.
  • Foretrækker test frem for ren produktionskode. Det er godt at kode, men leder kandidaten efter eller udvikler han eller hun test ved siden af implementeringen? Dette aspekt overses næsten altid i forbindelse med en algoritmisk test.
Algoritmeprøve

Husk, at det ikke er nødvendigt at mødes på stedet for at arbejde sammen. Skærmdeling og samarbejde i realtid er i dag ganske problemfrit, også med DevSkiller.

Resumé

Der er intet galt med algoritmiske spørgsmål under en jobsamtale. Det er en vigtig del af vores område. Men i betragtning af hvor lidt tid du har til at rekruttere, er der klogere måder at vælge din næste bedste ingeniør på. Ved at udøve reelle færdigheder sikrer du dig, at en kandidat er god til det, du virkelig har brug for. Desuden reducerer dette stress og forbedrer kandidatens opfattelse af din virksomhed.

Del indlæg

Få mere at vide om ansættelse af teknologiske medarbejdere

Tilmeld dig vores Learning Hub for at få nyttig viden direkte i din indbakke.

Kontroller og udvikl kodningsevner uden problemer.

Se DevSkiller-produkterne i aktion.

Sikkerhedscertificeringer og overholdelse. Vi sørger for, at dine data er sikre og beskyttede.

DevSkiller-logo TalentBoost-logo TalentScore-logo