FizzBuzz - davvero? [chiuso]

Quando si tratta di domande sul "test di intervista", spesso emerge l'argomento di FizzBuzz. C'è anche un post di Coding Horror a riguardo.

Ora, se ti preoccupi di leggere siti come questo, probabilmente hai meno probabilità di essere nella demografia dei programmatori che troverebbero FizzBuzz tutt'altro che banale.

Ma è proprio vero che il 99% dei programmatori avrà difficoltà con esso?

Veramente?

Quali sono le prove a sostegno di questo?

Alcuni esempi di vita reale sarebbero molto utili per rispondere a questa domanda.

99%? No. Una percentuale significativa? Sì. Dalla mia esperienza diretta di intervistare persone posso testimoniare a questo. Potrebbe sembrare insignificante per te, ma ci sono molte persone nel campo della programmazione che si sono più o meno finte per anni e si applicano a posizioni di livello non d'ingresso e falliscono.

Anche se PUOI risolverlo facilmente, ma mi dai grande staticità riguardo al fatto che ti venga chiesto di fare un tale compito umile conterà contro di te. Far parte di una squadra significa dover fare a volte cose che potrebbero non piacerti ma che sono necessarie. Se fin dall'inizio, prima ancora che iniziamo a lavorare insieme, pensi che sarebbe meglio provare ad affermare il tuo speciale stato di essere al di sopra di fare qualcosa che ti ho chiesto di fare, quindi fungerà da segno contro di te.

Non mi interessa necessariamente quanto sia elegante la tua soluzione (anche se sarebbe bello), ma vederti prendere una pugnalata su una lavagna e parlarne mentre mi mostri che sei almeno disposto a prenderla . Se sei indignato e dici qualcosa del tipo "Sono un risolutore di problemi, non una scimmia di codice!" allora verrai abbattuto un piolo.

Ho avuto intervistati che si sono rifiutati di iniziare a provarlo. Basta semplicemente rifiutare. No. Uh. Non lo farò. Faccio una o due domande più educate, le ringrazio per il loro tempo e chiudo l'intervista.

Lo dico come manager e come sviluppatore.

Penso che il 99% dei programmatori che fanno domanda per un posto di lavoro (e non lo ottengono) possa lottare per questo. Ma non il 99% dei programmatori che svolgono un lavoro in modo produttivo.

Questa è la natura del nostro moderno processo di ricerca di lavoro. Molte persone che si applicano non sono qualificate.

Quel post di Coding Horror parla anche del modo in cui insegniamo informatica oggi. In passato (in particolare al MIT), dovevi imparare cose come Lisp, che richiede praticamente di afferrare concetti come la ricorsione.

Al giorno d'oggi alle persone viene insegnato Java perché è ampiamente usato nell'industria e l'attenzione si è spostata sulla sintassi piuttosto che sul profondo pensiero della programmazione. Non mi piace Java; in effetti, penso che sia un primo linguaggio di programmazione ideale. Ma non ho visto i miei istruttori insegnare principi di programmazione profonda con esso.

Odio dirlo ma

Il motivo principale per cui ho visto che le domande di programmazione non riescono a ottenere risposta è colpa del richiedente piuttosto che del risponditore.

Ricordo chiaramente un'intervista in cui mi è stato chiesto come creare un particolare algoritmo di ricerca della raccolta che verrà eseguito in tempo costante (stesso numero di ricerche indipendentemente dal numero di elementi nella raccolta). Armeggiai e borbottai per 20 minuti prima di arrendermi. Fu allora che questo genio durante l'intervista procedette a dimostrare la risposta come qualcosa che operava in un tempo quasi costante, ma ancora non costante. Un po 'come dire "Dammi una risposta pari a zero" e poi accettare 0.1.

A parte questo, ho visto troppi casi in cui qualcuno che sta intervistando fa una domanda che non soddisfa i seguenti criteri:

