Cum să Scrii Întrebări de Interviu pentru Programare Rezistente la AI

Premisa s-a schimbat

La mijlocul anului 2026, întrebarea interesantă nu mai este dacă candidatul are ChatGPT deschis. Este dacă interviul tău măsoară ceva odată ce are. Majoritatea echipelor au reacționat prin aglomerarea cu detectare — biometria tastaturii, indicatoare de paste, scoring coherenței codului. Detectarea ajută. Proiectarea întrebării ajută mai mult. O problemă pe care un LLM o rezolvă în opt secunde îți spune nimic despre omul din spatele tastaturii, indiferent cât de curat o marchezi pe paste.

Aceasta este un ghid de teren pentru scrierea întrebărilor de interviu pentru programare care produc încă semnal atunci când asistența AI este de asumat.

Ce face o întrebare ușoară pentru un LLM

Trei proprietăți se împotriva ta:

1. Apare în corpus-ul de antrenare. LeetCode, HackerRank, Codeforces, GitHub trending repos — totul este în greutăți. Dacă întrebarea ta are un nume de formă Wikipedia (Two Sum, Word Ladder, Longest Increasing Subsequence), presupune că răspunsul este memorat.
2. Specificația completă este transmisă în avans. Un prompt complet și neambiguu este exact forma pe care un LLM este antrenat să consume. Modelul nu are nevoie de nimic din partea candidatului.
3. Rezultatul este de formă închisă. O funcție cu o intrare, o ieșire, un răspuns corect este banal gradabilă — și banal generabilă.

LeetCode #1 îndeplinește toate trei. La fel și cea mai mare parte din biblioteca de întrebări pe care ai moștenit-o.

Principiul de proiectare 1: Ascunde specificația, evidențiază simptomul

În loc de "implementează o funcție care returnează cel mai lung subșir fără caractere repetate," oferă candidatului un caz de test eșuat și un raport de eroare vag: "Clienții văd elemente duplicate în coșul lor după ce se execută acest endpoint. Aici este o intrare cu eșec. Oprește-o."

Candidatul trebuie acum să:

• Citească codul existent
• Formeze o ipoteză despre ce este greșit
• Decidă ce înseamnă chiar "corect"

Modelul poate totuși ajuta — dar doar după ce candidatul cadru-ează problema. Cadru-area este abilitatea pe care vrei să o măsori oricum.

Principiul de proiectare 2: Transmite baza de cod, nu prompt-ul

Înlocuiește puzzle-urile autonome cu un depozit mic. 100–300 de linii, multiple fișiere, una sau două erori intenționale, un README rar. Întreabă: "Găsește eroarea care provoacă 500-ul pe POST /orders și remediaz-o."

Un model care nu a văzut baza ta de cod nu este mai bun decât candidatul la aceasta. Va ghici plauzibil și cu încredere — și va greși — pentru că răspunsul este în codul din jur, nu în prompt.

Acest format servește și ca interviu fără LeetCode pentru echipele care doresc să măsoare ingineria reală în loc de viteza puzzle-ului.

Principiul de proiectare 3: Construiește o pivotare la jumătatea întrebării

La jumătate, schimbă cerința. "Acum clientul dorește să suporte rambursări parțiale — extinde soluția ta." Sau: "Acest endpoint trebuie să fie idempotent. Ce se schimbă?"

Pivotarea face trei lucruri:

• Forțează candidatul să demonstreze că înțelege propriul cod (o lipituri proaspătă dintr-o fereastră de chat nu poate).
• Evidențiază instinctele de arhitectură pe care o soluție cu un singur șut le ascunde.
• Face ca prompta-area unui model la jumătate în interviu să fie evidentă — candidatul fie se oprește, cere câteva minute, fie produce o a doua lipituri curată care nu seamănă cu prima. Toate care devin semnal în raportul de integritate.

Principiul de proiectare 4: Cere judecată, nu rezultat

Unele dintre întrebările cu cel mai mare semnal nu au cod de scris deloc:

• Exercițiile de revizuire a codului. Transmite o diferență de 60 de linii. Cere candidatului să lase comentarii ca și cum ar fi revisorul pe un PR. LLM-urile produc revizuiri de cod sincere și generice ("ia în considerare adăugarea unui comentariu aici"). Inginerii seniori produc critică specifică și prioritizată ("acest lock este ținut pe apelul de rețea — asta va interblocare sub sarcină").
• Conversații despre compromisuri. "Ai două opțiuni pentru această invalidare a cache-ului. Pe care ai alege și de ce?" Candidatul trebuie să apere o alegere. Modelul nu are nimic de pus în joc și va oscila.
• Citirea unui PR necunoscut. "Explică-mi ce face această schimbare și ce ar putea merge greșit."

