Puzzle logici ingannevoli: sono davvero utili per valutare le capacità di programmazione? [chiuso]

Nell'ultima intervista a cui ho partecipato, mi è stato chiesto di risolvere un enigma in cui mi sarei aspettato di misurare esattamente i litri d'acqua di bla dati due secchi con capacità - rispettivamente blah e blah litri. Non sono stato in grado di risolvere il puzzle in un dato tempo (~ 5 minuti).

L'intervistatore è rimasto un po 'deluso e ha detto che un programmatore deve avere "queste" abilità. Non ho avuto le capacità di cui stava parlando.

Mi sono sempre sentito strano per questo tipo di enigmi che normalmente vengono richiesti durante la programmazione dei colloqui di lavoro. Non capisco quale sia la connessione tra tali enigmi e la programmazione. Quali abilità intendono valutare gli intervistatori con tali enigmi?

Alcune persone li chiedono nel tentativo di valutare le tue capacità e il tuo approccio alla risoluzione dei problemi. Personalmente, non penso che tali enigmi forniscano un indicatore preciso. Nel "mondo reale", si dispone di più di cinque minuti per capire se il vostro fare con un bin packing vs uno zaino problema, per esempio. Inizialmente, a volte è facile fraintendere il problema attuale fino a quando non si è nel mezzo dell'applicazione della soluzione sbagliata. Questo succede alle persone con 1, 5, 10 o addirittura 20 anni di esperienza.

I "puzzle" delle migliori interviste sono quelli in cui ti siedi davanti a un computer per risolvere un problema nel dominio in cui richiedi esperienza. Non mi piace anche il pensiero "Beh, un programmatore dovrebbe essere in grado di ..." perché non tiene conto del fatto che le persone diventano ansiose quando vengono colpite da qualcosa di inaspettato in un ambiente già stressante. Certo, si potrebbe risolvere che se tu avessi il tempo di pensarci .. e forse si potrebbe risolvere più velocemente se si rese conto che la tua vita sarebbe finita se non l'avete fatto. Vuoi lavorare da qualche parte dove la tua vita sarà finita se non riesci a risolvere i problemi in cinque minuti ? Verrai licenziato se non puoi ?

Tutti i grandi programmatori dovrebbero essere anche i solutori del sudoku campione? Sono sicuro che ce ne sono molti, ma non è come una sorta di prerequisito per la competenza.

Non sto dicendo che si dovrebbe non essere testato su come ci si avvicina problemi, ma i test dovrebbe essere divertente e invitare il 'migliore' che il richiedente deve dare, data la loro area di competenza. Dimostrando che sei intelligente come un personaggio che ritrae Bruce Willis sembra tipo di inutile, considerando che i produttori hanno trascorso una bella somma per ottenere quella scena solo a destra.

In altre parole, se ti accorgi di essere intervistato da qualcuno che ha poca comprensione di ciò che effettivamente farai , scusati per andare in bagno e non tornare mai più.

Microsoft ha iniziato a utilizzare queste domande all'inizio degli anni '80. Man mano che Microsoft riscuoteva un notevole successo, altre aziende iniziarono a copiarle, ma un paio di punti chiave si persero nella traduzione.

A quel tempo, Microsoft stava cercando di ricoprire un sacco di posizioni tecniche ma non di programmazione: scrittori tecnici, tester, supporto telefonico, ecc. Questi non erano lavori comuni ai giorni nostri e le persone con esperienza effettiva in queste aree erano difficili da trova. In alternativa, Microsoft pensava di poter assumere persone davvero intelligenti, intelligenti e flessibili e di addestrarle al lavoro. Dal momento che queste persone non avevano un background di programmazione, porre loro domande di programmazione nell'intervista era inutile. Gli enigmi sono stati scelti per provare a individuare persone intelligenti e con abilità analitiche eccezionalmente buone. Ai programmatori venivano generalmente dati problemi di programmazione con la lavagna, anche se a pranzo o cena potevano anche essere richiesti enigmi.

