In un'intervista, è meglio codificare una soluzione di forza bruta per una domanda difficile o passare l'intervista esaminando attentamente la domanda? [chiuso]

A volte le domande del colloquio sono difficili, se l'intervistatore intende che lo siano o no. Si può decidere se utilizzare il tempo limitato dell'intervista per codificare una brutta, inefficiente soluzione di forza bruta o passare il tempo a comprendere ogni aspetto del problema con l'intervistatore.

Ad esempio, il Problema 91 di Project Euler può essere risolto con una soluzione non così difficile di forza bruta che calcola ogni possibile triangolo, scrive un test isRightTriangle () e fa scoppiare tutti i triangoli che superano il test in un set. Ma le due coppie di coordinate X / Y rendono quella una soluzione O (x ^ 4) con un valore costante elevato. Un amico e io abbiamo appena trovato una soluzione che è molto più elegante ed efficiente, ma noi due abbiamo trascorso 3 ore su di esso e abbiamo disegnato dozzine di diagrammi, testato più formule, esaminato più approcci, ecc.

Non tutte le domande dell'intervista sono giuste. Inoltre, ciò che è facile per una persona può essere difficile per un'altra. Se qualcuno fa fatica con una domanda, saresti più colpito da una brutta soluzione bruta che funziona? O eccellente comprensione dei problemi e strade per una soluzione elegante, ma nessuna soluzione codificata? C'è una regola come dopo 20 minuti che dovresti iniziare a scrivere codice, non importa cosa?

Prima di tutto, una domanda che richiede due ore di sviluppo a due sviluppatori esperti per ottimizzare in modo elegante è una cattiva scelta per una domanda di intervista. Se lo chiedi, non dovresti aspettarti risposte perfette.

D'altra parte, a volte impari di più su qualcuno quando lo fai raggiungere i suoi limiti. Ecco perché molti corsi universitari aumentano la difficoltà e poi valutano sulla curva. Se tutti ottengono il 100% di ogni esame, lascerai molto potenziale apprendimento.

Il mio candidato ideale probabilmente farebbe prima il calcolo della complessità, dicendo "Oh, sono solo 6 milioni di iterazioni, il che non richiederà molto tempo", quindi scrivo rapidamente la soluzione della forza bruta. Quindi avrebbero discusso gli approcci che potevano adottare per ottimizzarlo, senza necessariamente implementarli a meno che l'intervistatore non glielo chiedesse.

In parte, ciò è dovuto al fatto che molti dei problemi di tipo euler del progetto che si presentano nel mondo reale sono problemi a colpo singolo che è necessario risolvere una volta, quindi dimenticarsene. Voglio sapere che qualcuno che assumerò sarà in grado di riconoscere un algoritmo di forza bruta che impiega 2 minuti per scrivere e 10 minuti per essere eseguito è più efficiente di un algoritmo che impiega 3 ore per scrivere e 10 secondi per funzionare, se hai solo bisogno per eseguirlo una volta.

Come responsabile delle assunzioni, se ti sto chiedendo di risolvere un problema con il codice proprio lì davanti a me, non lo faccio così tanto per vedere il codice stesso (anche se è importante) ma piuttosto per accertare come e perché hai fatto quello che hai fatto. Una di quelle cose che potresti fare non è il codice e invece mi interroga sugli aspetti del problema stesso, per risolverlo meglio. Questo è significativo per me e di solito più significativo della soluzione esposta nel codice. Tuttavia, non è così che fanno tutti, né è ciò che tutti vogliono vedere (e in effetti, raramente chiedo alle persone di programmare in un ambiente di intervista, ma metto i problemi sul tavolo e parliamo attraverso di loro e talvolta emerge lo pseudocodice , che è altrettanto buono per me ).

Hai ragione sul fatto che non tutte le domande del colloquio sono giuste, e ciò che è facile per qualcuno è difficile per un altro, in quel contesto e con quei vincoli, ed è per questo che quelle interviste che capiscono che di solito non cercano la soluzione del codice (sebbene , ancora una volta, questo svolge un ruolo importante) ma piuttosto il processo di soluzione .

"Esiste una regola come dopo 20 minuti che dovresti iniziare a scrivere codice, non importa cosa?" Ti risponderei dicendo che in brevissimo tempo dovresti pensare al problema, almeno dovresti fare qualcosa : porre più domande, delineare un framework per una soluzione o dire che semplicemente non puoi farlo / non so da dove cominciare.

