Recentemente ho avuto una discussione con un collega programmatore. Stava intervistando una nuova posizione e gli è stata posta questa domanda:

Dai una sequenza di numeri che iniziano con X e finiscono in Y ma con un elemento mancante, quindi N è YX-1, trova l'elemento mancante in O (N) o meglio.

Ora, la risposta è irrilevante qui (ma interessante). Ciò ha avviato una discussione sul fatto che questa fosse una buona domanda da porre durante un'intervista.

Un lato: gli algoritmi sono parte integrante della programmazione e la capacità dei candidati di rispondere a questa domanda sostiene che questo candidato sarà un buon programmatore e sarà in grado di risolvere problemi più grandi e in grado di gestire la maggior parte delle attività di programmazione che sono in definitiva facili da capire e rispondere.

Dall'altro lato: scrivere algoritmi da zero è raramente usato nella programmazione moderna e quindi è irrilevante nella domanda più grande se la persona sarà un buon programmatore. Una persona potrebbe rispondere correttamente a questa domanda ma non essere ancora in grado di svolgere attività di programmazione più comuni.

I vostri pensieri? Buona intervista o no?

Sono d'accordo con la domanda di un algoritmo, ma non sono d'accordo con l'insistenza su uno specifico livello di qualità big-O.

Fare questo tipo di domanda è interessante per vedere come la persona si avvicina al problema e quali insidie ​​considerano nel loro tentativo, ma a meno che non stiano scrivendo qualcosa di follemente errato o inefficiente, i dettagli reali di ciò che scrivono non sono così chiari come il fatto che essi superare le fasi di risoluzione dei problemi / progettazione in modo coerente.

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

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

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

Devo ammettere qui che sono uno di quelli a cui piace fare domande sugli algoritmi durante le interviste, ma devo sottolineare che la risposta effettiva alla domanda è assolutamente irrilevante. Non mi interessa minimamente se l'intervistato conosce o meno la risposta. Invece, per me, questa domanda si rivolge a diversi aspetti, come i seguenti - 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à corretta 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 un array di N numeri, ma non dovrebbe farlo senza chiedere maggiori dettagli su X e Y. Diciamo che X e Y sono compresi tra 1 e 1000 , quindi, vai avanti e avvia una soluzione basata su array. Ma se ti dico che l'intervallo è 1 e 1 miliardo, allora il problema diventa completamente diverso. Lasciami sottolineare ancora, che non mi interessa la soluzione.

Tecniche standard

Non voglio assumere un programmatore che non sa nemmeno cosa significhi O (n). È assolutamente da sapere se hai avuto un'educazione decente in quella zona. Ma è anche importante non solo sapere cosa significa, ma applicare effettivamente tale conoscenza. Nel tuo esempio, voglio che un candidato si renda conto che non gli è consentito ordinare i dati (senza fare ulteriori domande mirate all'opzione di un bucket bucket o altri approcci di ordinamento O (n)) a causa dell'ordinamento richiesto O (n log n) in generale.

Allo stesso modo, altre domande dell'algoritmo si rivolgono a tecniche standard come la traversata di alberi o grafici o la ricorsione. Un candidato può scivolare su una di queste tecniche, il che non fa una buona impressione. In questi casi, tuttavia, mi piace scavare più a fondo per scoprire se il candidato ha un background CS. Naturalmente, dipende da quale sia la posizione target, ma di solito uno sviluppatore che non conosce le complessità del runtime, né le strutture di dati tipiche e i loro attraversamenti, non sarà di alcun aiuto.

Mentalità problematica

Dopo aver posto la domanda, controlli attentamente il candidato. Come reagisce? Qui ottieni i migliori risultati da candidati che non hanno assolutamente idea di come risolvere il problema all'inizio . A tale proposito, la domanda verifica cosa potrebbe accadere se si verificasse una situazione simile sul posto di lavoro in un secondo momento. Potresti imbatterti in un simile problema durante il tuo sviluppo ed è bene sapere come il tuo candidato affronta questi problemi, anche se non è in grado di risolverlo da solo.

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

Come rispondere

In generale, le migliori risposte che puoi dare per questo tipo di domande sono contro-domande! Dire subito una risposta fallisce sostanzialmente, e in realtà non è affatto una buona risposta, perché tutte queste domande suggeriscono compromessi, cosa che la tua risposta implica, senza che tu abbia le informazioni richieste ma che lo fai in modo intelligente scambio. Naturalmente, la qualità delle contro-domande varia tra i candidati.

