Quanto aiuto devo dare durante le interviste tecniche? [chiuso]

Quando ero in una posizione simile, direi all'intervistato: "Fai finta di essere Google. Se hai bisogno di cercare qualcosa, basta dirlo".

In una domanda gli intervistati dovevano essere in grado di capire il volume di un cilindro, quindi non mi importava se qualcuno dicesse "dovrei Google per la formula per il volume di un cilindro". Ero interessato a sapere se sapevano come attaccare il problema, non se avessero memorizzato le formule. Per il lavoro, dovevano avere una conoscenza decente di come tradurre il mondo reale in software, quindi era un concetto importante.

D'altra parte non avevo intenzione di dire loro che avevano bisogno di quella formula.

Hai ragione che i nervi possono essere un problema, ma mi aspetto ancora che le persone siano in grado di esprimere il loro modo di pensare, anche se sono nervosi. Semplicemente non dare una risposta era inaccettabile.

Hai due approcci che funzionano sia per la risoluzione dei problemi sia per brevi domande tecniche:

1. Il primo è utilizzato dal tuo capo: non fornire alcun aiuto per testare come la persona si comporta in un contesto stressante. È un approccio perfettamente valido e può fornire alcuni suggerimenti sulla persona. Dopo tutto, una volta assunto questa persona, non sarà in grado di ricevere un aiuto costante da tutti i suoi colleghi.

2. Il secondo è fornire suggerimenti e supporto. Il livello di supporto non importa troppo; l'unica cosa che conta è che più aiuti fornisci alla persona, meno devi valutare il suo successo.

Personalmente, credo che dovresti avere abbastanza tempo per essere sicuro che la persona non è in grado di risolvere un problema da sola e far sentire alla persona che non è in grado di risolverlo senza aiuto. Ma poi, puoi fornire un aiuto progressivo finché non dici alla persona la risposta stessa.

Esempio:

‒ Can you tell me how do you create read only properties in C#, i.e. properties with a value which can be initialized only within a constructor and cannot be changed later?
‒ Of course. I just use the keyword readonly.
‒ Are you sure? Can you explain me the difference between a property and a field?
‒ Hm. A property is... you see... get and set...
‒ Ok. So a field is a variable declared inside a class or a struct and valid within the class/struct scope, while a property is like a field, but also provides a mechanism to read, write or compute a value. Now what about readonly? Is it used with properties?
‒ I believe that it's used only for fields...
‒ Right. So what about the properties?
‒ They cannot be read only.
‒ Are you sure? What about the properties which have only getters?
‒ They are read only.
‒ Does it mean that their value will always remain the same?
‒ Yes.
‒ No, not really. The fact that you have a property with a getter doesn't mean that its value doesn't change during the lifespan of the instance of the class. If the getter refers to a field which is incremented each time you access the property, the returned value will continuously increase.
‒ Right.
‒ So? Do you have an idea of a way you can implement a property with a value which never changes?
‒ No.
‒ Well, you can use a readonly backing field. Do you know what is a backing field?
[...]

Dare la risposta è una buona idea in tutti i casi. Ci sono stati diversi casi in cui l'intervistato ha commentato la mia risposta in modo interessante, dimostrando che, anche se non era in grado di rispondere alla domanda in un primo momento, sa ancora cose correlate.

Inoltre, semplicemente facendo una domanda senza ulteriore aiuto, non hai troppe informazioni sulla persona, a parte il fatto che lei conosca o non conosca la risposta . Fornire un aiuto progressivo può consentire di vedere come la persona sta pensando a un problema.

Potrebbe anche mostrare altre cose che la persona non conosce. Prendiamo l'esempio sopra: se mi fermassi alla prima risposta, non avrei saputo che la persona non può spiegare la differenza tra un campo e una proprietà o che non sa che cos'è un backing field.

Se la persona risponde immediatamente, va bene. Se ha bisogno di assistenza, non c'è niente di sbagliato in questo. Se finisci per rispondere alla domanda da solo, è un brutto segno e spero che l'intervistato sarà in grado di rispondere agli altri.

Ricordo di aver ricevuto una particolare domanda per la soluzione di problemi da parte di un intervistatore che aveva in mente un risultato molto specifico, ma non era in grado di comunicarmi chiaramente la domanda. Questo descrive la situazione in cui si imbattono molti intervistati. A volte lo sguardo vuoto non è perché la persona non è un buon risolutore di problemi, ma perché la persona che pone la domanda non è chiara in quello che sta chiedendo. In tal caso, l'approccio del tuo collega di dire e non fare nulla dimostra che il candidato non pensa come il tuo collega, o non è nella testa del tuo collega. Penso che fornire chiarimenti sulla domanda in parole diverse possa fornire risultati migliori per tutti i soggetti coinvolti.

