Ho fallito FizzBuzz, mi assumeresti? [chiuso]

Sono uno sviluppatore con una laurea in CS e ho esperienza lavorativa facendo sviluppo in diverse lingue per quasi 3 anni.

Oggi ho avuto un colloquio, nel complesso è andato abbastanza bene, mi sono preparato per la maggior parte delle domande e mi sono sentito pronto a tutto. Alla fine dell'intervista, mi hanno posto UNA domanda di programmazione ... un problema come FizzBuzz (senza la stampa della parte numerica). Credo di aver fatto troppi errori e di averlo "fallito". Tutta la speranza è persa per me?

Ecco il mio codice:

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

Come puoi vedere ho incasinato i bool che dovrebbero avere la sintassi i% 3 == 0; Se ricordo bene la domanda, metto anche un altro invece di un altro con isThree && isFive. Ero abbastanza stressato, ma questa non è una scusa per perdere un semplice problema.

Quindi la domanda è: quanto è importante essere in grado di produrre un codice funzionante sul posto rispetto ad altri fattori, come l'esperienza e la personalità? Ad esempio, il codice di cui sopra sarebbe un rompicapo?

Il punto di FizzBuzz è mostrare che in realtà sai come programmare , non che hai memorizzato tutte le regole di sintassi più fini della lingua in cui ti è stato chiesto di programmare (anche se questo è importante, se vogliono sapere quanto vissuto sei nella lingua).

Se sei arrivato così lontano nello stress di un ambiente di intervista e puoi dimostrare di aver compreso gli errori che hai commesso, direi che hai superato.

sì

La maggior parte delle persone che ho intervistato che hanno fallito la parte di esercitazione del codice sulla sintassi minore o leggermente fuori logica hanno finito per essere i migliori assunti.

Ottenere l'idea di base della logica (cosa che hai fatto) e convertirla in qualcosa di decente e conciso dal punto di vista del codice (cosa che penso che tu abbia fatto per lo più) è molto più importante per me che ottenerla assolutamente perfetta.

Compro un IDE per il suo controllo della sintassi, non assumere un dev per questo, e avresti realizzato gli altri errori in pochi istanti del tuo primo debug.

Sei passato dal requisito iniziale a un primo tentativo abbastanza direttamente e senza fare nulla di terribile. Ciò è più prezioso in molti ambienti della perfezione in assenza di feedback. Se il datore di lavoro è così aggrappato ai dettagli che hai perso, potrebbe comunque essere un segnale dell'ambiente a venire.

Se l'attività fosse la variante dei numeri di stampa, la mancanza dei dettagli sarebbe un po 'brutta, ma non avrebbe abbastanza peso per cambiare la mia decisione se mi piacessi per la posizione altrimenti.

[Modifica] Come ha sottolineato Alex, c'è anche l'aspetto della reazione e della compostezza. Personalmente cerco di toglierlo di mezzo prima di arrivare agli esercizi pratici cercando di angolare l'intervistato su qualcosa un po 'al di fuori della loro esperienza, ma alcuni potrebbero scegliere di combinare i due. Ogni tanto mi sono imbattuto in qualcuno che ha solo una conoscenza dei libri di testo e naviga attraverso le questioni teoriche e di fondo, ma mi viene seriamente da dove iniziare con l'esercizio pratico. Alcuni non riescono nemmeno a capire da dove cominciare.

Queste persone sono ESATTAMENTE ciò che desidero eliminare con questo esercizio.

Quindi, a meno che tu non abbia impiegato 20 minuti per fare in modo che l'intervistatore chiarisca il requisito, immagino che la tua soluzione sia stata più o meno il tuo primo tentativo con forse un paio di correzioni man mano che procedi. Se hai ottenuto ciò che hai messo sopra in meno di 5 minuti, hai dimostrato di poter pensare abbastanza ai miei standard.

Il codice di cui sopra probabilmente sarebbe un punto di rottura per me se non avessi qualcos'altro da fare. Se seguono lo stile dell'intervista con Microsoft, probabilmente la persona che ti ha fatto questa domanda ti bloccherà e spesso ne basta uno.