1. Conoscono tutte le possibili risposte corrette.
2. Sanno perché le risposte corrette sono corrette.
3. Sanno come fornire effettivamente abbastanza informazioni senza dare la risposta.
4. Le domande di "risoluzione dei problemi" non si basano sulla conoscenza di un fatto sconosciuto (questo è il problema più grande che abbia mai visto).
5. Ci vorrebbe meno di 1 minuto per scrivere la risposta se non fosse necessario capirla. Se ci vogliono 5 minuti solo per digitare il codice, richiede davvero più problem solving di quanto possa essere inserito nella parte verbale dell'intervista.
6. Le domande si basano su più di un semplice "Un problema che ho incontrato una volta o mi è stato dato a scuola e quindi dovresti sapere come risolverlo adesso ". Scommetto che hai avuto più di 2 minuti per rispondere, perché non dai la stessa cortesia al candidato.

Scherzi a parte (1), penso che chiedere alle persone di scrivere codice nella parte verbale di un'intervista sia stupido.

Scherzi a parte (2), penso che anche intervistare le persone senza chiedere loro di scrivere codice sia anche stupido.

Scherzi a parte (3), dovresti dare loro "compiti a casa", chiedere loro di portare esempi di codice, o dare loro un laptop e un paio di domande e un ufficio tranquillo per lavorare su di loro. Quindi lasciali soli mentre ci lavorano. Di solito vado con quest'ultimo approccio in quanto limita la loro capacità di ottenere aiuto esterno (cheat) e posso cronometrarlo.

Tutto quello che devi fare è cercare su FizzBuzz. C'è stata un'enorme ondata di post sul blog. In generale, il blogger ha detto "Ho detto alla gente di scriverlo in [qualche lingua] e qui ci sono i tipi di errori che hanno fatto:" e poi ha elencato alcune insidie. Il divertimento inizia nei commenti in cui la gente dice "ah! È banale in [qualche altra lingua], tutto ciò che devi scrivere è questo:" seguito dal codice. Il prossimo commento trova invariabilmente bug in quello primo. Sembra che alcuni sviluppatori molto bravi non abbiano capito bene la prima volta, in qualsiasi lingua. Alcuni degli errori:

• Ho chiesto da 1 a 100 e tu hai fatto da 1 a 99 o da 0 a 99
• incasinare se stampare il numero insieme a fizz e / o buzz
• disaccordi su "fizzbuzz" vs "fizz-buzz"
• ottimizzazioni perse, come confrontare due volte quando una volta avrebbe fatto
• molto di più

Quando assumo, chiedo alle persone di scrivere un codice alla lavagna per me, niente di così complicato (lo so, non pensi che sia complicato) e molti candidati falliscono completamente. Voglio dire come scrivere VB in stile If, ​​Then, End If ma mettere anche le parentesi graffe (solo per essere al sicuro immagino) o scrivere C # (e chiedere prima, C #?) Ma non avere un punto e virgola da nessuna parte. Non iniziare con errori logici!

Ho letto l'articolo di Coding Horror che menzioni e la mia opinione è che Jeff abbia ragione ... ma quando è stata intervistata l'ultima volta?

Quando vieni intervistato, di solito sei molto stressato e spesso devi rispondere a domande teoriche (niente intelligenza, niente google, nessun resharper, ... solo la tua memoria è turbata dallo stress). È lo stesso nei test. Lo stress non ti aiuta.

Ho notato che l'unico modo per sapere se qualcuno è adatto per una posizione è lavorare con lui per un po '... Prendi solo le ultime 10 persone che hai assunto su 100 (forse di più), quanto è stato davvero buono assumere???

Un datore di lavoro dovrebbe assumere un risolutore di problemi, non una scimmia di codice che conosca i moduli.

Non puoi testare "per un po 'tutti i candidati", quindi è necessario intervistarli. Ecco perché focalizzo le mie domande su questo (problem solving) e faccio un controllo di riferimento passato.

