Non parteciperò al vostro colloquio per il test algoritmico

Pubblicato: Ultimo aggiornamento:
Test algoritmico di Tomasz Nurkiewicz

Come fa una persona comune ad assumere un sarto di alto livello? Si chiede ai candidati di mostrare loro ciò che hanno cucito finora, magari chiedendo loro di cucire qualcosa di veloce. Poi osservano i risultati, notando il buon funzionamento della macchina da cucire, l'organizzazione del posto di lavoro e valutando l'attenzione del sarto ai dettagli. Stanno sprecando troppo tessuto o semplicemente non stanno facendo un buon lavoro?

Come fanno gli sviluppatori di software ad assumere sarti di alto livello? Beh, probabilmente sarebbe più o meno così: "Questa è una lavagna. Per favore, disegnate la differenza tra un Nodo di Ghiordes e Senneh. Derivare la lunghezza del filo in funzione della superficie del tessuto".

Onestamente, credo che un sarto di alto livello dovrebbe conoscere la differenza, ma cosa stiamo realmente verificando qui? Volete una giacca elegante o un'equazione elegante su una lavagna?

La mia esperienza con una società di ricerca e una banca d'investimento

Vorrei condividere alcune esperienze vissute come intervistato in due grandi aziende. La prima vendeva annunci pubblicitari occasionalmente intercalati con risultati di ricerca organici e l'altra era una grande banca aziendale. Nella prima, ho trascorso diverse ore a trovare soluzioni a compiti algoritmici non banali. La seconda era simile, ma ho descritto i miei algoritmi al telefono a una persona seduta dall'altra parte dell'Atlantico... e la cosa è diventata ancora più strana.

Test algoritmico tweet

Alla società di ricerca, stavo cercando il suffisso più lungo di un elenco collegato che faceva... qualcosa. Francamente, non ricordo molto. Così come non ricordo l'ultima volta che ho usato un elenco collegato. Sì, capisco che è diverso da un array: implicazioni sulle prestazioni, casi d'uso diversi, ecc. Lo so anche perché questa domanda viene posta in ogni maledetto colloquio! Ma nel lavoro reale non ho mai avuto la possibilità di sfruttarle. C'è stata anche una domanda relativa al bilanciamento o all'attraversamento di un albero in qualche modo bizzarro. Onestamente, non è stata un'esperienza memorabile. In realtà, sarebbe onesto da parte mia dire che conoscevo già questo esercizio. Non da un libro sugli algoritmi, ma da una guida su come essere assunti in questa particolare azienda. Ne riparleremo più avanti.

Alla banca d'investimento mi è stato chiesto di generare tutte le possibili permutazioni di un elenco di elementi. Tenete presente che tutto questo è avvenuto durante una telefonata transcontinentale. Ok, solo per divertimento, immagino di pormi questo tipo di domanda. Ecco le possibili risposte che mi aspettavo, dalla peggiore alla migliore:

  • Cercare una soluzione su Internet, affermare che è vostra e pensare che non sento battere la tastiera.
  • Recitare una soluzione a memoria, riga per riga, perché ci si è preparati come matti e per fortuna si conosce la soluzione a menadito. E non molto di più.
  • Codice imperativo e contorto che itera sull'input. Preferibilmente utilizzando variabili come i, j, k
  • Soluzione pulita e ricorsiva, perché il candidato ha capito che questo problema può essere scomposto.
  • Se siete disgustati dal codice scritto a mano, cercate ancora un po' e trovate una libreria che fa esattamente questo (ad es. Collezioni2 di Guava)
Test di algoritmi alla lavagna

Sul serio, probabilmente state cercando un nuovo compagno di squadra. Preferireste vedere una richiesta di pull con un codice elegante e ricorsivo o una singola chiamata alla libreria? Una libreria testata da milioni di sviluppatori, basata su Donald Knuth "L'arte della programmazione informatica"? Inoltre, mi ci è voluto un po' per trovare una libreria, mentre i loop annidati fatti a mano sono ovunque su Internet. Che tipo di atteggiamento stai cercando? Memorizzare e copiare ciecamente il codice da Internet o fare davvero una ricerca per trovare soluzioni collaudate?

Un altro esercizio che mi è stato assegnato richiedeva di mescolare casualmente un array avendo a disposizione solo un lancio casuale di una moneta. Si tratta di un problema interessante di per sé, ma del tutto estraneo alle condizioni di lavoro. In qualche modo ho trovato un algoritmo (ed è stato piuttosto divertente), ma dopo qualche mese non facevo altro che passare un pezzo di XML da una parte all'altra della banca. Centinaia di trasformazioni banali al secondo e, tra l'altro, tutti i principali linguaggi ha il supporto per lo shuffle: [1], [2], [3], [4]o un pacchetto [5].

Domande di colloquio sui test algoritmici: la rovina del reclutamento

