Cum să evaluezi abilitățile de colaborare cu AI în interviurile de programare

Când utilizarea AI devine o abilitate, nu un comportament de detectat

De-a lungul majorității ultimilor doi ani, AI-ul în interviuri a fost ceva de apărat. Rubrica a fost „a folosit candidatul asta și l-am prins?". Această abordare se aplică încă în rundele unde AI este interzis, iar stratul de integritate care detectează abuzul acolo este o muncă reală.

Dar în același timp, tot mai multe companii efectuează acum o rundă în care AI-ul este necesar. Meta, Canva, Shopify și Coinbase evaluează explicit candidații după abilitatea de colaborare cu AI. Dacă procesul tău se mișcă în această direcție, ai nevoie de o rubrică — pentru că dacă spui unui candidat „folosește orice instrumente vrei" și îl evaluezi doar după faptul că codul funcționează, măsori aproape nimic. Faptul că codul funcționează este contribuția AI-ului. Abilitatea este cea pe care o aduce candidatul.

Această postare este pentru managerii de angajare care proiectează acea rundă colaborativă cu AI. Patru dimensiuni de evaluat, un format de exercițiu și erorile comune ale interviurilor care diluează semnalul.

Patru dimensiuni care merită evaluate

O rubrică utilă de colaborare cu AI testează abilități observabile în 45 de minute și care diferențiază inginerul care folosește bine AI-ul de cel care copiază doar rezultatele sale. Patru dimensiuni, cu ancoraje la fiecare nivel.

1. Calitatea prompturilor și descompunerea problemei

Candidații buni nu cer modelului să „construiască funcționalitatea". Descompun mai întâi problema, apoi cer ajutor pentru piesa de care au nevoie. Primul prompt al unui bun inginer arată ca un task bine definit; al celui slab arată ca enunțul problemei inițiale.

La ce trebuie să te gândești:

• A reformulat problema în cuvintele lor înainte de a da promptul?
• A limitat instrucțiunile modelului — căi de fișiere, semnături de funcție, forma datelor, exemple din rezultatul așteptat?
• A cerut câte o chestie pe rând, sau a lipizit tot briefing-ul și speră?

Un indicator util: câți tokeni a scris candidatul în prompt pentru fiecare linie de cod produsă de AI? Sub un anumit raport, candidatul folosește modelul ca pe o cutie magică și nu exercită judecată asupra input-ului.

2. Verificare și skepticism

Aceasta este dimensiunea care cel mai des separă cei buni de cei slabi. Modelul produce output. Ce face candidatul cu asta?

Cel mai puternic semnal este dacă candidatul verifică înainte de a integra. Comportamente specifice:

• Citirea codului generat linie cu linie înainte de a-l insera
• Testarea împotriva unui caz de test construit de candidat (nu una sugerată de model)
• Capturarea unei funcții sau biblioteci halucinate și fie reintrebarea modelului, fie înlocuirea lor
• Observarea că rezultatul pare plauzibil dar e greșit pe cazuri limită

Cel mai slab comportament este paste-and-pray: candidatul copiază codul modelului în editor, rulează happy path, vede verde și trece mai departe. Aceasta este echivalentul colaborării cu AI a unui junior care face merge fără a citi diff-ul.

Folosește aceeași analiză de coerență a codului care semnalizează codul generat de LLM în evaluările asincrone. Într-o rundă cu AI-ul necesar, scorul nu este „a folosit candidatul AI" — asta e de așteptat. Scorul este dacă editările candidatului asupra output-ului AI-ului arată dovezi de citire și gândire, sau dacă diff-ul e pur paste.

3. Control asupra buclei

Candidații juniori urmăresc AI-ul oriunde duce. Candidații buni conduc AI-ul.

Comportamente concrete de evaluat:

• Când modelul returnează un răspuns greșit, diagnostichează candidatul și reintreabă cu o limitare corectată — sau doar regenerează în speranța unui răspuns diferit?
• Când modelul propune o arhitectură cu care candidatul nu e de acord, candidatul o contestă („Aș prefera o mașină de stări aici, poți refigura asta cu acel pattern?") sau o acceptă?
• Când modelul se abate de la subiect (refactorizează ceva pe care nu l-a cerut candidatul), candidatul observă și o readuce?

Această dimensiune e invizibilă fără înregistrare pe ecran. Asigură-te că runda captează istoricul prompturilor și diff-ul editorului împreună, nu doar codul final.

4. Comunicare în timp ce faci pair programming cu AI

Ultima dimensiune este dacă candidatul ține interviuvatorul în mână. Sună soft dar e cel mai puternic predictor al modului în care candidatul va lucra zi de zi în echipă care face pair programming cu AI.

Ce înseamnă bine:

• Naratură înainte de prompt: „Voi cere lui Claude să redacteze parser-ul. Mă aștept să facă bine tokenizer-ul dar probabil va greși cu escape-urile — voi trebui să corectez asta."
• Arătarea promptului înainte de a-l trimite
• Expunerea dezacordului cu modelul cu voce tare, nu în tăcere
• Distingerea a ceea ce au scris de ceea ce a scris modelul când explică codul

Versiunea slabă: prompting în tăcere, pauze lungi în timp ce citești output-ul modelului fără a-ți împărți opinii, cod apărând în editor fără explicație de unde vine. Un candidat care codează în tăcere cu AI va lucra în tăcere și cu oameni, și asta e un semnal de dinamică de echipă pe care vrei să-l prinzi în proces.

Exercițiul care relevă aceste abilități

Tentația este să dai candidatului o problemă de algoritm și să-l lași să folosească AI. Nu face asta. AI-ul o va rezolva în secunde și candidatul va petrece 40 de minute editând comentarii. Nu vei învăța nimic.

Un exercițiu mai bun are trei proprietăți:

1. Multi-etapă, cu o surpriză încorporată. Începe cu o sarcină mică pe care candidatul o poate rezolva clar. Pe la jumătate, introdu o cerere de schimbare care rupe o presupunere — un format nou de date, o limitare de performanță, o bibliotecă deprecată. Adaptarea este locul unde abilitatea de colaborare cu AI se arată.
2. Un punct de plecare subtle stricat. Dă candidatului cod care se compilează și se execută dar are un bug subtil — off-by-one, excepție înghițită, condiție de curse sub sarcină. Observă dacă o prinde singur sau dacă se încrede în AI. Majoritatea modelelor nu vor găsi un bug subtil fără promptare.
3. O componentă de documentare sau cercetare. Sarcina necesită candidatului integrarea cu o bibliotecă sau API necunoscută. Modelul știe despre asta. Candidatul trebuie să verifice ceea ce spune modelul față de documentația reală. Diferența între „model susține" și „docs spun" e semnal bogat.

Patruzeci și cinci de minute pentru toată runda. Editorul de cod colaborativ al ClarityHire rulează Monaco cu execuție integrată și îl asociază cu captură de istoric prompt, astfel încât interviuvatorul poate vedea diff-ul editorului și conversația modelului side-by-side în timpul debriefing-ului — nu doar codul final.

Ancoraje de scor, 1 la 4

Evaluează fiecare dimensiune independent pe o scară 1–4. Ancorează nivelurile la comportamente, nu la adjective.

Calitate prompturi (1–4):

• 1: Lipește enunțul complet al problemei în model; fără descompunere.
• 2: Cere funcționalitatea în ansamblu, dar adaugă cel puțin o limitare.
• 3: Descompune sarcina în două-trei piese; întreabă fiecare separat cu context relevant.
• 4: Scrie prompturi bine definite care includ semnătura funcției, forma datelor și un exemplu lucrat.

Verificare (1–4):

• 1: Lipește output-ul modelului fără a-l citi.
• 2: Citește output-ul dar testează doar happy path.
• 3: Construiește cel puțin un caz de test independent de sugestiile modelului; prinde cel puțin o problemă.
• 4: Tratează fiecare output ca suspect; verifică față de documentație reală, date de test reale și cazuri limită înainte de integrare.

Control (1–4):

• 1: Urmează orice produce modelul; regenerează în loc să reprompteze la eșec.
• 2: Reintreabă cu același context după eșec; uneori prinde modelul ieșind din urmă.
• 3: Diagnostichează de ce e greșit modelul și repromptează cu o limitare corectată.
• 4: Stabilește arhitectura singur și folosește modelul pentru piese tactice; contestă când modelul sugerează un design diferit.

Comunicare (1–4):

• 1: Prompting în tăcere; output apare în editor neexplicat.
• 2: Narează rezultatul final dar nu procesul.
• 3: Narează înainte de prompt și arată promptul interviuvatoru.
• 4: Distinge clar propria contribuție de a modelului; expune dezacorduri cu modelul cu voce tare.

Folosește o foaie de scor structurată unde fiecare interviuvator fixează scorul înainte de debriefing. Dimensiunile sunt independente de-ajuns ca dezacordul să fie informativ — un interviuvator ar putea nota candidatul 4 la verificare și 2 la comunicare, și acel tipar e ceea ce merită discutat.

Greșeli comune ale interviuvatorului

Cinci erori care diluează semnalul în această rundă:

1. Evaluarea codului final. Codul e al AI-ului. Judecata, prompturile și editările sunt ale candidatului. Evaluează pe alea.
2. Întrebarea „explică ce a făcut AI-ul". Asta testează înțelegerea lecturii, nu colaborarea. În loc, întreabă „ce ai schimba despre modul în care AI-ul a abordat asta?"
3. Lasă runda să decurgă în tăcere. Dacă candidatul e mut doi minute citind output-ul modelului, întreabă: „descrie-mi prin ce treci". Tăcerea nu e testul; evaluezi cum fac pair programming.
4. Alege o problemă pe care modelul o poate rezolva dintr-o dată. O problemă trivială înseamnă că nu trebuie niciodată candidatul să demonstreze control, verificare sau recuperare. Alege o problemă care necesită cel puțin o rundă de dezacord cu modelul.
5. Uită linia de bază de integritate. Aceasta e runda cu AI-ul necesar, dar ești încă în același proces ca runda unde AI este interzis. Dacă modelul de taste al candidatului în această rundă arată identic cu runda interzisă, asta e interesant — atât pentru motive bune (candidatul genuinu tipărește așa) cât și rele (același ajutor off-camera rulează ambele runde).

Ce să faci în continuare

Dacă estezi pe punct să adaugi o rundă de colaborare cu AI la procesul tău:

1. Decide care din cele patru dimensiuni conteaza cel mai mult pentru rolul specific. Un inginer ML aplicat probabil cântărește verificarea cel mai mare; un inginer software generalist ar putea cântări comunicarea.
2. Proiectează un exercițiu care include o surpriză la jumătate și un bug subtil la plecare. Scrie ancoraje înainte ca primul candidat să o vadă.
3. Captură istoricul prompt-urilor alături de diff-ul editorului. Fără prompturi, evalueaz codul; cu ele, evalueaz inginerul.
4. Calibrează cu doi interviuvatori pe o sesiune înregistrată înainte de a o rula live. Dezacordul dintre ei este rubrica.
5. Evaluează această rundă independent de runda unde AI este interzis. Ele măsoară lucruri diferite, și confundarea lor va răsplati candidatul greșit.

Scopul acestei runde nu este găsirea candidaților care pot folosi AI — aproape toți candidații pot. Este găsirea celor a căror judecată, verificare și direcție sunt de-ajuns ca leveragul AI-ului să devină real, în loc de paste-and-pray scump.