Come intervisti qualcuno con più esperienza di te? [chiuso]

La società per cui sto lavorando sta cercando di assumere uno sviluppatore senior con più esperienza di me e si aspettano che io faccia la parte tecnica dell'intervista. Ho programmato solo alcuni anni e non sono sicuro di avere le conoscenze necessarie per valutare le capacità di programmazione di qualcuno che ha una comprensione / esperienza maggiore di me.

Qualcuno può raccomandare alcune domande di intervista tecnica da porre che sono un buon mezzo per valutare le capacità di programmazione di livello superiore, ma essere ancora quelle che posso capire?

Direi che ho passato il jr. livello di programmatore, ma da nessuna parte vicino senior. La maggior parte di ciò che ho fatto sono state create piccole app (web e desktop), alcune piuttosto complicate, ma tutte sono state pensate per essere utilizzate da non più di una manciata di utenti. Sento di avere una buona comprensione della maggior parte dei concetti di programmazione e sono in grado di apprendere / insegnare a me stesso praticamente qualsiasi cosa, tuttavia mi manca l'esperienza. Come il mio capo ama dirmi "Non sai cosa non sai".

In particolare, le cose che vorremmo che la persona che assumiamo con cui fare esperienza (che non ho) sono: sviluppo multi-livello, ambiente multi-utente, sviluppo di applicazioni su larga scala, messaggistica bidirezionale, sessioni condivise, e Multi-threading / BackgroundWorkers.

AGGIORNARE:

In risposta al commento di Thor qui sotto, abbiamo assunto qualcuno alcuni mesi fa e penso che abbia funzionato alla grande. Sto imparando molto, non solo sulla codifica, ma anche su cose come modelli di progettazione, architettura software, documentazione e come altri team di programmazione più grandi svolgono attività. Non è sempre facile far entrare qualcuno e indicare modi migliori per fare le cose che hai fatto, ma se puoi ingoiare il tuo orgoglio ed essere disposto a provare cose nuove puoi imparare molto.

Il processo di intervista è andato meglio di quanto mi aspettassi. Ho iniziato a fare domande su cose che conoscevo, poi ho fatto alcune domande su alcune cose con cui stavo lottando. Ogni volta che l'intervistato diceva qualcosa che non capivo, chiedevo loro di spiegarmelo e poi scriverlo per poterlo cercare in seguito. Nel complesso, mi è sembrato di essere in grado di avere una buona idea del livello di abilità, dell'intelligenza del candidato e su come sarebbe stato lavorare.

Non puoi.

Invece, ti suggerirei di presentarti nell'intervista con un elenco di problemi che hai oggi e chiedergli come risolverli .

Questo è un metodo molto interessante per i seguenti due motivi:

1. È una consulenza gratuita . Anche se non assumi il ragazzo, potrebbe suggerire delle belle soluzioni ai tuoi problemi .

2. Se arriva con soluzioni interessanti , è un risolutore di problemi . Il tipo di ragazzo che vuoi assumere.

Usa la tua età come vantaggio.

Ho intervistato un sacco di persone più grandi di me. Scelgo una tecnologia che faccio conosco abbastanza bene e dico loro che ho sentito parlare di tecnologia X, ma mai usato. Chiedo al candidato di darmi una panoramica della tecnologia e di come l'hanno utilizzata in un progetto.

Questo funziona sorprendentemente bene. Prima di tutto, se il candidato sta usando quella Tecnologia X solo come una parola d'ordine sul loro curriculum, allora la loro spiegazione farà schifo / non avrà senso. Inoltre, se non possono darti un buon esempio concreto di come hanno usato una tale tecnologia nei loro progetti passati, hai una grande bandiera rossa proprio lì.

