I puzzle di codifica fanno una buona intervista [chiuso]

Che tipo di sviluppatore stai cercando:

• Chi può prendere una serie di requisiti scritti come un indovinello e creare un codice che risolva l'enigma?
• Uno che può eseguire il debug del codice che sembra un indovinello? o
• Uno che può parlare con gli utenti e con quelli che scrivono i requisiti; quindi creare il codice che risolve il problema e soddisfa i requisiti?

Non mi è mai stato chiesto di risolvere un indovinello o di scrivere codice come parte di un'intervista. Il più delle volte il lavoro è stato come programmatore solista; altre volte è stato quello di assumere una tecnologia che l'azienda non ha familiarità con; in entrambi i casi non esiste un modo semplice per costruire e valutare un indovinello.

Dipende da cosa usi il puzzle.

Se lo usi come punto di partenza, per vedere come un candidato si avvicina a un problema e per accendere una discussione sulle tecniche di programmazione, lo stile e la filosofia, allora va bene.

Se lo utilizzi come test bianco / nero, dove il candidato più veloce per risolvere il puzzle ottiene il lavoro, allora stai sbagliando.

Vuoi valutare un candidato su una vasta gamma di aspetti: comunicazione, pensiero immediato, comprensione del codice, capacità di problem solving, atteggiamento generale verso la codifica, abilità sociali, punti di forza e debolezza, e se sono " si adatta bene alla squadra. Ridurre tutto questo a un singolo booleano "risolto il puzzle" non è mai abbastanza buono.

Se stai cercando di assumere qualcuno bravo in puzzle allora sì, è un buon approccio. Se stai cercando di assumere un buon programmatore potresti prendere l'approccio presentato da Joel .

Penso che la chiave sia capire che cosa ti chiede il puzzle che ti viene in mente e che cosa no.

Ce ne sono alcuni, di vari livelli di utilità (imo):

• Puzzle per motivi di puzzle. Forse hanno lo scopo di testare come un candidato pensa sotto pressione. Forse sono destinati a cercare studenti agili o simili. Non mi interessa davvero - li odio. Sono terribile ai rompicapo, e onestamente se ne colpissi uno in un'intervista che sentivo proprio come se fossi appena stato messo alla prova su quanto succhiassi ai giochi di avventura, probabilmente direi qualcosa. Mi piacerebbe dire che questi non appaiono, ma lo fanno.
• Puzzle di lettura del codice. Come quello nell'OP. Io ... non sono necessariamente convinto della loro utilità. Spesso sembra che questo sia un codice scritto in modo scadente per iniziare, seguire le cattive pratiche o essere veramente inventato.
• "Trova l'algoritmo". Quelli che vedi occasionalmente in "Risolvi questo, lavora qui" sugli annunci di trasporto pubblico, dove davvero starai cercando qualcuno che abbia familiarità con alcuni concetti che vengono applicati nel tuo campo. Potrei vederle utili se la tua particolare applicazione è riempita con un particolare tipo di problema.
• Puzzle di FizzBuzz e relativi "conosci un concetto". Penso che siano decenti per testare le competenze di base.