Ciò che mi sconcerta è che l'intervistatore non ti ha chiesto questo codice. Un buon intervistatore ha visto abbastanza del proprio codice per sapere che le persone commettono errori, soprattutto quando hanno fretta. Di solito dicono "Ora vedi qualcosa di sbagliato in questo codice?" "No? Beh proviamolo". Vengono forniti alcuni set di risultati e quindi viene eseguito attraverso la funzione. Quindi dici "Oh merda, non ha funzionato." "Ok, come lo aggiusteresti ..." e così via. Se sopravvivi a quel dialogo, in realtà è abbastanza impressionante e dimostra una capacità di pensare in modo critico, elaborare casi di test ed eseguire il debug del tuo codice.

Inoltre, di solito non sono alla ricerca di "codice funzionante". Chi lo produce comunque il primo tentativo? Ma logicamente corretto con la gestione degli errori e buoni set di test è un buon obiettivo.

Inoltre, questo potrebbe sorprenderti, ma stai competendo con molte persone che non possono nemmeno iniziare a usare fizzbuzz. Tendiamo a supporre che tutti gli altri stiano attraversando b + alberi nel loro sonno .... ma in realtà, non riescono nemmeno a capire multipli di 3 e 5 e usano un operatore di modulo. Potresti essere piacevolmente sorpreso da quanto hai fatto meglio degli altri candidati.

Il mio consiglio, basta spazzarlo via. Di recente ho intervistato grandi aziende produttrici di software (Microsoft, Amazon ecc ...) ed è stata la mia prima volta in assoluto a superare un processo di intervista così approfondito. Mi sono preso gioco di me stesso in un'intervista a Microsoft in gran parte a causa dei nervi, ma non sapevo cosa aspettarmi o esattamente cosa stessero cercando. Ho risolto un problema con il percorso più breve solo per risolvere alcuni problemi davvero semplici. Ho estratto i valori dall'estremità sbagliata di uno stack, dimenticato in unint atoi(char* value) un'implementazione cheint val = value[i] - '0';mi darebbe il valore intero del personaggio e molti altri errori sciocchi. Sono stato felice per la maggior parte dell'intervista, ma ho ancora capito perché non ho ricevuto un'offerta. Ho dovuto rendermi conto che non si trattava tanto di una riflessione sulle mie capacità, quanto di un indicatore che dovevo solo continuare a provare fino a quando non sono stato in grado di padroneggiare i miei nervi. Alla fine ho inchiodato alcune interviste con domande molto più difficili e ho ottenuto il lavoro dei miei sogni. È davvero - per la maggior parte delle persone che sanno davvero cosa stanno facendo - solo una questione di capire cosa vogliono gli intervistatori, avere fiducia in se stessi e darlo a loro. Ci vuole un po

Dovrei dire di no, ma non per il motivo che hai indicato, ma che hai inserito la sezione FizzBuzz per ultima. Con il modo in cui funziona il tuo codice, non stamperà mai FizzBuzz quando te lo aspetti. Come ha commentato Lee, lo stamperà per ogni valore non divisibile per 3 o 5.

Ma il punto principale è che impari da esso. Mi piace il fatto che tu stia qui chiedendo come avresti potuto fare di meglio. Assicurati di fare alcuni enigmi con il codice e di cercare domande comuni per le interviste. Inoltre, potresti provare a cronometrare te stesso o fare qualcos'altro che aumenterebbe la pressione in modo da poter provare a imitare la sensazione che otterrai durante un'intervista. E prep, prep, e fai ancora più preparazioni per l'intervista se vuoi davvero buttarla fuori dal parco.

No. Il punto di FizzBuzz è vedere se sei in grado di elaborare la logica condizionale di base, che copre tutti i casi. Contrariamente alle opinioni di alcune persone, FizzBuzz non riguarda l'operatore di modulo, conoscendo operazioni ternarie o operandi booleani. È un semplice esercizio in condizioni e non ci sei riuscito.

Il problema è strutturato in modo che tutto il codice dall'aspetto "elegante" non riesca a coprire almeno un caso.

