Sono d'accordo nel porre una domanda all'algoritmo, ma non sono d'accordo nell'insistere su uno specifico livello di qualità big-O.

Chiedere questo tipo di domande è interessante per vedere come la persona si avvicina al problema e quali trabocchetti ritengono nel loro tentativo, ma a meno che non stiano scrivendo qualcosa di follemente scorretto o inefficiente, i dettagli reali di ciò che scrivono non sono così indicativi fatto che superano le fasi di problem solving / design in modo coerente.

Faccio una domanda simile, ma le persone con cui ho avuto la fortuna migliore dopo il noleggio sono le persone che hanno fornito risposte sbagliate ma hanno avuto l'idea corretta nel loro approccio.

Non sono d'accordo con l'idea che la capacità di scrivere algoritmi sia irrilevante nella più grande domanda se la persona sarà un buon programmatore. Anche se non dovesse mai usarlo, (che è dubbio), mostra ancora se ha la flessibilità mentale necessaria per elaborare una soluzione logica a un problema che è più complicato di un semplice insieme di requisiti che è già scritto e presentato in dettaglio dal cliente.

Non vorrei assolutamente assumere qualcuno che non sa come pensare e analizzare. Questo è ciò che fa la differenza tra una scimmia del codice e un programmatore di computer.

Devo ammettere che sono uno di quelli a cui piace porre domande sugli algoritmi nelle interviste, ma devo sottolineare che la risposta effettiva alla domanda è assolutamente irrilevante. Non mi interessa minimamente se l'intervistato conosce la risposta oppure no. Invece, per me, questa domanda si rivolge a diversi aspetti, come il seguente: in ordine di importanza:

Requisiti

Tali domande sono deliberatamente sottostimate. Nel tuo esempio, non ci sono ulteriori dettagli sulla sequenza. Se hai un intervistato che ti chiede se questi numeri sono effettivamente ordinati, allora è un buon segno. Ha la mentalità giusta per chiedere ai clienti ulteriori dettagli, che aiuteranno a trovare una soluzione migliore in un tempo più breve. Il candidato può anche giocare con l'idea di usare lo spazio O (n) per memorizzare una serie di numeri N, ma non dovrebbe farlo senza chiedere maggiori dettagli su X e Y. Diciamo che X e Y sono tra 1 e 1000 , quindi sicuro, andare avanti e accendere una soluzione basata su array. Ma se ti dico che l'intervallo è 1 e 1 miliardo, allora il problema diventa completamente diverso. Vorrei sottolineare ancora una volta che non mi interessa la soluzione. Voglio vedere se il candidato può trovare la differenza tra questi problemi, che sono immensamente diversi.

Tecniche standard

Non voglio assumere un programmatore che non sappia nemmeno cosa significa O (n). Questo è un assoluto deve sapere se hai avuto un'educazione decente in quella zona. Ma è anche importante non solo sapere cosa significa, ma applicare effettivamente quella conoscenza. Nel tuo esempio, voglio che un candidato si renda conto che non è autorizzato a ordinare i dati (senza porre ulteriori domande che mirano all'opzione di un ordinamento del bucket o altri approcci di ordinamento O (n)) a causa dell'ordinamento richiesto O (n log n) in generale.

Allo stesso modo, le altre domande sugli algoritmi hanno come obiettivo tecniche standard come il tree-or-traversal grafico o la ricorsione. Un candidato può scivolare su una di queste tecniche, che non fa una buona impressione. In questi casi, tuttavia, mi piace scavare più a fondo per scoprire se il candidato ha qualche background di CS. Naturalmente, dipende da quale sia la posizione di destinazione, ma in genere uno sviluppatore che non conosce le complessità di esecuzione, né le tipiche strutture di dati e le loro traversate, non sarà di alcun aiuto.

Mente mentale per la risoluzione dei problemi

Dopo aver fatto la domanda, controlli attentamente il candidato. Come reagisce? Ottieni i migliori risultati qui da candidati che non hanno assolutamente alcun indizio su come risolvere il problema all'inizio . A tale riguardo, la domanda verifica cosa potrebbe accadere se una situazione simile si verifica successivamente sul posto di lavoro. Durante lo sviluppo potresti riscontrare un problema simile, ed è bene sapere in che modo il tuo candidato affronta questi problemi, anche se non è in grado di risolverli da soli.

Esempio: non vuoi che il tuo candidato entri in modalità silenziosa per la prossima mezz'ora! Controlla se riesce a trovare domande intelligenti (vedi Requisiti), controlla se inizia a pensare fuori dagli schemi una volta che si rende conto che non può farlo. Anche una contro-domanda "divertente" come "Posso usare l'opzione di un collaboratore telefonico?" è un buon segno.

Come rispondere

In generale, le risposte migliori che puoi dare per questo tipo di domande sono contro-domande! Dire una risposta immediatamente fallisce fondamentalmente, e in effetti non è una buona risposta, perché tutte queste domande lasciano intendere i trade-off, che la tua risposta implica, senza che tu abbia ancora le informazioni richieste per farlo in modo intelligente scambio. Naturalmente, la qualità delle domande contrarie varia tra i candidati.

Come nota generale sulle domande dell'intervista: le contro-domande sono raramente una cosa negativa. In una delle mie interviste mi è stato chiesto ad esempio qualcosa del tipo: "Se dovessi implementare X, sceglieresti C ++ o Java per quello, e perché?" - Ho semplicemente ribattuto con "Sono limitato a questi due?". Indovina per te, che tipo di reazione hai ricevuto da un intervistatore per una tale contro-domanda - e quanto sia facile per te mostrare effettivamente all'intervistatore ciò di cui sei capace.

