Qual è il modo migliore per discernere un programmatore eccellente in un colloquio di lavoro?


82

Nel contesto di un'intervista: qual è il modo migliore per identificare in modo affidabile quando qualcuno è un programmatore eccellente . Con questo intendo dire che è uno di quelli che è 10-15 volte più efficiente / rapido / migliore dei suoi pari verso l'estremità inferiore dello spettro.

Molti di noi hanno sentito parlare del problema FizzBuzz come un modo per eliminare quelli deboli. Certamente, impiegare 5-10 minuti per risolvere quel problema è un serio indicatore che un candidato è un candidato debole. Sono convinto che un buon indicatore sia in grado di risolverlo il più rapidamente possibile. Questo non sembra sufficiente, però.

È forse qualcosa come dargli un programma buggy moderatamente complicato, e vedere con che velocità può farlo e identificare tutti i problemi con esso?


La domanda presuppone che possa essere fatta in modo affidabile.
Anthony,


non necessariamente. una risposta valida sarebbe "non c'è assolutamente modo"
Claudiu,

Risposte:


65

Mi scuso con chiunque non si occupi di risposte lunghe, ma penso che sia abbastanza importante qualificare i candidati prima di assumerli. Chiunque abbia condotto un numero significativo di interviste in questo settore sa che la maggior parte dei candidati non durerà per i primi 15-30 minuti di un'intervista, quindi la maggior parte di questo elenco non sarà necessario. Tieni a mente quanto costa (sia finanziariamente che emotivamente) licenziare qualcuno prima di chiudere la mia lista come eccessiva. Ho cercato di elencare i miei argomenti di intervista qui per ordine di importanza.

Intelligenza generale (rompicapo / puzzle logici)

Conoscenza Informatica

Esercitazioni di programmazione

  • GCD , Factorial , Fibonacci , Torri di Hanoi
  • Inversione di stringhe ed elenchi
  • Determina se un elenco collegato singolarmente ha un ciclo (puoi farlo con solo due puntatori?)
  • Trova il bug

Conoscenza di tecniche di programmazione orientate agli oggetti e modelli di progettazione comuni

Analisi algoritmo (runtime O (n) complessità e requisiti di archiviazione)

Utilizzo di strumenti e metodologie

Conoscenza delle vulnerabilità e degli attacchi di sicurezza comuni