Avendo una laurea in Informatica, non trovo che i test algoritmici siano intimidatori o inutili. Anzi, è proprio il contrario: sono ottimi per esercitare il cervello, come risolvere il sudoku o giocare a bridge. Ho partecipato a diverse gare di algoritmi (ad es. Avvento del codice) e li ho sempre trovati divertenti. Ma questo è solo il mio hobby, forse preferireste studiare DDD o SQL avanzato. E non sono sicuro che gli algoritmi puri e le strutture di dati siano particolarmente adatti alla maggior parte dei processi di assunzione. Verificano le capacità analitiche astratte di un candidato, così come una solida preparazione in matematica e scienze informatiche (che sono entrambe caratteristiche importanti nell'ingegneria del software), ma non riescono a cogliere altre caratteristiche importanti o sono troppo contorte per essere conclusive.

Al giorno d'oggi, la maggior parte del lavoro nell'IT richiede di cucire insieme API e framework. Siamo più simili a sarti che a produttori di tessuti. La conoscenza degli algoritmi è utile quando si tratta di scalare una singola funzione del sistema, ma un'esperienza più mirata nei sistemi distribuiti vi porterà probabilmente più lontano. Ad esempio, conoscere la teoria dei grafi o le funzioni discrete è utile. Tuttavia, l'esperienza pratica con una grande rete di database replicati o la comprensione del motivo per cui alcune funzioni hash sono compromesse hanno un impatto molto maggiore sul vostro lavoro quotidiano.

Test di algoritmi alla lavagna

In effetti, capire cosa sia la ricorsione è essenziale. Proprio come sapere perché HashMap è così veloce in Java. Ma capire perché Dizionario è ancora più veloce in C# è il livello successivo. Suggerimento: layout della memoria, qualcosa di non correlato alla complessità computazionale teorica. Tuttavia, molti credono che porre domande puramente algoritmiche sia il modo più semplice per trovare sviluppatori eccezionali e ben preparati. Questa convinzione è molto romantica, ma spesso estremamente ingenua. Basta vedere quanti libri vi aiutano ad avere successo specificamente nei colloqui (notoriamente algoritmici) di Google. Non insegnano i fondamenti della CS, ma spiegano a malapena come risolvere classi specifiche di problemi in stile Google.

L'ordinamento è una delle domande più comunemente (ab)usate nei colloqui sugli algoritmi. Sapere come Ordinamento rapido è prezioso, anche se, ad esempio, Java non l'ha usato per quasi un decennio. Anche capire cosa sia O(nlogn) può essere utile. Ma molto più spesso non era la complessità algoritmica a causare l'arresto del mio sistema. Si trattava invece di un problema N+1, un problema che ho incontrato sempre più spesso, ma che è stato a malapena affrontato durante la mia formazione in informatica. Se non riuscite a resistere all'impulso di chiedere informazioni sull'ordinamento, discutete almeno di cosa significa che un algoritmo è stabile. Molto probabilmente userete un algoritmo veloce e già pronto. Stabile o instabile è probabilmente la vostra unica preoccupazione. Suggerimento: l'ordinamento in Java è stabile, in C# no.

Test di algoritmi alla lavagna

Tenete presente che le domande algoritmiche sono ottime se è davvero quello che vi serve quotidianamente. Gli esperti di apprendimento automatico devono capire cosa discesa del gradiente è, e questo richiede una sostanziale preparazione in matematica. Inoltre, le statistiche, la ricerca, la grafica computerizzata e lo sviluppo di giochi tendono a richiedere una certa preparazione in CS. Per il resto, utilizzate saggiamente il tempo a disposizione per il reclutamento e fate le domande giuste.

Un approccio migliore a un test algoritmico: progettare e lavorare insieme

Nel corso della mia carriera ho fatto moltissimi colloqui, che considero parte del mio lavoro, soprattutto nelle posizioni più elevate. Molti colloqui sono stati dimenticabili, ma a volte i candidati erano estremamente soddisfatti, anche se non hanno ottenuto il lavoro. Questo crea un ottimo rapporto e un marchio per la vostra azienda. Come ho fatto a creare un'esperienza così bella?

  • Preferite la risoluzione di problemi reali. Progettare un'architettura simile a quella di Twitter o creare un sito web simile a quello di Instagram: esercizi di questo tipo sono molto più divertenti della ricerca del percorso più breve o del palindromo più lungo.
  • Preferite la programmazione a coppie agli schizzi alla lavagna. Vedere come lavora un candidato, come naviga nel codice, cerca le risposte, affronta gli ostacoli: questo dovrebbe dirvi molto. Inoltre, lavorare insieme riduce lo stress e rende il processo più umano.
  • Preferite una base di codice esistente a un editor vuoto. Ci piacciono i progetti greenfield, ma modificare una base di codice esistente è molto più vicino al lavoro reale.
  • Preferire i test al puro codice di produzione. La codifica è ottima, ma un candidato cerca o sviluppa test insieme all'implementazione? Questo aspetto è quasi universalmente trascurato durante un test algoritmico.
Test dell'algoritmo

Ricordate che per lavorare insieme non è necessario incontrarsi sul posto. La condivisione dello schermo e la collaborazione in tempo reale sono oggi molto semplici, anche grazie a DevSkiller.

Sintesi

Non c'è nulla di sbagliato nelle domande sugli algoritmi durante un colloquio di lavoro. È una parte importante del nostro settore. Tuttavia, dato il poco tempo a disposizione per il reclutamento, ci sono modi più saggi per scegliere il vostro prossimo miglior ingegnere. Esaminando le competenze reali, ci si assicura che il candidato sia bravo in ciò di cui si ha realmente bisogno. Inoltre, questo riduce lo stress e migliora la percezione che il candidato ha della vostra azienda.

Condividi post

Per saperne di più sulle assunzioni nel settore tecnologico

Iscrivetevi al nostro Learning Hub per ricevere utili approfondimenti direttamente nella vostra casella di posta elettronica.

Verifica e sviluppo delle competenze di codifica senza soluzione di continuità.

Guardate i prodotti DevSkiller in azione.

Certificazioni di sicurezza e conformità. Ci assicuriamo che i vostri dati siano sicuri e protetti.

Logo DevSkiller Logo TalentBoost Logo TalentScore