Come reagire alle domande sbagliate / non risposte durante l'intervista? [chiuso]

Oggi ho tenuto la mia prima intervista con potenziali stagisti. Mentre queste sono state domande per lo più aperte, ho avuto alcune banali attività di programmazione per loro:

• Scrivi una funzione che restituisce vero se i lati del triangolo (tutti i numeri interi) a, bec possono rappresentare un triangolo rettangolo .
• FizzBuzz.
• Calcola l'ennesimo elemento di Fibonacci usando la ricorsione (se non sapessero cosa fosse Fibonacci , scriverei anche loro la definizione F (n) = F (n-1) + F (n-2); F (1) = 1; F (0) = 1).
• Implementare la struttura Elenco per intero e scrivere la funzione per invertire.

Questi sono ovviamente compiti molto facili e non ero preparato per qualcuno che non li risolvesse.

Come dovrei agire quando hanno difficoltà con queste domande? Devo rinunciare alla risposta? Dare un consiglio dopo l'altro (l'ho fatto e ho finito per risolvere il problema da solo)? O semplicemente andare avanti (o forse semplicemente fermarsi) con l'intervista?

ps. Avendo problemi con le domande, non intendo come avere un bug, voglio dire se non possono nemmeno iniziare. Questo è stato un caso con domande di Fibonacci ed Elenco.

Hai detto che stai intervistando per le posizioni degli stagisti nella domanda, quindi questo è da quel punto di vista, per gli sviluppatori a tempo pieno la barra sarà un po 'più alta.

Quando stai intervistando stagisti, devi ricordare che potrebbero non aver completato i loro studi e che potrebbero anche essere entrati al college senza precedenti in programmazione e informatica. Pertanto, è necessario ridimensionare le aspettative rispetto a ciò che ci si può ragionevolmente aspettare che qualcuno conosca e al grado di prestigio della posizione (ad esempio, Google può cavarsela con le aspettative di cui una società di cui la gente non ha sentito parlare).

Osservando le domande che hai presentato, probabilmente le vedrei come segue in un'intervista:

1) Scrivi una funzione che ritorni vera se i lati del triangolo (tutti i numeri interi) a, bec possono rappresentare un triangolo rettangolo.

Applicazione di base della geometria con semplice codifica, la maggior parte degli studenti dovrebbe essere in grado di farlo senza troppe difficoltà. Al massimo potrebbe essere necessario un promemoria del teorema di Pitagora se mostrano un po 'di stress a causa del fatto di essere in un'intervista. Questo potrebbe quasi essere visto come un problema di "ego boost" in quanto può aiutare a sistemare alcune persone se sono molto nervose durante l'intervista.

2) FizzBuzz

Ancora una volta, un'altra applicazione di alcune dichiarazioni di controllo di base. Gli studenti che non sono stati esposti all'operatore del modulo, o che non lo hanno usato molto, potrebbero aver bisogno di ricordarselo, ma non dovrebbero riscontrare problemi reali nella risoluzione del problema.

3) Calcola l'ennesimo elemento di Fibonacci usando la ricorsione (se non sapessero cosa fosse Fibonacci, scriverei anche la definizione F (n) = F (n-1) + F (n-2); F (1 ) = 1; F (0) = 1).

Questo tende ad essere un problema abbastanza comune, quindi la maggior parte degli studenti (se non tutti) lo vedranno ad un certo punto prima della laurea. Il trucco è che di solito si presenta quando la ricorsione viene presentata agli studenti mentre si presta bene o una soluzione ricorsiva o basata su loop che può quindi essere confrontata in modo che gli studenti di diverse scuole possano vederlo in momenti diversi a seconda della sequenza dei corsi. In pratica, se qualcuno non fosse in grado di trovare il ricorsivo, chiederei un'alternativa usando i loop e se non fosse in grado di inventarlo, sarei più preoccupato per la loro potenziale capacità.

4) Implementare la struttura Elenco per intero e scrivere la funzione per invertire.