Se ti ponessi un problema difficile e la soluzione che mi hai fornito - dati i vincoli di tempo e quello che hai - era la forza bruta e brutta, ti farei quindi una serie di domande sul perché fosse così, e cosa lo cambierebbe in qualcosa di più elegante: più informazioni? più tempo? un ambiente diverso? Essere autocoscienti e in contatto con il perché di ciò che hai fatto e di ciò che non hai fatto, e riuscire a spiegarlo razionalmente, è una grande stella d'oro nel mio libro, ma quelli sono i tipi di sviluppatori che cercare. Quindi, "un'eccellente comprensione del problema e strade per una soluzione elegante" funzionerebbe anche per me, ma non per tutti.

Vorrei entrambi, ma potrebbero visualizzare un "codice che funziona" in una soluzione e quindi eventualmente discutere di potenziali soluzioni per il miglioramento in quell'uno o nell'altro problema.

Se chiedi a qualcuno di scrivere codice e vogliono solo parlare di possibili soluzioni con codice zero, questo sarebbe un problema.

Come hai detto, qualcuno può lottare con il problema particolare per qualsiasi motivo, ma devi imparare come risolverli. Potrebbero essere fortunati e hanno già sentito parlare di una soluzione a un problema simile. Succede.

Guarda qualcuno che scriva abbastanza codice e ne discute e puoi capire se sono adatti al lavoro.

C'è una regola come dopo 20 minuti che dovresti iniziare a scrivere codice, non importa cosa?

No, ma se passi 20 minuti ad analizzare il problema prima di iniziare l'attività, probabilmente sei già nei guai. Un datore di lavoro che ti pone una domanda come quella che hai citato è per lo più interessato al modo in cui affronti un problema, ma se lo pone come un problema di codifica, vorrà vedere anche del codice. Parla attraverso il tuo processo di pensiero ...

Bene, l'approccio ovvio qui è la forza bruta. Se avessi un modo per riconoscere un triangolo rettangolo dati i tre vertici, potrei scorrere tutte le combinazioni di due punti e l'origine cercando triangoli retti. Non dovrebbe essere difficile: posso scrivere una funzione che utilizza il Teorema di Pitagora per identificare i triangoli rettangoli. Per facilitare ciò, scriverò anche una funzione che determina la distanza tra due punti usando la formula della distanza ...

La scrittura di tali funzioni dovrebbe richiedere circa tre minuti. Ora, a pochi minuti dalla domanda, hai già dimostrato che ricordi la geometria di base e che sai davvero come scrivere il codice. Ti dà anche qualcosa di cui parlare:

Quindi, potremmo ovviamente mettere la isRightTriangle(p1, p2, p3)funzione nel mezzo di quattro forloop e iterare su tutte le possibili scelte per ciascuno dei due punti variabili. Vediamo ... il problema richiede il numero di triangoli retti, inclusa l'origine su una griglia 50x50, quindi l'utilizzo del metodo della forza bruta ci consente di verificare 50 possibilità per ciascuna coordinata di ciascun punto. Sono 50 ^ 4 controlli ... Sono sicuro che possiamo fare di meglio, ma il codice è ovvio, quindi lasciami scrivere ...

Quindi ora scrivi una funzione che utilizza forloop nidificati e la isRightTriangle()funzione che hai appena scritto. Hai risolto il problema, ma hai anche permesso all'intervistatore di vedere dove stai andando. Se il loro obiettivo era solo quello di poter scrivere codice, potrebbero dirti di smettere. Più probabilmente, sono felici di parlare con qualcuno che sa cosa stanno facendo e vorranno vedere fino a che punto lo porti. Quindi vai avanti ...

Mi è venuto in mente mentre scrivevo che possiamo sfruttare la simmetria. Possiamo riflettere qualsiasi dato triangolo rettangolo attorno alla linea di 45 °, quindi se scegliamo di controllare uno dei punti solo su un lato di quella linea, possiamo semplicemente contare tutti i triangoli retti che troviamo due volte ... una volta per il triangolo e una volta per il suo riflesso. Ciò dimezza il numero di controlli. Inoltre, osservandolo ora, stiamo prendendo una radice quadrata per trovare la distanza tra due punti, ma poi la quadriamo di nuovo in isRightTriangle()...

E così via. Ancora una volta, di solito non vogliono vedere una soluzione perfetta, vogliono vedere come si arriva a una soluzione. Il tuo processo di pensiero non deve essere niente di simile a quello sopra - solo avere la sicurezza di pensare ad alta voce conta molto. Non sudare se commetti un errore - dì semplicemente "hmmm, penso di essere uscito dai binari qui - fammi tornare indietro di un passo ..."

