Abbiamo avuto un candidato per un colloquio di livello senior che non ha superato una sfumatura della domanda FizzBuzz ^{1 2} .
Voglio dire, davvero, completamente, completamente fallito la domanda - nemmeno vicino.
Ho anche lui allenato fino alla pensando di usare un ciclo e che 3e 5erano veramente la pena di considerare come casi particolari.

Lo ha fatto esplodere.

Solo per scopi di controllo qualità, ho posto la stessa domanda esatta a tre compagni di squadra; ha dato loro 5 minuti; e poi tornò a raccogliere il loro pseudo-codice. Tutti l'hanno inchiodato e non avevano mai visto la domanda prima. Due hanno chiesto quale fosse il trucco ...

In un esercizio logico diverso, il candidato ha mostrato una certa comprensione di alcune delle funzionalità disponibili nella lingua che ha scelto di usare (C #). Quindi non è come se non avesse mai scritto una riga di codice. Ma la sua logica è ancora bloccata.

La mia domanda è se avrei dovuto dargli o meno la risposta alle domande logiche.

Sapeva di averli fatti esplodere e lo ha riconosciuto più tardi nell'intervista.
D'altra parte, non ha mai chiesto la risposta o quello che mi aspettavo di vedere.

So che gli esercizi di codifica possono essere utilizzati per impostare i candidati all'insuccesso (di nuovo, vedi il secondo link dall'alto). E ho davvero cercato di aiutarlo a casa a rispondere al nocciolo della domanda. Ma questo era un candidato di livello senior e Fizz-Buzz è, francamente, ridicolmente facile anche dopo aver tenuto conto dei nervosismi delle interviste.

Sentivo che avrei dovuto mostrargli un modo di risolvere il problema in modo che potesse almeno imparare dall'esperienza. Ma ancora una volta, non ha chiesto.

Qual è il modo giusto di gestire quella situazione?

² _{Per chiarire, questa è la sfumatura di Fizz-Buzz che ho chiesto ed è dal primo problema di Project Euler . Stampa sostitutiva Fizz | Buzz per la somma dei numeri e hai la stessa domanda fondamentale.
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Write a function that finds the sum of all the multiples of 3 or 5 below 1000.}

³ _{Questa domanda ha attirato più attenzione di quanto mi aspettassi e apprezzo tutte le risposte. Alcune delle risposte successive sono arrivate davvero al nocciolo della mia domanda, quindi permetterò alla community di rivedere e votare prima di assegnare la "risposta".}

⁴ _{Ho selezionato "la" risposta in base ai voti della comunità in quel momento. E penso che la risposta di Yannis sia appropriata per le interviste con i nuovi sviluppatori. Penso che anche la risposta collettiva incentrata sulla mancanza di chiedere la risposta sia esatta.}

La maggior parte delle mie interviste sono state con studenti in cerca di una posizione di tirocinio, e il più delle volte hanno rovinato semplici esercizi (?). Volevo un modo semplice e amichevole per comunicare i loro errori, e quello che mi è venuto in mente era abbastanza semplice: ho risolto gli esercizi da solo e ho mostrato loro le mie soluzioni dopo che avevano finito con i loro.

Ho avuto alcune discussioni estremamente interessanti e rivelatrici con i candidati che sono iniziate confrontando i nostri diversi approcci per risolvere lo stesso problema. Dopo un po 'ho anche anticipato alcuni degli errori, solo controllando a quale scuola frequentava il candidato (alcuni "professori" sono ... idioti). E, bene, nei pochi casi in cui un candidato non è riuscito a trovare alcuna soluzione, ne avevo già dato uno per la prossima volta.

Dare la risposta

Stavo per dire che se il candidato non fosse abbastanza interessato da chiedere, non sprecherei fiato, ma la risposta di @Yannis_Rizos è molto meglio.

Le interviste sono piuttosto veloci. So di cercare spesso le cose per giorni dopo un'intervista.

Persone che non sanno programmare FizzBuzz Classic

Immagino che un grande punto critico sia la consapevolezza dell'operatore%. Si spera che qualcuno possa pensare di confrontare, (myInt / 3) == (myDouble / 3.0)ma forse con lo stress di un'intervista ... Tuttavia, FizzBuzz Classic impone un approccio a forza bruta, inserendolo nella categoria dei problemi di algoritmo più semplici da risolvere. Come suggerimento, hai provato a chiedere alle persone di codificare "Fizz" per mezzo credito e magari aggiungere "Buzz" in seguito come miglioramento?

