Ingannevoli puzzle logici - Sono davvero utili per valutare le abilità di programmazione? [chiuso]

Alcune persone li chiedono nel tentativo di valutare la tua capacità e l'approccio alla risoluzione dei problemi. Personalmente, non penso che questi puzzle forniscano un indicatore accurato. Nel "mondo reale", hai più di cinque minuti per capire se hai a che fare con un imballaggio del contenitore contro un < per esempio, un problema di href="http://en.wikipedia.org/wiki/Knapsack_problem"> back pack . Inizialmente, a volte è facile fraintendere il problema fino a quando non si è nel mezzo dell'applicazione della soluzione sbagliata. Ciò accade a persone con 1, 5, 10 o anche 20 anni di esperienza.

I migliori "rompicapo" per interviste sono quelli in cui ti siedi al computer per risolvere un problema nel dominio in cui rivendichi l'esperienza. Inoltre, non mi piace "Beh, un programmatore dovrebbe essere in grado di ..." pensare perché non tiene conto del fatto che le persone diventano ansiose quando vengono colpite da qualcosa di inaspettato in un ambiente che è già stressante. Certo, potresti risolverlo se hai tempo per pensarci .. e forse potresti risolverlo più velocemente se ti rendessi conto che la tua vita sarebbe finita se non lo facessi. Vuoi lavorare da qualche parte dove la tua vita sarà finita se non riesci a risolvere i problemi in cinque minuti ? Sarai licenziato se non puoi ?

Tutti i grandi programmatori dovrebbero essere anche campioni solisti di sudoku? Sono sicuro che sono molti, ma non è come una sorta di prerequisito per la competenza.

Non sto dicendo che dovresti non essere testato su come ti avvicini ai problemi, ma i test dovrebbero essere divertenti e invitare il "migliore" che il candidato deve dare, data la loro area di competenza. Dimostrando di essere intelligente come un personaggio che interpreta Bruce Willis sembra un po 'inutile, considerando che i produttori hanno speso una bella somma per ottenere quella scena giusta giusta.

In altre parole, se rilevi di essere intervistato da qualcuno che ha poca comprensione su che cosa farai effettivamente , scusa se stesso per andare in bagno e non tornare più.

Microsoft ha iniziato a utilizzare queste domande all'inizio degli anni '80. Con il notevole successo di Microsoft, altre aziende hanno iniziato a copiarle, ma un paio di punti chiave si sono persi nella traduzione.

All'epoca, Microsoft stava cercando di riempire un sacco di posizioni tecniche ma non di programmazione: scrittori tecnici, tester, supporto telefonico, ecc. Questi non erano lavori comuni nel corso della giornata e persone con esperienza reale in queste aree erano difficili da trovare In alternativa, Microsoft pensava di poter assumere persone davvero intelligenti, intelligenti, flessibili e addestrarle nel lavoro. Dal momento che queste persone non avevano un background di programmazione, chiedere loro domande di programmazione nell'intervista era inutile. Gli indovinelli sono stati scelti per provare e individuare persone che erano intelligenti e avevano eccezionali capacità analitiche. Ai programmatori venivano generalmente dati problemi di programmazione sulla lavagna bianca, anche se potevano essere richiesti enigmi durante il pranzo o la cena.

Queste domande non sono mai state intese come pass-fall. Dovevano essere l'inizio di una conversazione su come avresti affrontato il problema e su come pensavi a problemi che non avevi mai visto prima. L'unico modo sicuro per "fallire" era rifiutarsi di provare a risolvere il problema. All'epoca questa era una nuova strategia, e non potevi semplicemente cercare le domande su Google.

Modifica:

