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

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

Quando intervisti gli stagisti, devi ricordare che potrebbero non aver completato i loro studi e che potrebbero aver anche frequentato il college senza alcun precedente background in programmazione e informatica. In quanto tale, devi ridimensionare le aspettative su ciò che puoi ragionevolmente aspettarti che qualcuno sappia e sul grado di prestigio della posizione (ad esempio Google può farla franca con le aspettative che una società non ha mai sentito nominare).

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

1) Write a function that returns true if triangle sides (all integers) a, b and c can represent a right triangle.

Applicazione di base della geometria con semplice codifica, la maggior parte degli studenti dovrebbe essere in grado di farlo senza troppe difficoltà. Al massimo un promemoria del Teorema di Pitagora potrebbe essere necessario se mostrano un po 'di stress a causa dell'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 modulo, o non l'hanno usato molto, potrebbero aver bisogno di ricordarselo, ma non dovrebbero incontrare problemi reali per risolvere il problema.

3) Calculate the Nth element of Fibonacci using recursion (if they didn't know what Fibonacci was, I would even write them the definition F(n) = F(n-1) + F(n-2); F(1) = 1; F(0) = 1).

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

4) Implement structure List for integer and write function to reverse it.

Questa domanda potrebbe in realtà essere un po 'troppo aperta come è stata scritta, quindi potrebbe anche essere una buona domanda per vedere come il candidato cerca informazioni aggiuntive (ad esempio dovrebbe essere inclusa la funzione di eliminazione, conversione in array, ecc.), ma data una dichiarazione di problemi ben definita ("Implementa una struttura di lista 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 le liste sono una struttura comune presentata in un primo corso di strutture di dati, o in un corso di informatica iniziale di base.

In termini di trattare con i candidati, se stanno lottando, assicurati che siano rilassati e permetti loro un po 'di clemenza perché potrebbero semplicemente provare ansia da prestazione, perché questa potrebbe essere la loro prima vera intervista. Potrebbero essere necessari suggerimenti per risolvere i problemi, soprattutto nel caso del terzo e quarto problema rispetto ai primi due.

Inoltre, strutturare il processo dell'intervista in modo che ci siano dei punti di "grazia di uscita" integrati. Ad esempio potresti avere il seguente ordine del giorno:

• Meet and greet, procedure di intervista.
• Breve intervista con i programmatori dello staff, domande di base sullo sfondo.
• Presentazione del quiz di programmazione.
• Interruzione
• Ritorno dalla pausa, licenziamento di alcuni candidati che non sono adatti.
• Intervista estesa ai programmatori dello staff.
• Intervista con risorse umane (se necessario)
• Riepilogo.

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

In qualsiasi momento durante le interviste per uno stage ei candidati sono studenti, è necessario ricordare che sono ancora studenti e che potrebbero non avere molta pratica con le interviste (che portano a possibili ansie da prestazione) e potrebbero anche non aver raggiunto il punto i loro studi possono anche essere in grado di rispondere alle domande, il che significa che potrebbe essere una buona idea inviarli sulla loro strada con una copia delle "soluzioni ideali" ai problemi che vengono loro assegnati.

Il mio obiettivo per qualsiasi colloquio di lavoro, non importa da che parte sto, è finire per sentirmi come se stessi parlando con un collega. I colleghi vengono nel mio ufficio tutto il tempo in cui sono bloccati su un problema. Chiedo aiuto ai miei colleghi quando rimango bloccato. Quindi in un'intervista, cerco di 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 finché non lo afferreranno abbastanza per continuare da soli. Non c'è vergogna nell'ignoranza finché non è permanente.

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

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

Capendo questo, darei un suggerimento o due per far iniziare qualcuno, e forse ancora 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 al mio attuale lavoro, mi è stata data una domanda su come trovare il percorso più breve da un nodo all'altro su un grafico. Ho risposto che probabilmente userei qualcosa come Algorithm di Dijkstra, che ho vagamente ricordato di aver saputo di un giorno al college e che non usavo da allora, e di aver dato una spiegazione rapida (e scorretta) che soddisfacesse le condizioni specifiche date dal domanda. L'intervistatore ha sottolineato che la mia soluzione sarebbe finita in un ciclo infinito se il grafico fosse leggermente modificato e che la mia memoria fosse jogged, così ho spiegato il modo giusto per evitare questo problema. E ho finito per ottenere il lavoro.

per le posizioni interne che potresti chiedere un po '.

