Cum să proiectezi întrebări de interviu pentru codare rezistente la IA

Nu poți interzice IA. Poți proiecta în jurul ei.

Până în 2026, să ceri candidaților să renunțe la asistenții IA pentru o intervie este doar teorie. Pragul pe care candidații îl depășesc cu ChatGPT deschis într-un alt tab este pragul pe care concurenții tăi îi angajează. Întrebarea nu este cum să detectezi utilizarea IA — asta este jumătatea primului job, și o acoperim în cum să detectezi ChatGPT în interviurile de codare. Cealaltă jumătate este proiectarea problemelor care nu se clatină atunci când candidatul are un LLM disponibil.

Acesta este un ghid pentru a doua jumătate: cum să scrii probleme de interviu pentru codare care produc semnal real chiar și atunci când IA este pornită, și unde ajutorul IA se mapează clar pe abilități pe care de fapt vrei să le angajezi.

De ce problemele standard nu mai funcționează

O problemă tipică de LeetCode are trei proprietăți care o fac banală pentru un LLM:

1. Se află în setul de antrenament. Fiecare problemă clasică de two-pointer, sliding window și dynamic programming a fost răspunsă, explicată și re-explicată pe întreg internetul.
2. Intrarea este bine specificată. Doi vectori întregi, o țintă, returnează indicii. Modelul știe exact ce să producă.
3. Ieșirea este binară. Testele trec sau nu. Nu există judecată în răspuns pe care candidatul să o apere.

O problemă cu toate trei proprietăți este, în 2026, o verificare a abilității ChatGPT, nu o verificare a abilității de programare. Fiecare proprietate pe care o elimini face problema mai greu de externalizat.

Principul 1: ancorez problema în cod pe care LLM nu l-a văzut niciodată

Cel mai curat mod de a elimina avantajul setului de antrenament de la masă este să faci candidatul să lucreze în interiorul unei baze de cod specifice. Un LLM poate scrie o traversare a grafului din senin. Nu poate extinde în mod fiabil un repo de 400 de linii în care două dintre module folosesc o convenție internă pe care nu a întâlnit-o niciodată.

Ce arată asta în practică:

• Fix-the-bug. Un repo de 200–400 de linii cu o defecțiune care nu este evident. Simptomul este dat, cauza nu. Candidatul trebuie să citească, să formuleze ipoteze, să testeze și să plaseze patch-ul. Descriem formatul în ghidul nostru de interviuri fără Leetcode.
• Extend-the-feature. O aplicație funcțională cu o cerere mică de caracteristică bine definită. Calitatea diff-ului este evaluarea. Un LLM poate genera un diff plauzibil; nu poate garanta că diff-ul se potrivește cu convențiile existente și trece testele existente la prima rulare.
• Refactor under a constraint. "Acest fișier are 600 de linii și este greu de citit. Împarte-l în trei fișiere fără a schimba comportamentul. Testele trebuie să treacă încă." Răspunsul corect este o decizie de judecată. Nu există o soluție canonică de memorat.

Aceste formate neutralizează avantajul setului de antrenament, deoarece LLM nu a putut vedea repo-ul. Capacitatea candidatului de a naviga codul necunoscut devine semnalul.

Principul 2: fă intrarea ambiguă în mod deliberat

Modelele lingvistice mari sunt la cel mai puternic atunci când specificația este precisă. Sunt la cel mai slab atunci când specificația lipsește informații pe care un om le-ar observa și ar întreba.

O problemă standard: "Dat un CSV de comenzi, calculează venitul lunar."

O versiune mai grea de externalizat: "Iată un CSV de comenzi. Calculează venitul lunar. Unele rânduri sunt restituiri și sunt reprezentate ca sume negative. Unele rânduri sunt restituiri parțiale și folosesc o valoare status diferită. Unele rânduri sunt din o linie de produse discontinuate care nu au fost de fapt expediate. Decide care dintre acestea să incluzi și explică raționamentul tău înainte de a scrie orice cod."

Pasul de raționament este evaluarea. Un LLM va produce cu plăcere cod care gestionează cazul canonic și ignoră cu linște restul. Un inginer adevărat va face o pauză, va lista ambiguități și va pune o întrebare de clarificare — sau va documenta ipotezele pe care le-a făcut.

Evaluează clarificările și ipotezele candidatului separat de codul care urmează. Lista de clarificări este mai greu de falsificat decât implementarea.

Principul 3: mută greutatea pe conversația din jurul codului

