Fram till 2024 anställde vi på samma sätt som de flesta företag fortfarande gör. En take-home-uppgift eller ett demoprojekt, några kodningsfrågor, ett samtal om vad de hade byggt. Det fungerade för att bygga själva grejen var svårt. Om någon levererade en ren, fungerande applikation betydde det något.
Det är inte svårt längre, och följden är rent mekanisk: varje hemuppgift vi fick in i våra senaste rekryteringsomgångar såg likadan ut, eftersom varje hemuppgift var skriven av en modell, och på skärmen syns ingen skillnad. I praktiken sållar team som fortfarande använder dem bara fram kandidater som är beredda att lägga en kväll på att övervaka en agent.
LeetCode-liknande tester har det omvända problemet. De mäter något verkligt, men vad de mäter är mönsteråterkallning mot klockan, och det var aldrig en bra indikator för senior arbete ens innan verktygen förändrades. Du lär dig inte hur en senior utvecklare hanterar en schemaändring genom att se dem invertera ett binärt träd. Värre är att den återkallning testerna belönar är precis det arbete som agenter har absorberat. Du skulle selektera hårdast för den färdighet som spelar minst roll.
Vad som gick sönder, i en mening: anställningsprocesser byggdes för att utvärdera utdata, och utdata slutade bära information om personen. Inget av formaten visar grunderna längre, och inget visar agent-färdigheterna. Så vi ersatte båda med två arbetssessioner i en verklig kodbas, en utan agenter och en med, där vi ser hur folk faktiskt arbetar.
Ingen session står ensam. De är steg tre och fyra i en längre process: CV-granskning mot ett bedömningskriterium och ett trettio minuter långt introduktionssamtal kommer före dem, en kulturintervju och referenser efter, för när det mesta av koden skrivs av agenter spelar hur någon delar kontext och arbetar med de omkring dem minst lika stor roll som deras tekniska färdigheter.
Den första sessionen testar grunderna, utan AI. Kandidaten får en kodbas de inte har sett, ett antal verkliga ärenden, ett av dem ett produktionsfel, och sextio minuter. Det är en normal arbetssession, inte ett test: de plockar upp ärendena och kör igång, och vi tittar på. Att skriva kod har blivit enkelt, men att förstå hur ett system hänger ihop har det inte, och om grunderna inte finns där har kandidaten inget att validera en agents utdata mot. Vad bra ser ut är specifikt: läsa dataflödet och felmönstren innan koden rörs vid, sätta produktionsfelet först och kunna säga vad det påverkar, hitta grundorsaken snarare än symptomet, lägga till testet som hade fångat felet. Denna omgång fångar de som har vidarebefordrat en LLM genom några år av distansarbete, vilket är vanligare än branschen gärna erkänner. Det är också här vi tar reda på om de flytande kan prata om ett systems design på engelska, vilket vi granskar hårdare på än de flesta.
Den andra sessionen är samma typ av arbete med motsatt begränsning: en ny uppsättning ärenden, och vilka AI-kodverktyg kandidaten normalt skulle använda. Nu ser vi vad de gör när en agent gör det mesta, bedömt på sex kriterier: om de verifierar vad agenten producerar, hur de orkestrerar verktygen, om de delar upp arbetet i delar innan de genererar, hur de sätter upp prompt och kontext, hur de felsöker, och om de håller reda på allt de har påbörjat. Oavsett om de planerar först, om de läser vad som kommer tillbaka, och om de kan förklara en förändring de inte själva har skrivit.
Den här andra sessionen är där en nylig kandidat med tretton års erfarenhet föll ihop. Hans CV såg bra ut och grundsessionen gick bra. Sen fick han använda agenter, och från det ögonblicket slutade han läsa. Varje förändring accepterades, varje prompt fick ett "kör på", och han stängde ärenden utan att kontrollera något av dem. De flesta företag hade anställt honom. Vi hade gjort det också, för två år sedan, för de flesta processer ser aldrig den timme vi såg. Om du fortfarande filtrerar med take-home-uppgifter och kodtester, tar han sig igenom dina intervjuer just nu, och du får veta det när hans kod når granskning.
Om du bygger om din egen process är tvåsessionsstrukturen principen värd att ta med sig, mer än någon specifik uppgift. Grunderna utan agenten, för de är det som gör verifiering möjlig. Verkligt arbete med agenten, för det är jobbet. De delar av anställningen som aldrig handlade om artefakten, granskningen, kultursamtalet, referenserna, behåller sin gamla roll; om något spelar referenskontrollen ännu större roll nu.
Och om du utvärderar en leverantör snarare än en kandidat gäller samma logik med ett tillägg: be att få se processen. Varje företag som placerar ut utvecklare bör kunna visa dig vad de testar, hur det bedöms och varför folk inte klarar sig. Vi publicerar vår i sin helhet. En granskningsprocess som inte tål att publiceras mätte fel saker.
Den fullständiga processen, med båda scorecards och exempel på vad bra och dåligt ser ut i varje session, finns i The Next 10X Engineer. Om du vill veta hur din nuvarande rekrytering står sig jämfört med andra ledares är Engineering Leader Benchmark öppen.