Non ho idea di cosa intendi per la quarta domanda. per quanto riguarda la domanda di ricorsione, è un po 'impraticabile, passare attraverso la propria base di codice e determinare il numero di aree utilizzate per la ricorsione, sono disposto a scommettere che non ne ha nessuna. Le situazioni di intervista sono stressanti e aspettarsi che i candidati implementino strategie raramente utilizzate a ritroso rispetto alla maggior parte delle cose che verranno mai programmate è ingiusto nei loro confronti, specialmente all'inizio di un'intervista. Personalmente vorrei fare domande su dove devono spiegare quali concetti importanti significano / come sono usati, fornendo esempi predefiniti. 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 con chiunque definisca se stesso un programmatore, junior o senior, direttamente fuori dalla scuola o autodidatta.

Se vedo che l'intervistatore sta lottando con uno di questi, proverei a riformulare il problema e a verificare se (s) l'ha compreso appieno. Quindi incoraggiarla a usare carta e penna, lavagna, disegnare figure o qualsiasi altro approccio preferisca affrontare il problema. Le chiedo anche di pensare ad alta voce, di avere una visione del suo processo mentale e, se necessario, dare piccoli suggerimenti se è sulla buona strada, non ha il coraggio di avanzare o ha qualche ostacolo. Ma se anche diversi suggerimenti non aiutano, o - come hai detto sopra - alla fine risolvo il problema per lei, probabilmente finirei l'intervista per smettere di sprecare il nostro tempo. In un'intervista, mi sforzo sempre di vedere e concentrarmi su ciò che il candidato sa, invece di ciò che non sa, ma se non riesco a trovare alcuna conoscenza significativa, mi arrendo dopo un po '.

Il 3 ° e il 4 ° sono un po 'più difficili, quindi potrei accettare se un junior non riuscisse a ottenerli, se (s) avesse altrimenti dimostrato un buon approccio alla risoluzione dei problemi e all'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 in un istante. Quindi, non pensare di non dover fornire NESSUNA informazione agli intervistati.

Detto questo, questi sono tutti problemi di programmazione di base che mi aspetterei che qualcuno intervista anche per una posizione di codifica entry-level per essere in grado di pensarci su, se non fosse in grado di codificare una risposta tramite ispezione. Quindi siamo sulla stessa pagina lì. La risposta al tuo problema dipende da come si sbagliano:

• Problemi di sintassi di lieve entità: se ti aspetti un codice in una determinata lingua, non contare su un numero eccessivo di punti se perdi un punto e virgola o un errore di battitura di un identificatore. La maggior parte degli IDE lo prenderanno immediatamente, e tutti fanno errori di battitura di tanto in tanto. In quasi tutte le interviste in cui mi aspettavo di codificare qualcosa, "pseudo-C-ish" era accettabile finché l'algoritmo veniva comunicato correttamente all'intervistatore e la logica era corretta.

• Difetto logico secondario: se l'algoritmo si comportasse come previsto nella maggior parte, ma non in tutti, degli scenari previsti (ad esempio quando si codifica FizzBuzz, 15 risulterebbe solo in "Fizz" o "Buzz" ma non entrambi come dovrebbe), quindi essere il "tester dell'unità" e indicare che l'algoritmo non funzionerà in quell'istanza e vedere se è possibile correggerlo. Potrebbero aver trascurato quel caso particolare, oppure potrebbero non aver compreso completamente i requisiti. Entrambi sono di nuovo completamente comprensibili, ricorrenze quotidiane nella codifica, che dovrebbero essere facilmente superati fornendo semplicemente informazioni aggiuntive o feedback.

• Principali errori logici: se l'algoritmo non supera la maggior parte o qualsiasi scenario di test è stato fornito, segnalalo anche all'esterno e verifica se è in grado di risolverlo. Questo è più di un problema; o hanno frainteso alcuni requisiti basilari del sistema, oppure trascuravano qualche lacuna logica. Ma, se riescono a risolverlo dando più dettagli del problema, senza che gli venga detto esattamente dove il loro codice sta fallendo, aggiungilo a requisiti non 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, spiegandogli quelle regole, e ottieni uno sguardo vuoto, l'intervista è finita. Per lo stesso motivo, se riescono a mettere SOMETHING sulla lavagna ma fallisce in grandi porzioni dello spazio del problema, e devi tenere la mano per illustrare il fallimento e come risolverlo, non procederei ad una seconda intervista .

