Att bedöma AI-förmåga hos utvecklare kräver att du tittar bortom verktygskunskap och in i arbetsvanor: hur de styr modeller, granskar utdata och återhämtar sig när modellen är övertygat fel. En utvecklare som har använt AI i produktion visar det i hur de beskriver avvägningar, inte bara i vilka verktyg de nämner.
Varför den vanliga intervjun inte räcker
Att fråga 'använder du Copilot eller Cursor?' ger dig nästan ingen information. Verktygsanvändning är numera nästan universell. Frågan är hur en utvecklare använder dessa verktyg, vad de kontrollerar och var de väljer att sluta förlita sig på dem.
Ett standardiserat kodningstest, genomfört ensam och under tidspress, ger också begränsad information. Utvecklare som förlitar sig på AI-hjälp i sitt faktiska arbete kommer naturligt att vilja använda det under ett test. Att förbjuda det mäter fel sak. Att tillåta det utan en strukturerad genomgång ger dig inget sätt att skilja på utvecklaren och utdatan.
Vad du bör titta på istället
Hur de beskriver ett nyligen genomfört AI-assisterat arbete. Be dem gå igenom något de byggde med AI-hjälp den senaste månaden. Du lyssnar efter: vilken prompt eller vilket sammanhang de gav modellen, vad som kom tillbaka och var fel eller ofullständigt, vad de ändrade och hur de bestämde att det var redo att driftsättas. Vaga svar, eller svar som behandlar AI som en svart låda de litade på okritiskt, är informativa.
Hur de granskar AI-genererad kod. En användbar övning är att ge dem ett kort kodstycke de inte skrivit, där en del har subtila fel. Observera om de läser det noggrant eller skummar igenom det. Observera om de fångar upp problem som ser rimliga ut men är felaktiga. Det här överlappar med vanlig kodgranskningsförmåga men skärps av att AI-genererad kod tenderar att misslyckas på specifika sätt: övertygande hallucination av API:er, logik som är strukturellt korrekt men beteendemässigt fel, säkerhetsantaganden som tyst bäddas in.
Hur de talar om sammanhang. Utvecklare som använder AI väl tenderar att ha en klar bild av vad de ska inkludera i en prompt, hur mycket historik de ska ta med och när en konversation har drivit tillräckligt långt bort att det är bättre att börja om. Om de aldrig funderat på context engineering, är det ett tecken. Om de har starka åsikter om det är det också ett tecken, värt att utforska.
Hur de hanterar en ofullständig specifikation. Ge dem en brief som avsiktligt saknar detaljer. Ställer de klargörande frågor, formulerar de explicita antaganden och flaggar vad de vill ha bekräftat innan de genererar något väsentligt? Eller fyller de tyst igen luckor och levererar med självförtroende? AI-verktyg förstärker både goda och dåliga vanor kring tvetydighet.
Var de säger att modellen hade fel. Fråga direkt: 'berätta om ett tillfälle då modellen gav dig något som verkade rätt men inte var det.' Om de inte kan minnas ett specifikt fall använder de antingen inte AI på ett meningsfullt sätt i produktion eller granskar inte utdatan. Båda delarna spelar roll.
Signaler som inte säger så mycket
Att känna till vilka verktyg som finns är inte ett bevis på kompetens. Att kunna beskriva vad en RAG-pipeline eller en MCP-server är berättar inte om någon kan bygga eller utvärdera en. Certifikat och kursavslutningar inom det här området har begränsat prediktivt värde; området har utvecklats snabbare än de flesta kursplaner.
Att strukturera genomgången
Om du tillåter AI-användning under en teknisk övning, lägg in en 20-minuters genomgång direkt efteråt. Be dem förklara varje del av det som producerats. Fråga vad modellen fick fel och hur de upptäckte det. Fråga vad de skulle gjort annorlunda med mer tid. Det här tillvägagångssättet är mer användbart än något hemtest som lämnas in välpolerat utan efterföljande samtal.
För mer om vad som har förändrats strukturellt i den här processen, se vad som ersatte kodtestet.
Vad vi testar
På Miyagami bedömer vi varje utvecklare två gånger. Den första bedömningen görs utan AI-verktyg och täcker grunderna, bland annat felsökning, prioritering och kommunikation. I den andra får kandidaten använda sina vanliga AI-verktyg, och vi ser vad de faktiskt gör: om de verifierar AI:ns resultat innan de litar på det, hur de styr flera verktyg och om de tar ansvar för kod de inte själva har skrivit. Riskbedömning och hur väl verktygen utnyttjas poängsätts i båda. Alla detaljer om vad vi letar efter och varför finns under så granskar vi.
Korta svar
Bör jag förbjuda AI-verktyg under en teknisk intervju?
Att förbjuda AI-verktyg mäter ett arbetssätt som skiljer sig från de flesta produktionsmiljöer. Att tillåta dem med en strukturerad genomgång ger mer användbar information: du kan se vad utvecklaren accepterade, vad de fångade upp och hur de förklarar resultatet.
Vilken är den mest användbara intervjufrågan för att bedöma AI-förmåga?
Be utvecklaren beskriva ett nyligen genomfört arbete de byggt med AI-hjälp och var modellen hade fel. Kvaliteten och specificiteten i svaret ger dig mer information än någon fråga om verktygskunskap.
Signalerar kännedom om AI-verktyg som RAG eller agenter stark AI-förmåga?
Konceptuell kunskap är i sig ett svagt tecken. Den mer användbara informationen är om utvecklaren kan beskriva hur de använde ett verktyg i produktion, vad som gick fel och hur de upptäckte det.
