Efficacia di FizzBuzz e Beyond [chiuso]

Come parte del processo di intervista, inizialmente chiediamo ai candidati di fare 'FizzBuzz' al giorno d'oggi la percentuale di candidati che possono rispondere correttamente a FizzBuzz è aumentata drammaticamente - questo potrebbe essere dovuto alla sua popolarità sul web.

Circa un anno fa, come seconda domanda, abbiamo iniziato a porre una domanda molto simile all'originale FizzBuzz. La domanda è stata progettata per essere semplice come l'originale FizzBuzz e per valutare anche una particolare abilità del candidato, in particolare la capacità di ordinare e dare priorità in modo significativo e logico una serie di "regole commerciali" che sono state fornite in alcuni ordine arbitrario. La formulazione della domanda inizialmente sembra leggermente ambigua, il che può rendere difficile per chi non parla inglese nativo, ma se il pensiero può essere risolto correttamente - Inoltre offre al candidato l'opportunità di porre domande per chiarimenti, il che è sempre una buona cosa .

Riteniamo che sia una competenza molto importante avere come sviluppatore, poiché lo sviluppo del software si basa in genere su requisiti funzionali che non sono derivati ​​in un ordine particolare nel tempo, che possono imporre vincoli e condizioni su altre aree del software senza indicare esplicitamente ed è il compito dello sviluppatore astuto di investigare almeno potenziali problemi e conflitti per quanto riguarda l'implementazione.

Quello che abbiamo scoperto è che poco più del 65% dei candidati (dimensione del campione di 38) che hanno superato FizzBuzz ha fallito completamente FizzBuzz v2.0 Normalmente questi candidati sarebbero stati rilevati più avanti nel processo, ma sembra essere un buon modo per rilevare presto.

La mia domanda non riguarda se FizzBuzz è obsoleto, ma piuttosto quali fattori potrebbero contribuire a un numero così elevato di candidati che non hanno superato la domanda FizzBuzz v2.

• La domanda è troppo ambigua?
• Lo stress dell'ambiente di un colloquio riduce la capacità di pensare in modo critico al punto da non riuscire a completare un compito così banale?

Domanda:

Scrivi una routine nel tuo linguaggio di programmazione preferito che prenderà un elenco di stringhe come input e per ciascuna stringa nell'elenco eseguirà una delle seguenti operazioni:

1. Stampa solo Fizz se la stringa contiene la lettera A
2. Stampa solo Buzz se la stringa contiene la lettera B
3. Stampa solo BuzzBuzz se la stringa contiene sia A che B
4. Stampa solo FizzFizz se la stringa non contiene sia A che B
5. Stampa solo FizzBuzz se la stringa contiene solo una A e solo una B.

Alcune domande tipiche poste dai candidati sono:

• Dovrebbe essere case sensitive?
• "Contiene A e B" significa che A dovrebbe precedere B
• Cosa dovrebbe essere stampato se nessuno dei punti è soddisfatto?
• Cosa dovrebbe accadere se è possibile soddisfare più di una condizione?

Abbiamo scoperto che la stragrande maggioranza dei candidati che hanno completato con successo la domanda, non hanno fatto nulla, hanno semplicemente fatto come FizzBuzz.

Ha il potenziale per essere un test molto migliore rispetto a FIZZBUZZ, ma se hai un'idea di una risposta corretta, è il peggior test al mondo. Questi test hanno pochissimo valore nelle interviste per cominciare.

Se un candidato risponde "correttamente" senza fare una domanda, allora hai un problema che la selezione del candidato selezionerà il tipo sbagliato di programmatore. Non è in grado di identificare requisiti ambigui o non è in grado di comprendere che la maggior parte delle persone non può scrivere requisiti non ambigui . Non importa se il programma è tecnicamente perfetto in ogni aspetto, è probabile che sia il tipo di ragazzo che fornirà software con un "Non mi interessa che non sia quello che volevi, è quello che hai chiesto".

La parte del test qui è l'ordine di priorità delle regole. Non lo specifichi. L'immissione "ABC" può stampare Fizz, Buzz, BuzzBuzz o FizzBuzz - ognuno di questi è corretto

Il candidato che prenderei è colui che l'ha capito (per lo più) giusto, ma ha fatto molte domande e, idealmente, ha fatto molti "scherzi" sulla lavagna.

Ad esempio, esplorerei la mia comprensione di tali requisiti dandoti una serie di testi di esempio e chiedendoti cosa ti aspettavi di essere stampato e perché. - La discussione sul mio input di esempio "ABC" dovrebbe portare ad alcuni insiti utili per te.