Qualche tempo dopo aver scritto questa risposta ho letto The Computer Boys Take Over , una storia di informatica istituzionale negli anni '50 e anni '60. Apparentemente la pratica di chiedere teaser e indovinelli di candidati per lavori di programmazione risale agli anni '50. Gli Stati Uniti stavano cercando di automatizzare il proprio sistema di difesa aerea e IBM stimava che avrebbero avuto bisogno di diverse migliaia di programmatori per fare il lavoro. La risposta fu shock e costernazione: c'erano solo un paio di dozzine di "programmatori professionisti" in tutto il mondo. Sono stati sperimentati diversi approcci: test di attitudine alla programmazione astratta, reclutamento di matematici come programmatori, reclutamento di giocatori di scacchi e solutori di cruciverba e screening dei candidati con enigmi e rompicapi.

Alla fine riuscirono a reclutare un numero sufficiente di programmatori per completare il progetto, ma la conclusione era che nessuno dei metodi di screening era migliore del caso nell'identificare le reclute che avevano avuto un notevole successo come programmatori.

Sono utili? No, non proprio. Una volta erano così comuni in Microsoft che si sono persino chiamati "domande Microsoft" e ci sono stati libri scritti su di loro, questo è in realtà una buona lettura ..

Ci sono 2 problemi con loro. In primo luogo, se il richiedente fa ricerche (e legge il libro), le conosceranno comunque e in secondo luogo, anche se possono risolverle, come dimostra che sarà un buon dev / test / PM.

Per questi motivi vengono raramente richiesti a Microsoft. È molto meglio porre domande di codifica o domande di risoluzione dei problemi che non richiedano una risposta "ingannevole". In altre parole è necessario porre domande che permettano di esplorare le capacità e il comportamento del richiedente nel tentativo di affrontare il problema - come intervistatore voglio che facciano domande, escogitino soluzioni e poi tornino in pista quando capiscono un problema, forse nemmeno trovare una soluzione nel tempo che hanno, ma almeno affrontarlo in modo sensato. Ciò riflette il lavoro della vita reale. Non ho mai dovuto misurare 3 pinte usando 2 secchi e un pollo (o qualsiasi altra cosa fosse la domanda).

Detto questo, mi è stato chiesto un paio di domande trabocchetto nel mio tempo, e ora mi considero un esperto nel trasporto di polli e volpi su piccole imbarcazioni e nel calcolare la vita di una mosca che vive su un treno. Non ho mai dovuto usare questa informazione, ma chissà, forse un giorno ....

Potresti voler leggere il libro How Would You Move Mount Fuji? . Il ragionamento è che molte persone usano enigmi nell'intervista, e la mia opinione è che si tratta di una combinazione di comportamento settoriale del carico ( "Microsoft lo fa, e se vogliamo avere il successo che hanno, allora è meglio fai quello che fanno ") e la fraternità nonnina (" di gosh !, ho dovuto rispondere a queste domande e faresti meglio a credere che il prossimo ragazzo dovrà rispondere loro! ").

La storia di queste domande come pratica di intervista è iniziata con William Shockley negli anni '50. Erano una sorta di domanda di intervista abbastanza comune della Silicon Valley che gli intervistatori hanno chiesto perché altri intervistatori lo stavano facendo (e forse sapevano qualcosa che questo intervistatore non sapeva?). Shockley li aveva intesi come test di intelligenza, e la domanda con i 2 bucket era su uno degli originali Stanford Binet IQ prova nel 1916.

Molto probabilmente, le persone che fanno l'intervista vogliono davvero vedere come si cercano le risposte, quindi saranno impossibili da calcolare le domande, come quante pompe di benzina ci sono nella tua città. Questi tipi di problemi sono Problemi Fermi . Due post interessanti del blog Jeff su questo argomento sono La domanda più difficile del rompicapo di un'intervista mai e Quanto sei bravo uno stimatore? Parte III .

Personalmente, ho una scarsa opinione su questo tipo di domande, in quanto sono generalmente utilizzate da intervistatori che non sanno cosa stanno facendo, né come cercare gli sviluppatori. A meno che tu non abbia intenzione di lavorare per una società che crea enigmi / enigmi, essi appartengono alla raccolta della storia insieme a "qual è la tua più grande debolezza" (rispondi alla verità e alla fine interrompi il tuo colloquio) o "perché sono coperti di tombini "(non tutti lo sono).

