Jag kommer inte att delta i din intervju för algoritmiska tester.

Publicerad: Senast uppdaterad:
Tomasz Nurkiewicz algoritmiskt test

Hur anlitar en genomsnittlig person en förstklassig skräddare? De ber kandidaterna att visa dem vad de har sytt hittills och kanske till och med be dem att sy något snabbt. Sedan observerar de resultatet och noterar hur väl de sköter symaskinen, hur väl arbetsplatsen är organiserad och bedömer skräddarens känsla för detaljer. Slösar de bort för mycket tyg eller gör de helt enkelt inte ett särskilt bra jobb?

Hur anlitar programutvecklare förstklassiga skräddare? Tja, det skulle nog gå ungefär så här: "Det här är en whiteboard. Var snäll och rita upp skillnaden mellan en Ghiordes och Senneh knut. Härled trådlängden som en funktion av tygets yta".

Ärligt talat anser jag att en förstklassig skräddare borde kunna skilja på dessa, men vad är det egentligen vi kontrollerar här? Vill du ha en elegant jacka eller en elegant ekvation på en whiteboardtavla?

Min erfarenhet av ett searchföretag och en investeringsbank

Låt mig dela med mig av några erfarenheter som jag fick när jag intervjuades på två stora företag. Det första företaget sålde annonser som ibland varvas med verkliga organiska sökresultat och det andra var en stor företagsbank. I det förstnämnda företaget tillbringade jag flera timmar med att komma på lösningar på icke-triviala algoritmiska uppgifter. Det senare var liknande, men jag beskrev mina algoritmer över telefon till en person som satt på andra sidan Atlanten ... och det blev ännu konstigare än så.

Algoritmiskt test tweet

På sökföretaget letade jag efter det längsta suffixet i en länkad lista som gjorde... något. Ärligt talat minns jag inte mycket. Precis som jag inte minns när jag senast använde en länkad lista. Ja, jag förstår hur den skiljer sig från en array - prestandaimplikationer, olika användningsområden osv. Jag råkar också veta det eftersom denna fråga ställs i varje jävla intervju! Men i det verkliga arbetet har jag helt enkelt aldrig haft chansen att dra nytta av dessa. Det fanns också en fråga som gällde balansering eller genomgång av ett träd på något bisarrt sätt. Ärligt talat, ingen särskilt minnesvärd upplevelse. Egentligen tyckte jag att det skulle vara ärligt av mig att säga att jag kände till den här övningen i förväg. Inte från en bok om algoritmer, utan från en guide om hur man blir anställd på just det här företaget. Mer om det senare.

På investeringsbanken ombads jag först att generera alla möjliga permutationer av en lista med element. Tänk på att allt detta skedde över ett transkontinentalt telefonsamtal. Okej, bara för skojs skull ska jag tänka mig att ställa den här typen av frågor till mig själv. Här är de möjliga svaren som jag förväntade mig, från sämst till bäst:

  • Sök efter en lösning på internet, påstå att den är din och tro att jag inte hör tangentbordet knacka.
  • Recitera en lösning ur minnet, rad för rad, för att du har förberett dig som en galning och som tur är råkade du veta lösningen direkt ur huvudet. Och inte mycket mer än så.
  • Ovillkorlig, invecklad kod som itererar över inmatningen. Företrädesvis med hjälp av variabler som i, j, k.
  • Ren, rekursiv lösning, eftersom kandidaten insåg att problemet kan delas upp.
  • Om du äcklas av handskriven kod kan du leta lite längre och hitta ett bibliotek som gör just det (t.ex. Samlingar2 från guava)
Test av algoritmer på whiteboard

Allvarligt talat, du letar förmodligen efter en ny lagkamrat. Vill du hellre se en pull request med elegant, rekursiv kod eller ett enda biblioteksanrop? Ett bibliotek som testats av miljontals utvecklare och som bygger på Donald Knuths "Konsten att programmera datorer"? Dessutom tog det mig ett tag att hitta ett bibliotek, medan det finns handgjorda, nästlade slingor överallt på Internet. Vilken typ av inställning är du ute efter? Att memorera och blint kopiera kod från internet, eller att faktiskt göra research för att hitta stridsbeprövade lösningar?

En annan övning som jag fick göra var att slumpmässigt blanda en matris med bara ett slumpmässigt myntkast till mitt förfogande. Detta är ett intressant problem i sig självt, som dock inte har något med arbetsförhållanden att göra. Jag kom på något sätt fram till en algoritm (och det var ganska roligt), men efter några månader var det enda jag gjorde att skicka en bit XML från den ena sidan av banken till den andra. Hundratals vardagliga omvandlingar per sekund och förresten, alla större språk. har stöd för shuffle: [1], [2], [3], [4], eller ett paket [5].

Intervjufrågor om algoritmiska tester: rekryteringens förbannelse

Eftersom jag har en examen i datavetenskap tycker jag inte att algoritmiska tester är skrämmande eller meningslösa. Det är faktiskt tvärtom, de är bra för att träna hjärnan, som att lösa sudoku eller spela bridge. Jag deltog i flera algoritmiska tävlingar (t.ex. Kodens ankomst) och har alltid tyckt att de är trevliga. Men det är bara min hobby, du kanske föredrar att studera DDD eller avancerad SQL. Och jag är inte säker på att rena algoritmer och datastrukturer passar särskilt bra för de flesta rekryteringsprocesser. De verifierar en kandidats abstrakta analytiska färdigheter, liksom en gedigen bakgrund inom datavetenskap och matematik (som båda är viktiga egenskaper inom programvaruteknik), men de misslyckas med att fånga upp andra viktiga egenskaper eller är för invecklade för att vara avgörande.