O depunere este o mostră, nu un răspuns. Un LLM poate produce o depunere. Doar candidatul poate să o apere sub interogare live.

Două moduri de a exploata asta:

• Async-then-sync. Rulează mai întâi runda take-home sau codare asincronă, apoi programează o rundă live de 30 de minute în care candidatul te ghidează prin depunerea lor. Cere-le să o extindă, să schimbe o constrângere sau să argumenteze de ce au ales o structură de date în locul alteia. Am desfășurat acest format în întrebări de follow-up pentru depunerile take-home.
• Live pairing pe codul propriu al candidatului. La mijlocul interviuului, schimbă o cerință și cere-le să refactorizeze în fața ta. Candidatul care a lipit soluția originală de la un LLM va lupta să o dezvolte fără re-prompting.

În ClarityHire instrumentm runda live cu verificări de coerență a codului pe depunerea originală, deci intervievatorul intră știind care secțiuni din codul candidatului arată generate de LLM și care arată scrise manual. Conversația poate apoi ținti secțiunile suspecte în mod specific.

Principul 4: alege probleme în care ajutorul IA este o caracteristică, nu o defecțiune

Dacă postarea de locuri de muncă spune "vei folosi instrumente IA în fiecare zi în acest rol", atunci proiectează probleme care te lasă să observi cum le folosesc de fapt candidații. Aceasta nu este la fel cu a-i lăsa să lipească răspunsul.

• Open-book cu atribuire. Afirmă în mod explicit: "Poți folosi ChatGPT sau orice documentație. Documentează fiecare prompt pe care l-ai folosit și partea soluției pe care a produs-o." Un candidat puternic folosește modelul cu precizie; unul slab promptează de cinci ori pentru aceeași funcție defectă. Urmele sunt semnalul.
• IA ca adversar. Dă candidatului o funcție generată de IA cu erori ca punct de plecare. Jobul lor este să identifice ce e rău, de ce, și să o repare. Aceasta testează abilitatea pe care rolul o necesită: a revizui în mod critic rezultatul IA înainte de a-l expedia.
• Debugging asistat de IA. Dă-le un repo necunoscut cu o defecțiune reală, permite utilizarea instrumentelor și observă cum localizează cauza. Inginerii care se bazează pe model pentru întrebări înguste ("ce înseamnă această urmă de stivă?") arată foarte diferit de cei care lipesc întregul fișier și se roagă.

Explorăm peisajul mai larg al acestui format în evaluările de codare open-book.

Principul 5: combină prevenția cu detectarea — nu te baza niciodată pe una singură

Chiar și problema cel mai bine proiectată scapă semnal într-o singură direcție. Împerechează alegerile de proiectare de mai sus cu semnale pasive de integritate:

• Biometria tastaturii marchează evenimentele de lipire în rafală care nu corespund autoriei umane.
• Analiza coerență a codului surprinde schimburi stilistice la mijlocul depunerii.
• Un follow-up live surprinde autori care nu pot apăra propriul lor cod.

Fiecare este slab singur. Împreună, fac costul trișării mai mare decât costul efectuării muncii.

O scurtă listă de verificare înainte de a expedia întrebarea

Înainte de a pune o problemă de codare în fața unui candidat în 2026, întreabă-te:

1. ChatGPT ar putea rezolva asta doar din enunțul problemei? Dacă da, reproiectează-o sau reduce greutatea ei în buclă.
2. Specificația este ambiguă în mod că recompensează întrebările de clarificare? Dacă nu, adaugă ambiguitate.
3. Candidatul trebuie să apere sau să-și evoluționeze soluția live? Dacă nu, programează un follow-up.
4. Măsori cum folosesc IA, sau pretenzi că nu vor? Fii sincer cu candidatul în orice caz.
5. Ai un semnal de integritate care confirmă că aceeași persoană a scris depunerea și a rulat follow-up-ul? Dacă nu, adaugă unul.

Ce să faci în continuare

Dacă runda de codare actuală este o problemă de tip LeetCode cu o cutie de depozitare take-home, testezi inginerie de prompt în acest moment, nu inginerie. Alege unul din formatele de mai sus, scrie o problemă în el și rulează-o pe trei ingineri interni înainte de a o pune în fața unui candidat. Prima versiune va fi prea ușoară sau prea neclară; a treia va fi cea care produce semnal real.

Pentru un context mai larg despre unde se potrivește async-ul în buclă, consultă async vs live technical interviews. Pentru jumătatea de detectare a aceleiași probleme, începe cu cum să detectezi ChatGPT în interviurile de codare.