Gli altri hanno fornito le risposte che ho promosso a causa di devono . La ragione per cui scrivo un'altra risposta è perché quello che voglio dire probabilmente non rientra in un commento, e perché qualcosa deve essere detto su come può essere un buon colloquio di lavoro di programmazione.

Nella prima buona intervista che ricordo, abbiamo parlato molto, senza fretta. Prima per un'ora, al telefono, sulla progettazione orientata agli oggetti e sui pro e contro dell'implementazione in C ++. Poi, sul posto, ho parlato con diverse persone sulle loro pratiche di sviluppo del software, integrazione, test, controllo della versione e gestione della configurazione, su team e responsabilità, sulla tecnologia e sulla progettazione. Era un'intervista di un'intera giornata che includeva il pranzo con le persone che mi hanno intervistato. Con il senno di poi, si trattava del fatto che avrei adattato produttivamente quello che stavano già facendo.

Da allora, le buone interviste sono state lunghe conversazioni da uno a due ore sullo sviluppo del software. Non ci sono state domande di risoluzione dei problemi, nessun enigma e nessuna sfida di codifica.

Se dovessi intervistare qualcuno per un lavoro di programmazione oggi, procederei con simili. Richiederei opinioni su una vasta gamma di argomenti e lasciamo da parte la profondità:

1. Quali sono le tue preferenze di lingua di programmazione? Perché?
2. Come avvicinarsi alla gestione delle eccezioni?
3. I vantaggi del design a strati non sono forse un mito?
4. L'integrazione continua non rappresenta un onere per l'efficienza?
5. Chi ha scritto un pezzo di codice dovrebbe possederlo, vero?
6. Che cosa fai per entrare nel "flusso".
7. In che modo i difetti segnalati devono essere inclusi in un piano di progetto?
8. ...

Queste sono domande con più di una risposta, e riguardano argomenti su cui uno sviluppatore di software dovrebbe avere un'opinione informata. Sono pienamente d'accordo con le risposte che menzionano i precedenti problemi reali vissuti come argomento di conversazione (non come domande).

Gli studi più scientifici sull'efficace sviluppo del software poiché Peopleware dicono che i migliori programmatori sono quelli che capiscono le dinamiche dello sviluppo del software, anche se non hanno il QI più alto. Preferirei prendere un debuttante che sia impaziente di imparare di qualcuno con n di anni di esperienza che si riduce a 1 anno di esperienza ripetuto n volte. Il mio pregiudizio personale è nei confronti dei candidati che tendono a pensare fuori dagli schemi, e allo stesso tempo sanno come adattarsi alla casella (mia) attuale.

Possono essere utili per valutare le abilità di risoluzione dei problemi , che è ovviamente uno degli aspetti chiave della programmazione.

Come intervistatore di molte persone nel corso degli anni, di solito non faccio domande tipo gotcha simili a quelle che sembra descrivere, ma potrei benissimo chiedere qualcosa e chiedere "come faresti risolvere ... ".

Le mie aspettative in tal caso sono sentirti articolare il tuo approccio al problema. Quali altri dati vorresti raccogliere? Come verificherai le tue ipotesi, ecc.

Queste sono solo pratiche di assunzione voodoo. Altre persone fanno queste domande in modo che si sentano come dovrebbero. Sanno che non rispondere alla domanda è "cattivo" e rispondere è "buono", ma non possono dirti perché oltre le non risposte come "uno sviluppatore ha bisogno di queste capacità". Sono una perdita di tempo e un indicatore che l'intervistatore non è un intervistatore competente.

Questo è il razionalismo della vecchia scuola che devi avere abilità logiche di base; qualsiasi altra cosa può essere insegnata. Ma non è del tutto vero. Leggere Logica booleana , condizioni e cicli, non è la stessa cosa che riuscire a risolvere un puzzle logico .

Detto questo, ai tempi dei linguaggi procedurali, probabilmente era vero che qualcuno che poteva risolvere questi problemi avrebbe avuto una maggiore propensione a poter applicare qualsiasi problema in termini di interruttori. Ma a mio parere, la programmazione OO / funzionale richiede una mentalità ingegneristica, che è abbastanza diversa (anche se non contraddittoria).