Come nota generale sulle domande del colloquio: le contro-domande raramente sono 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 questo, e perché?" - Ho semplicemente contrastato con "Sono limitato a questi due?". Indovina da te, che tipo di reazione ricevi da un intervistatore per una contro-domanda del genere - e quanto sia facile per te mostrare effettivamente all'intervistatore di cosa sei capace.

A meno che tu non stia facendo domande su algoritmi / formule che il candidato deve conoscere per il lavoro (fluidodinamica, ad esempio, se la posizione lo richiede), non vedo il loro valore. Probabilmente il candidato si sta già preoccupando del modo in cui sono vestiti, di come stanno parlando, ecc ... se riescono a rispondere a una domanda di matematica sul posto non prova altro che forse come potrebbero andare in uno spettacolo televisivo.

Quando intervista, non faccio nemmeno domande di "programmazione" di per sé. Ho il candidato che descrive i loro progetti passati, come il loro codice ha raggiunto gli obiettivi, quali sono i loro approcci, ecc. Da ciò posso dire abbastanza rapidamente se il candidato sa cosa sta facendo o se è un poser.

Concordo sul fatto che i programmatori debbano conoscere molto bene gli algoritmi, anche con nuovi fantasiosi framework, ma non sono del tutto convinto di un rompicapo in un'intervista. La mia più grande preoccupazione sarebbe che in un ambiente reale, tu scriva algoritmi in condizioni molto diverse; in altre parole, non sotto pressione con qualcuno che ti guarda ogni colpo di scena, con almeno alcuni minuti per pensarci in silenzio. Per coloro che sostengono questo metodo di valutazione, quanto tempo in genere concedi alla persona per risolverlo? Credo che il codice non riguardi tanto la ricerca di una soluzione in un febbrile terrore di 3 minuti, quindi convincimi che questo è in realtà un buon modo per vedere come qualcuno gestirà un compito quotidiano.

Il problema con quella domanda specifica è che è quasi una domanda trabocchetto. Con una particolare intuizione, otterrai facilmente O (n), altrimenti avrai difficoltà a migliorare di O (n log n). Si riduce quasi a "L'hai mai visto prima?"

Non sono sicuro che ci siano buone domande algoritmiche. Se ne chiedessi uno basato sulla teoria dei grafi, per esempio, dipenderà da quanto gli intervistati avessero familiarità con la teoria dei grafi - e, se lo assumessi, lui o lei potrebbero essere abbastanza veloci sulla teoria dei grafi. Ancora una volta, torniamo a "Sei stato esposto a questo prima?"

Non c'è tempo in un'intervista regolare per risolvere seriamente i problemi, e mi rivolgo alle cose in modo diverso quando posso sedermi, usare Wikipedia e generalmente impiegare del tempo per capire le cose. Probabilmente non c'è tempo per l'intervistatore di discutere con attenzione ciò che l'intervistato sa in dettaglio e scegliere una domanda algoritmica adatta.

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

Vuoi una domanda che ti dia un'idea del candidato. Una domanda di algoritmo può dare una buona risposta, oppure no. E non mi riferisco al fatto che siano in grado di rispondere o meno. Se ci riescono e 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 congelano e differenziare il congelamento dal non avere capacità di problem solving potrebbe essere difficile.

La gente si lamenterà di aver chiesto qualsiasi cosa nelle interviste, per vari motivi. Il richiedente può congelare, il richiedente avrebbe potuto semplicemente cercare quella domanda, il richiedente potrebbe non sapere quel particolare pezzo di curiosità / tecnologia / qualunque cosa. Tutto ciò è vero, ma deve ancora avvenire un'intervista, e molti di noi in questa professione odiano questo. Odiamo l'idea di qualcuno seduto in giudizio nei nostri confronti. Abbiamo immediatamente evocato ragioni per cui potremmo essere giudicati ingiustamente o come il test potrebbe essere falso o giocato. La linea di fondo è, non importa.

Quello che vuoi veramente è un intervistatore con la capacità di determinare le abilità che possono o meno essere presentate durante il colloquio. Le domande sono solo gli strumenti. Per me, tutti i martelli sembrano uguali. Ma per qualcuno abbastanza abile con loro, sono sicuro che ci sia differenza.

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

Non mi piace richiedere che le risposte a questo tipo di domande siano "scrivere 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.

La domanda originale viene posta, dice l'intervistato, "iniziare dall'inizio e marciare verso la fine cercando il 'buco'". L'intervistatore dice che è troppo lento, perché N è gigantesco. L'intervistato inizia a discutere della ricerca binaria. L'intervistatore afferma che all'improvviso i dati non vengono più ordinati. L'intervistato dice "ordina, quindi cerca". "Adesso è troppo lento". Ecc. Ecc.