Come valutare le capacità di comunicazione di un programmatore [chiuso]

D'accordo con molti dei commenti, questo sembra eccessivamente artificioso / complicato ma ...

Sembra che tu abbia qualche scelta

• Fai una domanda da un dominio al di fuori del campo di competenza - "Spiega come funziona una trasmissione" Che ti aiuta a vedere come comunicano la loro comprensione dei sistemi di scatole nere.
• Fai una domanda dall'interno del dominio di programmazione - "Spiega come funziona il controllo della versione distribuita" Che ti aiuta a capire come capiscono qualcosa di cui entrambi conosci e che hanno esperienza.
• Fai una domanda che ha come obiettivo la loro comprensione ma non la tua - "Spiegami l'algoritmo / sistema / interazione X su cui hai lavorato per quei cinque anni dal 2003 al 2008" Che ti aiuta a capire come comunicano la loro (profonda) comprensione a un novizio. (nota: puoi anche testare separatamente per la correttezza della loro comprensione in un'altra parte dell'intervista, non è necessario testare per la comunicazione e la correttezza insieme)

Probabilmente manchi uno o due :-)

Facile, chiedi a cosa hanno lavorato, quali strumenti hanno usato o quali tecniche sono state utilizzate. In ogni caso, non importa, purché non lo sappia. Tutti hanno un po 'di conoscenza di nicchia sull'ultima cosa su cui hanno lavorato.

Quindi chiedigli di spiegartelo. Non solo quello che ha fatto, o come lo ha fatto, piuttosto fargli spiegare come funziona. Come se il suo ultimo lavoro includesse algoritmi di hashing. Chiedigli di spiegarteli. Forse non l'algoritmo di hashing vero e proprio, ma come funzionano, per cosa sono utilizzati, i loro limiti, sai, materiale tecnico.

In breve, per testare le sue capacità comunicative, dovrai comunicare con lui.

Modifica
Se si desidera testare la propria capacità di comunicare con persone non tecniche, coinvolgere una persona non tecnica e sedere tranquillamente di lato mentre l'intervistato spiega qualcosa al non tecnico. Per questo, sceglierei un argomento che ti è familiare, in modo che tu possa scoprire le cazzate. Ma ricorda, nessuna analogia sarà perfetta. Inoltre, assicurati che il non-tech sia almeno un po 'interessato, o sia disposto a impegnarsi per imparare qualcosa di nuovo. Cavallo - > acqua.

Se stai cercando di valutare come qualcuno comunica, sarebbe una buona idea tenere ciò che è comunicato come costante. Dai al candidato tutte le informazioni di cui hanno bisogno - magari un pezzo di codice o un diagramma di un qualche tipo di sistema - e un tempo sufficiente per digerirlo. Quindi chiedi al candidato di spiegarti le informazioni o chiedi loro come lo spiegherebbero a una persona intelligente ma non tecnica, ecc.

Fornendo l'argomento, metti tutti i candidati su un piano di parità, e puoi anche assicurarti di comprendere il materiale personalmente.

La comunicazione persuasiva è una forma di pensiero critico e la forma più difficile di comunicazione. Quindi, testerei la loro capacità di considerare le idee in competizione e di formulare un argomento razionale supportandone uno.

Idee:

• Poni loro una domanda caricata di soggettività riscaldata, come la loro preferenza per la tipizzazione statica o la digitazione dinamica. Un buon risultato sarebbe se valutassero oggettivamente i fatti, l'applicabilità di entrambi gli approcci in situazioni diverse.
• Chiedere loro una domanda ambigua e aperta, come "Qual è il miglior tipo di sviluppatore da avere in un team di software?" Un buon risultato sarebbe se elencassero una manciata di attributi che sono caratteristici di tutti i buoni sviluppatori e poi discutono di come una filosofia orientata al team non richieda che tutti gli sviluppatori abbiano lo stesso set o livello di competenze; piuttosto, vuoi almeno uno sviluppatore con set di abilità A e altri sviluppatori con set di abilità B o C.
  • Una domanda a risposta aperta che implica la scelta della tecnologia potrebbe essere "Qual è il miglior linguaggio di programmazione per un'applicazione web?"
  • O relative al design: "Quali sono gli schemi di progettazione più importanti da avere in un codebase?"

Le risposte errate avrebbero:

• Sconvolgimenti poco chiari
• Preferenza prevalentemente soggettiva
• Nessuna valutazione obiettiva
• Nessuna considerazione dei punti di vista opposti

La maggior parte dei programmatori è sufficientemente abile nella descrizione procedurale (cioè la domanda come ) poiché è così che comunichiamo con i computer, quindi testerei la loro capacità di formulare una risposta al perché domanda. Chiedendo una domanda a risposta aperta, scopri se sono in grado di distillare le possibilità in una conclusione utile e saggia.

Relativamente difficile potrebbe essere un termine piuttosto carico per la mia mente. Era solo difficile in quel momento? Difficile come nel problema potrebbe essere un dottorato di ricerca. tesi? Difficile come uno dei Millennium Prize Problems ? Ci sono varie interpretazioni del termine qui come si potrebbe dedurre che questo era solo il problema più difficile che qualcuno ha affrontato fino ad oggi, più difficile che qualcuno abbia affrontato e risolto, o più difficile qualcuno abbia mai letto per dare alcune indicazioni qui.

Ciò che potresti percepire come difficile potrebbe essere o non essere per qualcun altro. Quindi, suggerirei di suddividere la domanda in 2 parti. Innanzitutto, chiedi al candidato di identificare il problema più difficile passato e di raccontare solo i fatti sul problema. La seconda parte sta spiegando dove era la difficoltà, che sta dando un'opinione su dove è stata la sfida e come è stato visto e affrontato. Mentre questo inizia con ciò che è stato fatto, la seconda parte è dove possono esserci tutti i tipi di domande di follow-up per vedere come qualcuno ha visto questo come difficile.