Personalmente, non sono sicuro che vorrei un lavoro con un'azienda che pensava che la logica fosse più importante delle capacità di programmazione pratica.

Disclaimer: sono molto bravo nei puzzle logici e probabilmente non avrei avuto il mio inizio in questa linea di lavoro senza questo razionalismo.

L'intervistatore deve aver fatto riferimento alle capacità di risoluzione dei problemi e di logica, che fa parte del lavoro quotidiano di un programmatore. Quando viene fornito un problema, è necessario essere in grado di analizzarlo, suddividerlo e scrivere una soluzione utilizzando l'approccio ottimale.

Potresti discutere di quanto un simile puzzle rappresenti la tua capacità di farlo. Non vedo il merito di fare una domanda di enigma invece di chiedere un vero problema di programmazione della vita.

La programmazione non riguarda la scrittura di righe di codice, ma la risoluzione di problemi per e da altre persone (cliente, utente, ecc.).

Succede che per i programmatori la soluzione assume la forma di un programma.

Ecco perché è importante avere capacità di problem solving e perché è testato.

Detto questo, non sono sicuro che risolvere un puzzle complicato sia il modo migliore per valutare qualcuno.

Gli enigmi delle interviste si dividono in due categorie: "puzzle logici" (come quello che ti è stato chiesto) e "pensa in modo diverso". La categoria di pensare in modo diverso (non sono sicuro che vengano chiamati anche puzzle laterali?) Sono solitamente di questo tipo: quante foglie ci sono in quell'albero? o Quanti sarti sono presenti nella tua città?

Sto bene con "Puzzle logici" perché hanno una o forse due soluzioni al massimo e possono essere raggiunte con una logica semplice. E credo che i puzzle logici siano buoni in una certa misura perché il processo necessario per risolverli è proprio il modo in cui un programmatore deve pensare nella vita reale.

Il tipo "pensa in modo diverso" non mi infastidisce perché ti costringono a formulare ipotesi e, quindi, a fare alcuni calcoli basati sulle ipotesi. In poche parole, se il tuo intervistatore è d'accordo con la tua logica ma non con le tue ipotesi, o viceversa, hai perso. C'è troppo spazio per l'intervistatore per non essere d'accordo con la tua soluzione.

Quando prendo le interviste non chiedo enigmi logici. Motivazione: la maggior parte dei candidati, anche quelli con 3-4 anni di esperienza, falliscono o si arrendono quando chiedo loro di codificare semplici problemi da manuale come serie di Fibonacci o palindromi.

Il problema con gli enigmi, in entrambi i casi, è che i programmatori non-così-buoni sanno che solo guardando le soluzioni a tali enigmi comuni sulla rete possono impressionare gli intervistatori. Pochissime persone saranno abbastanza oneste da dire che conoscono già la soluzione.

Due punti:

1. La programmazione è principalmente diversa dalla risoluzione di enigmi. È spiegato per errore da Steve McConnell in "Code Complete":

   Che cosa? Non devi essere superintelligente? No, non lo fai. Nessuno è abbastanza intelligente da programmare i computer. La piena comprensione di un programma medio richiede una capacità quasi illimitata di assorbire i dettagli e una pari capacità di comprenderli tutti allo stesso tempo. Il modo in cui focalizzi la tua intelligenza è più importante di quanta intelligenza hai. Come menzionato nel Capitolo 5, alla conferenza del Premio Turing del 1972, Edsger Dijkstra consegnò un documento intitolato "The Humble Programmer." Sosteneva che la maggior parte della programmazione è un tentativo di compensare le dimensioni strettamente limitate dei nostri crani. Le persone che sono i migliori nella programmazione sono le persone che si rendono conto di quanto siano piccoli i loro cervelli. Sono umili. Le persone che sono le peggiori nella programmazione sono le persone che si rifiutano di accettare il fatto che il loro cervello non è all'altezza del compito. Il loro ego li impedisce di essere dei grandi programmatori. Più tu impari a compensare il tuo piccolo cervello, migliore sarà un programmatore . Più sei umile, più velocemente migliorerai.