Risposte accettabili:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

Offro alla gente banali problemi di programmazione da fare alla lavagna. Se il codice risultante è privo di bug non è affatto il punto di decisione. Invece mi interessa un certo numero di comportamenti esibiti durante la stesura del codice. È interattivo e sto imparando molto sui candidati mentre sta accadendo.

Vado più in dettaglio al "test" della lavagna durante un'intervista: un modo legittimo per eseguire il backup del codice (lavagna)?

Certo, il tuo intervistatore potrebbe non essere niente come me. Ma è del tutto possibile che tu abbia superato un colloquio con me durante la produzione di codice che è un po 'piccolo, e del tutto impossibile aver fallito con lo stesso codice.

Se stavo valutando questo, avrei cercato le seguenti cose:

1. Il candidato cerca di comprendere chiaramente i requisiti prima di passare all'implementazione? Il candidato cerca di risolvere il mio problema o di usare i suoi strumenti per animali domestici nella sua cassetta degli attrezzi di programmazione? In che modo il candidato risolve i problemi?
2. Il candidato parla fluentemente almeno un linguaggio di programmazione?
3. Il candidato ha una comprensione della logica booleana?
4. Cosa fa il candidato per garantire la qualità delle sue soluzioni?
5. Come risponde il candidato al feedback sul suo codice?

-

È difficile da dire sul n. 1. La tua domanda afferma che il tuo problema non includeva la parte "numero di stampa" e che la tua soluzione non lo include. Non ho altra scelta che prendere la tua parola, ma se in realtà era il classico problema di FizzBuzz che includeva la stampa di numeri che non erano divisibili per entrambi, allora sembra che tu sia passato a una soluzione prima di comprendere appieno i requisiti, che sarebbe un segno distintivo.

Ti darei un credito parziale per # 2 e # 3. Sapevi di usare l'operatore del modulo e avevi la struttura di una soluzione funzionante, ma mancavano parti di entrambi.

Sembra che tu non abbia fatto il n. 4, il che ti segnerebbe. In futuro, consiglierei di fare un passo indietro dalla lavagna e di esaminare la tua soluzione prima di chiamarla fatta. Vorrei anche (senza essere richiesto) passare attraverso un paio di unit test per la tua soluzione, che avrebbe rapidamente dimostrato dove hai sbagliato.

Non ti hanno dato la possibilità su # 5, il che è sfortunato. Ma il punto è che non voglio qualcuno che pensi che ogni riga di codice che abbia mai scritto sia oro puro che non potrebbe essere migliorato, ma piuttosto qualcuno disposto ad accettare feedback sulle sue soluzioni e impegnarsi in una conversazione sul suo approccio .

-

Quindi, se stessi valutando da solo, voterei "No Hire". Cose come questa sono una sorta di misurazione di una performance art piuttosto che capacità di programmazione , ma padroneggiarla può comunque aiutare la tua carriera. Quindi i miei consigli per future interviste tecnologiche sarebbero:

1. Prima del colloquio, pratica un paio di questi tipi di esercizi a freddo, usando il minor numero possibile di risorse esterne. Non per memorizzare soluzioni, ma per essere sicuri che tu sia a tuo agio con la tua lingua preferita

2. Poni domande sul problema per convalidare i tuoi presupposti.

3. Prima di annunciare la soluzione completa, fai un passo indietro dalla lavagna e guardala oltre, e attraversa un paio di semplici casi di test unitari.

Chiedere a qualcuno di risolvere un problema senza dargli la possibilità di ottenere feedback sulla propria soluzione è un approccio discutibile, perché non gli è permesso migliorare.

Tutto ciò che questo test ci dice è che non hai dimostrato ottime capacità di risoluzione dei problemi "top-of-the-head".

Questo potrebbe essere uno degli elementi nella decisione di assumerti o meno, ma per me non dovrebbe assolutamente essere l'unico.

Ti avrebbero fornito un ambiente di testing o esecuzione dell'unità, gli errori che avresti commesso sarebbero stati meno scusabili.