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

Mi viene chiesto di esibirmi o di sedermi durante molte interviste tecniche. Facciamo domande logiche e semplici problemi di programmazione che l'intervistato dovrebbe essere in grado di risolvere su carta. (Preferirei avere accesso a una tastiera, ma questo è un problema per un'altra volta.) A volte sento che le persone sanno come affrontare un problema, ma sono bloccate dal nervosismo o da una seconda ipotesi della domanda ( non intendono essere domande a trabocchetto).

Non ho mai sentito il mio capo dare alcun aiuto o suggerimenti. Ringrazia semplicemente l'intervistato per la risposta (non importa quanto sia buona o cattiva) e passa alla domanda o al problema successivo. Ma so qualcosa sulla tana del coniglio che la sconfitta e i nervi possono portarti giù, e come disabilita la tua mente, e non posso fare a meno di chiedermi se fornire un piccolo aiuto ora e poi alla fine ci aiuterebbe a finire con programmatori più capaci invece di più interviste fallite.

Dovrei fornire suggerimenti e assistenza agli intervistati confusi (e in tal caso, fino a che punto dovrei andare pur essendo equo con i candidati più preparati)?

Quando mi trovavo in una posizione simile, direi all'intervistato: "Fai finta di essere Google. Se hai bisogno di cercare qualcosa, dillo."

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". Mi interessava sapere se sapevano come attaccare il problema, non se avessero memorizzato le formule. Per il lavoro, dovevano avere una buona conoscenza 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 sul fatto che i nervi possono essere un problema, ma mi aspetto ancora che le persone siano in grado di esprimere il loro processo di pensiero, anche se sono nervose. 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 è usato dal tuo capo: non fornire alcun aiuto per testare il comportamento della persona in un contesto stressante. È un approccio perfettamente valido e può dare alcuni suggerimenti sulla persona. Dopotutto, una volta assunta questa persona, non sarà in grado di ricevere un aiuto costante da tutti i suoi colleghi.

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

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

Esempio:

- Puoi dirmi come si creano proprietà di sola lettura in C #, ovvero proprietà con un valore che può essere inizializzato solo all'interno di un costruttore e non può essere modificato in un secondo momento?
- Ovviamente. Uso solo la parola chiave readonly.
- Sei sicuro? Puoi spiegarmi la differenza tra una proprietà e un campo?
- Hm. Una proprietà è ... vedi ... ottieni e imposta ...
- Ok. Quindi un campo è una variabile dichiarata all'interno di una classe o di una struttura e valida nell'ambito della classe / struttura, mentre una proprietà è come un campo, ma fornisce anche un meccanismo per leggere, scrivere o calcolare un valore. E adesso readonly? È usato con proprietà?
- Credo che sia usato solo per i campi ...
- Giusto. E le proprietà?
- Non possono essere letti solo.
- Sei sicuro? Che dire delle proprietà che hanno solo getter?
- Sono di sola lettura.
- Significa che il loro valore rimarrà sempre lo stesso?
- Sì.
- No, non proprio. Il fatto che tu abbia una proprietà con un getter non significa che il suo valore non cambi durante la durata dell'istanza della classe. Se il getter si riferisce a un campo che viene incrementato ogni volta che si accede alla proprietà, il valore restituito aumenterà continuamente.
- Giusto.
- Così? Hai un'idea di come puoi implementare una proprietà con un valore che non cambia mai?
- No.
- Bene, puoi usare un campo di supporto di sola lettura. Sai cos'è un 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 primo luogo, sapeva ancora cose correlate.

Inoltre, ponendo semplicemente una domanda senza ulteriore aiuto, non si hanno troppe informazioni sulla persona, a parte il fatto che lei conosce o non conosce 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. Prendi 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 cosa sia un campo di supporto.

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