Questa domanda potrebbe in realtà essere un po 'troppo aperta in quanto è scritta, quindi potrebbe anche essere una buona domanda per vedere come il candidato cerca informazioni aggiuntive (ad esempio dovrebbe includere funzioni di cancellazione, conversione in array, ecc.), Ma dato un pozzo definizione del problema definita ("Implementare una struttura di elenco di base per numeri interi che consente di aggiungere numeri alla fine o in un indice arbitrario, eliminati e includere una funzione per restituire una copia invertita dell'elenco") gli studenti dovrebbero essere in grado di risolvere il problema fintanto che gli elenchi sono una struttura comune presentata in un corso iniziale sulle strutture di dati o in un corso iniziale di informatica.

In termini di rapporti con i candidati, se stanno lottando, assicurati che siano rilassati e concedi loro un po 'di indulgenza poiché potrebbero avere solo ansia da prestazione in quanto questa potrebbe essere la loro prima vera intervista. Potrebbero essere necessari suggerimenti per risolvere i problemi, soprattutto nel caso del terzo e del quarto problema rispetto ai primi due.

Inoltre, strutturare il processo di intervista generale in modo che siano integrati punti di "uscita gradevole". Ad esempio, è possibile avere il seguente ordine del giorno:

• Incontrare e salutare, procedure di intervista.
• Breve intervista con i programmatori del personale, domande di base sul background.
• Presentazione del quiz di programmazione.
• Rompere
• Rientro dalla pausa, licenziamento di alcuni candidati che non sono adatti.
• Intervista estesa con i programmatori del personale.
• Intervista con le risorse umane (se necessario).
• Incartare.

Questo flusso di interviste tende a funzionare bene se si desidera essere in grado di licenziare i candidati in anticipo poiché sanno fin dall'inizio che potrebbero essere licenziati dopo l'interruzione. La breve intervista prima del quiz significa anche che non si stanno solo presentando per fare il test, il che li rende un po 'di pratica del colloquio e può anche consentire loro di decidere che non sono adatti. Se ci sono altri programmatori che osservano il quiz o assistono il candidato durante questo, allora dà loro anche la possibilità di passare / fallire il candidato mentre stanno facendo una breve pausa.

In ogni momento in cui stai intervistando per uno stage e i candidati sono studenti, devi ricordare che sono ancora studenti e potrebbero non avere molta pratica con le interviste (portando a possibili ansie da prestazione) e potrebbero anche non aver raggiunto il punto nei loro studi per anche essere in grado di rispondere alle domande, il che significa che potrebbe essere una buona idea inviarle sulla loro strada con una copia della "soluzione (e) ideale" ai problemi che vengono loro sottoposti.

Il mio obiettivo per qualsiasi colloquio di lavoro, non importa da che parte sto, è finire con la sensazione di parlare con un collega. I colleghi entrano nel mio ufficio tutto il tempo quando sono bloccati su un problema. Chiedo aiuto ai miei colleghi quando rimango bloccato. Quindi in un'intervista, provo a ricreare quella dinamica.

In altre parole, cosa diresti se un collega avesse bisogno di implementare una sequenza di fibonacci e non sapesse cosa fosse? Lo spiegheresti a loro fino a quando non lo afferreranno abbastanza per continuare da soli. Non c'è vergogna nell'ignoranza finché non è permanente.

Se esegui quell'esercizio e non riesci ancora a immaginarti di lavorare con quella persona, allora non sono adatti per il lavoro.

Il punto di porre domande come questa in un'intervista è determinare se qualcuno può capire come risolvere i problemi. Il compito di essere un programmatore in genere consiste di due cose: "Accettare questi requisiti e implementarli nel codice" e "capire perché l'implementazione non corrisponde ai requisiti e risolverli". Quindi quello che stai davvero cercando non è una soluzione a queste domande specifiche, ma la capacità di capire le cose.

Comprendendo questo, darei un suggerimento o due per far iniziare qualcuno, e forse un po 'di più se è chiaro che stanno facendo progressi reali ma mancano un dettaglio da qualche parte. Ma se diventa chiaro che non riescono a capire come risolvere il problema, allora hai la tua risposta e non è necessario continuare con l'esercizio.