Acestea se grupează mai bine cu rubricile design-ului de sistem decât cu cartele de punctaj pentru algoritmi. Notează-le pe baza raționamentului, nu a veredictului.

Principiul de proiectare 5: Constrângeri noi peste probleme noi

Nu trebuie să inventezi o nouă clasă de problemă. Ai nevoie doar de o constrângere neobișnuită pe una familiară.

• "Implementează un limitator de viteză — dar ceasul poate merge înapoi până la 30 de secunde din cauza derivei NTP."
• "Construiește o coadă — dar enqueue-ul trebuie să fie O(1) cel mai rău caz, nu amortizat, pentru că rulează aceasta în o buclă de control cu timp real dur."
• "Analizează acest fișier de configurare — dar specificația evoluează. Arată-mi cum ai gestiona compatibilitatea inversă trei versiuni de acum."

LLM-urile pot rezolva acestea. De obicei vor rata constrângerea. Candidatul care o detectează, o întreabă și proiectează în jurul ei este candidatul pe care îl vrei.

Ce nu trebuie să faci

Câteva reacții comune care se întorc împotriva ta:

• Interzicerea AI fără schimbarea întrebării. Vei pierde candidații de top care folosesc deja AI bine, vei ține cărușii care nu le pasă de regulile tale și vei învăța nimic nou.
• Facerea problemelor în mod gratuțios greu ca să "depășești" modelul. Dificultatea adversarială selectează oamenii dispuși să meștering sub presiune, nu oamenii care pot face treaba. Rata de promovare se prăbușește și pâlnia se blochează.
• Trecerea la toate interviurile pe tablă albă / fără laptop. Aceasta este o opțiune reală, dar are propriile compromisuri — accesibilitate, stresul candidatului și faptul că niciun inginer nu codifică în acel fel în munca sa reală.
• Încrederea în etichetele "rezistente la AI" de la furnizorii de întrebări. Unii furnizori verific-ă că o întrebare obține un scor sub un prag atunci când este transmisă GPT-4 astazi. Modelul de mâine retestează diferit. Tratează eticheta ca un punct de plecare, nu o garanție.

Împerechează proiectarea întrebării cu stratul de măsurare

Chiar și o întrebare bine proiectată beneficiază de un strat de integritate care îți oferă o a doua axă de semnal. Inteligența coherenței codului a ClarityHire citește traiectoria unei submitări, nu doar codul final — a iterat, testat și refactorizat candidatul, sau soluția a sosit într-o singură lipituri coesivă mare? Combinată cu sincronizarea tastaturii și événementele paste/tab, obții un scor de încredere care se împerechează cu alegerile de proiectare de mai sus în loc să le înlocuiești.

Cel mai puternic model pe care îl vedem: o întrebare rezistentă la AI pentru etapa asincronă, urmată de o parcurgere în viu de 30 de minute unde candidatul trebuie să explice deciziile pe care le-a luat ore mai devreme. Combinația este semnificativ mai greu de falsificat decât fiecare pas singur.

Ce să faci mai departe

Alege cele trei întrebări pe care le asignezi cel mai des și notează-le pe baza principiilor de mai sus:

1. Fiecare întrebare ascunde o parte a specificației pe care candidatul trebuie s-o scoată la iveală?
2. Întrebarea necesită citirea codului pe care candidatul nu l-a văzut înainte?
3. Există o pivotare sau o apel de judecată pe care un model gata-făcut nu poate ușor să o dețină?

Pentru fiecare întrebare care obține o notă slabă, rescrie-o o dată și pilot-o noua versiune pe cinci candidați reali înainte de a o răscumpăra. Măsoară două lucruri: calitatea medie a submitării din cuartila ta de top și rata de trecere la următoarea rundă. Dacă calitatea crește și trecerea rămâne constantă, ai o întrebare mai bună. Dacă trecerea se prăbușește, noua versiune este adversarială, nu selectivă — revizuiește și încearcă din nou.

AI în interviurile de programare nu este problema. Întrebările de formă AI sunt. Repară întrebările și restul stivei de integritate începe să facă ceea ce avea întotdeauna de făcut: confirmă semnalul, nu-l genera.