Capisco che per misurare un progetto o un codice, possiamo usare il test di Joel , ma esiste un semplice test standard (come The Joel Test) che è in grado di misurare e filtrare quanto è buono un programmatore?
Il mio piano è di avere questo test come filtro rapido prima di passare a un test più dettagliato.
C'è la matrice di competenza del programmatore .
Come per il test di Joel, è solo una vaga guida. L'unico modo per valutare correttamente un programmatore è chiedere ai bravi programmatori che hanno lavorato con loro.
Vorrei trasformare il test di Joel in giro:
Hanno usato il controllo del codice sorgente?
Sanno come automatizzare una build di un passo?
...
L'unico che non sembra particolarmente applicabile è la domanda dei tester. Gli altri che sembrano abbandonarsi a questo è come lo gestiamo come lo avete gestito nel passato tipo di domande (questo è il modo in cui gestiamo il mantenimento del nostro programma aggiornato come avete gestito la programmazione in passato?) .
modifica:
Fondamentalmente non ottieni le cose nel test di Joel gratis, devi assumere persone che possono farlo accadere. Vuoi stabilire la loro capacità di farlo accadere.
Il Joel Test è solo un controllo di base informale per giudicare rapidamente se un posto ha buone condizioni di lavoro per i programmatori. Anche se segna un perfetto 10, può ancora essere un buco infernale che andrà in bancarotta sei mesi lungo la strada. Un punteggio basso è un'indicazione di qualcosa che non è del tutto giusto, e fa domande per interviste eccellenti ("Attualmente non stai usando il controllo del codice sorgente, ci sono piani per farlo in futuro?"), E le risposte potrebbero essere tali che accetteresti il lavoro nonostante il basso punteggio di Joel.
Anche il test di Joel non è un test "standard"; è solo una lista di controllo che Joel Spolsky ha pubblicato sul suo blog.
Per quanto riguarda "misurare", la qualità di un programmatore va; sfortunatamente, le abilità e le qualità veramente importanti di un buon programmatore sono difficili o impossibili da quantificare, quindi non c'è alternativa alla completa valutazione umana. È possibile estirpare i candidati completamente privi di problemi abbastanza facilmente però, usando un compito di programmazione molto semplice - idealmente, qualcosa che coinvolge ricorsione, strutture ad albero o puntatori (un programmatore che non "capisce" è improbabile che sia di grande utilità). Per coloro che superano questo test, dovrai valutare le competenze manualmente: leggi il codice che hanno scritto, prova le applicazioni di guida che hanno scritto, dai loro più attività di programmazione (progettazione e implementazione), guardale mentre lavorano, parla con loro, vedi se può innescare una discussione professionale. Se stai cercando uno specialista / guru della lingua, potresti anche chiedere alcune domande di conoscenza, ma per un candidato di programmazione generale non mi preoccuperei.
Sì:
Do you program in your spare time?
In tutta la mia esperienza, questa singola domanda è indicativa di quanto sia buono un programmatore. Se loro si divertono; se hanno la passione per il compito, allora saranno bravi a farlo.
E, francamente, molti da 9 a 5 lavori non comportano molta codifica . Non comportano molte iterazioni durante il ciclo di vita della progettazione di nuovi programmi e il modo in cui il progetto funziona / fallisce. Senza questa iterazione, semplicemente non esiste la pratica necessaria per i programmatori per acquisire competenze di progettazione di base del programma.
E non comportano molto apprendimento. I programmatori che si limitano a hackerare le cose a casa esploreranno nuove e interessanti soluzioni senza i vincoli delle grandi aziende.
Eh, mi sento in colpa con la dicitura all'inizio. Non è "hai usato X" o "Conosci Y", è una questione di uso e di pratica. Qualsiasi programmatore che non abbia toccato o sentito parlare degli articoli sul test di Joel è semplicemente disconnesso e ha bisogno di avere un indizio. Ma hai ragione, i code-shop falliscono il test di Joel perché le persone nei negozi lo fanno fallire. L'unica difesa che riesco a vedere corre lungo le linee di "Ho provato, ma non avevo l'autorità e ora sto facendo domanda qui".
Do you use source control?
Sì, ma
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Sì, ma non l'ho configurato e non lo amministro, lo uso semplicemente.
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
No, non è il mio lavoro.
Do you have a spec?
Mi viene data una specifica, quindi la analizzo e produco documenti pertinenti.
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Non sai quali siano gli strumenti migliori e se pensi di farlo, ci sarà sempre qualcuno che discuterà il tuo punto.
Do you have testers?
Sì. In realtà sì e non sono molto buoni, ma non era nella domanda.
Do new candidates write code during their interview?
Sì e falliscono. Sì e passano. Cosa ti dice questo?
Do you do hallway usability testing?
No, ma cosa succede se facciamo qualcosa di meglio?
Per concludere:
Questo non è uno sproloquio, ma sarei molto interessato a sapere che tipo di sviluppatore pensi che io sia basato sulle risposte che ho fornito. Spero che questo dimostrerà il mio punto.
Leggi altre domande sui tag interview