La mia opinione è che FizzBuzz sia pericoloso per la società che cerca sviluppatori che sostengano la sua crescita.

Recentemente mi è stato assegnato il compito di intervistare oltre 50 programmatori per una posizione senior in cui avrebbero lavorato principalmente con PHP.

Ho lanciato il problema del fizzbuzz sull'esame di screening, soprattutto per divertirmi e perché volevo dieci buone domande e ne avevo solo nove. Il mio intento, a quel tempo, era mostrare alle persone che anche noi possiamo divertirci, anche sulle domande dei colloqui.

L'80% dei richiedenti ha risolto il problema, ma non ha utilizzato l'operatore del modulo.

Il 15% dei richiedenti non è stato in grado di risolvere il problema.

Il 5% dei richiedenti ha risolto il problema utilizzando l'operatore del modulo.

Mentre il mio campionamento è piuttosto limitato (50 candidati da un paese), posso dirti che:

Il 95% di loro aveva un BS o superiore in un curriculum CS (le università qui competono cercando di rendere il suono CS più spettacolare).

Sono stato davvero sorpreso. Bene, spaventato .. ma stupito. Non pensavo di avvicinarmi alla riproduzione dei risultati, dal momento che il problema è diventato così popolare. Questo mi mostra che il 5% dei miei candidati potrebbe non essere un super programmatore, ma almeno legge blog relativi alla programmazione.

Nel mio ultimo giro di assunzioni ho avuto 3 operai edili con 0, ripeto zero, istruzione di programmazione o esperienza richiesta per una posizione di sviluppatore di software. ^* Quindi questo è il fondo della canna. Se si assume una distribuzione normale delle abilità, si può vedere come il livello medio di abilità sarà piuttosto basso e anche 'sopra la media' (tra i candidati) sarà ancora relativamente scarso.

Ora, se stai frullando solo i candidati che avevano quella che sembrava essere una certa capacità di programmazione, scoprirai che ora hai:

1. Bugiardi
2. appassionati di parole d'ordine (ho letto un articolo su .NET una volta)
3. programmatori effettivi difettosi
4. persone che hanno utilizzato una tecnologia per completare un progetto, ma non ne sono venuti a conoscenza (vedi domande fizzbuzz su idisposable per identificarli)

