Come creare un test di programmazione

What you'll need

• Uno spazio di lavoro SkillCort (o una demo)
• Un esempio reale del codice che la sua squadra scrive — un bug, una piccola funzionalità, un refactoring
• Un ingegnere senior che definisca il compito e la matrice di valutazione
• Una decisione su quali linguaggi accetterà

Step 1: Scelga un compito realistico anziché un rompicapo algoritmico

Guardi le pull request dell'ultimo mese e scelga un compito della stessa forma di quelli che ricorrono: correggere un bug dato un comportamento errato, estendere una piccola funzione per gestire un nuovo caso, rifattorizzare un blocco disordinato o scrivere una trasformazione di dati. Questi prevedono la prestazione quotidiana molto meglio dell'inversione di un albero binario.

Lo dimensioni su 30-45 minuti di lavoro concentrato per una persona competente. Un rompicapo premia chi lo ha già provato; un piccolo compito realistico premia chi sa leggere l'intento esistente, fare una modifica sensata e mantenere comprensibile il codice — che è ciò per cui lei sta assumendo.

Elimini le conoscenze legate a uno specifico framework o alla sua azienda, a meno che il ruolo non le richieda davvero, e fornisca nel brief stesso tutto il contesto di cui il compito ha bisogno. Un bravo ingegnere che non ha mai toccato il suo stack dovrebbe comunque poterle mostrare un giudizio solido. Testi l'abilità, non la familiarità con i dettagli minuti del suo codice.

• Ricorre nel suo codice reale, non nei manuali di preparazione ai colloqui
• Ha più di una soluzione ragionevole
• Sta in 30–45 minuti senza imprese eroiche
• Leggibile da un valutatore in meno di dieci minuti

Step 2: Crei l'item di codice nella libreria degli item

Faccia una cartella per il ruolo — Ingegnere backend, per esempio — con tag per area di abilità e difficoltà, poi crei un item usando il tipo di item per il codice. I candidati scrivono e modificano il codice direttamente nell'area di risposta, e i valutatori lo rivedono poi sul posto.

Prepari l'item con del codice di partenza anziché con un editor vuoto. Una breve funzione con un bug descritto, o uno stub con un contratto chiaro, ancora ogni candidato allo stesso punto di partenza e rende direttamente confrontabili le loro modifiche. Il lavoro reale non parte quasi mai da un file vuoto, e nemmeno il test dovrebbe farlo.

Step 3: Scriva il brief accanto all'editor

Usi il layout dello stimolo affiancato: il brief, i requisiti e gli esempi di input e output da un lato, l'editor di codice accanto. Il candidato non si allontana mai dalla specifica per scrivere la soluzione: la stessa forma che ha lavorare su un ticket dentro un IDE.

Scriva il brief come si legge un buon ticket: comportamento attuale, comportamento atteso, vincoli e due o tre esempi concreti. Dichiari esplicitamente che cosa le interessa — "prima il codice funzionante; leggiamo anche in cerca di chiarezza" — così i candidati puntano a ciò che lei valuterà davvero. L'ambiguità nel brief diventa rumore nei risultati.

Step 4: Costruisca una matrice che valuti più della sola correttezza

Un output corretto è necessario, non sufficiente. Costruisca una matrice di valutazione a livelli con tre o quattro criteri — di norma correttezza, leggibilità e approccio, facoltativamente la gestione dei casi limite — ciascuno con descrizioni ancorate di come appare un codice forte, accettabile e debole. "I nomi rivelano l'intento, nessun codice morto" è valutabile; "codice pulito" no.

Pesi la correttezza più di tutto, ma mantenga reali anche gli altri criteri: una soluzione che funziona a stento e che nessuno può manutenere non è un buon segnale per un'assunzione. Quando collega la matrice, questa si congela in uno snapshot, così ogni candidato della sessione viene rivisto sullo standard identico anche se in seguito la versione nella banca evolve.

Step 5: Assembli e delimiti i tempi nel builder

Crei l'assessment in sezioni, pagine e blocchi e importi l'item di codice tramite la finestra di selezione. Molte squadre aggiungono una breve prima sezione di rapide domande di giudizio — leggere un diff, individuare il bug in uno snippet, incollate rapidamente come scelta multipla — e mettono il compito di programmazione in una sezione dedicata.

Imposti il limite di tempo complessivo con un margine per leggere e ragionare, e usi un limite per pagina sulla pagina di programmazione, così il compito non può inghiottire l'intero tentativo. Pesi la sezione di programmazione più di tutte (per esempio ×3), così l'aderenza al ruolo sul Decision Board rifletta il lavoro, non il riscaldamento. Scriva istruzioni che indichino i linguaggi ammessi e che cosa succede se il tempo finisce.

Step 6: Faccia l'anteprima, superi la checklist e pubblichi

Usi Preview as candidate e affronti lei stesso il compito, o meglio, lo faccia affrontare a freddo a un ingegnere che non l'ha scritto. Se finisce in dieci minuti è troppo facile; se non riesce a finire entro il limite, allarghi il tempo o riduca la portata. Corregga il brief ovunque abbia esitato.

Poi soddisfi la checklist di pubblicazione: blocca Publish finché valutazione, tempi e istruzioni non sono completi. Un test di programmazione con una matrice mancante o un limite di tempo non collaudato non dovrebbe mai raggiungere un candidato, e la checklist fa in modo che non possa.

Step 7: Imposti controlli di integrità proporzionati alla posta in gioco

Crei la somministrazione con un nome e una finestra temporale, poi scelga con intenzione gli interruttori di sicurezza. Per un normale screening di selezione, il blocco del copia-incolla e il blocco a schermo intero con un limite di violazioni sensato sono di norma sufficienti. La registrazione della webcam, la registrazione dello schermo, il rilevamento del secondo schermo e le verifiche dell'identità esistono per sessioni con posta in gioco davvero alta — certificazioni, round finali — non come impostazioni predefinite.

Tutto ciò che lei attiva viene dichiarato nella schermata di consenso e di controllo preliminare prima che il candidato inizi. I segnali di integrità sono segnalazioni che una persona rivede nel contesto, mai motivi di rifiuto automatico: un'uscita dallo schermo intero può essere una notifica, non una frode. La proporzionalità evita che i candidati bravi si allontanino di fronte a una rete di sorveglianza a strascico.

Step 8: Riveda il codice con la matrice, con l'IA come supporto

I valutatori rivedono ogni consegna con la matrice condivisa, cliccando su ciascun criterio la scheda di livello che corrisponde al codice — correttezza, leggibilità, approccio. Mettere due revisori sui casi al limite o ad alta posta in gioco mantiene onesto lo standard e, poiché tutti valutano sullo stesso snapshot congelato della matrice, i disaccordi emergono come scarti su criteri specifici anziché come vaghe differenze di sensazione.

L'IA può abbozzare una sintesi della consegna e suggerire punteggi a livello di criterio — una prima passata davvero utile sul codice, con modello e versione registrati agli atti. Ma è un ingegnere identificato a confermare o correggere ogni punteggio. Qui l'IA è supporto alla decisione, mai chi decide: il giudizio di cui si risponde sul codice di un candidato è sempre umano.