Per fare un esempio, quando ho intervistato il mio lavoro attuale, mi è stata data una domanda su come trovare il percorso più breve da un nodo all'altro in un grafico. Risposi che avrei probabilmente usato qualcosa come l'algoritmo di Dijkstra, che ricordavo vagamente di aver appreso un giorno al college e che non avevo mai usato da allora, e diede una rapida (e errata) spiegazione di ciò che soddisfaceva le condizioni specifiche fornite dal domanda. L'intervistatore ha sottolineato che la mia soluzione sarebbe finita in un ciclo infinito se il grafico fosse stato leggermente modificato, e questo avrebbe mosso la mia memoria, così ho spiegato il modo giusto per evitare questo problema. E ho finito per ottenere il lavoro.

per le posizioni di stagista potresti chiedere un po 'di più.

Non ho idea di cosa intendi anche con la quarta domanda. per quanto riguarda fare una domanda di ricorsione, è un po 'poco pratico, passare attraverso la propria base di codice e determinare il numero di aree utilizzate per la ricorsione, sono disposto a scommettere che è poche. Le situazioni del colloquio sono stressanti e aspettarsi che i candidati attuino strategie utilizzate raramente che sono arretrate rispetto alla maggior parte delle cose che programmerai mai è ingiusto nei loro confronti, specialmente all'inizio di un'intervista. Personalmente farei domande su dove debbano spiegare cosa significano i concetti importanti / come vengono utilizzati, fornendo esempi in scatola. Sarei molto più interessato ai candidati che possono dirti che X Book o Google Y Search forniranno tutto il necessario per implementare qualcosa nella tua base di codice.

IMHO le tue prime due domande dovrebbero essere risolvibili per chiunque si definisca un programmatore, che sia junior o senior, appena uscito da scuola o autodidatta.

Se vedo che l'intervistatore sta lottando con uno di questi, proverei a riformulare il problema e verificare se lo ha compreso appieno. Quindi incoraggiala a usare carta e penna, lavagna, disegnare figure o qualunque approccio preferisca affrontare il problema. Le chiedo anche di pensare ad alta voce, di avere una visione del suo processo di pensiero e, se necessario, di dare piccoli suggerimenti se è sulla buona strada, non osa avanzare o ha qualche ostacolo. Ma se anche diversi suggerimenti non fossero d'aiuto, o - come hai detto sopra - finissi per risolvere il problema per lei, probabilmente finirei l'intervista per smettere di perdere altro tempo. In un'intervista, cerco sempre di vedere e concentrarmi su ciò che la candidata sa, invece di ciò che non sa, ma se non riesco a trovare alcuna conoscenza significativa, dopo un po 'mi arrendo.

Il 3 ° e il 4 ° sono un po 'più difficili, quindi potrei accettare se un junior non riuscisse a ottenerli, se altrimenti dimostrasse un buon approccio alla risoluzione dei problemi ed entusiasmo. Ma per un anziano, sono ancora un must.

Ho dovuto cercare cosa intendevi per "FizzBuzz"; risulta che avevo sentito parlare del gioco e delle sue regole, ma non con quel nome e non da un po '. Quindi, non pensare di non dover fornire NESSUNA informazione agli intervistati.

Detto questo, questi sono tutti problemi di codifica di base che mi aspetterei che qualcuno intervistando anche per una posizione di codifica entry-level sia in grado di riflettere, se non riuscissero a scrivere una risposta tramite ispezione. Quindi siamo sulla stessa pagina lì. La risposta al tuo problema dipende da come stanno sbagliando:

• Problemi di sintassi minori: se ti aspetti un codice in una determinata lingua, non contare troppo in caso di mancamento di un punto e virgola o errori di ortografia nell'uso di un identificatore. La maggior parte degli IDE lo afferrerà immediatamente e tutti fanno errori di volta in volta. In quasi tutte le interviste in cui mi aspettavo di scrivere qualcosa, la "pseudo-C-ish" era accettabile fintanto che l'algoritmo veniva comunicato correttamente all'intervistatore e la logica era solida.