Mi piace sempre aiutare gli intervistati se sono bloccati su qualche cosa semplice (come il nome di un particolare modello se sanno ovviamente di cosa si tratta), e lasciandoli sorvolare su cose come i dettagli di stabilire una connessione al database. Se stanno cercando di progettare qualcosa, però, non dico molto perché non voglio né guidarli né buttarli via se pensano a qualcosa di diverso da dove indovino che stanno andando.

Dato che i programmatori (molti di noi almeno) non lavorano nel vuoto, e che le interviste sono abbastanza stressanti senza limiti artificiali, sarei propenso a offrire tutto l'aiuto richiesto dall'intervistato. / p>

Ma prendi tutto in considerazione quando esprimi un giudizio finale sul reale livello di competenza di un candidato.

Qualcuno che sta cercando una posizione di alto livello ma ha bisogno di molto aiuto suonerebbe un campanello d'allarme.

Per "persone anziane", offro brevi domande aperte e presta maggiore attenzione alle domande che chiedono rispetto alla risposta. Trovo persone di alto livello che ascoltano, comunicano, usano l'ascolto attivo, chiariscono, quindi forniscono soluzioni sono il tipo che mi piace.

Per "ingegneri di linea", ho usato la tecnica per programmare i test in cui fornisci a un richiedente un computer e un problema e qualche ora, poi torni indietro. In quella situazione, abbiamo chiesto al richiedente in anticipo quale sistema operativo e strumenti preferivano (anche una parte interessante delle competenze di un programmatore). Quando hanno finito, come gruppo abbiamo chiesto loro di presentare la soluzione e perché era meglio di altre soluzioni: una revisione del codice. Tutte le competenze che mi aspetto da un ingegnere esperto il primo giorno.

È importante sottolineare che l'intero team di intervistatori aveva preso un pomeriggio per fare lo stesso test, quindi sapevamo che il test era equo. Abbiamo passato un'ora a esaminare l'approccio di ciascuna persona come avremmo fatto con un intervistato, il che ci ha dato un senso di approcci diversi.

Questa seconda tecnica ci ha trovato alcuni dei migliori programmatori "non celebrati" (pessimo curriculum, pessima esperienza di colloquio) che io abbia mai trovato.

Preferisco iniziare le interviste con una semplice domanda di fiducia per far sì che il candidato si senta a suo agio nel processo. Quando funziona, consente comunque di raccogliere più informazioni possibili dalle domande successive senza dare vantaggi ai candidati che comprendono meglio il linguaggio del corpo rispetto al materiale relativo al lavoro.

A volte fornire minor hints durante l'intervista orale aiuta a capire in che modo il candidato comprende l'argomento o gli argomenti. Tuttavia, dovrebbe esserci no hints sui test standard che ogni candidato è tenuto a prendere.

In sostanza, ci sono two main things che potresti voler sapere sul potenziale candidato:

a) Caratteristiche personali - si adatta bene alla tua azienda o al tuo team

b) Abilità tecniche - ha un buon background tecnico e interesse nel raccogliere nuove cose

Per conoscere questi punti citati devi coinvolgere il potenziale candidato in una conversazione. È anche importante assicurarsi che il candidato sia comfortable during the interview per ottenere la massima comprensione delle sue attuali competenze (sia soft che tech) e del suo potenziale per fare il lavoro.

Inoltre, le capacità di comunicazione del potenziale candidato sono altrettanto importanti come le sue capacità e competenze tecniche per risolvere i problemi.

Parte di ciò che dovrebbe essere considerato è la capacità di comunicazione. Se il candidato non è chiaro sulla domanda, dovrebbe porre domande per chiarire. Questa è una buona cosa, secondo me. Troppo spesso, vengono prese decisioni sbagliate perché determinate ipotesi vengono prese durante la lettura delle specifiche o, in questo caso, l'elaborazione di una domanda di intervista. Il candidato può rispondere sulla base di questi presupposti e perdere completamente il punto previsto. La domanda potrebbe essere errata o potrebbe essere il candidato. In entrambi i casi, il chiarimento tramite comunicazione dimostra un'abilità preziosa, che i datori di lavoro dovrebbero cercare.

Penso che questo alla fine dipenda dalla tua personalità come intervistatore e da ciò che pensi sia importante e quindi stai davvero classificando il candidato.

Personalmente, apprezzo la capacità pratica / pragmatica rispetto a quiz accademico / esoterico. Sono molto più interessato a un candidato che può entrare, mettersi al lavoro e contribuire efficacemente in qualche modo prezioso a qualsiasi progetto per il quale sono stati assunti su cui lavorare di quanto io sia su quanto sia buona la loro memoria per minutia.

Quindi, allenerò un po 'se il candidato è bloccato su qualcosa di esoterico, o una sfumatura raramente usata, o un caso limite che potrebbe essere rilevante in una domanda di intervista fatta su misura, ma è raramente, se mai rilevante nella vita reale . Soprattutto qualsiasi cosa che potrebbero ottenere con un paio di minuti su Google o con un utile riferimento sulla scrivania, o "impostarlo e dimenticarlo" digitare le cose.