Penso che ci siano due trappole principali a questo approccio. Il primo è duro / opaco / intelligente fine a se stesso, come una sorta di sadico Dungeon Master. Perché stai mettendo alla prova le persone per la loro capacità di decrittografare codice scritto in modo terribile progettato per non essere letto o capito (farò un'eccezione per i posti che hanno già una base di codice scritta in modo terribile)?

Il secondo sta spendendo troppo tempo con i puzzle, e non sta davvero affrontando il loro valore. Fare bene su questi tipi di domande indica che sei bravo a risolvere enigmi . È questo il talento principale che vuoi nei tuoi dipendenti?

Ovviamente non puoi chiedere enigmi solo e le "trame" che ruotano attorno alle banalità linguistiche non sono molto utili. Ma una sorta di esercizio di programmazione è una necessità virtuale se si utilizza un'agenzia di assunzione di personale o reclutatori, o se si continua ad assumere persone che sono brave a simulare il proprio livello di competenza.

Chiedere i giusti tipi di domande può aiutare a valutare quanto i programmatori familiari siano con algoritmi comuni e come applicarli ai problemi. Può anche dirti se cercano approcci multipli e scelgono quello migliore, o ne scelgono uno che sanno funzionare. In quest'ultimo caso possono essere consapevoli che esiste un modo migliore, ma sarebbe necessario cercarlo per farlo correttamente, il che è abbastanza corretto: lavorare, se meno che massimamente efficiente, il codice è meglio del codice che non funziona e sapere che c'è un modo migliore è più della metà della battaglia.

Un esempio di un posto decente da avviare è un problema che ho avuto in una competizione di programmazione nel 1985, quando ero un giovane hacker Applesoft BASIC. Il problema era di stampare tutti i quadrati perfetti tra 1 e 1000. Naturalmente, ci sono due approcci per risolvere questo problema:

1. Iterate attraverso tutti gli interi tra 1 e 1000. Prendete la radice quadrata di ciascuno e verificate se questo è uguale al risultato troncato-intero dello stesso calcolo. (Nessun operatore modulo in Applesoft BASIC!) In tal caso, stampare il numero.
2. Scorrere tutti gli interi tra 1 e sqrt (1000). Stampa il quadrato di ciascuno.

Ovviamente il secondo è molto più efficiente del primo e, come bonus, stamperà tutte le risposte giuste, mentre il primo, a causa degli errori di arrotondamento nell'implementazione in virgola mobile di Apple, ne ha persi uno o due. Tuttavia, la maggior parte delle soluzioni sono state utilizzate nell'approccio # 1. (Questi erano studenti delle scuole superiori, dopotutto).

Una discussione su un problema moderno di questo tipo potrebbe rivelare se un candidato è consapevole del fatto che ci sono due approcci, può dire quale è meglio e comprende i limiti della matematica in virgola mobile binaria. In effetti, direi che qualcuno che non può dirti perché il secondo approccio è migliore sarebbe un candidato povero - fondamentalmente al livello di uno studente delle superiori del 1985. Questo problema è solo leggermente più complicato di "fizzbuzz" - e molto meno complicato di quello su cui probabilmente lavoreranno!

Il mio punto è sapere cosa ti aspetti di imparare da una domanda del genere, e non impostarli come domande pass / fail ma usarli come punti di partenza per sondare i limiti della conoscenza di un candidato. Puoi fare una serie di domande sempre più difficili e vedere dove iniziano ad avere problemi.

Potresti chiedere, come faccio a capire da una serie di esercizi di programmazione se qualcuno è abbastanza intelligente da lavorare nella mia squadra? E la risposta è: non lo fai, li classifichi in ordine di intelligenza e assumi il più intelligente che ti puoi permettere, supponendo che sia abbastanza intelligente .

Giuro uno di questi giorni in cui qualcuno mi fa questo tipo di domande e io risponderò qualcosa come: "Ho un suggerimento migliore, licenzi qualsiasi pazzo che scrive codice come questo". Codice come questo non dovrebbe mai superare la revisione del codice.

OTOH, mi piacciono i puzzle. Li trovo divertenti. Non ha NIENTE da fare se posso scrivere codice decente, manutenibile e robusto.

Se dovessi dare una risposta definitiva, direi di no, gli indovinelli fanno male alle interviste. Che cosa succede se la persona che stai intervistando è bravissima in enigmi, ma pessima o forse diciamo inesperta nella codifica Java. Forse il risolutore dell'enigma sarà in grado di arrivare più veloce del programmatore medio, ma sei disposto ad aspettare? Se stai assumendo uno sviluppatore Java, assumi qualcuno che sogna Java nel sonno. Forse se l'ambiente fosse un ambiente in cui i progetti e le tecnologie cambiano rapidamente e il candidato potrebbe programmare in un certo numero di lingue diverse su un numero di piattaforme diverse utilizzando un numero di quadri diversi nei prossimi 2-3 anni, sarei più incline a vai con il risolutore di enigmi.

Non lo definirei un classico rompicapo, come discusso ad es in questa domanda . Lo definirei un esercizio di lettura del codice. Quasi tutti sono d'accordo sul fatto che i puzzle misurano solo se un candidato ha già visto questo tipo di puzzle. Ma gli esercizi di lettura del codice possono avere senso, IMHO, gli sviluppatori passano gran parte del loro tempo a leggere il codice, dopotutto.

Ma personalmente, vorrei usare un codice un po 'più realistico. Ad esempio, ho una funzione da qualche parte nella mia base di codice che la larghezza attraversa prima un albero. Se si spoglia il nome, un programmatore ragionevolmente esperto dovrebbe essere ancora in grado di capire cosa fa detta funzione. E rispondi a domande come "cosa succederà se quella struttura di dati è un grafico con cicli al posto di un albero?" oppure "cosa dovresti cambiare per ottenere la ricerca in profondità?".

Non ho mai pensato che i puzzle di codice siano particolarmente efficaci nel scoprire se qualcuno ha una buona conoscenza del codice o della risoluzione dei problemi. Di solito trovo che il tipo di problema richiesto per loro sia piuttosto diverso dal tipo di problem solving quando si scrive software. In genere non hanno bisogno di pensare in modo creativo. COntrast questo con il tipo di domanda di intervista di Google "Come ti viene in mente un prezzo per lavare tutti i finestrini di Seatle?" Ciò richiede creatività e capacità di problem solving, ma può essere applicato a qualsiasi linguaggio di programmazione che utilizzerai in futuro.

Questi puzzle sono semplicemente un proxy per misurare il tuo QI, o almeno le tue abilità di ragionamento logico. L'ovvia logica è che, a lungo termine, una persona intelligente imparerà qualsiasi pila di tecnologia che sta usando, mentre nessuno può aumentare la propria intelligenza. L'intelligenza ha una strong correlazione positiva con l'essere un buon programmatore. Sospetto di sì, tuttavia ci sono molte più variabili e l'esperienza non può essere spazzata via così facilmente.

Penso che usare i puzzle non sia un metodo sbagliato, forse una combinazione di puzzle e la codifica effettiva sarebbe la migliore.

Secondo me, il metodo peggiore sono le interviste faccia a faccia dal momento che stai vedendo quella persona e non puoi fare a meno di concludere in soli 30 minuti basandosi su ipotesi spurie (se il candidato è grasso, balbetta o parla lentamente o, al contrario , è molto articolato). Anche se ne sei a conoscenza, discriminerai inconsciamente in base a variabili arbitrarie.