Se hai davvero un potenziale stagista che agisce come un cervo al faro perché non è mai stato intervistato, ha problemi di ansia, non è mai stato in una situazione di vita reale come quella (di solito ti accorgi del loro linguaggio del corpo), puoi inizia semplicemente chiedendo loro cosa hanno lavorato per ultimo.

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

Metti i tuoi test all'ordine del giorno dopo.

Fizzbuzz è un requisito assoluto. Se non possono codificare Fizzbuzz, non dovresti assumerli.

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

In genere sono al telefono o su Skype con loro durante questo, e dal momento che sto osservando il problema completo (e parlando loro di quello che stanno pensando in certi punti), posso essere ragionevolmente sicuro che non hanno solo google la risposta.

Se gli altri problemi vengono specificati correttamente (cioè, gli dai 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, praticamente tutto ciò che l'utente deve affrontare ha a che fare con una sorta di manipolazione delle stringhe. Come gestiscono ciò è importante.

Dipende dal calibro della posizione che stai tentando di riempire.

Se hai intenzione di uno sviluppatore senior, allora mi aspetterei che sapessero tutto questo. Se avessero sbagliato e mi sentissi male, avrei semplicemente interrotto l'intervista, grazie e arrivederci. Se fossi in uno stato d'animo più educato, vorrei solo ringraziarli e correre attraverso il resto dell'intervista.

Se avessi scelto uno sviluppatore junior, quelle domande potrebbero essere considerate piuttosto difficili. Sarei più interessato a esplorare la loro capacità e volontà di imparare. Quindi proverei a dare loro suggerimenti e a guidarli e vedere come rispondono.

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

Dopo aver ricevuto queste informazioni, focalizzo l'intervista su altre competenze come, saranno in grado di lavorare in una squadra, sono disponibili, trarranno beneficio dall'internare nella nostra azienda, sono appassionati di sviluppo / apprendimento , ecc.

Per me, sono le cose non tecniche che hanno davvero distinto uno stagista dagli altri candidati. Preferirei trascorrere un po 'di mesi coaching / tutoraggio di qualcuno che è guidato a imparare e crescere, rispetto a qualcuno che vuole solo un lavoro per il semestre.

Chiediti quale valore è probabile che l'intervistato aggiunga alla tua azienda. Fattore nel costo di avere un mentore coinvolto, specialmente se non possono risolvere problemi a livello di fizzbuzz. Se la risposta non è commisurata al salario previsto, allora hai un buon caso economico per non assumerli.

Non aver paura di tornare dal tuo manager e di dire "non c'erano candidati che avrebbero aggiunto un valore sufficiente alla nostra azienda per renderne conto l'assunzione". Questo deve essere un modo migliore di agire che finire con qualcuno che in realtà ha un valore negativo, a causa del costo di avere qualcuno che li aiuta costantemente.

La mia risposta potrebbe sembrare un po 'scortese o sprezzante, ma penso che funzioni bene. Per cominciare, do al candidato una domanda che è molto facile, che serve come una domanda di riscaldamento per aiutare a costruire la loro fiducia. Se riescono o meno, passo a una domanda che è meno banale e direttamente correlata a ciò che il lavoro comporta.

A questo punto, è tutto o niente. Se navigano attraverso di esso, grande, nessun problema. Se lottano un po ', nessun problema, li aiuterò a spronarli e poi passare ad altre domande per gestire altre abilità.

Se, tuttavia, manca completamente la capacità di risolverlo, vado avanti e brucio 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. Va bene 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 anche qui. Pensi che tutti dovrebbero conoscere questo termine "fizzbuzz"? O dovremmo cercare in rete perché eri pigro a scriverlo da solo? Al contrario, penso, tutti qui sanno qual è il triangolo giusto.
2. Che cos'è "struttura elenco"? Non lo so. Conosco "la struttura delle liste". 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. Anche a me. E anche io non ero mai stato in un paese di lingua inglese. Sicuramente sapere che il numero intero al plurale sarà intero s . Se non stai cercando di essere comprensibile con i tuoi pari qui, posso immaginare come stai là .
3. Qualsiasi programmatore esperto sa che la fila 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 le capacità 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, aspetteranno che il loro capo sia un simpaticone simpatico, comprensivo e disponibile. Se non lo sei, non avrai mai dei bravi programmatori. Non sono maschi alfa-ratto. Se sentiranno un'aggressione, semplicemente si chiuderanno nei loro gusci e non faranno nulla.

Quindi, la mia risposta è: preparatevi meglio.

P.S. Sei già un gestore, quindi tu dovresti davvero tenere duro.