Mi piace sempre aiutare gli intervistati se sono bloccati su qualcosa di semplice (come il nome di un particolare schema se ovviamente sanno 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 guidarli o buttarli via se stanno pensando a qualcosa di diverso da dove sto immaginando che stiano andando.

Ricordo di aver ricevuto una particolare domanda di risoluzione dei problemi da 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 ciò che sta chiedendo. In tal caso, l'approccio del tuo collega di dire e non fare nulla dimostra solo che il candidato non pensa come il tuo collega o non è nella testa del tuo collega. Penso che fornire chiarimenti sulla domanda con parole diverse potrebbe fornire risultati migliori per tutti i soggetti coinvolti.

Dato che i programmatori (almeno la maggior parte di noi) non lavorano nel vuoto e che le interviste sono abbastanza stressanti senza limiti artificiali, sarei propenso a offrire tutto l'aiuto di cui un intervistato chiede o ha bisogno.

Ma tieni tutto in considerazione quando esprimi un giudizio definitivo sul livello di competenza effettiva del candidato.

Qualcuno che è alla ricerca di una posizione senior ma ha bisogno di molto aiuto suonerebbe il campanello d'allarme.

Per le "persone anziane", offro domande brevi e aperte e prendo più attenzione alle domande che fanno della risposta. Trovo persone anziane che ascoltano, comunicano, usano l'ascolto attivo, chiariscono, quindi forniscono soluzioni del tipo che mi piace.

Per gli "ingegneri di linea", ho usato la tecnica per programmare i test in cui dai a un richiedente un computer e un problema e poche ore, poi torni. In tale situazione, abbiamo chiesto al richiedente in anticipo quale sistema operativo e strumenti preferissero (anche una parte interessante dell'esperienza 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 impiegato un pomeriggio per fare lo stesso test, quindi sapevamo che il test era giusto. Abbiamo trascorso un'ora a esaminare l'approccio di ogni persona come faremmo con un intervistato, il che ci ha dato un'idea di approcci diversi.

Questa seconda tecnica ci ha trovato alcuni dei migliori programmatori "non celebrati" (pessimo curriculum, pessime capacità di intervista) che io abbia mai trovato.

Preferisco iniziare le interviste con una semplice domanda di rafforzamento della fiducia per mettere il candidato a proprio agio nel processo. Quando funziona, ti consente comunque di raccogliere quante più informazioni possibili dalle domande successive senza dare vantaggi ai candidati che capiscono il linguaggio del corpo meglio del materiale relativo al lavoro.

A volte fornire minor hintsdurante l'intervista orale aiuta a vedere quanto il candidato capisce l'argomento / i. Tuttavia, dovrebbero essere no hintsprevisti test standard che ciascun candidato deve sostenere.

Fondamentalmente, two main thingspotresti voler conoscere il potenziale candidato:

a) Caratteristiche personali : si adatta bene alla tua azienda o squadra

b) Competenze tecniche - ha una buona preparazione tecnica 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 interviewal fine di ottenere la massima comprensione delle sue attuali competenze (sia soft che tecnologiche) nonché il suo potenziale per svolgere il lavoro.

Inoltre, le capacità comunicative del potenziale candidato sono importanti quanto le sue capacità tecniche e competenza per risolvere i problemi.

Parte di ciò che dovrebbe essere guardato è abilità comunicative. 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é vengono prese alcune ipotesi durante la lettura delle specifiche o, in questo caso, durante l'elaborazione di una domanda di intervista. Il candidato può rispondere in base a questi presupposti e perdere totalmente il punto previsto. La domanda potrebbe essere difettosa o potrebbe essere il candidato. In entrambi i casi, consentire chiarimenti tramite la comunicazione dimostra un'abilità preziosa, quella che i datori di lavoro dovrebbero cercare.

Penso che alla fine ciò dipenda dalla tua personalità di intervistatore e da ciò che pensi sia importante e quindi sta davvero valutando il candidato.

Personalmente, apprezzo le capacità pratiche / pragmatiche rispetto alle curiosità accademiche / esoteriche. Sono molto più interessato a un candidato che può entrare, mettersi al lavoro e contribuire efficacemente in qualche modo prezioso ai progetti su cui sono stati assunti per lavorare rispetto a quanto io sia su quanto sia buona la loro memoria per la minutia.

