Qual è il modo migliore per mostrare parte del mio codice durante un'intervista? [duplicare]

Perché non li fai entrambi? Porta stampe di carta e porta un dispositivo elettronico per mostrare il resto?

Se ti hanno permesso di sapere quante persone stai intervistando, porta la stampa per ogni intervistatore più due o tre pezzi di ricambio. Gli intervistatori extra vengono aggiunti in ogni momento e tu vuoi essere preparato per questo.

Se puoi, porta un dispositivo con uno schermo facilmente visibile da lontano. Non devi necessariamente rannicchiare sullo schermo da 4 "del tuo telefono per mostrare il tuo codice.

Prenderò in considerazione la selezione di sezioni separate di codice da mostrare. Per la stampa, una routine più piccola, per lo più autonoma, sarebbe l'ideale. Per il dispositivo, vorrei provare a identificare alcuni problemi spinosi che dovevi risolvere e caricare quelli pronti per lo spettacolo.

Vale la pena notare che devi non per portare copie della tua applicazione di origine chiusa a meno che tu voglia di farlo. Qualsiasi potenziale datore di lavoro dovrebbe rispettare il tuo copyright e capire che potresti non sentirti a tuo agio nel distribuire copie di tale fonte.

Ci sono diversi obiettivi:

1. Per vedere che la persona può codificare.

   Non essere sorpreso: molti programmatori che vengono a un colloquio non sanno come scrivere codice. Mentre è davvero difficile scrivere codice sotto pressione durante un'intervista, alcuni non sono nemmeno in grado di scriverlo al di fuori di un'intervista. Se quei programmatori copia-incolla sono inutili in un'azienda, chiedere a loro di fornire il proprio codice è un buon modo per filtrare quei candidati.

2. Per vedere che la persona ha i suoi progetti o partecipa a progetti open source esistenti.

   Molti programmatori che stavo intervistando avevano solo codice sorgente scritto al lavoro. Questo è un buon segno che per loro, la programmazione è solo un modo per guadagnare denaro, non una passione.

3. Per vedere il codice di alta qualità (o quello che la persona pensa essere un codice di alta qualità).

   Una parte non trascurabile dei candidati che ho intervistato stava portando il codice pieno di bug e, per bug, intendo bug chiaramente visibili come loop infiniti, codice morto, ecc. Quasi ogni candidato che portava codice C # aveva il suo stile, o meglio niente stile (nota: C # ha convenzioni consolidate create da Microsoft e applicate da StyleCop, uno strumento che si integra bene con l'IDE utilizzato per scrivere C # su Windows).

   Uno sguardo al codice sorgente può dirti molto di più sul candidato di quindici minuti di intervista.

4. Per verificare che la persona non stia portando codice proprietario.

   Ho fatto diverse interviste in cui i candidati stavano portando codice proprietario. Non stavano nemmeno nascondendo il nome della compagnia. Uno, alla domanda "Non pensi che sia inquietante mostrare a una terza parte un pezzo di codice per un progetto probabilmente coperto dalla NDA?", Ha risposto: "Davvero non mi preoccupo, in tutti i casi questa compagnia è stata zoppa !”.

5. Per vedere che la persona è in grado di gestire o partecipare a un progetto su larga scala.

Personalmente, chiedo agli intervistati di inviarmi un pezzo di codice prima dell'intervista. Durante l'intervista, faccio loro delle domande, come ad esempio:

At line 27, you are using a stream without disposing it. Why? What are the two ways, in C#, to dispose it?

o

You have code duplication between the line 14-18 and the line 55-59. Why? How can you easily avoid it?

o

At line 62, you do a cast. Why?

Alcune di queste domande sono legate ai bug: quando chiedo loro, voglio sapere come il candidato gestirà questa situazione (e se prima vedrà il bug stesso). Alcune persone sono estremamente cattive a gestirlo. Ad esempio, risposte come: "Ha dei bachi perché questa parte non è stata scritta da me." (Beh, ho chiesto di portare il tuo codice, non quello dei tuoi colleghi) sono frequenti.

Altre domande sono relative alle parti scure del codice. Sono stato spesso sorpreso dai candidati che erano perfettamente in grado di spiegare perché l'hanno fatto in questo modo, e perché un approccio diverso sarebbe stato peggio.

• Se pensi di essere soggetto a tali domande, assicurati di portare un breve pezzo di codice che conosci perfettamente: rispondere alle domande sulle parti che non conosci bene non è facile. Cerca di portare un pezzo di codice che potrebbe non essere particolarmente impegnativo, ma che è scritto in modo impeccabile, pulito e facile da spiegare.

• Se non pensi che l'intervistatore farà domande (ma piuttosto ascolti mostrando il tuo codice), porta più pezzi di codice per mostrare l'architettura, oltre a mettere in evidenza aspetti tecnicamente impegnativi.

Ricorda: se i tuoi progetti sono open source, inserire il link ad essi nel tuo CV può essere utile (a meno che non ci siano motivi per vergognarsi del tuo codice).

• Credo che Github sia la migliore vetrina per il codice in questi giorni, quindi assicurati di creare un repository per ogni progetto interessante. Bitbucket è un'alternativa se vuoi repository privati gratuiti.
• Un tablet è davvero utile in questo caso, è possibile creare una presentazione con schermate e alcune righe di testo per mostrare alcuni progetti (come quelli a sorgente chiusa).
• Mostra loro le applicazioni in esecuzione e evidenzia le funzionalità più interessanti. Niente è paragonabile all'esperienza di un prodotto funzionante.