Queste domande non sono mai state pensate per essere pass-fail. Dovevano essere l'inizio di una conversazione su come affrontare il problema e su come hai pensato a problemi che non avresti mai visto prima. L'unico modo sicuro per "fallire" era rifiutarsi di provare a risolvere il problema. All'epoca questa era una strategia innovativa e non potevi semplicemente cercare le domande su Google.

Modificare:

Qualche tempo dopo aver scritto questa risposta ho letto The Computer Boys Take Over , una storia di informatica istituzionale negli anni '50 e '60. Apparentemente la pratica di chiedere ai rompicapo e agli enigmi dei candidati di programmare lavori risale agli anni '50. Gli Stati Uniti stavano cercando di informatizzare il proprio sistema di difesa aerea e IBM stimò 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 provati diversi approcci: test di attitudine alla programmazione astratta, reclutamento di matematici come programmatori, reclutamento di giocatori di scacchi e risolutori di cruciverba e screening dei candidati con enigmi e rompicapo.

Alla fine sono riusciti a reclutare abbastanza programmatori per completare il progetto, ma la conclusione è stata che nessuno dei metodi di screening era migliore della possibilità di identificare le reclute che hanno avuto un notevole successo come programmatori.

Sono utili? No, non proprio. Una volta erano così comuni in Microsoft che venivano persino chiamati "domande di 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) li conoscerà comunque e in secondo luogo, anche se possono risolverli come dimostra che sarà un buon dev / test / PM.

Per questi motivi raramente vengono più richiesti a Microsoft. È molto meglio porre domande di codifica o domande di risoluzione di problemi che non richiedono una risposta "ingannevole". In altre parole, devi porre domande che ti consentano di esplorare le capacità e il comportamento del candidato mentre cercano di affrontare il problema: come intervistatore voglio che facciano domande, escoglino soluzioni e poi torni indietro quando scoprono un problema, forse nemmeno trovare una soluzione nel tempo che hanno ma almeno risolverlo in modo sensato. Ciò riflette il lavoro della vita reale. Non ho mai dovuto misurare 3 pinte usando 2 secchi e un pollo (o qualunque fosse la domanda).

Detto questo, mi sono state poste un paio di domande trabocchetto ai miei tempi, e ora mi considero un esperto nel trasporto di polli e volpi in piccole imbarcazioni e nel calcolo della vita di una mosca che vive su un treno. Non ho mai dovuto usare queste informazioni, ma chissà, forse un giorno ...

Potresti voler leggere il libro Come faresti a spostare il Monte Fuji? . Si parte dal ragionamento secondo cui molte persone usano indovinelli durante le interviste, e la mia opinione è che si tratta di una combinazione di comportamenti di culto del carico ( "Microsoft lo fa, e se vogliamo avere successo come loro, allora facciamo meglio quello che fanno do " ) e fraternity hazing ( " per Dio! Ho dovuto rispondere a queste domande e faresti meglio a credere che il prossimo dovrà rispondere! " ).

La storia di queste domande come pratica di intervista è iniziata con William Shockley negli anni '50. Erano una specie di domanda di intervista della Silicon Valley abbastanza comune che gli intervistatori ponevano perché altri intervistatori lo stavano facendo (e forse sapevano qualcosa che questo intervistatore non sapeva?). Shockley li intendeva come un test di intelligenza, e la domanda con i 2 secchi era su uno dei test del QI di Stanford Binet originale nel 1916.

Molto probabilmente, le persone che intervistano in realtà vogliono vedere come cerchi le risposte, quindi porranno domande impossibili da calcolare, come ad esempio quante pompe di benzina ci sono nella tua città. Questi tipi di problemi sono problemi di Fermi . Due interessanti post sul blog di Jeff su questo argomento sono la domanda più difficile sul colloquio di intervista e quanto sei bravo in uno stimatore? Parte III .

Personalmente, ho una scarsa opinione di questo tipo di domande in quanto vengono generalmente utilizzate da intervistatori che non sanno cosa stanno facendo, né come cercare sviluppatori. A meno che non lavorerai per un'azienda che crea enigmi / indovinelli, essi appartengono al cumulo della storia insieme a "qual è la tua più grande debolezza" (rispondi alla verità e finisci la tua intervista in modo negativo) o "perché sono chiusini rotondi "(non tutti sono).