Ho intervistato qualcuno che ha avuto l'esperienza java Spring. Avevo usato Spring nel mio lavoro precedente e una delle grandi caratteristiche della primavera è l'iniezione di dipendenza. Ho detto al candidato che ho intervistato di aver sentito parlare della primavera e di non averlo mai usato. Ha iniziato a blaterare ancora e ancora, ma non poteva dirmi dove aveva usato Spring AOP e non poteva spiegarmi l'iniezione di dipendenza, anche dopo che ho esplicitamente chiesto dopo aver visto quelle cose chiamate sul suo curriculum. Mi ha appena detto che erano davvero fantastici, e c'è così tanto da imparare là fuori, ecc. Ecc. Si scopre davvero che non conosceva Jack ... ed io ero l'unico a capire che in b / c ero un membro più giovane del team di sviluppo.

Quindi usa la tua età come vantaggio! Entra, sii fiducioso e fai alcune domande sulla tecnologia che conosci bene.

Ricorda che solo perché hanno più esperienza di te, potrebbero non essere uno sviluppatore migliore di te. La frase "Un anno di esperienza ripetuta n volte". arriva perché lo vedi accadere nell'industria. Pertanto, il tuo primo compito durante il colloquio dovrebbe essere quello di stabilire che hanno effettivamente l'esperienza pertinente e possono presentarsi come qualcuno che sa cosa stanno facendo. Allo stesso modo, solo perché qualcuno ha avuto n anni di esperienza nel settore, ciò non significa che abbiano un sacco di esperienza in una determinata lingua, biblioteca o struttura, quindi potrebbero ancora venire da te di volta in volta facendo domande mentre sono imparare qualcosa.

Successivamente, ricorda che un buon sviluppatore senior è qualcuno con cui dovresti essere in grado di avvicinarti e chiedere qualcosa con cui hai problemi. Questo è un buon momento per porre loro alcune domande di progettazione che hai avuto problemi e vedere come rispondono e qual è il loro ragionamento nella loro spiegazione. Hanno visto qualcosa di simile prima da qualche altra parte, stanno facendo un'ipotesi educata basata sull'esperienza, hanno letto un articolo online o su un diario?

Infine, un'altra cosa da considerare è il modo in cui si avvicinano al codice di debug. Nella mia esperienza, ho scoperto che, indipendentemente dalla lingua, alcune tecniche di debug tendono ad essere applicate all'universalità. Dato al candidato un esempio di uno dei bug più esoterici che hai riscontrato e ti guida attraverso il modo in cui si avvicinerebbe al bug. Hanno una visione del problema che non è immediatamente evidente?

In sintesi, intervistare un candidato con un'intervista impressionante può essere intimidatorio, ma c'è qualcosa che devi coprire indipendentemente dal livello che sarà (cioè sanno effettivamente cosa stanno facendo) e una volta completato puoi iniziare a sondare loro per vedere come stanno applicando la loro esperienza. Il modo in cui i candidati applicheranno la loro precedente esperienza lavorativa sarà ciò che renderà un candidato straordinario più di un altro.

Mi piace molto usare la tua età come una risposta di vantaggio , e suggerirei qualcosa di simile:

Usa il tuo livello di esperienza inferiore come vantaggio

Questa persona sarà probabilmente il tuo capo o mentore, quindi fai domande in un modo che ti permetta di scoprire se quella persona può davvero farti da mentore.

Poni domande complicate che potrebbero essere rese molto più semplici o che includono problemi troppo complicati. Se lui / lei va bene, non solo risolverà il tentativo di rispondere alla domanda / risolvere il problema, ma in realtà arriva al vero problema, mostrandoti i difetti della tua domanda. Se riesce a farlo in modo educato senza intimidirti, è un custode.

La cosa davvero significativa è che ti assicuri che sia il giusto tipo di sviluppatore esperto per quello che ti serve.

Mentre le persone passano attraverso la loro carriera, tendono ad andare in direzioni diverse in termini di ciò che fanno. Potresti intervistare persone esperte nella gestione di grosse squadre di programmatori o che lavorano con codice legacy contorto e abbastanza brillanti in quello che fanno senza che loro siano la persona giusta per il tuo ruolo. Quindi prova ad avere un'idea di cosa stai esattamente cercando in anticipo e pensa a domande che differenzieranno esattamente il tipo di sviluppatore per il tuo lavoro dalle altre persone.