Matematica di base

  • Sistemi numerici (conversione da una base all'altra)
  • Teoria della probabilità
  • Distanza tra due punti sul piano cartesiano (teorema di Pitagora)
  • Radice quadrata (Airone di Alessandria, approssimazione successiva)

Crittografia

  • Crittografia a chiave pubblica
  • Crittografia a chiave simmetrica
  • Funzioni hash
  • Protocolli crittografici (condivisione segreta, prove a conoscenza zero)

Matematica discreta

  • Logica
  • Insiemistica
  • Teoria dei grafi
  • Teoria dell'informazione
  • combinatorio
  • Prove (come l'esistenza di numeri irrazionali, numeri primi infiniti)

Potresti anche dare un'occhiata al libro Programmazione delle interviste esposte . È un buon riferimento sull'argomento.


10
Uff, deve essere una lunga intervista.
Rick Minerich,

8
Oggi ho tentato di risolvere "Crossing Bridges" con il mio compagno di squadra della competizione ACM Programming. L'unica differenza è che dobbiamo risolverlo per un numero qualsiasi di persone. Ci sono voluti circa 30 minuti per risolvere qualsiasi numero di N persone .. ma in un contesto di intervista mi sembra che i puzzle siano una metrica scadente.

52
In un'intervista, i puzzle fanno schifo perché l'intervistato è nervoso, non pensa dritto, ecc. Inoltre, molti puzzle sono a-ha! scrivi cose che in realtà non ti dicono nulla sul candidato.

11
Trovo questi problemi matematici di grande difficoltà. Dopo aver terminato la tua laurea in Informatica per 10 anni, come puoi ricordare come provare numeri irrazionali e simili?

14
Il problema con i puzzle è che la maggior parte delle persone non li ha risolti; hanno appena visto le risposte prima. Quindi i candidati più esperti faranno finta di non averli visti e elaboreranno senza sosta la risposta che già conoscono. Se il tuo obiettivo è assumere persone intelligenti, non ingannevoli, i puzzle sono una cattiva scelta.
Kyralessa,

28

Ah, l'eterna domanda.

Quest'anno ho fatto molte interviste (domani ho in programma due candidati) e, nella mia esperienza, l'assunzione riguarda più le sensazioni intestinali e le capacità delle persone e meno le conoscenze tecniche.

  1. Prenditi il ​​tuo tempo con i CV. Alcuni CV possono essere rifiutati in pochi secondi, altri in mezz'ora. A volte penso al candidato basato sul CV molto più a lungo di quanto lo intervista. Alcune volte ho preparato domande di intervista specifiche per quel candidato, anche se in genere non ho preparato domande.

  2. Conoscenza tecnica - c'è un minimo che desidero, e di solito è abbastanza facile da dire. In caso di dubbi, durante l'intervista, parla dei progetti che ha citato nel CV e approfondisci quanto è necessario. Questo di solito è più che sufficiente per dirti ciò che sa e ciò che lo fa tick. L'istruzione non è importante, i lavori precedenti contano, i possibili progetti personali ottengono un punteggio elevato.

  3. Chiedi cosa vuole fare e dove vuole andare con la sua carriera: hai bisogno di ciò che ha e puoi fornire ciò che vuole? Inoltre, verso la fine del colloquio, di solito chiedo uno stipendio preferito. Se è fuori dalla mia portata, o se non pagherò così tanto per quello che sa, è lì che finiamo l'intervista.

  4. Ancora più importante, il candidato deve inserirsi nel team e devo essere fiducioso che saremo in grado di lavorare insieme. Non ho bisogno che mi piaccia, ma devo essere in grado di gestirlo e lui deve essere in grado di gestirmi. In caso contrario, passerò, perché non sarò in grado di utilizzare le sue conoscenze tecniche. D'altra parte, se questo è il caso, e se è uno studente veloce, la sua mancanza di conoscenza tecnica non mi impedirà di assumerlo.

Ho addestrato le ragazze delle risorse umane a passarmi tutti i CV non appena li ricevono; Pianifico il colloquio personalmente, il più velocemente possibile (idealmente dopodomani dopo aver ricevuto CV per buoni CV). Poi riceve un'intervista di mezz'ora o un'ora con me e almeno un collega (di solito il mio capo o un membro del team), dove lo conosco e rispondo a qualsiasi domanda. Anche se rifiuto la sua domanda sul posto, ottiene un tour della compagnia di 20-30 minuti e parlo di ciò che facciamo e di come lo facciamo. Poi lo mando a risorse umane per test psico-diagnostici e un po 'di codifica / SQL cartacea davvero di base. Entrambi i test non giocano quasi mai un ruolo significativo nella mia decisione, è più che altro una verifica che ho giudicato correttamente nell'intervista. Dopo i risultati, sono 15 minuti in cui gli faccio un'offerta, e se negoziamo i termini di cui siamo entrambi contenti, viene assunto.

Questo è un processo per il quale ho dovuto lottare attraverso la burocrazia aziendale, dopo aver perso un paio di ottimi candidati, e che funziona perché sono io che decido di assumere (anche se ascolto i consigli sia delle risorse umane che dei colleghi, il mio la parola è definitiva). Più decisori, processo più lungo. Più lungo è il processo, più devi essere Google per ottenere il massimo.

Non appena sono sicuro che non c'è corrispondenza, finisco l'intervista, inizia il tour dell'azienda ed è finito. Questo potrebbe durare solo due minuti al telefono durante la pianificazione del colloquio. Anche se rifiuti un candidato, vendi l'azienda. Se hai fatto un buon lavoro, una buona assunzione può venire attraverso il passaparola dal candidato rifiutato.

Inoltre, un consiglio. Invia lettere di rifiuto (o e-mail) per ogni domanda che ricevi. Nella mia attuale compagnia di solito lo lascio alle risorse umane (a parte quelle che dico durante l'intervista), ma a un certo punto è stato inestimabile ottenere una risposta felice dal candidato rifiutato nelle righe di "GRAZIE! Sei la prima azienda che in realtà rispose invece di lasciarmi chiedendo se un giorno risponderanno! "


Test psicologici?

5
@ Ink-Jet: no, i test psicologici erano corretti - al candidato viene chiesto di scrivere un codice che verrà gestito da un uomo violento che conosce anche il suo indirizzo di casa.

Questo è quello che l'ho letto per la prima volta, a dire il vero.

@Grundlefleck - sì, è corretto. :)
Domchi,

2
Se avessi ricevuto la tua lettera di rifiuto ti ringrazierei. Sono stato respinto attraverso il silenzio dopo essere arrivato a un'intervista telefonica, ed è snervante.
01d55

24

Questa risposta è un po 'fuori dagli schemi, ma penso che sia un punto prezioso.

I migliori programmatori raramente intervistano. Non devono . Se la tua azienda sta cambiando in modo particolare il mondo, o è eccitata in segreto, o se molti programmatori che rispettano sono andati lì, allora potrebbero applicarsi, ma di solito grandi programmatori ottengono lavoro attraverso la loro rete di associati, non inviando curriculum.

Quindi: il modo migliore per dire a un programmatore eccellente in un colloquio di lavoro è che non è lì .


2
così vero ... ottimo punto. :)
Arnis Lapsa,

5
Quindi .... è "chi conosci" piuttosto che "cosa fai"? I programmatori veramente orribili ottengono il loro lavoro anche attraverso amici e familiari. Oh, mi dispiace "rete di associati".
Filippo

17

Ogni risposta deve includere esempi di codice. Assumere un programmatore senza vedere il suo codice è come assumere un cuoco senza provare la sua cucina.


11

Forse un programmatore "eccellente" non verrà da te per un'intervista. Probabilmente devi rubarlo da qualcun altro.


doh! questa risposta sembra diventare popolare. Proprio come devo iniziare ad uscire e fare domanda per un lavoro ...
interstar

9

Un modo per dire ai programmatori appassionati dei programmatori "Voglio solo un lavoro" è chiedere loro quale libro stanno leggendo questa settimana. Quindi chiedi loro dei libri che hanno letto nelle ultime settimane.

Ho scoperto che i programmatori appassionati leggono SEMPRE e di solito l'elenco includerà alcune programmazioni / Comp. Sci. libri nell'elenco recente.

Non si tratta solo di "stare al passo con la professione" - i programmatori appassionati hanno un desiderio e l'amore per la programmazione e tendono a divorare materiale su una varietà di argomenti - non solo la lingua che stanno usando ora, ma metodologie, altre lingue (specialmente nuovi o "strani" o antichi), altri aspetti dell'IT (forse robotica, intelligenza artificiale o giochi o ...)

Se non hanno una lista di libri recenti, probabilmente non sono un programmatore, secondo la mia esperienza.

Saluti,

-R


8
La mia recente lista di libri è quasi sempre una finzione. La mia recente lettura tecnica è quasi interamente online, perché è più aggiornata.

1
Meglio ancora, chiedi loro quale libro hanno scritto questo mese. :)