Inoltre, alcune domande "fizzbuzz" che ho visto sono specifiche del dominio. Puoi sviluppare progressivamente con un linguaggio / framework x per un certo numero di anni (quindi z anni di esperienza con x) e non esserti imbattuto in alcune parti di esso (gli sviluppatori di biblioteche non conoscono molto sullo sviluppo dei componenti dell'interfaccia utente per es.)

Allo stesso modo, molti sviluppatori fanno lo sviluppo della manutenzione in questi giorni, quindi le loro capacità di architettura / progettazione potrebbero essere deboli in alcune aree.

Ora, non sono sicuro che il 99% sia preciso, ma l'IME è ancora piuttosto alto. Almeno nell'intervallo dell'80%.

^{* No, non abbiamo chiamato o dato una seconda occhiata a queste applicazioni.}

Sì davvero. Probabilmente non al 99% ma comunque piuttosto alto. Ho intervistato gli studenti di informatica per stage e assunzioni a tempo pieno. Intervisterei circa 25 studenti in un college. Ci dissero di non porre le stesse domande, perché gli studenti parlavano. Ho rapidamente imparato che non aveva importanza, perché avrei avuto solo 3 o 4 studenti su 25 che potevano rispondere alla mia prima domanda. "Scrivi strcmp"

Ho chiesto loro di scrivere una funzione per confrontare due stringhe. Forse per usare la funzione per ordinare le parole per un dizionario. Sareste sorpresi dal numero di studenti che non hanno capito come confrontare due parole, figuriamoci sapere come scrivere la funzione. E alcuni di questi studenti hanno affermato di aver ottenuto tutti gli A in CSc.

La cosa che sta programmando è MOLTO DIFFICILE. Molte persone amano pensare di saper programmare, ma non lo fanno.

Alcuni pensieri:

• Non lo terrei contro qualcuno se il loro programma avesse dei bug ma chiaramente avevano l'idea giusta. Il debug fa parte della programmazione.

• Penso che sia triste che così tante persone facciano domanda per un lavoro che non sanno di non poter fare. Mi sembra un problema con l'economia.

• È davvero facile porre alla gente cattive domande, in cui l'unica risposta "corretta" è quella che l'intervistatore darebbe.

Questo test copre molto bene diverse cose che vorrei sapere su un programmatore che potrei assumere:

1. Puoi persino programmare del tutto?
2. Puoi scrivere un programma da zero (perché non tutti possono !!!)
3. Riesci a risolvere un problema senza pensarci troppo .

Per approfondire l'ultimo punto, ci sono innumerevoli soluzioni per ronzio. Vai per leggibilità? Velocità? La brevità? Cerchi di finire di scrivere velocemente il programma? Come un programmatore attacca questo semplice problema è molto significativo. Se un programmatore non può scegliere una soluzione e vederla fino alla fine, cosa ti dice su come questa persona si esibirà in un vero compito?

Sfortunatamente, molte persone con curriculum dall'aspetto impressionante sembrano mancare delle capacità di programmazione di base. Ho visto molti casi in cui le persone che elencano C e C ++ sui loro curriculum non potevano rispondere alle domande di base sui puntatori.

Ci sono due tipi di persone che spero che FizzBuzz mi aiuti ad evitare.

1. Changer con nessuna conoscenza della programmazione o nessuna conoscenza rilevante della programmazione. Di solito puoi riconoscerli dal CV ma non sempre e dare loro una semplice attività di programmazione è un buon modo per chiarire che non sono un programmatore.
2. Laureati Java, che hanno completato un corso di programmazione o una laurea, ma in realtà non sanno come programmare. Queste persone possono essere più difficili da filtrare perché possono parlare di teoria ma non hanno abilità pratiche. Mettere un semplice problema davanti a loro e chiedere una soluzione e una spiegazione della soluzione è un ottimo modo per vedere la differenza tra un Petra Java e un Paula Bean.

In entrambi i casi, non mi interessa davvero un'implementazione perfetta. Il test che devi fare con le persone che fanno domanda per i lavori degli sviluppatori è che possono programmare a tutti.

Detto questo, probabilmente non mi preoccuperei di quel particolare test per diversi motivi ora. In primo luogo è molto noto e uno dei gruppi di cui sopra sarebbe veloce a provarlo. In secondo luogo, preferirei utilizzare le domande sullo schermo del telefono di Steve Yegge per escludere i non programmatori prima che arrivassimo al punto di introdurli. Se qualcuno riconoscesse quelle domande, ciò implicherebbe che avrebbero letto il blog di Steve Yegge che mi suggerirebbe di essere nel l'1% superiore degli sviluppatori che prende sul serio la propria professione e merita sicuramente un colloquio. Allo stesso modo se qualcuno avesse un buon rappresentante qui o su SO sarei propenso a intervistarli.

È difficile credere che gli sviluppatori non possano codificare FizzBuzz fino a quando non vedrai i "nove a venticinque" che copiano e incollano il loro lavoro insieme e cercano di non scrivere scrupolosamente il codice. Non ci potevo credere quando ho sentito uno dei nostri sviluppatori senior insegnare a uno sviluppatore C #, con 3 anni di "esperienza", su come usare un dizionario. Interfacce? Modelli di progettazione? stdout? YAGNI? La mia guida non aveva mai sentito parlare di YAGNI! È incredibile ciò che queste persone non sanno.

Ora ci credo. Penso anche che ci siano troppi sviluppatori che stanno facendo abbastanza.

Penso che parte del motivo per cui sia una domanda così popolare sia perché esiste più di un modo di rispondere, e in base al modo in cui il candidato sceglie di andare può darti un'idea di come codificano. Alcuni ottimi esempi possono essere visti qui se si dispone di un rep di 10K su Stack Overflow.

Per quanto riguarda la statistica del 99%, controlla da dove proviene quel numero. Probabilmente è di parte. Se si basa su programmatori entry-level che intervistano per il loro primo lavoro, allora sì, posso vedere che ciò è possibile, soprattutto se la maggior parte dei loro candidati esce direttamente dal college. Posso effettivamente pensare a qualcuno che probabilmente scriverà una condizione 100 se la dichiarazione come soluzione a quel problema.

Trovo che il 99% dei programmatori non sia in grado di programmare o risolvere un semplice test di codifica sia molto esagerato. Nel caso del test FizzBuzz, o hai riscontrato questo problema in precedenza e puoi risolverlo facilmente con l'operatore modulo oppure non l'hai mai riscontrato prima e dovrai affrontare questa difficoltà. Non dice nulla all'intervistatore sulle tue capacità di programmazione.

Penso che il problema con molti programmatori apparentemente lasciando una brutta impressione durante un'intervista risieda nella natura dei metodi di intervista tecnica. Gli intervistatori si aspettano che i candidati memorizzino e riproducano istantaneamente la sintassi del linguaggio, i dettagli e la complessità computazionale di strutture dati, architetture hardware, schemi di progettazione, ecc. Ecc. L'area dell'informatica / ingegneria del software è vasta. È impossibile e insensibile provare a memorizzare tutto.

Nel mondo reale, la chiave è essere in grado di comprendere il problema di programmazione / progettazione assegnato a te e sapere dove trovare informazioni (il tuo IDE, pagine man, libri, google, ecc.) Come risolvere il tuo problema. Questo è qualcosa per cui gli intervistatori non testano mai.

Sono ancora un programmatore relativamente junior (sto programmando denaro per ~ 2 anni e programmando in qualche modo professionale come responsabilità secondaria per circa 2 prima) quindi usa abbastanza granelli di sale.

Ho una certa esperienza nella realizzazione di una prima schermata per programmatori di un progetto per grandi imprese (sapevamo che il progetto era destinato a fallire, ma ehi, volevano comunque pagare). Come unico programmatore della ditta che stava assumendo, mi è stato affidato il compito di rivedere i curriculum e di selezionare i candidati.

Questo è stato per un progetto di governo in modo che forse probabilmente non attirare i candidati più talentuosi, ma non ho ricevuto una sola applicazione da chiunque abbia un account github che in realtà aveva il codice mostrato, né nessuno che aveva un portafoglio, quindi ho usato FizzBuzz ( letteralmente il problema esatto) come primo passaggio a chiunque sembrasse in grado di programmare.

L'ho preceduto con una pseudo-scusa affermando che sapevo che era stupido, ma che volevo solo vedere qualsiasi codice funzionante e che se lo avessero voluto avrebbero potuto inviare un altro esempio di valore uguale o maggiore o davvero qualsiasi cosa, ma quel fizzbuzz sarebbe sufficiente.

Il risultato: non ho ricevuto una risposta che fosse effettivamente corretta, il che è strabiliante considerando il volume di risposte su Internet. Nessuno si è nemmeno preso la briga di plagiare. Dovevamo semplicemente assumere persone che in precedenza avevano lavorato alle fallite precedenti iterazioni del progetto.

Dopo lo shock iniziale dell'esercizio e la delusione per quanto era complicato il software / contratto del governo, mi sentivo molto meglio delle mie capacità, così piccole vittorie?

Modifica: per non corretto non intendo un errore off-by-one (cioè ho chiesto attraverso 100 non 99) o qualche altro bug innocente che è una soluzione semplice. Voglio dire, non funzionante, o non verrà eseguito / compilato / etc o mostrerà chiaramente che il problema non è stato semplicemente letto e compreso, anche una parte significativa ha ritirato l'applicazione e non uno invece ha inviato un altro codice.