Proprio come FIZZBUZZ, il risultato di questo test è buono solo quanto le tue osservazioni fatte su come è stato ottenuto il risultato - il risultato è irrilevante.

Vorrei modificarlo un po '- solo per renderlo più interessante - togliere l' "unico". È coperto nella riga sopra ("stampa una delle seguenti") e vedi quante persone lo chiedono. Se al candidato manca il "solo" e hai tempo, segnalalo e vedi cosa succede. Se si occupa del "solo", rimuoverlo dal requisito e farli cambiare il codice.

La parola "solo" nelle tue esigenze crea una contraddizione in tutte le domande.

Quindi la tua domanda verifica i requisiti che si raccolgono quando sei sotto pressione, sei sicuro di voler testare quella combinazione di abilità?

Se vuoi testare la raccolta dei requisiti, suggerirei di rendere ambigua una delle domande. Se si desidera una sostituzione per FizzBuzz, rimuovere l'ambiguità.

La definizione delle priorità delle regole di business può essere eseguita solo con conoscenze specifiche del dominio, a meno che non si includa un semplice contesto per ciò che si sta facendo (forse sono coupon da riscattare per vari valori), non c'è base per lo sviluppatore di prendere una propria decisione.

Ma richiedere a qualcuno di chiedere chiarimenti in merito al fatto che ciò comporti un rischio significativo di risultati indesiderati, non è forse il modo migliore per valutare la propria abilità nel riconoscere i limiti delle proprie conoscenze. Potrebbero pensare che sia più sicuro indovinare e sbagliare, piuttosto che sottolineare che sei incompetente nel scrivere i requisiti, o se nessuno degli intervistatori è uno sviluppatore, essendo etichettato con un cattivo atteggiamento.

Abbiamo scoperto che la stragrande maggioranza dei candidati che hanno completato con successo la domanda, non hanno fatto nulla, hanno semplicemente fatto come FizzBuzz.

Con l'ambiguità dei requisiti non è possibile completare correttamente v2.0 senza fare domande.

Se si desidera rimuovere qualsiasi ambiguità, è possibile modificare i requisiti in:

Scrivi una routine nel tuo linguaggio di programmazione preferito che prenderà un elenco di stringhe come input e per ogni stringa nell'elenco esegui quanto segue:

1. Stampa "Fizz" se la stringa contiene il carattere "$" e non contiene "?".
2. Stampa "Buzz" se la stringa contiene il carattere '?' e non contiene '$'.
3. Stampa "FizzBuzz" se la stringa contiene esattamente un '$' e esattamente un '?'.
4. Stampa "BuzzBuzz" se la stringa contiene esattamente un '$' e più di uno '?'.
5. Stampa "BuzzBuzz" se la stringa contiene esattamente un '?' e più di un '$'.
6. Stampa "FizzFizz" se la stringa non contiene '$' e non contiene '?'.

La domanda è troppo ambigua?

Sì, la domanda è troppo ambigua per rispondere senza chiarimenti. Tuttavia, una regola aggiuntiva che dice che nei casi in cui si applicano più regole, il tuo programma dovrebbe scegliere la cosa più specifica, dovrebbe rimuovere l'ambiguità.

Lo stress dell'ambiente di un colloquio riduce la capacità di pensare in modo critico al punto da non riuscire a completare un compito così banale?

È più probabile un'indicazione del candidato "stipare" il FizzBuzz: stress o no, il programma è molto semplice.

Penso che il FizzBuzz modificato non sia paragonabile a quello originale, perché la sua soluzione ideale è diversa: sebbene una catena di if-then-elseresti accettabile, penso che una soluzione basata su tabella sia più appropriata per questo problema:

static string[,] FB = new string[3,3] {
    {"FizzFizz", "Buzz", "Buzz"}
,   {"Fizz", "FizzBuzz", "BuzzBuzz"}
,   {"Fizz", "BuzzBuzz", "BuzzBuzz"}
};
static string FizzBuzz(string str) {
    return FB[
        Math.Min(str.Count(c => c == 'a'), 2)
    ,   Math.Min(str.Count(c => c == 'b'), 2)
    ];
}

La dimensione dello spazio problematico 3x3non è 2x2, quindi si associa a una tabella molto più facilmente rispetto all'originale FizzBuzz. In effetti, trovo più difficile da capire una soluzione basata su tabella al problema originale di FizzBuzz .

