Dici semplicemente che hai una soluzione al problema e lo dimostri. Se un intervistatore sta per tirare fuori un problema estremamente comune, non dovrebbe sorprendersi quando i candidati l'hanno già visto prima.

Prima di tutto, se questo argomento ti interessa, ho una serie di articoli nella coda del mio blog in arrivo nelle prossime due settimane su come gestisco le domande dei colloqui tecnici come intervistatore.

A rispondi alla tua domanda specifica: questo non è un problema che ti pongo, ma supponiamo che lo fosse. Perché dovrei farlo? Per scoprirlo:

• Il candidato riconosce questo famoso, standard, vecchio problema? In caso contrario, è un punto di dati interessante che posso esplorare ulteriormente.

• Se non hanno familiarità con il problema, possono escogitare una soluzione? Questa è in realtà la parte a cui tengo di meno. Un candidato che non è in grado di risolvere questo problema immediatamente non avrà successo nel mio team, quindi presumo che possa escogitare una soluzione rapidamente indipendentemente dal fatto che il problema sia noto o meno.

• Sotto-specificherò il problema e vedrò quali scelte fa il candidato. Il problema è produrre una "sequenza di mosse". OK, il candidato scarica le mosse sulla console, come se fosse il 1970? Producono un elenco? Producono una sequenza pigramente valutata? Quale struttura viene utilizzata per rappresentare il trasloco? Posso dire molto sul candidato solo dalla firma del metodo che scelgono di scrivere. Fanno una domanda per chiarire o semplicemente saltano dentro e codificano la prima cosa che viene in mente?

• Quando si scrive codice per risolvere un problema in modo ricorsivo, il codice è ben organizzato ? Il caso base e i passaggi ricorsivi sono chiaramente identificati? Un candidato che non ha completamente interiorizzato la struttura degli algoritmi ricorsivi, ancora una volta, non avrà successo nel mio team.

• Il candidato può chiaramente giustificare perché il codice è o è Non corretto? Se il codice è corretto, dovrebbero essere in grado di spiegare a parole il motivo. Se non è corretto, non dovrebbero essere in grado di spiegare perché è corretto, dovrebbero essere in grado di trovare il bug.

• Il candidato può suggerire casi di test che dimostrino la correttezza dell'algoritmo?

• Ora che abbiamo una soluzione corretta, posso iniziare a sondare davvero le loro conoscenze. Qual è la complessità temporale di questo algoritmo dato che l'input è l'altezza della pila di dischi? Se il candidato ha scelto di produrre ricorsivamente una sequenza pigra di mosse, questa domanda è più difficile di quanto potresti pensare. Qual è la complessità dello spazio sia nello spazio heap che nello stack?

• Ora possiamo iniziare a rendere il problema più difficile. E se fossimo in un ambiente in cui lo spazio dello stack era fortemente limitato ma lo spazio dell'heap non lo era; il candidato può utilizzare uno stack esplicito per trasformare l'algoritmo in un algoritmo iterativo e non ricorsivo?

• Supponiamo che io abbia chiesto al candidato di utilizzare lo stile di passaggio di continuazione per implementare una versione senza stack; sanno di cosa sto parlando? e se è così, possono farlo?

L'algoritmo specifico è del tutto irrilevante. È un punto di partenza per il vero compito dell'intervista, che è determinare se il candidato può ragionare sul codice utilizzando gli strumenti nella sua cassetta degli attrezzi . Non ho mai dovuto risolvere il problema della torre di Hanoi nel mio lavoro. Molte, molte volte ho dovuto riscrivere un algoritmo ricorsivo in un algoritmo iterativo con uno stack esplicito in un ambiente con vincoli di stack. Un candidato che non può farlo è improbabile che abbia successo nel mio team.

Quindi, la risposta alla tua domanda è: risolvi il problema in buona fede. Se il problema è davvero un "fizzbuzz" - solo un test per vedere se puoi scrivere del codice - allora lo passerai rapidamente e l'intervistatore andrà avanti. Ma userei un semplice problema standard come un'opportunità per sondare le capacità del candidato in modo più approfondito.

Mi sono state poste molte di queste domande standard in diverse interviste. Penso che tutti gli intervistatori sapessero / presumessero che avessi sentito parlare del problema e delle possibili soluzioni. La cosa importante quando si risponde a queste domande è che molti intervistatori sono principalmente interessati a:

• Quanto sei bravo a spiegare le cose? Ho visto alcune pessime spiegazioni da parte degli studenti che hanno compreso bene il problema e la soluzione ma non sono stati in grado di spiegarle a nessuno.
• Quanto sei bravo a implementare effettivamente una soluzione (se l'implementazione fa parte di il test)? Sei a conoscenza di potenziali problemi (es. Il tempo di esecuzione) e di soluzioni alternative?

Quindi non puoi semplicemente affermare:

Questo è un problema comune , la soluzione usa la ricorsione.

ma devi cercare di spiegarla all'intervistatore, fornendo un contesto se disponibile (tempo di esecuzione, generalizzazione ...). Se possibile, fai dei disegni per supportare le tue spiegazioni. Mostra il contesto del problema e indica soluzioni alternative. In breve: dimostra di essere in grado di spiegare una soluzione a un collega.

Negli esami di programmazione, cerco sempre di creare codice di produzione. Non digitare una minima soluzione pseudo-codifica, ma aggiungi commenti, test (se appropriati) e simili.

Se sei preoccupato di essere disonesto, è abbastanza facile dire: "Oh, sì, ho già visto questo problema. La soluzione che ho trovato è stata ..."

Quando intervistando per il mio lavoro attuale, mi hanno fatto un quiz che includeva quello che equivaleva al classico problema del fizz-buzz, ma usando parole diverse e con alcune piccole differenze. Quindi ho solo detto: "Oh, questo è molto simile a un fizz-buzz" e ho provveduto a dare una soluzione.

Se fossi stato avvertito che questa domanda sarebbe emersa durante l'intervista (forse il reclutatore dice tu o un amico intervistato lì di recente) e hai cercato una risposta su Internet e l'hai memorizzata, quindi tiri fuori questa risposta come se l'avessi appena capito, okay, potrebbe essere un imbroglio. Ma se dici francamente: "oh sì, ho letto una soluzione a questo problema non molto tempo fa" e puoi spiegare perché e come funziona la soluzione, anche se non ci hai pensato tu stesso, stai dimostrando un livello di comprensione. Di tanto in tanto ho intervistato persone che erano in grado di dare una soluzione a un problema, ma è diventato subito chiaro che non avevano idea da dove provenisse questa soluzione o come funzionasse. Ovviamente l'hanno semplicemente copiato da qualche parte.

Come ha detto qualcun altro qui, se un intervistatore userà problemi comunemente noti - ronzio o radici quadrate o qualsiasi altra cosa - sarebbe assurdo per loro accusare qualcuno di barare perché ha già sentito parlare del problema. (Non mi è mai stato chiesto delle Torri di Hanoi in un'intervista, e non ricordo i dettagli del problema quindi oltre a un vago, "sì, sono abbastanza sicuro che la soluzione fosse ripetitiva o ricorsiva o qualcosa del genere", Dovrei capirlo di nuovo comunque. Ma qualunque cosa.)

Questo è successo a me, non in particolare alla Torre di Hanoi, ma a un problema che riconosco e di cui conosco già la soluzione.

Cosa ha funzionato per me (e per pochi altri di cui so chi " sono stato in questa situazione) è dire qualcosa del genere:

L'ho visto di recente; infatti ho risolto questa ultima settimana. Vuoi che proceda o vuoi farmi una domanda diversa?

Questo fa alcune cose:

• Dimostra la tua conoscenza senza essere fuorviante.
• offre loro l'opzione . Alcuni luoghi sono risoluti nel porre a tutti le stesse domande per rendere le loro interviste il più uniformi possibile.
• Dà loro la possibilità di metterti alla prova in modo diverso . Potrebbero saltare questo o potrebbero decidere che se riesci a buttarlo via velocemente, possono farti una seconda domanda.
• Ricorda loro sottilmente che questo probabilmente non è l'unico posto in cui stai intervistando.

Un colloquio è un microcosmo del tuo eventuale rapporto di lavoro (se ci vai). Sei onesto? Sei flessibile? Sei concentrato sul problema in questione , che non risolve la Torre di Hanoi ma dimostra le tue capacità? Sei un giocatore di squadra, lavori con l'intervistatore per ottenere ciò che entrambi desiderate? Tutto ciò si rifletterà bene su di te nella valutazione delle "competenze trasversali".

Per quanto mi riguarda, questi problemi sono spesso ridicoli ed esistono davvero solo per consentire agli intervistatori di sentirsi compiaciuti di se stessi. Sì, puoi capire come alcune persone potrebbero risolvere un problema, ma non è che nessuno riuscirà mai a tirare fuori un numero dal nulla o a indovinare a caso un algoritmo.

Io " Presumo che questa sia stata un'intervista di sviluppo poiché è qui che abbondano questi tipi di problemi. Personalmente penso che sia molto più istruttivo mostrare a un candidato un codice sbagliato, chiedergli cosa fa e come può essere migliorato. È incredibile quanto possa essere efficace.

Francamente se avessi una domanda su un problema e avesse una soluzione come Hanoi, darei solo la mia migliore risposta. Sapere qualcosa per esperienza non è in alcun modo barare; è come funziona effettivamente il lavoro.