7

Esistono diverse scale temporali in cui qualcuno può essere "veloce": alcune persone intelligenti possono risolvere enigmi difficili in pochi secondi, ma alcune persone intelligenti producono un buon codice in un mese, anche se potrebbero non essere così veloci alle domande dell'intervista.

Chiedere ai candidati se sono attivi in ​​qualsiasi progetto open source in cui è possibile rivedere parte del loro codice e trascorrere un po 'di tempo a leggere gli archivi della mailing list di tali progetti e impegnare i registri. Questo ti dirà molto più di qualsiasi cosa i candidati possano dimostrare in un'intervista. (Ovviamente questo non può sostituire l'intervista, dal momento che non tutti i buoni programmatori fanno il lavoro open source.)


7

Il libro " Smart and Gets Things Done: la guida concisa di Joel Spolsky alla ricerca del miglior talento tecnico " può aiutare a trovare una risposta.

Tabella dei contenuti:

  • introduzione
  • Capitolo 1: "Colpire le note alte"
  • Capitolo 2: "Trovare grandi sviluppatori"
  • Capitolo 3: "Una guida sul campo per gli sviluppatori"
  • Capitolo 4: "Ordinamento dei curriculum"
  • Capitolo 5: "Lo schermo del telefono"
  • Capitolo 6: "La Guerrilla Guide to Interviewing"
  • Capitolo 7: "Correzione di team non ottimali"
  • Appendice: "The Joel Test"

Anche l'articolo di Joel "The Guerrilla Guide to Interviewing (versione 3)" può essere utile.

E l'articolo "Done, and Gets Things" di Steve Yegge sull'argomento.


4

Poni loro una serie di domande che richiedono loro di programmare e fai in modo che le domande diventino più difficili. Se sembrano apprezzare la sfida, probabilmente ne hai una dal vivo.

Se non riescono a rispondere alla prima domanda facile, come "scrivere un ciclo for" o qualcosa di stupidamente facile, allora sai che questa persona non può programmare.


4

Fagli codificare su una lavagna. L'unico modo in cui sarai in grado di dire se sanno come scrivere il codice.


Non so perché questo sia stato sottoposto a downgrade. Se un programmatore non può scrivere codice su una lavagna, cosa ti fa pensare che sarà in grado di scriverlo su un computer?
Kristopher Johnson,

3
@Kristopher: se un programmatore può scrivere un buon codice su un computer, cosa ti fa pensare che sarà in grado di scriverlo su una lavagna? Questi sono ambienti notevolmente diversi.
David Thornley,

Il "test della lavagna" non ha lo scopo di simulare la codifica effettiva. È un'opportunità per vedere come pensa il candidato, se il candidato può descrivere ciò che sta facendo, quanto velocemente il candidato forma una soluzione nella sua testa, ecc. Qualcuno che fissa semplicemente la lavagna senza avere idea di cosa scrivere probabilmente avrà il stesso problema al computer.
Kristopher Johnson,

3

Dovresti principalmente giudicare il lavoro che hanno già svolto. Qualsiasi codice o idea che qualcuno genera durante un colloquio angosciato è un cattivo indicatore di ciò che possono effettivamente produrre in una squadra.

Per fare sfide con il codice, usa la messaggistica istantanea con qualcosa come codepad.com e lascia che lo facciano comodamente da casa. Scrivi gran parte del tuo codice su una lavagna davanti al tuo capo, con una scadenza di 30 minuti e il tuo bonus sulla linea? Io non.

Quindi, l'intervista è inutile? No, ma l'enfasi dovrebbe essere su di loro spiegando cosa hanno fatto ed esattamente cosa hanno contribuito.

Sarai anche soggetto a tutti i tipi di pregiudizi psicologici una volta che incontri qualcuno faccia a faccia. Non assumere accidentalmente un programmatore perché hanno migliorato il contatto visivo o sono più alti di qualcun altro. Per aggirare questi, condurrei il maggior numero di interviste possibile tramite messaggistica istantanea / e-mail prima di incontrarli faccia a faccia.


È possibile invertire questo effetto osservando i pregiudizi psicologici di altre persone nella storia dei candidati che assumono. Le persone basse che hanno avuto posizioni senior e hanno raggiunto risultati sono probabilmente davvero molto buone. Saranno alte le persone con la stessa storia, in media non molto brave e cavalcando punti aureola.
Tim Williscroft,

2

La lingua non ha importanza. La logica lo fa. Voglio dire, IDE e complier sono così bravi in ​​questi giorni che qualsiasi buon programmatore può imparare qualsiasi lingua (ok forse non assemblatore) in una settimana; diventare decente in un paio di settimane ed essere molto bravo in un paio di mesi.

È il suo (suo) cervello che devi confermare. E lo fai parlando io. Chiedo loro di risolvere semplici problemi. Non scrivendo codice ma guidandomi attraverso la loro logica per giungere a una soluzione.

Ma lo ammetto, se non riesce a scrivere un semplice ciclo che contenga da 1 a 10, hai problemi.


1

Prima di tutto, c'è un modo per ottenere un'idea prima ancora che inizi l'intervista:

Se hanno un blog o contribuiscono a uno o più progetti open source, basta guardare il codice e gli articoli che hanno scritto. Prima di tutto, se hanno fatto uno di questi, hanno l'iniziativa di fare le cose. Inoltre, puoi confrontare queste cose con l'esperienza di lavoro che hanno elencato nel loro curriculum e avere un'idea se tornano a casa e imparano di più dopo il lavoro o se tornano a casa e dimenticano di lavorare dopo le 17:00.

In sostanza, hanno passione per la programmazione o no? Questa è la vera domanda.


1

Avere un buon programmatore presente nell'intervista è la cosa migliore secondo me.

Solo un esperto può giudicare se il richiedente conosce solo molte domande di intervista o se sta effettivamente pensando ai problemi e può entrare nei dettagli. Ricorda, non vuoi assumere persone per risolvere i puzzle delle interviste, vuoi assumerle per fare il vero lavoro.

I puzzle sono per escludere le persone che non hanno le basi giuste. Se vuoi testare l'abilità, prepara alcune cose su cui tu (o il tuo "buon programmatore") potete approfondire e focalizzarvi su quello a cui il candidato deve pensare per un po '. Come affronta i problemi di cui non conosce immediatamente la soluzione?


1

Non penso che dovresti parlare di passione durante l'intervista. Francamente, sembra che un'azienda che cerca "passione" significhi davvero "lavorare senza soldi per l'idea".

La passione non garantisce nemmeno l'eccellenza. Voglio dire, passo quasi tutta la mia vita a programmare, a leggere sulla programmazione, a imparare lingue folli come Erlang o Clojure e non vengo pagato per nulla di tutto ciò. Eppure faccio schifo alla programmazione.

Penso che un programmatore eccellente dovrebbe avere una traccia di progetti di successo in cui sono stati attivamente coinvolti. Pertanto, non è necessario far scrivere a un programmatore qualcosa sopra FizzBuzz di base nell'intervista. Parla dei loro progetti passati e di ciò che hanno fatto. Stai assumendo programmatori per risolvere i cubi di Rubik e contare i marmi o lavorare su progetti software lunghi e grandi ed estenuanti di oltre 50 linee di cemento?


1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

Dall'articolo:


I criteri nei punti elenco

Quindi, in sintesi, ecco alcuni indicatori e contro-indicatori che dovrebbero aiutarti a riconoscere un buon programmatore.

Indicatori positivi :

  • Appassionato di tecnologia
  • Programmi come hobby
  • Ti incoraggerà a parlare di un argomento tecnico se incoraggiato
  • Significativi (e spesso numerosi) progetti secondari personali nel corso degli anni
  • Impara nuove tecnologie da solo
  • Considerato quali tecnologie sono migliori per vari usi
  • Molto a disagio sull'idea di lavorare con una tecnologia che non crede essere "giusta"
  • Chiaramente intelligente, può avere grandi conversazioni su una varietà di argomenti
  • Ha iniziato a programmare molto prima dell'università / del lavoro
  • Ha alcuni "iceberg" nascosti, grandi progetti personali sotto il radar CV
  • Conoscenza di una grande varietà di tecnologie non correlate (potrebbe non essere presente nel CV)

Indicatori negativi :

  • La programmazione è un lavoro diurno

  • Non voglio davvero "talk shop", anche se incoraggiato a farlo

  • Impara nuove tecnologie in corsi sponsorizzati dall'azienda

  • Felice di lavorare con qualsiasi tecnologia tu abbia scelto, "tutte le tecnologie sono buone"

  • Non sembra troppo intelligente

  • Ha iniziato a programmare all'università

  • Tutta l'esperienza di programmazione è nel CV

  • Incentrato principalmente su una o due pile tecnologiche (ad esempio tutto ciò che riguarda lo sviluppo di un'applicazione java), senza esperienza al di fuori di essa


ti dispiacerebbe spiegare di più su ciò che fa e perché lo consigli come rispondere alla domanda posta? Le "risposte solo link" non sono del tutto benvenute allo Stack Exchange
moscerino del

0

Un eccellente programmatore sarà in grado di lavorare anche con quei peer di spettro inferiore. Finché possono fare il test e non crogiolarsi nel loro ego, allora hai un buon candidato, no?

Quel test fizzbuzz è piuttosto divertente però. La soluzione che mi viene in mente utilizza l'operatore modulo. Che conosco solo elaborando le coordinate della mappatura dei fogli dei personaggi (mai menzionata a scuola o all'università). Il programmatore medio potrebbe anche saperlo o avrei avuto un'educazione di merda?


Sono sorpreso che non ti sia mai imbattuto nell'operatore modulo. Mi è stato presentato nelle diverse lingue che ho imparato nel corso dell'anno.

2
Se sei laureato in CS al college, l'operatore Modulo sta programmando 101

sorprendentemente cose come bit-shift e modulo vengono saltate al college
Claudiu il

Penso che dipenda dal tipo di cose che stanno cercando di insegnarti al college. Non credo di aver mai usato il modulo in un problema del mondo reale, né di averlo insegnato esplicitamente. Ma è molto comune in questo tipo di esercizio (e nelle domande d'esame).
interstar,

2
In realtà, entrambi sono generalmente insegnati nella scuola elementare; a quel punto vengono definiti "il resto" e "moltiplicare per 10".
intuito il

0

Uno dei criteri che utilizzo è quello di vedere il "tipo" di lingue e strumenti su cui ha lavorato, sia in progetti accademici che professionali e ciò che ha esattamente raggiunto. Ha sempre lavorato a livello di applicazione usando librerie standard (sempre un tipo C # o VB6?) O ha fatto un progetto usando C in Linux occupandosi di cose hardcore come puntatori, gestione della memoria, ricorsione, sincronizzazione dei processi, esclusione reciproca, eventi ecc. Se ha sempre usato questi concetti fondamentali e fondamentali in qualche livello di astrazione, sarò dubbioso.

Questo ovviamente oltre a fargli scrivere codice. Niente è un sostituto per quello. Tuttavia, mi occupo del fatto che alcune persone possono scrivere codice più velocemente di altre e che le persone hanno tempi di risposta diversi durante un'intervista alla ribalta.


ricorsione, sincronizzazione dei processi, esclusione reciproca. Queste tecnologie sono ugualmente importanti se lavori con C #, VB.NET, C o linguaggio assembly.

-1 - Questo è completamente sbagliato. Il "tipo" di lingue e strumenti è "irrilevante" al 100%.
Morgan Herlocker,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.