Come manager, se ti chiedo di scrivere un codice come test, sono più interessato a:

• Se puoi scrivere codice
• Il tuo stile di codifica
• L'algoritmo che hai selezionato
• Il tentativo indica che hai capito il problema
• Se sono davvero entusiasta di una tecnologia specifica, hai dimostrato di conoscerla più o meno.

Il primo oggetto può sembrare pazzo, ma rimarrai sorpreso ...

Stile di codifica - con questo non intendo solo dove metti le parentesi graffe, ma cose come:

• Hai scelto composizione o eredità per risolvere quel problema? Perché?
• Per quel valore, perché hai scelto di usare un enum vs. una stringa vs. un int (o qualunque sia la permutazione applicabile)
• Hai usato proprietà, campi o metodi get / set per quel valore? Perché?
• Come hai gestito lo stato nelle tue lezioni?
• Capisci come funzionano ereditarietà, interfacce e lambda?
• Comprendi le convenzioni dei parametri del linguaggio (che cos'è ref rispetto al valore?)
• Sai come scrivere test unitari?

Ecco cosa non mi interessa davvero :

• Che si compila (supponendo che ti abbia appena dato il blocco note e nessun compilatore)
• Che tu sapessi dalla memoria l'ordine di quei 2 parametri in quella funzione
• Che puoi recitare una stringa di connessione SQL Server o Oracle a memoria
• Che puoi programmare perfettamente mentre io sono in piedi dietro la tua spalla a guardare ogni errore.

In tutta onestà, non sono mai stato un grande fan dei test di codifica, tranne come strumento per analizzare lo stile.

In tal caso, la strada verso una soluzione elegante è meglio di una soluzione peggiore ma completa. Entrambi i casi sono buoni però. È assolutamente corretto avere scritto pusdocode che dimostri di aver compreso il problema e come intendi risolverlo anche se non hai avuto il tempo di codificare effettivamente il programma.

Penso che tu stia facendo una domanda per la quale in realtà non esiste una risposta, tanto meno una risposta "giusta". La ragione per cui dico questo è che dipende interamente da ciò che la persona che pone la domanda apprezza.

È possibile che l'intervistatore sia un pragmatico hardcore che vuole davvero vedere che riuscirai a far funzionare qualcosa rapidamente e quindi ottimizzare come attività a priorità inferiore se hai tempo rimanente. È anche possibile che l'intervistatore stia facendo la sua migliore impressione delle pratiche di assunzione di Google e non sia interessato a nient'altro che all'algoritmo più sexy ed elegante e lo considera un segno di debolezza che avresti mai messo le parole "bruto" e " forza "entro 5 parole l'una dall'altra. È anche possibile che l'intervistatore abbia cercato su Google "domande di intervista" e trovato questo problema su Internet 5 minuti prima che tu arrivassi e non ha idea di cosa voglia.

In ogni caso, la soluzione migliore è probabilmente chiedere chiarimenti, se non è possibile dedurre in base alle informazioni sul contesto ciò che l'intervistatore desidera. Hai ragione sul fatto che non tutte le domande del colloquio sono giuste e, in effetti, non tutte sono buone domande o anche domande che hanno un senso. Un'intervista è un'attività intrinsecamente riduzionista, molto simile al "speed dating" in cui stai trascorrendo un'ora o due con qualcuno e voi due state cercando di indovinare, in base a quell'ora, se lavorerete bene insieme per il prossimo 5 anni o meno. Esaminato da quella prospettiva, spero sia più chiaro il motivo per cui dico che non c'è davvero nessuna risposta alla tua domanda su una "regola".

Qualcuno ti sta facendo una domanda che pensa possa darti un'idea delle tue competenze e adattarsi alla sua squadra. Devi guardare la loro squadra, ciò che sai di loro, la personalità dell'intervistatore e dozzine di altri fattori, e fare una migliore ipotesi su quali risposte, approcci e processi che potrebbero valutare. Personalmente, direi che dovresti affrontarlo nel modo in cui pensi sia l'idea migliore. Se non sono d'accordo con te, potrebbe non essere comunque una buona soluzione, più facile capirlo prima che dopo.

Gli intervistatori ti chiederanno comunque di migliorare la tua soluzione.

E l'approccio della "soluzione della forza bruta prima" ha un vantaggio indiscutibile: se non riesci a trovare una soluzione ideale, hai ancora qualcosa da completare per mostrarli.