private static string[] FB = new[] {"{0}", "Fizz", "Buzz", "BizzBuzz"};
public static void Main() {
    for (var i = 1 ; i <= 100 ; i++) {
        Console.WriteLine(FB[(i%5==0?2:0)+(i%3==0?1:0)], i);
    }
}

Due cose qui:

1. sì, penso che la maggior parte delle persone abbia solo googled ronzio di alcol e poi inciampano quando provano ad espanderlo
2. Dai un'occhiata a: http://dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html Spiega bene come risolvere il ronzio del fizz usando le astrazioni appropriate.

Abbiamo scoperto che la stragrande maggioranza dei candidati che hanno completato con successo la domanda, non hanno fatto nulla, hanno semplicemente fatto come FizzBuzz.

Ho visto processi di intervista che incoraggiano i programmatori a pensare ad alta voce e fare domande per vedere il loro processo di pensiero. Mi piace meglio questo processo.

Ho letto questo fizzbuzz v2.0 e lì avrei chiesto dei requisiti n. 3 e n. 5. Non conosco altre persone ma trovo in ingegneria che non voglio alcuna ambiguità, quindi faccio una domanda. Perché più avanti (codificato e tutto il resto), non voglio scoprire che dovevo fare un'ipotesi ed era sbagliato.

Forse il modo più semplice per evitare l'ambiguità è mostrare alcuni esempi:

"A" restituisce "Fizz" "aAbA" restituisce "Fizz" "B" restituisce "Buzz" "aBbB" restituisce "Buzz" "AB" restituisce "FizzBuzz" "ABaabb" restituisce "BuzzBuzz" "" restituisce "FizzFizz" "ab "restituisce" FizzFizz "

Invece di dare a un candidato requisiti contraddittori / poco chiari, basta chiedere loro come gestiscono quelle situazioni. Altrimenti ti stai facendo sembrare incompetente o peggio, mettendo le persone competenti sulla trave del tradimento di "come posso ottenere le risposte di cui ho bisogno senza implicare che questa domanda di intervista o la persona che la pone sia stupida?"

In entrambi i casi, è irritante come tutti quelli che escono. Le interviste sono un processo di abbinamento e con ciò intendo una strada a doppio senso. Le domande dirette e la chiarezza di intenti sono molto più importanti che mettere il candidato sotto una pentola a pressione, IMO. FizzBuzz è un buon esempio di domanda di programmazione perché è breve e dolce. Non riutilizzarlo direttamente. Scrivi domande semplici come questa che seguono quel modello.

Ma per FFS non fatevi furbi e nascondete il vero test dietro un altro test. Basta chiedere alla gente come gestiscono questo dannato problema. Uno sviluppatore esperto avrà affrontato ripetutamente requisiti ambigui e sarà lieto di raccontarvi le loro strategie. Potresti persino imparare qualcosa.

E non dare per scontato che tutti vogliano usare una lavagna o un periodo di scrittura a mano comodo. Alcuni di noi scrivono da quando avevamo 12 anni (grazie mille a Space Quest). Non riesco nemmeno a pensare dritto con una penna o un pennarello in mano. Sono le 20 e la 13, cosa c'è già con le lavagne? Quando le persone mi consegnano carta e penna e mi chiedono di fare un test del codice, è difficile reprimere una risata.

Penso che sia una bella domanda per l'intervista. I requisiti non sono chiari, come spesso accade nella realtà. Verifichi se il candidato è abbastanza intelligente da rendersene conto (anche sotto stress), che non ha paura di porre le domande che ritiene necessarie ed è in grado di mettere i requisiti in una struttura ragionevole. E racconta un po 'delle loro capacità di programmazione, anche se dovresti anche porre alcuni problemi più complicati che contengono ricorsione e puntatori, poiché questo problema è troppo facile.

Tuttavia, mi preoccupo un po 'che i candidati "di successo" non facciano domande. Proverei a scoprire se hanno realizzato che in alcuni casi è possibile applicare fino a 4 delle regole e che nella domanda non c'è nulla che possa risolvere tale ambiguità e chiedere loro di spiegare come hanno affrontato la questione. Forse la tua domanda non è abbastanza ambigua per costringerli a chiedere, o forse dovresti chiedere loro di pensare ad alta voce.

A proposito: trovo strano che tu stia parlando di una "soluzione corretta". Se pronunci la domanda in questo modo, è legittimo stampare "Fizz", "Buzz", "BuzzBuzz" o "FizzBuzz" se ottieni "AB". Quindi IMHO qualsiasi soluzione senza domande è chiaramente sbagliata.