Punteggio / analisi dei test soggettivi per la valutazione delle competenze [chiuso]

Una "valutazione delle competenze" mi sembra il classico problema di mescolare i requisiti con la soluzione.

Vorrei tornare indietro e documentare il problema aziendale e il beneficio atteso. Non conosco le specifiche nel tuo caso, ma un esempio potrebbe essere:

Problema: "Il 40% dei candidati che assumiamo non soddisfa i nostri bisogni, il che fa perdere al nostro team 200 ore di produttività ogni mese."

Benefici attesi: "Migliora la selezione dei candidati per ridurre i costi a non più di 40 ore al mese".

Stima: "Un mese FTE di sforzi".

Mese 1: Risultato = -140 ore investite Mese 2: Risultato = 20 ore risparmiate = Risparmio mensile (200 - 40) - 140 ore di implementazione Mese 3: Risultato = 160 ore risparmiate = Risparmio mensile (160) + 20 ore accumulate 1 anno: risultato = ... 2 anni: ... 3 anni: ...

Entrare nel vivo del problema apre alternative che non possono essere considerate altrimenti.

Il problema con i "test coerenti" è che le domande che porterai alla fine alla fine spariranno ai tuoi candidati e non saranno più coerenti.

Potresti provare a risolvere questo problema creando molte domande e fornendo solo un sottoinsieme a ciascun candidato, tuttavia non otterresti la coerenza finché una popolazione sufficientemente numerosa non ha preso i tuoi test.

Ti suggerisco di leggere i modi per prevedere le prestazioni IT. È probabile che tu trovi delle sorprese e non sono richiesti test.

Per quanto riguarda la valutazione del talento, lascia che ti indico al libro di Joel Spolsky, "Smart and Gets Things Done". È una lettura buona e veloce e, tra le altre cose, sottolinea che la gamma di abilità tra i candidati può variare di un fattore di 10, 20 o anche di più.

Avendo più volte intervistato candidati per posizioni di sviluppo software, trovo che i candidati siano abbastanza bravi a differenziarsi in test sia soggettivi che oggettivi. A meno che non si stiano assumendo molte posizioni, si potrebbe trarre vantaggio pesando il costo di un test automatizzato rispetto a un test somministrato manualmente.

Vorrei suggerire un approccio preso in prestito dai test del software che viene chiamato test basato sul profilo operativo (OPT). In OPT, identifichiamo il profilo operativo (OP) osservando quali funzioni vengono utilizzate più spesso. Per riferirsi al libro di Spolsky in cui descrive una classe di programmazione Yale che aveva gli sviluppatori scrivere alcuni programmi banali con nomi come CMDLINE99, MAKE01 o TAR00 per mostrare che potevano e misurare quanto velocemente (cioè produttivi) potevano essere, ma il istruttore considerava i suoi programmi tipici di ciò che i professionisti avevano scritto in precedenza e di ciò che i suoi studenti avrebbero scritto in seguito.

Per creare un profilo operativo per le domande o problemi di programmazione per i candidati, abbina il programma o passa solo un'ora o due a guardare un buon esecutore in un ruolo simile. Prova le attività e il codice che fanno. Discuti i problemi che stanno risolvendo e annota il vocabolario che potrebbe differenziare tra principianti ed esperti.

Se il test è ben progettato, sospetto che il successo di questo tipo di test possa essere strettamente correlato alla fluidità delle competenze chiave, alla scarsa necessità di assistenza di supervisione e alla capacità di completare la maggior parte delle porzioni in modo tempestivo.

Spero che questo aiuti, grazie per aver letto questa risposta.

La migliore domanda per un colloquio che abbia mai dovuto fare era fare una revisione del codice. Mi hanno dato l'IDE con un progetto e ho detto "lo abbiamo scritto, ma immaginiamo che sia uno sviluppatore junior che ha appena fatto questo e il suo compito è quello di rivederlo - mostraci i bug, le cose che faresti diversamente". E così ho avuto modo di mostrare loro che conoscevo l'organizzazione del codice e le migliori pratiche, nonché i soliti banali bit di programmazione.

Prova che, considerando che non ci sono "risposte" esplicite, puoi inventare qualcosa che misura i loro processi mentali e alcuni test oggettivi (cioè un bug o errore ovvio) che dovrebbero trovare anche.

Per il secondo tipo di test (soggettivo), potresti essere in grado di seguire un processo come questo. Prova a suddividere ciascuno degli argomenti per i quali le abilità sono importanti per te, in gruppi. Quindi C # può avere gruppi come:

• Gestione delle stringhe
• programmazione OO
• IO
• Le discussioni

Puoi farlo anche per altri argomenti.

Quindi per ognuno di questi gruppi prova e scrivi alcune semplici affermazioni. Per la gestione delle stringhe puoi scrivere affermazioni come:

• Uno sviluppatore dovrebbe sapere come concatenare le stringhe
• Uno sviluppatore dovrebbe essere in grado di determinare se una stringa contiene una sottostringa specificata
• Uno sviluppatore dovrebbe essere in grado di dividere una stringa in base a un'espressione regolare
• Uno sviluppatore dovrebbe essere in grado di determinare se una stringa corrisponde a un'espressione regolare

Quindi per ognuno di questi è possibile creare alcuni casi di test che funzionano con funzioni vuote. Una volta completate queste funzioni, i casi di test verranno superati.

Potrebbero essere i tuoi test soggettivi che possono essere eseguiti automaticamente.

Tieni presente che la creazione della raccolta iniziale di test richiederà probabilmente molto tempo.