Domande di colloquio tecnico asincrono che rivelano davvero la competenza

Il problema delle domande asincrone

Nel 2026, quasi ogni puzzle classico di algoritmi che un candidato trova in un take-home asincrono viene risolto da un modello linguistico in pochi secondi. Lo stesso vale per la maggior parte di LeetCode. Lo stesso per "implementa una cache" e "costruisci un URL shortener".

Se il tuo stage asincrono usa ancora domande dal canone di preparazione del 2020, non stai selezionando in base alla competenza ingegneristica — stai selezionando in base all'accesso a ChatGPT. Questo articolo raccoglie quattro formati di domande che resistono al completamento banale dell'IA e generano vero segnale in un contesto asincrono.

Formato 1: Domande "leggi questo codebase"

Al candidato viene fornito un piccolo repository (50–500 righe) e chiesto di fare qualcosa con esso: trovare un bug, aggiungere una feature, refactorizzare una classe, scrivere un test mancante.

Esempio per un ruolo backend:

"Allegato c'è una piccola API Express con un endpoint users. C'è un bug che fa restituire dati stantii dopo l'aggiornamento del profilo. (1) Trova e correggi il bug. (2) Aggiungi un test che l'avrebbe catturato. (3) Scrivi 2–3 frasi sulla causa sottostante."

Perché funziona:

• Il candidato deve leggere il codice, non solo scriverlo. L'IA può scrivere; il candidato deve capire.
• Il deliverable "spiega la causa" è breve ma rivela profondità. Le spiegazioni generate dall'IA tendono a essere generiche; i veri ingegneri puntano alla riga specifica.
• Una domanda di follow-up live ("come hai trovato il bug?") smonta qualsiasi submission generata solo dall'IA.

Formato 2: Domande di design con compromessi

Invece di "implementa X", chiedi "progetta X e scrivi cosa hai considerato."

Esempio per un senior engineer:

"Progetta un rate limiter semplice per un'API interna che serve 50 RPS al picco. Implementa una versione funzionante (qualsiasi linguaggio) e un README di 1 pagina che spieghi: (1) l'algoritmo scelto e almeno un'alternativa che hai scartato, (2) cosa cambieresti se il traffico crescesse a 5000 RPS, (3) cosa non stai gestendo e perché."

Perché funziona:

• Il codice è la parte piccola. Il README è il segnale.
• "Cosa non stai gestendo" è la domanda decisiva. L'IA è scarsa nell'ammettere i limiti; i senior engineer lo fanno naturalmente.
• Il deliverable è breve da leggere (≤15 min per il reviewer), a differenza di un progetto da 4 ore.

Formato 3: Domande "debug-questo-fallimento"

Fornisci al candidato un test che passa, uno che fallisce e il codice in test. Chiedgli di far passare il test rosso senza rompere il verde.

Questo formato è difficile da aggirare con l'IA perché l'IA tende a riscrivere troppo. Un candidato che ragiona su modifiche minime supera uno che incolla un file rigenerato.

Esempio:

"Allegato c'è un utility di parsing delle date. La funzione gestisce correttamente le date ISO 8601 (il test 1 passa). Non gestisce le date con abbreviazioni di mesi in maiuscole miste come 12-Mar-2025 (il test 2 fallisce). Fai passare il test 2 senza rompere il test 1. Invia la patch più piccola possibile."

La frase "patch più piccola possibile" fa tutto il lavoro. I reviewer leggono un diff di 3 righe in 30 secondi.

Formato 4: Domande stile code-review

Fornisci al candidato un pezzo di codice con 3–5 issue di severità variabile e chiedgli di fare una code review.

Esempio per un ruolo mid-level:

"Allegata una pull request che aggiunge un endpoint /checkout alla nostra API di e-commerce. Reviewla come se l'avesse inviata un collega. Elenca gli issue su cui bloccheresti, gli issue che suggeriresti solamente e almeno una cosa che l'autore ha fatto bene. Ordinali per severità."

Perché funziona:

• L'engineering consiste soprattutto nel leggere il codice degli altri, non nello scrivere codice da zero. Questa domanda testa il lavoro reale.
• Fa emergere il giudizio ("bloccheresti o solo suggeriresti?"), che è il segnale per distinguere il senior dal mid-level.
• È difficile da esternalizzare: l'IA può segnalare i problemi ovvi ma li classifica male e raramente coglie le sottigliezze.

Cosa evitare nelle domande asincrone

• Puzzle puri di algoritmi. "Implementa una sliding window per X" — risolti dall'IA in secondi, debolmente predittivi anche prima dell'IA.
• Qualsiasi cosa oltre le 2 ore. I candidati migliori le saltano. Vedi i dati di abbandono sul budget di tempo.
• App CRUD generiche. "Costruisci una lista di cose da fare con Postgres" — ogni candidato produce submission quasi identiche.
• Domande con una sola risposta corretta. Il formato asincrono è migliore nel far emergere il giudizio, che richiede più risposte valide.

Follow-up live

Ogni esercizio asincrono dovrebbe essere abbinato a un follow-up live di 20 minuti dove il candidato cammina attraverso la sua submission. Questo singolo passaggio fa di più per l'integrità di qualsiasi strumento di rilevamento dell'IA. In ClarityHire, la stanza live carica automaticamente il codice inviato dal candidato, così l'intervistatore arriva preparato.

Abbinare domande a rubriche

Una domanda straordinaria senza rubrica produce comunque risultati incoerenti. Per ogni formato di cui sopra, pre-scrivi una rubrica di scoring con almeno 3 livelli ancorati (1 = sotto soglia, 3 = a soglia, 5 = sopra soglia) prima che arrivi la prima submission. Vedi la nostra guida alle best practice per la strategia completa di hiring asincrono.