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

Prima di tutto, una domanda che richiede a due sviluppatori esperti tre ore per ottimizzare elegantemente è una scelta sbagliata per una domanda di intervista. Se lo chiedi, non dovresti aspettarti risposte perfette.

D'altra parte, a volte impari di più su qualcuno quando li fai raggiungere i loro limiti. Ecco perché molti corsi universitari aumentano la difficoltà e poi classificano sulla curva. Se tutti guadagnano il 100% per ogni esame, stai lasciando un sacco di potenziale apprendimento.

Il mio candidato ideale probabilmente farebbe prima il calcolo della complessità, dì "Oh, sono solo 6 milioni di iterazioni, che non impiegheranno molto a lungo", quindi scriverà rapidamente la soluzione di forza bruta. Quindi discuteranno gli approcci che potrebbero adottare per ottimizzarlo, senza necessariamente implementarli a meno che l'intervistatore non glielo abbia chiesto.

In parte, questo è dovuto al fatto che molti dei problemi del tipo euler del progetto che emergono nel mondo reale sono problemi one-shot che è necessario risolvere una volta e poi 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 serve solo per eseguirlo quella volta.

In qualità di gestore delle assunzioni, se ti sto chiedendo di risolvere un problema con il codice proprio lì davanti a me, non lo faccio tanto per vedere il codice stesso (sebbene sia importante) ma piuttosto per accertare come e perché hai fatto quello che hai fatto Una delle cose che potresti fare è il codice non , e invece interrogarmi sugli aspetti del problema stesso, per risolverlo meglio. Ciò è significativo per me, e di solito più significativo della soluzione presentata nel codice. Tuttavia, non è così che tutti lo fanno, né è ciò che tutti vogliono vedere (e in effetti, raramente chiedo alle persone di codificare in un'intervista, ma pongo problemi sul tavolo e ne parliamo e a volte emerge pseudocodice , che è altrettanto buono per me ).

Hai ragione che non tutte le domande dell'intervista sono giuste, e ciò che è facile per qualcuno è difficile per un altro, in quella situazione e con quei vincoli, ed è per questo che quelle interviste che capiscono che in genere non cercano il codice soluzione (anche se, ancora una volta, ha un ruolo importante), ma piuttosto la soluzione process .

"C'è una regola come dopo 20 minuti dovresti iniziare a scrivere il codice, non importa cosa?" Risponderei affermando che entro pochissimo tempo a pensare al problema, dovresti almeno facendo qualcosa - facendo più domande, tracciando una struttura per una soluzione, o dicendo che non puoi farlo / non so da dove cominciare.

Se metto di fronte a te un problema difficile e la soluzione che hai fornito - dati i limiti di tempo e quello che hai - era bruta e bruta, ti avrei fatto una serie di domande sul perché fosse il caso e cosa lo cambierebbe in qualcosa di più elegante: maggiori informazioni? più tempo? un ambiente diverso? Essere consapevole di sé e in contatto con perché di ciò che hai fatto, e ciò che hai non fatto, ed essere in grado di spiegarlo razionalmente, è un grande stella d'oro nel mio libro, ma quelli sono i tipi di sviluppatori che cerco. Quindi, "l'eccellente comprensione dei problemi e le indicazioni stradali per una soluzione elegante" avrebbero funzionato anche per me, ma non per tutti.

Vorrei entrambi, ma possono visualizzare un "codice che funziona" in una soluzione e quindi discutere possibili soluzioni per migliorare l'uno o l'altro problema.

Se chiedi a qualcuno di scrivere codice e vogliono solo parlare di possibili soluzioni con codice zero, sarebbe una preoccupazione.

Come hai detto tu, qualcuno può lottare con il particolare problema 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 sta scrivendo abbastanza codice e ne discute e puoi capire se sono adatti per il lavoro.

Is there a rule like after 20 minutes you should just start coding no matter what?

No, ma se passi 20 minuti ad analizzare il problema prima di metterti al lavoro, probabilmente sei già nei guai. Un datore di lavoro che ti fa una domanda come quella che hai citato è per lo più interessato a come ti avvicini a un problema, ma se lo chiedono come problema di codifica vorranno vedere anche del codice. Parlali attraverso il tuo processo di pensiero ...

Well, the obvious approach here is brute force. If I had a way to recognize a right triangle given the three vertices, I could run through all the combinations of two points and the origin looking for right triangles. That shouldn't be hard -- I can write a function that uses the Pythagorean Theorem to identify right triangles. To make that easier, I'll also write a function that determines the distance between two points using the distance formula...

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

So, we could obviously put the isRightTriangle(p1, p2, p3) function in the middle of four for loops and iterate over all the possible choices for each of the two variable points. Let's see... the problem asks for the number of right triangles including the origin on a 50x50 grid, so using the brute force method makes us check 50 possibilities for each coordinate of each point. That's 50^4 checks... I'm sure we can do better, but the code is obvious, so let me write that down...

Quindi ora scrivi una funzione che usa cicli for annidati e la funzione isRightTriangle() che hai appena scritto. Hai risolto il problema, ma hai anche lasciato che l'intervistatore vedesse dove stai andando. Se il loro obiettivo era solo quello di vedere che puoi scrivere codice, potrebbero dirti di smettere. Più probabilmente, sono felici di parlare con qualcuno che sa quello che stanno facendo e vorranno vedere quanto lontano si prende questo. Quindi vai avanti ...

It occurred to me while I was writing that that we can take advantage of symmetry. We can reflect any given right triangle around the 45° line, so if we choose to check one of the points only on one side of that line, we can just count any right triangles we find twice... once for the triangle and once for its reflection. That cuts the number of checks by half. Also, looking at it now, we're taking a square root to find the distance between two points, but then we just square that again in isRightTriangle()...

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

In qualità di manager, se ti chiedo di codificare come test, sono più interessato a:

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

Il primo oggetto potrebbe sembrare pazzo, ma rimarrai sorpreso ...

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

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

Ecco cosa mi interessa davvero non :

• Che compila (supponendo che ti abbia appena dato il blocco note e nessun compilatore)
• Che tu conoscessi per memoria l'ordine di quei 2 parametri in quella sola funzione
• Che puoi recitare a memoria una stringa di connessione SQL Server o Oracle
• Che puoi codificare perfettamente mentre sono dietro le spalle a guardare ogni errore.

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

In tal caso, l'incursione verso una soluzione elegante è migliore di una soluzione peggiore ma completa. Entrambi i casi sono comunque buoni. È assolutamente bene aver scritto pusdocode dimostrando di aver compreso il problema e di come si intende risolverlo anche se non si ha il tempo di codificare effettivamente il programma.

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

È possibile che l'intervistatore sia un vero pragmatico alla ricerca di qualcosa che funzioni rapidamente e poi si ottimizzi come attività a priorità più bassa se si ha tempo. È ugualmente possibile che l'intervistatore stia facendo la sua migliore impressione delle pratiche di assunzione di Google e non sia interessato a nient'altro che l'algoritmo più sexy e più elegante e lo prende come un segno di debolezza che tu abbia mai messo le parole "brute" e "brute" forza "entro 5 parole l'una dall'altra. È anche possibile che l'intervistatore abbia cercato su Google "domande dell'intervista" e trovato questo problema su internet 5 minuti prima di entrare e non ha idea di cosa voglia.

In tutti i casi, la soluzione migliore è probabilmente chiedere chiarimenti, se non è possibile dedurre in base alle informazioni contestuali ciò che l'intervistatore desidera. Hai ragione, non tutte le domande dell'intervista sono giuste e, in effetti, non tutte sono buone domande o anche domande sensate. Un'intervista è un'attività intrinsecamente riduzionista, molto simile a "speed dating" in cui trascorri 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 ponendo una domanda che ritengono possa darti un'idea delle tue competenze e adattarsi al loro team. Devi guardare la loro squadra, quello che sai su di loro, la personalità dell'intervistatore, e decine di altri fattori, e fare una stima ottimale su quali risposte, approccio e processo potrebbero valutare. Personalmente, direi che dovresti affrontarlo nel modo in cui pensi sia la migliore idea. Se non sono d'accordo con te, potrebbe non essere comunque un buon compromesso, più facile da capire prima.

Gli intervistatori ti chiederanno comunque di migliorare la tua soluzione.

E l'approccio "brute force solution first" ha un vantaggio indiscutibile: se non riesci a trovare una soluzione ideale, hai ancora qualcosa di completato da mostrare.