Quindi, mi allenerò un po 'se il candidato è bloccato su qualcosa di esoterico, o una sfumatura usata raramente o un caso limite che potrebbe essere rilevante in una domanda di intervista inventata ma raramente è mai rilevante nella vita reale. Soprattutto tutto ciò che potrebbero ottenere con un paio di minuti su Google o con un comodo riferimento da scrivania, oppure "imposta e dimentica" digita cose.

Tuttavia, non li istruirò su cose del mondo reale, comuni, tradizionali, fondamentali, lavorative al giorno. Queste sono le cose che voglio essere innate nei loro confronti.

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

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

Quando sto cercando di scoprire le loro conoscenze tecniche, faccio domande di follow-up che possono contenere suggerimenti su ciò che sto cercando. Contrariamente al pensiero del manager che ha detto che devi porre a tutti le stesse domande per essere giuste, credo che ciò sia giusto fintanto che sono soddisfatte diverse condizioni. Innanzitutto a tutti viene posta la stessa domanda di base. In secondo luogo, non dovresti porre domande di follow-up per aiutare solo una persona. Se hai lasciato che altri si dimenassero senza aiuto, devi lasciare che tutti si dimenino senza aiuto. In secondo luogo, dovresti confrontare la performance dei candidati sulla domanda, non solo in termini di risposta finale, ma in termini di quanto sia stato difficile trascinarli fuori da loro. Questo processo tratta ancora tutti in modo equo.

Dipende dal tipo di programmatore che desideri. Un introverso che può scrivere ben 20 righe di codice su carta starà bene al tuo capo. Uno sviluppatore di software che può lavorare su milioni di basi di codici di linea all'interno di un team per produrre in modo efficiente un buon software probabilmente non farà molto bene. Adoro questo tipo di interviste come candidato: mi raccontano molto su come il capo tratta il suo staff e qual è la cultura del lavoro. In un caso come questo, mentre lasciavo l'intervista, dissi "Grazie - Permettici di risparmiare un po 'di tempo a entrambi, se non mi chiami, non ti chiamerò". Alla domanda sul perché, ho fatto notare che non volevo lavorare per un'azienda che mi aveva insegnato a fallire.

È probabile che il tuo approccio ottenga selezioni migliori per lo sviluppo del software. L'approccio dei tuoi capi funzionerebbe bene per i collezionisti di rifiuti e per i ragazzi che detengono i lecca-lecca Stop / Go durante i lavori stradali.

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

Di recente mi sono trovato in una situazione simile. La direzione che ho preso dal mio manager e risorse umane è stata che dovevamo essere completamente onesti con tutti e 6 gli intervistati, quindi ho dovuto porre la stessa serie di domande tecniche con il minimo aiuto per vedere come si comporta ogni intervistato. A volte quando conoscevano la risposta ma rimanevano bloccati con un termine tecnico o qualcosa del genere, li aiutavo indirettamente con alcune domande che li guidavano a quel termine. C'è stato un secondo round di intervista dopo il round tecnico sulla personalità e sui tratti comportamentali se sono riusciti a superare il primo round.

Parte di ciò che vuoi in un dipendente è qualcuno che può interagire con il resto del team. 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 sua conoscenza di sé e abilità sociali per farlo. Quest'ultimo set di davanzali costruirà la società nel lungo periodo meglio di qualsiasi 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 faccio persino finta di aver dimenticato la risposta alla domanda, per rendere l'esercizio più collaborativo.

Hai mai lavorato con qualcuno con cui non riuscivi a trovare la stessa pagina ogni volta che hai affrontato un problema? O qualcuno che ha posto troppe domande invece di saltare e risolvere i problemi? In un'intervista mi assicuro soprattutto che la persona con cui sto parlando non sia una di quelle. C'è un forte elemento di chimica lì.

Ovviamente imparerò anche cose come "scrive codice pulito", "ha familiarità con i concetti richiesti" e "può abilmente inventare un problema per arrivare a intuizioni?" Il candidato sarà comunque quello "guida" e scrivere il codice. Ma lungo la strada si spera che sarà più rilassata e vedrò una sua versione più vicina a quella che vedrei ogni giorno come collega.