Altri hanno fornito risposte che ho votato per necessità . Il motivo per cui scrivo un'altra risposta è perché ciò che voglio dire probabilmente non si adatta a un commento, e perché bisogna dire qualcosa 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 delle loro pratiche di sviluppo software, integrazione, test, controllo della versione e gestione della configurazione, dei team e delle responsabilità, della tecnologia e della progettazione. È stata un'intervista di un'intera giornata che includeva il pranzo con la gente che mi ha intervistato. Col senno di poi, si trattava di adattarmi in modo produttivo a ciò che stavano già facendo.

Da allora, le buone interviste sono state tutte lunghe, da una a due ore di conversazioni sullo sviluppo del software. Non ci sono state domande per la risoluzione di problemi, enigmi e sfide di programmazione.

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

1. Quali sono le tue preferenze sul linguaggio di programmazione? Perché?
2. Come affrontare la gestione delle eccezioni?
3. I vantaggi del design a strati non sono forse un mito?
4. L'integrazione continua non è un peso per l'efficienza?
5. Chiunque abbia scritto un pezzo di codice dovrebbe possederlo, giusto?
6. Cosa fai per entrare nel "flusso".
7. Come dovrebbero essere inclusi i difetti segnalati in un piano di progetto?
8. ...

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

Gli studi più scientifici sullo sviluppo efficace del software dal momento che Peopleware affermano che i migliori programmatori sono quelli che comprendono le dinamiche dello sviluppo del software, anche se non hanno i QI più alti. Preferirei prendere un novellino desideroso di imparare rispetto a qualcuno con nanni di esperienza che si riduce a 1anni di esperienza ripetuti n. La mia propensione personale è verso i candidati che tendono a pensare fuori dagli schemi, e allo stesso tempo sanno come adattarsi all'attuale (mio) riquadro.

Possono essere utili nella valutazione delle capacità di problem solving , che è ovviamente uno degli aspetti chiave della programmazione.

Come intervistatore di molte persone nel corso degli anni, di solito non faccio domande sul tipo di gotcha proprio come quella che sembra descrivere, ma potrei anche chiedere qualcosa e chiedere "come risolveresti ...".

Le mie aspettative in quel caso sono di sentirti esprimere il tuo approccio al problema. Quali altri dati proveresti a raccogliere? Come testeresti le tue ipotesi, ecc.

Queste sono solo pratiche di assunzione di voodoo. Altre persone fanno queste domande così si sentono come dovrebbero. Sanno che non rispondere alla domanda è "negativo" e che rispondere è "buono", ma non possono dirti perché al di là delle non risposte come "uno sviluppatore ha bisogno di queste abilità". Sono una perdita di tempo e un indicatore del fatto che l'intervistatore non è un intervistatore competente.

Questa è la razionalità old-skool che devi avere abilità logiche di base; qualsiasi altra cosa può essere insegnata. Ma questo non è del tutto vero. Leggere la logica booleana , le condizioni e i loop, non è lo stesso che riuscire a risolvere un enigma logico .

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

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

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

L'intervistatore deve aver fatto riferimento alla capacità di problem solving e di logica, che fa parte del lavoro quotidiano di un programmatore. Quando ti viene dato un problema, devi essere in grado di analizzarlo, suddividerlo e scrivere una soluzione per esso utilizzando l'approccio più ottimale.

Potresti sostenere quanto un puzzle del genere rappresenti la tua capacità di farlo. Non vedo il merito di porre una domanda enigmistica invece di porre semplicemente un problema di programmazione nella vita reale.

La programmazione non riguarda la scrittura di righe di codice, si tratta di risolvere problemi per e da altre persone (clienti, utenti, ecc.).

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

Ecco perché è importante disporre di capacità di risoluzione dei problemi e perché è stato testato.

Detto questo, non sono sicuro che risolvere i rompicapo sia il modo migliore per valutare qualcuno.

I puzzle nelle interviste si dividono in due categorie: "puzzle logici" (come quello che ti è stato chiesto) e categoria "pensa diversamente". La categoria pensa diversamente (non sono sicuro che siano anche chiamati puzzle laterali?) Di solito sono 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 al massimo una o forse due soluzioni e possono essere raggiunti con una logica semplice. E credo che i puzzle logici siano buoni in una certa misura perché il processo necessario per risolverli è molto il modo in cui un programmatore deve pensare nella vita reale.