Ho dovuto farlo più volte. Ho imparato a farlo in un processo graduale.

1. Inizia con le stesse domande che faccio ai laureati. L'ho fatto perché la posizione per cui stavo facendo il colloquio tecnico era una posizione di programmazione in cui ci aspettavamo che lo sviluppatore fosse a portata di mano nel codice e volevo assicurarmi che i candidati potessero programmare. Con una sola eccezione, nessuno dei candidati poteva farlo: erano peggio di tutti i laureati. Tutti erano stati in posizioni manageriali troppo a lungo.
2. Per il candidato che ha superato un test di competenza sulla codifica di base, ho avuto alcune domande più generali su "come gestiresti lo scenario X". Se stai facendo servizi web nel tuo progetto, ad esempio, pensa a una domanda interessante sui servizi web e chiedi al candidato come lo risolverà. Non consiglierei che questo sia qualcosa su cui stai attualmente lavorando direttamente, principalmente a causa del problema della proprietà intellettuale e dei dati proprietari dell'azienda. Non dare quella roba!
3. Trascorrere del tempo a chiedere al candidato informazioni sul suo curriculum. Questo è importante. Puoi scoprire le sue esperienze di squadra migliori e peggiori, esperienze come supervisore e così via. Prova ad avere un'idea dello stile di lavoro della persona per vedere se si adatta alla tua squadra.

Il mio problema più grande quando ho intervistato i candidati senior è stato il fatto che spesso erano molto nervosi per essere intervistati da una persona più giovane, specialmente quelli che non erano in grado di gestire i miei test di codifica di base. Cerca di sembrare non minaccioso in tutte le abilità che mostri durante l'intervista - concentrati su di loro, anche se non sono in grado di rispondere bene alle tue domande. Prova e inclina l'intervista a domande a cui possono rispondere se falliscono le basi.

In termini di processo dell'intervista, fondamentalmente li tratti come qualsiasi altra persona che stai assumendo. Dovrebbe esserci un processo di assunzione simile:

1. Selezione, su CV o raccomandazione dell'agenzia.
2. Test attitudinale (che combina cose come FizzBuzz , strdup () / isAlpha (), OOD, ecc.)
3. Colloquio telefonico (per una rapida eliminazione se non comunicano bene)
4. Intervista faccia a faccia
5. Esercizio di codifica scritto
6. Incontra alcuni membri del team.
7. Per una persona con esperienza, che implica un rischio maggiore e costi più elevati, sono accettabili ulteriori cicli di interviste, ma è necessario comunicare chiaramente a loro dove si trovano (ovvero 1 di 3 cicli di colloqui).

Ci sono molti altri post su questo sito che trattano argomenti di discussione generali che dovresti trattare nel processo di intervista - ecco la mia risposta a uno di questi .

In ogni momento del processo di intervista, una persona con esperienza dovrebbe dimostrare un'eccellente comprensione delle specialità pubblicizzate. Puoi sondarli, in modo molto approfondito, su qualsiasi argomento trattato durante le discussioni. Poni domande ai limiti della tua esperienza / livello di comfort e vedi se possono continuare senza preoccupazioni. Se hai bisogno di approfondire qualcosa con cui non hai molta esperienza, fai una ricerca sul web per alcune domande di esempio (prendine una selezione), leggi e capisci le risposte prima dell'intervista , quindi chiedi al candidato una di queste domande. Non aspettarti che sappiano tutte le risposte, quindi fai una selezione di domande.

Esistono due tipi di ingegnere esperto che puoi assumere:

1) Esperienza nel settore rilevante

