Chiedi problemi del mondo reale

Abbiamo predisposto domande e test precompilati a ciascun candidato per vedere come soddisfa i requisiti minimi per la posizione. Ci aspettiamo una buona comprensione degli argomenti tecnici richiesti.

Iniziamo il nostro face-to-face interview (dopo un'intervista telefonica pre-screening ovviamente) con una domanda su quali sono gli interessi del candiate e continuiamo con le domande fondamentali di base e poi regolando il livello su quanto siamo in profondità vorrebbe continuare con quell'argomento.

La nostra guidance in technical topics is candidates resume . Pertanto, spending 10 minutes to read resume before interview è più che importante. Cerchiamo di verificare importanti stack di tecnologie con domande di routine quotidiane del mondo reale, su cui solo un candidato esperto può avere la colla.

Vorrei suggerire di combinare alcune domande di risoluzione dei problemi del mondo reale e provare a vedere come funziona il ragionamento del candidato sul problema. Se il candidato risponde onestamente e dice che non conosce gli argomenti che chiediamo, noi really appreciate honesty and not bullsh**ing.

Ad esempio: se un candidato rivendica più di 6 mesi di lavoro con jQuery , ma non può spiegare cos'è "selector" , vorrei semplicemente smettere di chiedere ulteriori informazioni. Perché la potenza di jQuery deriva dalla buona comprensione dei selettori.

La stessa cosa vale per altri argomenti come gli indici nel Database. Se qualcuno memorizza ciò che è indice cluster e non-cluster, ma non può dare una spiegazione adeguata quando e dove abbiamo bisogno di indici, rivendicando 2 anni di esperienza nello sviluppo di DB, tutto è chiaro.

What I mean is not just collecting good questions to be asked I am asking about strategy for evaluating a candidate and find out if he really good or just just studied well questions and answers.

Bene, se ha studiato le giuste domande / risposte, questo è già un vantaggio per lui.

Quindi, c'è questo: link

Ma, sai, potrebbe non essere la strategia giusta per te .
Cosa stai cercando esattamente? È qualcuno che ha molta esperienza in una determinata tecnologia e conosce i suoi trucchi o qualcuno che può adottare rapidamente nuove cose? O qualcuno che è creativo e può pensare fuori dagli schemi?
Quando ti rendi conto di cosa hai bisogno, non dovrebbe essere troppo difficile trovare le domande giuste per il candidato. Se stai cercando domande su Internet, e sei preoccupato che qualcuno possa effettivamente imparare la soluzione a memoria (o qualcosa di stupido come questo), puoi sempre modificarlo un po 'o trovare le tue domande.

Detto questo, non dovresti aspettarti troppe conoscenze tecniche da uno sviluppatore junior. Assicurati che sia brillante e interessato.
Quando si tratta di sviluppatori senior, dovrebbero avere già molta esperienza, quindi puoi sempre chiedere loro di parlare di ciò che hanno fatto prima.

Considera di studiare Interviste di programmazione esposte, 2a edizione di Mongan, Kindler, Giguère.

I capitoli da 3 a 11 sono vivamente consigliati per gli intervistatori, che forniscono un eccellente riferimento su come fare domande tecniche. Questi capitoli sono anche una buona lettura per i responsabili delle assunzioni - per avere un'idea di quanto impegno ci vorrebbe per preparare una domanda buona .

Eviterei il rote, domande sul tipo di memorizzazione. IMO, tutto quello che dicono è se il programmatore abbia o meno colpito quella particolare situazione prima o se abbia trovato la domanda "giusta" da studiare prima del tempo.

Fornire una soluzione ai problemi tecnici è un buon approccio: ti dà l'opportunità di vedere come risolvono nuovi problemi e quale sarà il loro approccio. Scegli qualcosa relativo al dominio del tuo programma. La difficoltà o l'ambito della domanda possono essere ridimensionati in base alla posizione per cui si sta assumendo. Gli sviluppatori junior dovrebbero avere domande che ti aspetteresti che siano in grado di risolvere. Gli sviluppatori senior dovrebbero ottenere le domande più impegnative, di tipo "open-ended", dal momento che ci si aspetterebbe che guidassero lo sviluppo del prodotto.

Per valutare la personalità, sono un grande fan dell'intervista basata sul comportamento. Invece di chiedere "cosa farebbe che fai" è chiedere "che cosa hai fatto ?" Dal momento che è del passato, tutto ciò che il candidato deve fare è raccontare ciò che è accaduto in realtà non devono pensare a una situazione e determinare quale sia la risposta "giusta". Va bene che i candidati facciano emergere le brutte situazioni in cui si trovavano, purché spieghino come farebbero le cose in modo diverso la volta successiva. BBI è un ottimo modo per capire se il candidato sarà adatto per la tua squadra. Ci vuole un po 'di pratica per abituarsi, ma è la tecnica migliore che ho trovato per capire la personalità dei candidati.

Invitali a scrivere codice su una lavagna o su carta per qualcosa di simile 1. Invertire un elenco di collegamenti senza utilizzare il metodo integrato nell'API java / std / .net 2. Progetta / Crea una pila usando un linklist. Per questo dovranno capire alcuni modelli di design.

I due punti principali da considerare, a mio avviso, sono questi:

1. Il candidato è un buon adattamento culturale?
2. Può il tuo programma candidato?

Nessuno vuole un grande programmatore con un ego due volte più grande della tua azienda (almeno non se hai un team di sviluppatori) o qualcuno che è troppo timido per condividere idee con altri. E anche la persona più simpatica è piuttosto inutile per te se non riescono a programmare la loro uscita da un sacchetto di carta.

Le domande culturali sono quelle che dovrai decidere tu stesso; dopotutto, è la tua cultura a cui il candidato deve adattarsi.

Per quanto riguarda le domande di programmazione, di recente ho avuto una buona intervista con alcuni ragazzi che mi hanno dato un FizzBuzz test (o magari provare alcune alternative ) < em> mentre mi ha fatto un sacco di altre domande. A volte è bello vedere come si esibiscono i candidati quando li li tolgono dalla loro zona di conforto ; questo può far inciampare anche alcuni programmatori "senior". L'ultima volta che ho intervistato i candidati, ho messo un codice intenzionalmente cattivo di fronte a loro e ho chiesto loro di indicare come potrebbe essere migliorato. Il punto delle domande di FizzBuzz e delle domande tipo codice su carta è quello di eliminare i "pretendenti" che sono bravi nella programmazione teorica ma che non possono eseguire quando devono scrivere o analizzare il codice reale. Può anche bloccare i veterani che sono troppo abituati a scrivere codice esclusivamente con il loro IDE preferito e dimenticano le basi della penna e della carta. Quanto hai letto nel loro spettacolo dipende da te (nel mio caso abbiamo ingaggiato un ragazzo che ha disegnato un completo vuoto guardando il codice di esempio, perché ha fatto davvero bene in tutte le altre domande e abbiamo potuto dire da altre domande che era tecnicamente abbastanza capace).

Che tu stia intervistando per un ruolo di sviluppatore junior o senior, ti consiglio anche di non sprecare troppo tempo a domande dettagliate su tecnologie specifiche. Una volta che sai che sono tecnicamente bravi programmatori (con buone capacità di base di Java), e si sono assicurati che non hanno messo le parole d'ordine nel loro curriculum senza sapere davvero nulla su di loro, dovresti essere sicuro di poter acquisire abilità nel quadri pertinenti relativamente rapidamente. Se puoi programmare, dovresti essere in grado di programmare indipendentemente da quale stack di tecnologia viene utilizzato.

Ultimo ma non meno importante, vai con il tuo istinto e prova a vedere le passate facciate artificiali che gli intervistati tendono a sopportare.