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 facile 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 aver finito con la loro.

Ho avuto un paio di discussioni estremamente interessanti e rivelanti con i candidati che hanno iniziato confrontando i nostri diversi approcci per risolvere lo stesso problema. Dopo un po 'ho persino anticipato alcuni degli errori, semplicemente controllando a quale scuola il candidato stava partecipando (alcuni "professori" sono ... idioti). E, beh, nei pochi casi in cui un candidato non è riuscito a trovare una soluzione, ne avevo già dato uno per la prossima volta.

Dando la risposta

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

Le interviste sono piuttosto rapide. So che spesso guardo le cose per giorni dopo un'intervista.

Persone che non possono codificare FizzBuzz Classic

Immagino che un grosso ostacolo sia l'essere consapevoli dell'operatore%. Speri che qualcuno possa pensare di confrontare (myInt / 3) == (myDouble / 3.0) ma forse con lo stress di un'intervista ... Tuttavia, FizzBuzz Classic forza un approccio a forza bruta, mettendolo nella categoria dei problemi dell'algoritmo più facili da risolvere. Come suggerimento, hai provato a chiedere alle persone di codificare semplicemente "Fizz" per l'half-credit e magari aggiungere "Buzz" in seguito come miglioramento?

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

Domande dell'intervista 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 hanno parlato animatamente di un progetto di programmazione e che potevano rispondere a domande tecniche a riguardo erano grandi assunzioni e coloro che non potevano farlo non lo erano. Questo ha i piacevoli effetti collaterali di mettere il candidato a suo agio e incoraggiare discussioni aperte. Con questa domanda, il candidato ti dirà in effetti a cosa sono più adatti.

Forse sono necessarie anche le domande dell'algoritmo di think tank, ma le ho abbandonate a favore della domanda "progetto preferito".

Sum (Son) di FizzBuzz

La tua domanda di intervista non è equivalente a FizzBuzz:

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.

Dove FizzBuzz Classic ti costringe a passare attraverso iterazioni n (per stampare ogni numero o Fizz / Buzz), il tuo problema può essere fatto in n / 5 + < em> n / 3 + n / 15 iterazioni, o anche senza iterazioni: è possibile un calcolo diretto a virgola fissa. 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;
}

Output (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 un 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 basso come off-topic

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

Se ridisci la formula per la somma di una serie dividendo la serie a metà, invertendone una metà e abbinandole, ottieni (n + 1) (n / 2) che ti può portare giù il percorso veramente disordinato per quanto riguarda la divisione intera e i resti troncati. La versione (n (a1 + an)) / 2 di questa formula è assolutamente fondamentale per una risposta semplice per tutti i valori di n.

I felt like I should have shown him a way of solving the problem so that he could at least learn from the experience. But again, he didn't ask. What's the right way to handle that situation?

Non mi interessa a che livello è l'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 ti preoccupare nemmeno di chiederti la risposta giusta , allora non valgono il tuo tempo. Come diavolo potresti essere così intellettualmente pigro?!?

E anche se sei totalmente puzzolente come programmatore e stai solo cercando di inserirti in un lavoro, perché non dovresti essere così pragmatico da ottenere la risposta giusta ora, in modo che tu lo sappia per il prossimo intervistare?

Quindi no, non dovresti "dare" la risposta, ma dovresti aspettarti che il candidato insista nel sentire la risposta giusta dopo che falliscono. Se non lo fanno, è un'enorme bandiera rossa nel mio libro.

Se qualcuno ha fatto esplodere FizzBuzz in un intervista di livello junior Dev, perché non potevano ricordare l'operatore modulo e semplicemente non potevano portarsi avanti senza di esso, ma poi si sono appassionate a rifarlo una volta che hai spiegato il risposta giusta, o almeno parlando con il codice giusto con te, allora è quasi buono come rispondere correttamente.

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

Non c'è davvero alcun recupero dal non essere in grado di farlo. È uno di quei fastidi necessari che è necessario togliersi di mezzo per ogni evenienza.

Direi che ha senso consegnare come pre-schermo in modo da non sprecare il tempo di tutti per portarli sul posto per un colloquio.

I even coached him through to thinking about using a loop and that 3 and 5 were really worth considering as special cases.

Sarebbe interessante sapere che tu pensi che sia la risposta "corretta" alla tua domanda su FizzBuzz. Da dove mi siedo, una buona (in C) scritta 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);
}

Una migliore potrebbe essere:

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

Il punto è che c'è più di un modo per skinare un gatto, e il fatto che il candidato in questione non abbia immediatamente iniziato a scrivere for loops e mod operatori non significa che sia stupido. Se vuoi sapere che cosa sa il candidato, discuti il problema: scopri cosa sta pensando. Se è bloccato o confuso, scopri dove e perché. Potrebbe portarti a un approccio che non hai mai considerato.

My question is whether or not I should have given him the answer to the logic questions.

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

Il tuo "problema" è che sei un umano empatico, quindi è difficile guardare qualcuno che lotta con un problema a cui si conosce la risposta (anche questo è un problema se si eseguono studi di usabilità). Dal punto di vista dei doveri come 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 davvero non sono in grado di risolvere il problema o se sono stati bloccati da uno o due errori o incomprensioni.

Quindi se vuoi dare all'intervistato la soluzione dopo il fatto, lo fai solo per te stesso. In generale, preferisco usare quel tempo per consentire all'intervistato di provare 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 illuderti di pensare che l'intervista sia andata meglio di quello che ha fatto (se ti trovi 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 fuori di testa e non riuscivo nemmeno a fare il primo tentativo di risolvere un problema con un colloquio. 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 escano lungo la strada; quel tipo di cose. Anche se ottengono la risposta sbagliata, potrebbero comunque essere validi secondo questi criteri.

OK, non sapendo che l'operatore mod è imperdonabile, e dalle metriche che ho dato a questo candidato sembra essere ancora un write-off, ma non credo che solo dando la risposta giusta a questo candidato stia per essere di qualsiasi beneficio.

Questo dipende dalla tua opinione personale da qui. Vuoi dare un feedback all'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 vissuto)? In tal caso, aggiungi il tuo feedback nei termini che ho appena delineato sopra: dì loro che non è solo la risposta giusta, ma il modo in cui funzionano per arrivare alla risposta è un fattore critico.

I felt like I should have shown him a way of solving the problem so that he could at least learn from the experience. But again, he didn't ask. What's the right way to handle that situation?

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

Infatti, anche se ha chiesto, non gli devi lui una spiegazione. E se hai parlato con le tue risorse umane su questo argomento, potrebbero consigliarti che ulteriori discussioni con il candidato non sono giustificabili per motivi legali.

Vale anche la pena notare che il problema di FizzBuzz ha diverse "migliori" risposte 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 sei chiaro nel modo in cui hai posto la domanda. (D'altro canto, un candidato buono / esperto avrebbe la lungimiranza di chiarire che prima di iniziare a scrivere codice ...)

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 la risposta, li stai derubando di questa opportunità.

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

Finché non creeremo uno standard che classificherà tutti gli ingegneri del software indipendentemente dalla loro lingua, rimarremo con l'individuo che decide il livello delle sue competenze. E continueremo a sentire gli "Ingegneri Senior" che non hanno superato il test di abilità più rudimentale.

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