Il tipo "pensa in modo diverso" mi infastidisce senza fine perché ti costringono a fare 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 i tuoi presupposti, o viceversa, hai perso. C'è troppo spazio perché l'intervistatore non sia d'accordo con la tua soluzione.

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

Il problema con i puzzle, in entrambi i casi, è che i programmatori non così bravi sanno che solo cercando soluzioni a tali puzzle comuni in 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 puzzle. È spiegato alla perfezione 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, durante la conferenza del Premio Turing del 1972, Edsger Dijkstra pubblicò un documento intitolato "L'umile programmatore". Sosteneva che la maggior parte della programmazione è un tentativo di compensare le dimensioni strettamente limitate dei nostri teschi. Le persone che sono le 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 rifiutano di accettare il fatto che il loro cervello non è all'altezza del compito. I loro ego impediscono loro di essere grandi programmatori. Più tuimpara a compensare il tuo piccolo cervello, migliore sarà il tuo programmatore . Più umile sei, più velocemente migliorerai.

2. Tali enigmi possono essere utili durante l'intervista, ma solo se l'intervistatore osserva il processo , non risulta se stesso.

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

Esistono un paio di modi diversi per esaminare tali problemi:

1. Conoscere una soluzione precedente. Nel film ... Die Hard with a Vengeance ... spiegamelo ...? essere un esempio di conoscenza di una soluzione per il caso in cui i blah sono rispettivamente 4,3 e 5. Alcune persone saranno in grado di attingere rapidamente alla propria conoscenza interna di una soluzione passata e di adattarla, se necessario. Questo di solito è ciò che credo si aspetterebbe da un intervistatore 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 diofantea. Quindi la domanda è quanto velocemente puoi usare ciò che viene dato e trovare una soluzione al problema in modo creativo insieme a spiegare perché ciò che hai è una soluzione valida al problema.

O potrebbe essere ciò che fa passare la domanda in modo soddisfacente sebbene in ogni caso ci sia anche un po 'di una prova delle proprie capacità comunicative come si potrebbe anche provare una risposta di "È davvero rilevante per la posizione che sto applicazione? Quando sono state utilizzate queste abilità per l'ultima volta? " ciò potrebbe portare a un dialogo interessante se l'intervistatore si aprirà su ciò che esattamente vogliono vedere che forse un approccio alternativo potrebbe essere visto come più efficace qui.

Non è un problema particolarmente complicato. 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 brevissimo tempo. Non presentiamo tali problemi nelle interviste, ma penso che sia ragionevole porre tali domande. Sono sicuramente più utili di 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 CS poiché non è possibile prevedere molte sfide che il lavoro potrebbe avere in serbo.

Quindi il potenziale datore di lavoro deve indovinare le tue prestazioni future.

Gradi, raccomandazioni e GPA possono essere ottenuti con tempo / impegno e ingegneria sociale, l'esperienza di lavoro può essere abbellita e / o falsa e test standardizzati sono francamente troppo basilari per essere eccessivamente indicativi di abilità. Quindi il curriculum può dare qualche indicazione dei livelli di impegno / impegno nella tua storia, ma nessuno di questi parlerà della tua effettiva capacità di risolvere problemi difficili che si presentano nel mondo dell'informatica. Non riesco a pensare a un modo migliore per prevedere quel tipo di abilità rispetto ad alcuni buoni puzzle di logica / mathy / CSy.

Ricorda che è un gioco d'ipotesi, e la realtà è che tutte le cose sono uguali a chiunque di noi preferirebbe assumere qualcuno in grado di risolvere quei puzzle piuttosto che uno che non può.

Sì, potresti studiare i puzzle delle interviste, ma penso che ti troverai bruciato se il puzzle dato non corrisponde a quelli che studi ... e finché non memorizzi i puzzle e le loro soluzioni, magari studiando i puzzle essi stessi ti renderanno una persona più intelligente in un modo reale, come ogni vera istruzione dovrebbe.