Tuttavia, non li istruirò su cose reali, comuni, mainstream, fondamentali, lavoro-un-giorno. Queste sono le cose che I vogliono essere innate per loro.

Penso che dipenda dalla situazione dell'intervista e dalle domande. Ho usato entrambe le tecniche.

Perché potrei non voler porre domande di follow-up? Quando sto cercando di scoprire la risposta della persona allo stress. Ho intervistato persone per alcuni lavori che si svolgevano in ambienti altamente stressanti e quanto bene potevano gestire lo stress era un fattore critico nelle nostre valutazioni, quindi abbiamo fatto alcune domande estremamente difficili a cui nessuno poteva rispondere senza alcuno stress.

Quando cerco di scoprire le loro conoscenze tecniche, pongo domande di follow-up che potrebbero contenere suggerimenti su ciò che sto cercando. Contrariamente al pensiero del manager che ha detto che devi chiedere a tutti le stesse domande per essere onesti, credo che questo sia giusto finché sono soddisfatte diverse condizioni. Prima viene chiesto a tutti la stessa domanda di base. In secondo luogo, non dovresti rivolgere domande di follow-up per aiutare una sola persona. Se hai lasciato che altri fuggissero senza aiuto, devi lasciare che tutti passino senza aiuto. In secondo luogo, dovresti confrontare le prestazioni dei candidati con la domanda, non solo in termini di risposta finale, ma in termini di quanto fosse difficile trascinarli fuori da essi. Questo processo tratta ancora tutti equamente.

Dipende dal tipo di programmatore che desideri. Un introverso in grado di scrivere sulla carta 20 grandi linee di codice ti starà bene. Uno sviluppatore di software in grado di lavorare su milioni di basi di codice di linea all'interno di un team per produrre in modo efficiente un buon software probabilmente non andrà molto bene. Adoro questo tipo di interviste come candidato: mi raccontano molto su come il capo tratta il suo staff e su quale sia la cultura del lavoro. In un caso come questo, quando ho lasciato l'intervista, ho detto "Grazie - lasciaci entrambi un po 'di tempo, se non mi chiami, non ti chiamo". Quando mi è stato chiesto perché, ho fatto notare che non volevo lavorare per un'azienda che mi ha impostato per fallire.

È probabile che il tuo approccio migliori le selezioni per lo sviluppo del software. L'approccio del capo dovrebbe funzionare bene per i collezionisti di spazzatura e per i ragazzi che tengono il lecca-lecca Stop / Go ai lavori stradali.

Lo sviluppo del software è uno sforzo di squadra, non un gioco solista / di lettura mentale / non interattivo. Quanti progetti falliscono perché il software fa ciò che è stato richiesto, non ciò che è voluto.

Sono stato di recente in una situazione simile. La direzione che ho ricevuto dal mio manager e HR era che dovevamo essere completamente giusti per tutti e 6 gli intervistati, quindi ho dovuto fare lo stesso insieme di domande tecniche con un aiuto minimo per vedere come si comporta ogni intervistato. A volte, quando conoscevano la risposta, ma rimanevano con un termine tecnico o qualcosa li ho aiutati indirettamente con alcune domande che li hanno guidati a quel termine. C'è stato un secondo round di interviste dopo il round tecnico sulla personalità e sui tratti comportamentali se fossero riusciti a passare il primo turno.

Parte di ciò che vuoi in un impiegato è qualcuno che può interagire con il resto della squadra. Hai bisogno di qualcuno con l'abilità richiesta, vero. Ma hai anche bisogno di qualcuno che sappia quando hanno bisogno di aiuto e ha la conoscenza di sé e l'abilità sociale per farlo. Quest'ultimo set di set sarà in grado di costruire meglio l'azienda nel lungo periodo rispetto a qualsiasi altro Du-jour in linguaggio informatico.

Per come la vedo io, un'intervista è una sessione di coworking di prova, non un test . Sto principalmente cercando di rispondere alla domanda "come ci si sente a lavorare con questa persona?" A volte persino faccio finta di aver dimenticato la risposta alla domanda, per rendere l'esercizio più collaborativo.

Hai mai lavorato con qualcuno che potresti non ottenere sulla stessa pagina ogni volta che hai parlato di un problema? O qualcuno che ha fatto troppe domande invece di saltare dentro e risolvere i problemi? In un'intervista mi sto principalmente assicurando che la persona con cui sto parlando non sia una di quelle. C'è un strong elemento di chimica lì.

Nel processo imparerò anche cose come: "Scrive un codice pulito", "conosce i concetti necessari" e "è in grado di risolvere un problema con intelligenza?" Il candidato sarà ancora il "guidare" e scrivere il codice. Ma lungo la strada spero che sarà più rilassata e vedrò una sua versione più vicina a quello che vedrei ogni giorno come un collega.