2. Questi enigmi possono essere utili durante l'intervista, ma solo se l'intervistatore osserva il processo , non si risolve da solo.

Ma idealmente i puzzle dovrebbero essere più complicati e legati alla programmazione (come un piccolo progetto di 2 ore), a mio parere. Il fatto è che gli intervistatori sono persone e non hanno perfette "capacità di intervistare".

Ci sono un paio di modi diversi per esaminare tali problemi:

1. Conoscere una soluzione precedente. Nel film ... Die Hard with a Vengeance ... spiegami questo ...? essere un esempio di conoscenza di una soluzione per il caso in cui i bla sono rispettivamente 4,3 e 5. Alcune persone saranno in grado di sfruttare rapidamente la propria conoscenza interna di una soluzione passata e adattarla se necessario. Questo di solito è ciò in cui credo che un intervistatore si aspetterebbe che potrebbe essere o meno una buona idea.

2. Abilità di improvvisazione creativa. Questo sarebbe il caso se non si conosce una soluzione precedente o addirittura si riconosce il problema come qualcosa che si potrebbe modellare come un'equazione diophantina. Quindi la domanda è quanto velocemente puoi usare ciò che viene dato e trovare una soluzione al problema in modo creativo insieme a spiegare perché quello che hai è una soluzione valida al problema.

O potrebbe essere ciò che riesce a superare la domanda in modo soddisfacente anche se in ogni caso c'è anche un po 'di test delle proprie capacità comunicative, come si potrebbe anche provare una risposta di "È davvero rilevante per la posizione che Sto applicando? Quando sono state usate queste abilità? " questo può portare ad un dialogo interessante se l'intervistatore si aprirà su cosa esattamente vogliono vedere che forse un approccio alternativo potrebbe essere visto come più efficace qui.

Non è un problema particolarmente difficile. Sono richiesti solo tre passaggi e ci sono solo due scelte per ogni passaggio. Sarei sorpreso se qualcuno dei miei colleghi non fosse in grado di risolverlo in tempi molto brevi. Non presentiamo tali problemi nelle interviste, ma penso che sia ragionevole porre tali domande. Sono certamente più utili delle domande dettagliate sulla sintassi o sulle librerie.

OTOH, penso che i problemi di programmazione siano più utili.

Devi ricordare che non c'è modo di sapere con assoluta certezza che qualcuno sarà bravo in un lavoro. Soprattutto un lavoro di CS, dal momento che molte sfide che il lavoro potrebbe avere in serbo non possono essere previste.

Quindi il potenziale datore di lavoro deve indovinare il rendimento futuro.

Gradi, raccomandazioni e GPA possono essere ottenuti con tempo / impegno e ingegneria sociale, l'esperienza lavorativa può essere abbellita e / o falsa, e i test standardizzati sono francamente troppo basici per essere eccessivamente indicativi di abilità. Quindi il curriculum potrebbe dare qualche indicazione sui livelli di impegno / impegno nella tua storia, ma nessuno di questi parlerà della tua effettiva capacità di risolvere i problemi seri che emergono nel mondo dell'informatica. Non riesco a pensare a un modo migliore per predire quel tipo di abilità rispetto a qualche buona logica / mathia / puzzle di CSy.

Ricorda che è un gioco di indovinelli, e la realtà è che tutto ciò che è uguale a qualcuno di noi preferirebbe assumere qualcuno in grado di risolvere quei enigmi piuttosto che uno che non può.

Sì, potresti studiare i puzzle delle interviste, ma penso che ti ritroverai bruciato se il puzzle fornito non corrisponde a quello che studi ... e finché non memorizzi i puzzle e le loro soluzioni, forse studiare gli enigmi ti renderà una persona più intelligente in un modo reale, come ogni vera educazione dovrebbe.