Sfondo:
Qual è il modo migliore per valutare equamente uno sviluppatore che si spera esperto in una lingua che non conosci personalmente bene?
Fai domande che non dipendono da una lingua. Ci sono molti concetti chiave da programmare che si trasferiscono in qualunque lingua tu stia usando. Pensa alle domande che sono più teoriche di quanto non siano pratiche. Lascia che uno (o più) dei tuoi attuali programmatori di Ruby sia l'intervistatore che convalida le reali abilità di Ruby dell'intervistato.
Inoltre, ci sono una serie di buone domande di intervista che dovresti chiedere a prescindere dalla posizione. Devi decidere se la persona sarebbe adatta alla squadra. Quindi fai domande che ti danno un'idea della personalità della persona e della sua metodologia di lavoro. Avere qualcuno che si adatta bene alla tua squadra può essere più importante che avere qualcuno che sia intelligente e ben informato su una lingua. È molto più facile insegnare le tecnologie che le abitudini di lavoro.
Se hai una persona Ruby nella squadra che può controllare il candidato in quella particolare area, stai bene. Puoi sempre fare domande più generali e di alto livello sui progetti precedenti del candidato.
Anche se i progetti che la persona ha fatto in passato erano in una verticale di cui non sai nulla con le tecnologie di cui non sai nulla, puoi comunque chiedere dei punti di dolore, delle lezioni apprese, superare gli ostacoli, affrontare la crisi pre-rilascio ecc. ecc. che scopriranno rapidamente se il candidato è stato un membro della squadra o solo qualcuno per la corsa.
Tuttavia potresti dedicare una mezza giornata a Google per apprendere le basi di Ruby, soprattutto se il tuo team di RoR è in crescita. Fallo durante un fine settimana se sei sommerso durante il giorno. TU sei il beneficiario finale di questo sforzo extra.
Ci sono pochissimi, se non zero, sviluppatori con Ruby come unica lingua. Quasi tutti sono almeno di conversazione, se non fluenti, in un linguaggio di tipo C # / C ++ / Java, specialmente se hanno una laurea.
Pertanto, sceglierei una lingua che hai in comune, stabilisci il modo idiomatico di risolvere un compito comune in quella lingua (ad esempio, eseguendo una semplice query di database e visualizzando i risultati), dì loro che sai molto poco su Ruby on Rails e chiedi loro di insegnarti brevemente il modo idiomatico per svolgere questo compito in Ruby.
Se entrambi avete esperienza come ogni vostro reclamo, il candidato sarà in grado di spiegare le differenze in un modo comprensibile. Dopotutto, una parte significativa della sua descrizione del lavoro spiegherà probabilmente i problemi alle persone che non conoscono la lingua, quindi è anche una prova di quella capacità di comunicazione.
Ho appena dovuto farlo l'altro giorno, intervistando per una posizione .NET in cui il candidato aveva familiarità con Java. Mi sono concentrato su principi generali di programmazione orientata agli oggetti, schemi di progettazione e concetti di sviluppo del software, rispetto a domande specifiche del linguaggio. Conosco abbastanza Java per mettermi nei guai, quindi ho fatto alcune domande Java per assicurarmi che lui ne sapesse più di me.
Ero un po 'preoccupato per l'intervista che non saremmo stati in grado di parlare di nulla, ma in realtà è andato abbastanza bene. Ci sono molte basi per lo sviluppo del software che non hanno nulla a che fare con la sintassi o le piattaforme del linguaggio.
In ordine di priorità decrescente, questo è quello che chiederei:
* Disclaimer: ho una laurea, ma ci è voluto del tempo per capire quanto fossi incapace. Ho detto "era"?
La mia opinione è che un buon codice è in qualche modo universale. Fagli vedere alcune cose che ha programmato, guarda come corrono e poi guarda il suo codice. Anche se non conosci la lingua, di solito puoi avere un'idea di che tipo di programmatore è guardando il suo codice.
Ancora più importante, in realtà gli ha fatto scrivere un codice nell'intervista . Può essere qualcosa di piuttosto semplice che richiede solo 20-30 minuti. Se stai assumendo qualcuno per un lavoro negli anni a venire, dovrebbe essere in grado almeno di darti 30 minuti per valutare se può fare il lavoro. Sono stupito di quante persone assumono programmatori senza nemmeno testare se possono davvero programmare.
Se hanno progetti di notevole impatto visivo con un codice di bell'aspetto, e se riescono a creare un piccolo, semplice e semplice programma di test con un codice ben organizzato, allora puoi avere un buon feeling con le loro capacità.