Questa è la persona a cui puoi prendere la tua lista di problemi attuali e parlare di come potrebbero affrontarli. Dovresti valutare il loro livello di comprensione di ciascuno degli argomenti specifici del dominio nel tuo settore. Dato che sei in quel settore, puoi dire una risposta "stupida" da una risposta "buona" e probabilmente individuare anche una risposta "esperta". Contrariamente alle altre risposte, non mi aspetto che risolvano effettivamente i tuoi problemi attuali - ciò accadrà quando li assumerai - ma ti serviranno per convincerti che avrebbero potuto farlo una volta iniziato.

2) Nessuna esperienza nel settore rilevante

Quindi questo candidato sta probabilmente cambiando settore ma ha una buona esperienza nelle tecnologie / piattaforme / competenze di base di cui hai bisogno. Approfondisci questi elementi, ma non aspettarti che siano in grado di trovare soluzioni per problemi specifici del dominio, anche se potresti semplicemente parlarne. Ad esempio, se la tua azienda è Facebook e la persona che stai intervistando è appassionata di PHP e C ++, non sarebbe realistico aspettarsi che conoscano tutte le insidie ​​di server farm di grandi dimensioni (a meno che non lo dichiarino nel proprio CV).

Una cosa che non ho visto esplicitamente sottolineato, è "Conosci molto bene la tecnologia X, e suona molto interessante. Potresti spiegarmelo tra cinque minuti?"

Dal momento che molto probabilmente ci si aspetta che riuscirai a mantenere il codice eventualmente uscito dalla nuova persona, è fondamentale che sia in grado di spiegarlo ad altri programmatori in modo efficiente e bene. Consideralo come abilità comunicativa.

È necessaria una comprensione approfondita per poter incontrare qualsiasi altro sviluppatore a livello di abilità e comunicare pensieri e idee al proprio livello.

Se la persona non è in grado di comunicare verbalmente, molto probabilmente scrive solo il codice per il compilatore, non per il manutentore.

Concordo con Steven sulla parte del tutoraggio. In effetti direi che puoi fargli domande su quali sono le sue opinioni sul tutoraggio e su come lo fa in diversi scenari. Quindi valuta in base alla risposta (puoi ottenere feedback dal tuo capo se ne hai voglia o discutere le risposte effettive nel debriefing).

Puoi anche porre domande che faresti a un collega, poiché il candidato dovrebbe probabilmente essere in grado di risolvere o almeno comprendere il tuo lavoro.

scegli sicuramente il cervello nell'intervista su problemi e tecnologie reali che attualmente hai o intendi utilizzare

supponendo che sia uno sviluppatore senior competente e fantasioso, decidi di assumere o meno in base a se pensi di poter imparare da lui / lei e lavorare bene con lui / lei

non stai intervistando il tuo futuro capo, stai intervistando il tuo futuro mentore. Non scegliere qualcuno che conosce tutte le risposte ma non può insegnare

Prendi un sacco di problemi che hai già risolto. Descrivigli cosa è stato fatto per risolvere il problema (tienilo in terza persona; non vuoi mettere in gioco il tuo ego personale). Chiedigli cosa avrebbe fatto "diversamente". Dovresti essere in grado, in base a ciò che sta suggerendo, di capire se sarebbe stato meglio o peggio, concettualmente, di quello che hai fatto.

Ti consiglio vivamente di leggere il libro "Smart and Gets Things Done: la guida concisa di Joel Spolsky alla ricerca del miglior talento tecnico" .

Non ho mai assunto nessuno, ma a volte quando ero l'intervistato, desideravo che alcuni idioti che sapessero solo delle parole d'ordine e mi stessero intervistando, mostrino la linea di ragionamento in quel libro. Il testo è molto fluido e piacevole da leggere.

E no, non sto facendo pubblicità solo perché questo sito è dell'autore del libro. Il libro è davvero fantastico e lo consiglierò a chiunque sia in grado di assumere personale IT, specialmente a chi non capisce la tecnologia - Oggi è molto comune avere un project manager o un capo non tecnico.