Sono d'accordo sul fatto che i programmatori debbano conoscere gli algoritmi molto bene, anche con fantasiose nuove strutture, ma non sono totalmente convinto di un rompicapo in un'intervista. La mia più grande preoccupazione sarebbe che in un ambiente reale, si scrivono algoritmi in condizioni molto diverse; alias, non sotto pressione con qualcuno che ti osserva ogni penstroke, con almeno alcuni minuti per pensarci sopra in silenzio. Per coloro che sostengono questo metodo di valutazione, per quanto tempo dai alla persona di risolverlo? Credo che il codice non sia tanto l'escogitazione di una soluzione in un terrore febbrile di 3 minuti, quindi convincimi che questo è in realtà un buon modo per vedere come qualcuno gestirà un compito quotidiano.

A meno che tu non stia facendo domande su algoritmi / formule che il candidato deve sapere per il lavoro (fluidodinamica, per esempio, se la posizione lo richiede), non vedo il loro valore. Il candidato è già probabile che si preoccupi di come sono vestiti, di come stanno parlando, ecc ... se possono rispondere a una domanda di matematica sul posto non prova altro che forse come potrebbero fare su un gioco televisivo.

Quando intervisto, non chiedo nemmeno di "programmare" le domande di per sé. Ho il candidato a descrivere i loro progetti passati, come il loro codice ha raggiunto gli obiettivi, quali sono i loro approcci, ecc. Da quello posso dire abbastanza rapidamente se il candidato sa cosa sta facendo o se è un poser.

Il problema con quella domanda specifica è che è quasi una domanda trabocchetto. Con una particolare intuizione, ti verrà facilmente in mente O (n), altrimenti avrai difficoltà a migliorare di O (n log n). Si riduce quasi a "Hai visto questo prima?"

Non sono sicuro che ci siano delle buone domande algoritmiche. Se si ponesse una domanda basata sulla teoria dei grafi, per esempio, dipenderebbe dalla familiarità con la teoria dei grafemi dell'intervistato e, se assumete lui o lei, potrebbe essere in grado di accelerare la teoria dei grafi abbastanza rapidamente. Di nuovo, siamo tornati a "Sei stato esposto a questo prima?"

Non c'è tempo in un'intervista regolare per risolvere seriamente i problemi, e mi avvicino alle cose in modo diverso quando posso sedermi, usare Wikipedia, e in genere prendermi un po 'di tempo per capire le cose. Probabilmente non c'è il tempo per l'intervistatore di discutere attentamente ciò che l'intervistato conosce in dettaglio e scegliere una domanda algoritmica adatta.

Ho diverse domande tipo algoritmo che uso regolarmente, alcune delle quali sono molto difficili. Li uso per vedere come attaccano mentalmente un problema e per vedere se ingannano determinati concetti. (Ho visto troppi candidati per sviluppatori che non capiscono i puntatori.)

Vuoi una domanda che ti dia un'idea del candidato. Una domanda sull'algoritmo può dare una buona risposta, oppure no. E non mi sto riferendo a loro in grado di rispondere o meno. Se ci riescono, e tu capisci e segui il loro ragionamento, questo è un buon indicatore. Se si siedono lì, senza una vera risposta, non sembrano nemmeno sapere da dove cominciare, questo è un cattivo indicatore (forse). Il problema sarebbe che alcune persone si bloccano e differenziare il congelamento dal non avere capacità di problem solving può essere difficile.

Le persone si lamenteranno di chiedere qualsiasi cosa nelle interviste, per vari motivi. Il richiedente può congelare, il richiedente potrebbe avere appena esaminato quella domanda su, il richiedente non può sapere quel pezzo particolare di trivia / tech / qualunque. Tutto questo è vero, ma deve ancora avvenire un'intervista, e molti di noi in questa professione lo odiano. Odiamo l'idea che qualcuno sieda in giudizio di noi. Abbiamo immediatamente evocato motivi per cui potremmo essere giudicati ingiustamente, o come il test potrebbe essere fasullo o giocato. La linea di fondo è, non importa.

Quello che vuoi veramente è un intervistatore con la capacità di determinare le abilità che possono o non possono essere presentate durante l'intervista. Le domande sono solo gli strumenti. Per me, tutti i martelli hanno lo stesso aspetto. Ma per qualcuno abbastanza abile con loro, sono sicuro che c'è differenza.

Mi piacciono le domande sugli algoritmi, perché è ciò che facciamo. Mi piacciono i vincoli, perché è quello che usiamo. Big-O è particolarmente rilevante nel mio settore.

Non mi piace chiedere che le risposte a questo tipo di domande siano "scrivi il codice sulla lavagna". L'intervistato dovrebbe essere in grado di parlare in modo intelligente dell'approccio alla soluzione e impegnarsi in una discussione in corso mentre gli intervistatori cambiano i requisiti mentre la discussione è in corso.

Viene posta la domanda iniziale, l'intervistato dice: "Comincia dall'inizio e marcia verso la fine cercando il 'buco'". L'intervistatore dice che è troppo lento, perché N è gigantesco. L'intervista inizia a discutere della ricerca binaria. L'intervistatore dice che all'improvviso i dati non sono più ordinati. L'intervistato dice "ordina poi cerca". "Ora è troppo lento". Ecc., Ecc.