Nästan alla ingenjörer du intervjuar idag kommer förmodligen att säga att de använder AI-verktyg.
För ett år eller två sedan kunde det svaret ha varit användbart. Idag berättar det mycket lite. AI har blivit en så normal del av mjukvaruutveckling att det börjar kännas lite konstigt att fråga någon, "Använder du AI?" – nästan som att fråga, "Använder du e-post?"
Den viktigare frågan är vad som händer efter att de öppnar verktyget.
Kan de använda det väl?
Märker de när det ger dem fel svar?
Ifrågasätter de vad det producerar, eller antar de bara att något genererat av AI måste vara rätt?
Det är där skillnaden mellan kandidater börjar bli mycket tydligare. Två ingenjörer kan båda säga att de använder AI varje dag, men den ena kan använda det på ett genomtänkt sätt medan den andra bara accepterar vad som än kommer fram. De flesta intervjuprocesser är inte särskilt bra på att skilja dessa två åt.
Vi har hittat en fråga som kommer mycket närmare sanningen, och intressant nog handlar den egentligen inte alls om AI-verktyg – det handlar om vad som händer när verktyget gör något fel.
Varför räcker det inte längre att fråga "Använder du AI?"
AI är inte längre en ovanlig färdighet för ingenjörer. Stack Overflow Developer Survey 2025 visade att 70 % av utvecklare använder AI-verktyg dagligen. När något blir så vanligt slutar det helt enkelt att vara ett användbart sätt att skilja åt kandidater.
Problemet är att många företag fortfarande intervjuar för AI-färdigheter som om de vore något nytt. De frågar kandidater vilka verktyg de har använt, hur ofta de använder dem, eller om de vet hur man skriver bra instruktioner. De frågorna kan berätta om någon har öppnat en AI-kodningsassistent förut, men de säger ingenting om denna person kan använda det ansvarsfullt.
Tänk på det så här. Du skulle inte anställa någon för att köra bara för att de sa att de har kört bil varje dag i fem år. Du skulle också vilja veta om de vet när de ska sakta in, hur de reagerar när något går fel, och om de uppmärksammar vad som händer omkring dem.
AI-assisterad utveckling är inte så olika. Den användbara färdigheten är inte bara att kunna använda verktyget. Det är att veta när man ska lita på det, när man ska ifrågasätta det, och när man ska sluta och göra något själv.
Prova denna fråga istället
Här är frågan vi skulle rekommendera:
Berätta om en specifik gång då ett AI-verktyg gav dig något fel, och hur du fångade det innan det blev ett verkligt problem.
Det är allt. Du behöver inte be kandidater förklara hur en viss AI-modell fungerar. Du behöver inte testa dem på AI-terminologi. Du behöver inte ens fråga vilket verktyg de föredrar.
Du frågar efter en verklig historia, och den historien kan berätta överraskande mycket om hur någon faktiskt arbetar.
Här är vad den frågan avslöjar:
Först berättar den om de faktiskt använder AI som en del av sitt arbete. Någon som använder dessa verktyg regelbundet kommer vanligtvis att ha några exempel de kan prata om utan att behöva söka i minnet.
För det andra berättar den om de kontrollerar arbetet. AI kan producera något som ser helt rimligt ut men ändå är fel. Om någon aldrig har märkt ett AI-misstag, är de antingen ovanligt lyckliga, eller så tittar de inte tillräckligt noga.
För det tredje visar det var de drar gränsen mellan att lita på AI och att lita på sin egen bedömning. Det är på väg att bli en av de viktigaste färdigheterna för ingenjörer idag.
Slutligen visar det om de tar ansvar för resultatet. När något går fel, säger de, "AI gjorde det fel," eller förklarar de vad de borde ha kontrollerat och vad de ändrade efteråt? Den skillnaden spelar roll.
Lyssna efter historien
De starkaste svaren har vanligtvis en sak gemensamt: De är specifika.
En kandidat kan berätta att ett AI-verktyg genererade en fel databasfråga, föreslog en ändring som skulle ha bryta en befintlig funktion, eller missförstod en viktig del av applikationen, och ännu viktigare, de förklarar hur de märkte problemet.
De kommer inte bara säga, "Jag kontrollerar alltid AI-genererad kod." Istället kommer de att berätta vad de kontrollerade, vad som såg misstänkt ut, vad de ändrade, och vad som hände efteråt.
Bra kandidater är vanligtvis bekväma med att prata om misstag. De behöver inte låtsas att AI-verktyget var perfekt eller att de fångade allt omedelbar. I själva verket kan det att kunna säga, "Jag hade nästan missat detta, men sedan märkte jag…" berätta mer än en polerad framgångssaga.
Du letar efter omdöme, inte perfektion.
Ett svagare svar låter vanligtvis mycket mer allmänt. Kandidaten kan säga, "AI gör ibland misstag, så jag granskar alltid allt," och lämna det där. Det är ingenting tekniskt fel med det svaret, men det ger dig inte mycket bevis på hur de faktiskt arbetar.
När du ställer en enkel uppföljningsfråga som, "Kan du ge mig ett exempel?", lär du dig vanligtvis mycket mer.
Vad om de säger att AI aldrig har gjort något fel för dem?
Det är här frågan blir särskilt användbar. Om någon säger att de aldrig har haft ett AI-verktyg ge dem ett fel svar, bör det inte nödvändigtvis imponera på dig. Det kan faktiskt vara något värt att utforska vidare.
AI-verktyg gör misstag; ibland är de uppenbara, ibland är de subtila, och ibland ser svaret helt rimligt ut tills du kontrollerar det mot de faktiska kraven eller det befintliga systemet.
Så ställ en annan fråga: "Kan du tänka på en gång då du var osäker på om AI:s svar var rätt?" Det ger kandidaten en annan möjlighet att förklara hur de verifierar sitt arbete utan att omvandla samtalet till en knepig fråga.
Målet är inte att få någon på sannolika svek. Det är att förstå hur de tänker.
Fungerar detta för juniora ingenjörer också?
Ja, även om exemplen naturligtvis kommer att vara olika.
En juniora ingenjör kan prata om hur de fångade ett litet logikfel i genererad kod eller insåg att ett AI-förslag inte stämde överens med vad uppgiften faktiskt krävde. En mer erfaren ingenjör kan beskriva något mer komplext: upptäcker en riskfylld databasändring, ett felaktigt antagande om ett befintligt system, eller ett säkerhetsproblem som inte var uppenbart vid första blicken.
Det viktiga är inte hur dramatiskt misstaget var. Det är om kandidaten kan förklara vad som hände, hur de märkte det, och vad de lärde sig av det.
Gör inte detta din hela intervju
Den här ena frågan kan vara användbar, men den bör inte ersätta resten av din tekniska intervju. Du vill fortfarande förstå hur någon löser problem, kommunicerar, arbetar med andra människor, och hanterar de tekniska ansvaren i rollen.
Ett användbart tillägg är dock att låta kandidater använda AI under en del av intervjun. Ge dem ett praktiskt problem och låt dem använda de verktyg de normalt skulle använda på jobbet. Iaktta sedan hur de närmar sig det.
Accepterar de blindt det första svaret?
Ställer de bättre frågor när resultatet inte är rätt?
Kontrollerar de vad verktyget producerar?
Märker de när något inte ger mening?
Det ger dig en chans att se deras omdöme i aktion snarare än bara höra dem beskriva det.
Vad du lär dig från två kandidater
Föreställ dig att du intervjuar två personer för samma ingenjörsroll.
Den första kandidaten säger, "AI-verktyg gör ibland misstag, men jag granskar alltid koden noggrant."
Den andra kandidaten berättar om ett nyligt projekt där ett AI-verktyg föreslog en databasändring som skulle ha orsakat problem med befintliga data. De förklarar vad som såg misstänkt ut, hur de kontrollerade det, vad de ändrade, och vad de nu gör annorlunda när de granskar liknande förslag.
Båda kandidaterna använder AI, men du har lärt dig något helt olika om dem.
Den andra kandidaten har visat dig att de inte bara använder AI för att gå snabbare. De förstår att gå snabbare bara hjälper om de fortfarande kan känna igen när något är fel.
Färdigheten som faktiskt spelar roll
Den bästa AI-relaterade intervjufrågan handlar egentligen inte om AI. Det handlar om omdöme.
Verktyg kommer att fortsätta att förändras. Det verktyg en kandidat använder idag kanske inte är det de använder nästa år. Nya modeller kommer att dyka upp, befintliga kommer att bli bättre, och hur ingenjörer arbetar med dem kommer att fortsätta att förändras.
Det som inte kommer att förändras så snabbt är behovet av någon som tittar på resultatet och frågar, "Är det här faktiskt vettigt?"
Det är personen du vill ha i ditt team.
Så nästa gång en kandidat säger att de använder AI varje dag, sluta inte där. Fråga dem om sista gången det gjorde något fel. Deras svar kan berätta mycket mer än verktyget de använder någonsin kunde.
Och om du inte vill lägga tid på att omforma din intervjuprocess för att hitta den sortens omdöme, är det där MyNextDeveloper hjälper genom att koppla startups med granskade ingenjörer och AI-talang som utvärderas inte bara på vad de vet, utan på hur de faktiskt arbetar.
TL;DR
Nästan alla ingenjörer du intervjuar kommer att säga att de använder AI-verktyg varje dag, så den frågan berättar ingenting användbart längre. Den som gör det: Fråga dem om en specifik gång då ett AI-verktyg gjorde något fel, och hur de fångade det. Ett starkt svar kommer med verkliga detaljer, en ärlig historia om vad som bröt, och en tydlig känsla för vad de skulle göra annorlunda, inte ett vagt "Jag kontrollerar alltid allt."
Om någon påstår att ett AI-verktyg aldrig har svikit dem, är det faktiskt ett varningssignalen, inte en grön flagga. Den här ena frågan testar tyst exakt det omdöme som skiljer ingenjörer som använder AI för att gå snabbt på ett säkert sätt från de som bara gå snabbt.
Letar du efter att bygga ett högpresterande fjärrteknologiteam?
Kolla in MyNextDeveloper, en plattform där du kan hitta de bästa 3 % av mjukvaruingenjörer som brinner för innovation. Våra på-begäran, dedikerade och grundliga lösningar för mjukvaru talent ger en omfattande lösning för alla dina mjukvaru behov.
Besök vår webbplats för att utforska hur vi kan hjälpa dig att montera ditt perfekta team.