Numera kräver det mesta av arbetet inom IT att API:er och ramverk sammanställs. Vi är mer som skräddare än tygtillverkare. Algoritmiska kunskaper är till hjälp när du skalar en enskild funktion i ditt system, men mer fokuserad erfarenhet av distribuerade system kommer förmodligen att hjälpa dig längre. Det är till exempel värdefullt att kunna grafteori eller diskreta funktioner. Praktisk erfarenhet av ett stort nätverk av replikerade databaser eller att förstå varför vissa hashfunktioner är komprometterade har dock en mycket större inverkan på ditt dagliga arbete.

Test av algoritmer på whiteboard

Det är viktigt att förstå vad rekursion är. Precis som att veta varför HashMap är så snabb i Java. Men att förstå varför Ordbok är ännu snabbare i C# är nästa nivå. Tips: minneslayout, något som inte har med teoretisk beräkningskomplexitet att göra. Många tror dock att det enklaste sättet att hitta exceptionella, välutbildade utvecklare är att ställa rent algoritmiska frågor. En sådan tro är mycket romantisk, men ofta extremt naiv. Se bara hur många böcker som hjälper dig att lyckas specifikt i (berömda algoritmiska) Google-intervjuer. De lär inte ut grunderna i datavetenskap, de förklarar knappt hur man löser specifika klasser av problem i Google-stil.

Sortering är en av de vanligaste intervjufrågorna om algoritmer. Att veta hur Quicksort är värdefullt, även om till exempel Java har inte använt den i nästan ett decennium. Att förstå vad O(nlogn) är kan också vara till nytta. Men mycket oftare var det inte algoritmisk komplexitet som fick mitt system att stanna upp. Istället var det ett N+1-problem - något som jag ständigt stötte på på det hårda sättet men som knappt berördes under min utbildning i datavetenskap. Om du inte kan motstå att fråga om sortering, diskutera åtminstone vad det innebär att en algoritm är stabil. Du kommer med största sannolikhet att använda en färdig, snabb algoritm. Stabil vs. instabil är troligen ditt enda bekymmer. Tips: sortering i Java är stabil, i C# är den det inte.

Test av algoritmer på whiteboard

Tänk på att algoritmiska frågor är bra om det verkligen är vad du behöver dagligen. Experter inom maskininlärning måste förstå vad gradient nedstigning är, och det kräver en gedigen matematisk bakgrund. Statistik, forskning, datorgrafik och spelutveckling brukar också kräva en viss bakgrund inom datavetenskap. I övrigt bör du använda din rekryteringstid klokt och ställa rätt frågor.

En bättre strategi för en algoritmiskt test: utformning och samarbete

Jag har intervjuat massor av människor under min karriär och anser att det är en del av mitt arbete, särskilt i högre befattningar. Många av intervjuerna var bortglömda, men ibland var kandidaterna extremt nöjda, även om de inte fick jobbet. Detta bygger en bra relation och ett varumärke för ditt företag. Hur kunde jag skapa en sådan fantastisk upplevelse?

  • Föredrar problemlösning i verkliga livet. Designa Twitter-liknande arkitektur eller skala upp Instagram-liknande webbplatser - sådana övningar är mycket roligare än att hitta den kortaste vägen eller längsta palindromet.
  • Föredrar parprogrammering framför skissande på whiteboard. Att se hur en kandidat arbetar, hur han eller hon navigerar i koden, söker efter svar, närmar sig hinder - det borde säga dig mycket. Att arbeta tillsammans minskar dessutom stressen och gör processen mer mänsklig.
  • Föredrar befintlig kodbas framför en tom editor. Vi älskar nya projekt, men att ändra en befintlig kodbas är mycket närmare verkligt arbete.
  • Föredrar testning framför ren produktionskod. Kodning är bra, men letar eller utvecklar kandidaten tester vid sidan av implementeringen? Den aspekten förbises nästan alltid under ett algoritmiskt test.
Algoritmtest

Kom ihåg att samarbete inte kräver att man träffas på plats. Skärmdelning och samarbete i realtid är numera ganska smidigt, även med hjälp av DevSkiller.

Sammanfattning

Det är inget fel med algoritmiska frågor under en anställningsintervju. Detta är en viktig del av vårt område. Men med tanke på hur lite tid du har för rekrytering finns det klokare sätt att välja din nästa bästa ingenjör. Genom att utöva verkliga färdigheter ser du till att en kandidat är bra på det du verkligen behöver. Dessutom minskar detta stressen och förbättrar kandidatens uppfattning om ditt företag.

Dela inlägg

Läs mer om rekrytering av tekniker

Prenumerera på vår Learning Hub för att få nyttiga insikter direkt i din inkorg.

Kontrollera och utveckla kodningsfärdigheter utan problem.

Se DevSkillers produkter i praktiken.

Säkerhetscertifieringar och efterlevnad. Vi ser till att dina data är säkra och skyddade.

DevSkillers logotyp TalentBoost logotyp TalentScore-logotyp