• Difetto logico minore: se l'algoritmo si comporterebbe come previsto nella maggior parte, ma non in tutti, gli scenari previsti (ad esempio quando si codifica FizzBuzz, 15 si tradurrebbe solo in "Fizz" o "Buzz", ma non in entrambi come dovrebbe), quindi essere il "tester di unità" e sottolineare che l'algoritmo fallirebbe in quell'istanza e vedere se possono risolverlo. Potrebbero aver trascurato quel caso particolare, o potrebbero non aver compreso i requisiti in modo completamente completo. Entrambe sono di nuovo completamente comprensibili, occorrenze quotidiane nella codifica, che dovrebbero essere facilmente superate semplicemente fornendo informazioni o feedback aggiuntivi.

• Principali difetti logici: se l'algoritmo non supera la maggior parte o qualsiasi scenario di test è stato fornito, segnalalo anche tu e vedi se riescono a risolverlo. Questo è più un problema; o hanno frainteso alcuni requisiti basilari del sistema, oppure hanno trascurato un buco logico spalancato. Ma, se riescono a risolverlo, fornendo maggiori dettagli sul problema, senza che venga detto esattamente dove sta fallendo il loro codice, scrivilo a requisiti poco chiari e vai avanti.

• Non so da dove iniziare / risposta codificata a casi specifici / non riesco a capire il loro pseudocodice: queste sono le bandiere rosse. Se chiedi a qualcuno di codificare un algoritmo che segue le regole di FizzBuzz, spiegando loro quelle regole e ottieni uno sguardo vuoto, l'intervista termina. Allo stesso modo, se riescono a mettere QUALCOSA sulla scacchiera ma fallisce in ampie porzioni dello spazio problematico, e devi tenerle per mano quando illustrano l'errore e come risolverlo, non procederei a una seconda intervista .

Se hai davvero un potenziale tirocinante che si comporta come un cervo sotto i riflettori perché non è mai stato intervistato, ha problemi di ansia, non è mai stato in una situazione di vita reale come quella (di solito noti dal loro linguaggio del corpo), puoi semplicemente iniziare da chiedendo loro su cosa hanno lavorato per ultimo.

Quindi sarà il suo territorio, quindi potrebbe non essere follemente nervoso. Quando trovi un posto adatto, chiedi "Ehi, come lo hai implementato?". Se può spiegare, potrebbe darti un'idea del suo modo di pensare.

Dopodiché metti i tuoi test all'ordine del giorno.

Fizzbuzz è un requisito assoluto. Se non riescono a programmare Fizzbuzz, non dovresti assumerli.

In genere chiedo al candidato una sessione di codice pre-colloquio, in cui utilizziamo Google Documenti per risolvere un problema di programmazione (in genere Fizzbuzz + un problema di livello superiore se possono facilmente completare Fizzbuzz).

In genere sono al telefono o su Skype con loro durante questo, e dal momento che li guardo completare il problema (e parlare con loro di quello che stanno pensando in determinati punti), posso essere ragionevolmente sicuro che non lo hanno fatto t google la risposta.

Fintanto che i tuoi altri problemi vengono specificati bene (ovvero, dai loro la formula per ciascuno), le tue domande vanno bene.

Quando intervisto i candidati, cerco di attenermi ai problemi di programmazione che potrebbero incontrare. Adoro i problemi di manipolazione delle stringhe perché quando sei sul web, quasi tutto ciò che l'utente ha a che fare ha a che fare con una sorta di manipolazione delle stringhe. Come lo gestiscono è importante.

Dipende dal calibro della posizione che stai cercando di riempire.

Se stai cercando uno sviluppatore senior, mi aspetto che sappiano tutto ciò. Se avessero sbagliato e mi sentissi male, fermerei l'intervista, grazie e arrivederci. Se fossi di umore più educato, li ringrazierei e mi affretterei per il resto dell'intervista.

Se stavo andando per uno sviluppatore junior, quelle domande potrebbero essere considerate piuttosto difficili. Sarei più interessato ad esplorare la loro capacità e disponibilità ad imparare. Quindi proverei a dare loro suggerimenti e guidarli e vedere come rispondono.