Penso che la risposta definitiva alla tua domanda sia che è davvero difficile trovare buoni candidati.

Intervista Domande in generale

Ho spesso trovato più facile e più produttivo chiedere ai candidati di descrivere l'ultimo progetto di programmazione di cui erano entusiasti. Ho avuto il 100% di successo con questa domanda, il che significa che le persone che parlavano animatamente di un progetto di programmazione e potevano rispondere a domande tecniche su questo erano grandi assunzioni e quelli che non potevano, non lo erano. Ciò ha i piacevoli effetti collaterali di mettere a proprio agio il candidato e incoraggiare una discussione aperta. Con questa domanda, il candidato ti dirà in effetti per cosa sono più adatti.

Forse in un think tank sono necessarie anche domande, ma le ho abbandonate a favore della domanda sul "progetto preferito".

Somma (Figlio) di FizzBuzz

La tua domanda di intervista non è equivalente a FizzBuzz:

Se elenchiamo tutti i numeri naturali sotto 10 che sono multipli di 3 o 5, otteniamo 3, 5, 6 e 9. La somma di questi multipli è 23. Scrivi una funzione che trova la somma di tutti i multipli di 3 o 5 inferiore a 1000.

Laddove FizzBuzz Classic ti costringe a passare attraverso n iterazioni (per stampare tutti i numeri o Fizz / Buzz), il tuo problema può essere risolto in n / 5 + n / 3 + n / 15 iterazioni, o anche senza iterazioni - una correzione diretta- il calcolo del punto è possibile. Il seguente programma confronta questi tre metodi:

public static void main(String[] args) {
  long n = Long.valueOf(args[0]).longValue();
  long sum = 0;
  long ms = System.currentTimeMillis();
  // Brute force method  Performance: cn
  for (long i = 1; i <= n; i++) {
    if ((i % 3) == 0) { sum += i;
    } else if ((i % 5) == 0) { sum += i; }
  }
  System.out.print("Brute force sum:    " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Second solution: iterate through only numbers we are
  // interested in.  Performance: c * (n/3 + n/5 + n/15)
  // We counted multiples of 15 twice, so subtract one of them
  sum = countSum(n, 3) + countSum(n, 5) - countSum(n, 15);
  System.out.print("Only multiples sum: " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
  ms = System.currentTimeMillis();

  // Third solution: Use high school algebra.  Performance: c
  sum = sumSeries(n, 3) + sumSeries(n, 5) - sumSeries(n, 15);
  System.out.print("Sum of series:      " + sum);
  System.out.println(" time: " + (System.currentTimeMillis() - ms));
}

// Iteravely sum all multiples of skip
private static long countSum(long n, long skip) {
  long skipTotal = skip;
  long grandTotal = 0;
  while (skipTotal <= n) {
    grandTotal += skipTotal; skipTotal += skip;
  }
  return grandTotal;
}

// Thanks to @Caleb for pointing this out!  High school algebra
// tells us that the sum of a series is: (n * (a1 + an)) / 2
// where a1 is the first term and an is the nth term.  E.g. The
// sum of a series of 3 is: (n/3 * (3 + n - (n % 3))) / 2
// Since we are thinking about performance here, we'll shift
// right one instead of dividing by 2 for style points.  ;-D
private static long sumSeries(long n, long skip) {
  return (n/skip * (skip + n - (n % skip))) >> 1;
}

Uscita (somma di FizzBuzz <1000):

$JDK_HOME/bin/java FizzBuzzNot 999
Brute force sum:    233168 time: 0
Only multiples sum: 233168 time: 0
Sum of series:      233168 time: 0

Con una n più grande per il confronto delle prestazioni:

$JDK_HOME/bin/java FizzBuzzNot 1000000000
Brute force sum:    233333334166666668 time: 4744
Only multiples sum: 233333334166666668 time: 818
Sum of series:      233333334166666668 time: 0

Nota a coloro che hanno votato in negativo come fuori tema

Il punto di presentare una soluzione a questa domanda è mostrare che mentre la soluzione della forza bruta a Sum di FizzBuzz è simile a FizzBuzz Classic, sono disponibili soluzioni migliori al problema di Sum, rendendolo un problema fondamentalmente diverso. La somma di FizzBuzz è estremamente complicata se non ricordi la formula corretta per la somma di una serie o non ti rendi conto che si applica quando passi di 3 o 5.

Se si ricava la formula per la somma di una serie dividendo la serie a metà, invertendo la metà e accoppiandoli, si ottiene (n + 1) (n / 2) che può portarti lungo un percorso davvero disordinato per quanto riguarda la divisione intera e i resti troncati. La versione (n (a1 + an)) / 2 di questa formula è assolutamente critica per una risposta semplice per tutti i valori di n.

Sentivo che avrei dovuto mostrargli un modo di risolvere il problema in modo che potesse almeno imparare dall'esperienza. Ma ancora una volta, non ha chiesto. Qual è il modo giusto di gestire quella situazione?

Non mi interessa il livello dell'intervista, e nemmeno se si tratta di una domanda di livello "FizzBuzz" o di una domanda avanzata. Se chiedi a un candidato di risolvere una domanda e loro non possono, ma non preoccuparti nemmeno di chiederti la risposta giusta, allora non valgono il tuo tempo. Come nel mondo potresti essere così intellettualmente pigro?!?

E anche se puzzi totalmente come programmatore e stai solo cercando di farti strada in un lavoro, perché non dovresti almeno essere così pragmatico da ottenere la risposta giusta ora, in modo da conoscerla per la prossima intervista?

Quindi no, non dovresti "dare" la risposta, ma dovresti aspettarti che il candidato insista nel sentire la risposta giusta dopo aver fallito. In caso contrario, è un'enorme bandiera rossa nel mio libro.

Se qualcuno ha fatto saltare FizzBuzz in un'intervista Dev di livello junior perché non riuscivano a ricordare l'operatore del modulo e non potevano semplicemente andare avanti senza di essa, ma poi si sono tutti appassionati di rifarlo dopo aver spiegato la risposta giusta, o almeno parlare con te con il codice giusto, quindi è quasi come rispondere correttamente.

Ho digitato fizzbuzz mentre ero al telefono con l'intervistatore durante una pre-schermata. Questo è qualcosa che, anche se non tutti hanno sentito parlare, dovresti essere in grado di metterci insieme dopo un semestre di lavoro, ma sicuramente dopo aver acquisito lo status di "senior".

Non c'è davvero alcun recupero dal non poterlo fare. È uno di quei fastidi necessari di cui hai bisogno per toglierti di mezzo per ogni evenienza.

Direi che ha senso consegnare come pre-schermo in modo da non perdere tempo a portarli sul posto per un'intervista.

L'ho persino istruito a pensare di usare un loop e che 3 e 5 valevano davvero la pena di essere considerati casi speciali.

Sarebbe interessante sapere cosa si pensi che la risposta "corretta" alla tua domanda FizzBuzz-ish è. Da dove mi siedo, uno buono (in C) scritto sulla lettera della tua domanda è:

int f(void) {
    // sum the multiples of 3 and of 5 and subtract multiples of 15 so we don't count them twice
    return ((1000/3)/2)*(999+3) + ((1000/5)/2)*(995+5) - ((1000/15)/2)*(990+15);
}

Uno migliore potrebbe essere:

Perché diamine scriveresti un programma per farlo quando puoi calcolarlo direttamente?

Il punto è che esiste più di un modo per scuoiare un gatto e il fatto che il candidato in questione non abbia immediatamente iniziato a scrivere forloop e modoperatori non significa che sia stupido. Se vuoi sapere cosa sa il candidato, discuti del problema: scopri cosa sta pensando. Se è bloccato o confuso, scopri dove e perché. Potrebbe condurti ad un approccio che non hai mai considerato.

La mia domanda è se avrei dovuto dargli o meno la risposta alle domande logiche.

Come intervistatore, non è il tuo posto per dare una lezione al candidato . Se davvero non sanno come scrivere il codice, non è assolutamente necessario metterli in imbarazzo soffermandosi su quanto non sanno. Se sono abbastanza interessati da chiedere, allora sentiti libero di condividere. Altrimenti, completa l'intervista, ringraziali per il loro tempo e passa al candidato successivo.

Il tuo "problema" è che sei un essere umano empatico, quindi è difficile guardare qualcuno alle prese con un problema a cui conosci la risposta (questo è anche un problema se conduci studi di usabilità). Dal punto di vista del dovere di intervistatore, non sei in alcun modo obbligato a insegnare all'intervistato come programmare o risolvere i problemi, o la soluzione a un problema che chiedi.

Quando istruisci un intervistato, non è così che possano ottenere la risposta giusta. È così che puoi vedere se non riescono davvero a risolvere il problema o se sono appena stati bloccati da uno o due errori o incomprensioni.

Quindi, se vuoi dare a un intervistato la soluzione dopo il fatto, lo stai facendo solo per te stesso. In generale, preferirei usare quel tempo per consentire all'intervistato di tentare un altro problema. Ma un programmatore "senior" che non può rispondere a FizzBuzz è probabilmente fuori dalla lista. Se decidi di dare soluzioni assicurati di non ingannarti nel pensare che l'intervista sia andata meglio di quanto non abbia fatto (se ti ritrovi a pensare "non è stato in grado di risolvere il problema, ma quando l'ho spiegato lo ha capito bene", quindi sei su un sentiero pericoloso).

E sì, sono stato un intervistato che era sopra la sua testa e non poteva nemmeno fare il primo tentativo di risolvere un problema di intervista. Ciò significava semplicemente che avevo bisogno di imparare molto di più per perseguire un lavoro in quel campo.

Ottenere la risposta giusta non è la parte importante di questo test. Quello che stai misurando è l'approccio di qualcuno al problem solving, il modo in cui si impegnano con la domanda, qualsiasi cosa creativa o interessante che escogitano lungo il percorso; quel genere di cose. Anche se ottengono la risposta sbagliata, potrebbero comunque essere fattibili secondo questi criteri.

OK, non sapendo che l'operatore mod è ingiustificabile, e secondo le metriche che ho dato a questo candidato sembra essere ancora un annullamento, ma non credo che dare la risposta giusta a questo candidato sarà di alcun beneficiare.

Questo dipende dalla tua opinione personale da qui. Vuoi fornire un feedback sull'intervista al fine di aiutare il candidato a fare meglio nelle interviste future (e in modo che i futuri intervistatori non debbano subire ciò che hai appena passato)? In tal caso, inserisci il tuo feedback nei termini che ho appena delineato sopra: digli che non si tratta solo della risposta giusta, ma del modo in cui lavorano per arrivare alla risposta è un fattore critico.

Sentivo che avrei dovuto mostrargli un modo di risolvere il problema in modo che potesse almeno imparare dall'esperienza. Ma ancora una volta, non ha chiesto. Qual è il modo giusto di gestire quella situazione?

Per come la vedo io, non c'è situazione da gestire. Supponendo che tu abbia respinto la sua candidatura, la (apparente) mancanza di interesse del candidato non è qualcosa di cui devi preoccuparti.

Anzi, anche se glielo chiedesse, non gli devi una spiegazione. E se ne hai parlato con i tuoi responsabili delle risorse umane, potrebbero consigliarti che ulteriori discussioni con il candidato sono sconsigliabili per motivi legali.

Vale anche la pena notare che il problema FizzBuzz ha diverse risposte "migliori" a seconda di come lo chiedi. Se chiedi la soluzione "più semplice" e la soluzione "più efficiente", le risposte migliori sono radicalmente diverse. E questo può colorare il tuo giudizio ingiustamente ... se non eri chiaro nel modo in cui hai posto la domanda. (D'altra parte, un candidato buono / esperto avrebbe la lungimiranza di chiarire che prima di iniziare a programmare ...)

Per rispondere alla tua domanda, no non darei la risposta. Se la persona vuole essere un ingegnere del software migliore, troverà la risposta. Se dai loro una risposta, li stai derubando di questa opportunità.

La domanda più rilevante è quando puoi definirti uno sviluppatore senior? Questo varia tra organizzazioni e paesi. Ad esempio, una società con cui ho lavorato ha considerato ingegneri del software con 5 anni di esperienza come senior. Non c'era enfasi sulla qualità dell'esperienza, solo la lunghezza.

Fino a quando non creeremo uno standard che categorizzerà tutti gli ingegneri del software, indipendentemente dalla loro lingua, rimarremo con l'individuo che decide il livello delle loro abilità. E continueremo a sentire di "Ingegneri senior" che non superano il test di abilità più rudimentale.

Un paio di settimane fa è stata posta la domanda "Quando dovresti definirti uno sviluppatore senior" . Ho anche scritto un post sul blog sull'argomento.