Interventi e domande di intervista per uno stagista di sviluppatori software [chiuso]

Non aspettarti che siano completamente inutili (dovrebbero non dovrebbero essere).

Aspettatevi che siano in grado di codificare bene (chiedendo come usare la raccolta di scelta basata su array nella vostra lingua di scelta (es. Elenco in c #, Vector / ArrayList in Java, ecc.) è un buon inizio), ma si aspettano che abbiano poca esperienza in termini di controllo versione, documentazione dei requisiti aziendali e controllo qualità.

Sono entrato nella mia prima azienda come stagista estivo, ricevendo un compito che sembrava ragionevolmente complesso (implementando un modulo di analisi CSV per una determinata importazione di dati). Si aspettavano che questo compito mi portasse fino alla fine del mio stage di 6 mesi, e l'ho finito felicemente in una settimana.

Capisco che molte persone pensano che non si impari qualcosa di utile all'Università, tuttavia, probabilmente scoprirai che le persone che fanno domanda per tirocini saranno probabilmente ragazzi che eccellono nella programmazione e hanno una vera spinta per fare le cose.

Quindi, chiedi loro della codifica. Chiedi loro cosa hanno codificato prima di essere orgogliosi. Chiedi loro cosa vogliono uscire dallo stage (in termini di abilità).

Speriamo che ti ritroverai con un lavoratore di qualità, se inesperto, che puoi usare per un obiettivo costruttivo che è vantaggioso sia per te che per il tirocinante!

Ci sono alcune cose che cerchiamo di scoprire sui tirocinanti, ma in genere si tratta di attitudini e interessi. Vuoi chiedere delle cose tecniche che hanno fatto, a scuola o da sole, e decidere se hanno un potenziale reale e perché diamine stanno inseguendo CS. Nel secondo giorno la seconda parte era molto più facile. Non molte persone armeggiavano con schede perforate per 4 anni se non erano veramente interessati. Oggi ricevi un sacco di ragazzi che "amano Internet" e decidono di entrare in CS per questo motivo. Dio ci salvi.

Quindi chiedo cose come "qual è la cosa più bella che hai fatto?" e "cosa ti eccita di diventare un programmatore?"

Poi faccio in modo che svolgano compiti di automazione, test manuali e codifica di alcune piccole utility per un'estate.

Vorrei strongmente raccomandare ...

"Inserisci un codice che hai scritto per una delle tue classi o un progetto collaterale che hai e guidaci attraverso di esso"

Se non hanno il codice, probabilmente non dovrebbero essere internati per una posizione di programmatore (ancora).
Invitali a presentare il problema / progetto su cui stavano lavorando. Sii facile con il tirocinante, ma chiedi delle decisioni sul design che hanno preso, i compromessi che hanno affrontato. Quello che era facile / difficile per loro. Inoltre, inizia ad espandere l'ambito del progetto su di essi e chiedi loro come incorporerebbero le modifiche.

Cerca persone con risposte buone e premurose. Chiedendo "hai sentito parlare di semafori o mutex" se rimangono bloccati in qualche parte è giusto e non c'è problema se non lo fanno.

Questa intervista può essere ovunque da 1 a 4 ore a seconda di quanto vuoi andare. Penso che nel caso di stagisti, lo schermo del telefono sia un po 'fuori mano e mantenga l'intervista a 90 minuti (sconvolge la tua squadra per 2 ore). Questo sembra fornire un buon mix di dolore / valore.

Normalmente chiedo ai tirocinanti i loro progetti scolastici durante l'intervista. Dò loro la possibilità di spiegare su che cosa hanno lavorato, scelte di progettazione, qualsiasi cosa, cosa hanno imparato dall'esperienza, ecc. Mi dà la possibilità di vedere come vanno a fare i loro compiti e mi permette anche di prendere una decisione migliore se questo è qualcuno con cui mi vedrei lavorare e fare da mentore nei prossimi mesi.

Non trattare lo stagista come se fosse uno stagista. Trattali come se fossero parte della squadra, perché lo sono. Dare loro qualcosa da fare che possono possedere e questo non è banale. Dovrebbe essere abbastanza avanzato da imparare qualcosa ma abbastanza piccolo da non lasciarlo in una brutta situazione quando se ne vanno.

Assegnare loro le attività chump non li aiuta e non aiuta nemmeno la tua azienda. Se sono insoddisfatti del loro compito, mostreranno nelle loro prestazioni che non saranno felici e sentiranno che il loro lavoro non ha importanza.

Continuate con loro per assicurarvi che non siano in testa e facciano revisioni del codice in modo che possiate vedere cosa viene inserito nel vostro codice base e in modo che possiate dare suggerimenti su come migliorare il loro codice.