Le interviste agli stagisti sono una razza diversa di interviste. Quello che faccio di solito è usare le mie domande standard per gli sviluppatori (come quelle che hai fornito) per valutare dove si trovano nella loro istruzione. La capacità di risolvere questi problemi varierà notevolmente dal secondo anno agli anziani.

Dopo aver ottenuto tali informazioni, incentrerò quindi l'intervista su altre abilità come, saranno in grado di lavorare in gruppo, saranno insegnabili, trarranno beneficio dal tirocinio presso la nostra azienda, sono appassionati di sviluppo / apprendimento, ecc.

Per me, sono le cose non tecniche che distinguono davvero uno stagista dagli altri candidati. Preferirei spendere qualche mese come coach / mentoring per qualcuno che è spinto a imparare e crescere, piuttosto che a qualcuno che vuole solo un lavoro per il semestre.

Chiediti quale valore può aggiungere l'intervistato alla tua azienda. Fattore del costo del coinvolgimento di un tutor, soprattutto se non sono in grado di risolvere i problemi a livello di fizzbuzz. Se la risposta non è commisurata allo stipendio previsto, allora hai un buon caso economico per non assumerli.

Non aver paura di tornare dal tuo manager e dire "non c'erano candidati che avrebbero aggiunto un valore sufficiente alla nostra azienda per rendere utile assumerli". Questo deve essere un modo di agire migliore rispetto a finire con qualcuno che ha effettivamente un valore negativo, a causa del costo di avere qualcuno che li aiuti costantemente.

La mia risposta può sembrare un po 'scortese o sprezzante, ma penso che funzioni bene. Per cominciare, faccio al candidato una domanda molto semplice, che funge da domanda di riscaldamento per aiutare a costruire la propria fiducia. Indipendentemente dal fatto che abbiano successo, passo a una domanda che è meno banale e direttamente correlata a ciò che comporta il lavoro.

A questo punto, è tutto o niente. Se lo navigano, grande, nessun problema. Se lottano un po ', nessun problema, li aiuterò ad avanzare e poi passerò ad altre domande per indovinare altre abilità.

Se, tuttavia, mancano completamente della capacità di risolverlo, vado avanti e brucia il resto del tempo dell'intervista aiutandoli. Il candidato si sente ancora coinvolto nell'intervista, ma non devo guidare l'intervista in direzioni diverse e irrilevanti. È buono anche per il candidato, dal momento che può essere educativo.

1. Cerca di essere gentile con loro. Dalle tue domande si vede che non stai cercando di essere gentile nemmeno qui. Pensi che tutti dovrebbero conoscere questo termine "fizzbuzz"? O dovremmo cercare in rete perché eri pigro per scriverlo da solo? Al contrario, penso che tutti qui sappiano qual è il triangolo giusto.
2. Che cos'è "Elenco strutture"? Non lo so. Conosco "la struttura dell'elenco". Cosa significa: elenco per intero? Elenco di numeri interi che intendi? Anch'io non saprei come iniziare. E per favore, non parlare che non sei inglese. Anch'io. E nemmeno io ero mai stato in un paese di lingua inglese. Sicuramente sai che al plurale intero sarà intero s . Se non stai cercando di essere comprensibile con i tuoi pari qui, posso immaginare come stai andando lì .
3. Qualsiasi programmatore esperto sa che la riga di Fibonacci è un esempio di libro di ciò che non dovrebbe essere fatto con la ricorsione. Li stai testando per la capacità di opporsi a te o per abilità di codifica? Fai il tuo lavoro e trova un esempio migliore per testare le abilità nell'uso della ricorsione.
4. "Capacità di lavorare sotto stress" per un programmatore significa che potrebbe lavorare per notti quando è necessario. Ma se vuoi avere dei bravi programmatori, aspetterebbero che il loro capo sia un tipo simpaticissimo, comprensivo e disponibile. Se non lo sei, non avrai mai buoni programmatori. Non sono maschi alfa-ratto. Se sentiranno qualche aggressione, si chiuderanno semplicemente nei loro gusci e non faranno nulla.

Quindi, la mia risposta è: preparatevi meglio.

PS Sei già un manager, quindi dovresti davvero stressarti.