Quante domande sono appropriate da porre come stagista? [chiuso]

Quindi, ho appena iniziato uno stage e sono preoccupato di fare troppe domande. Il mio mentore mi assegna progetti e mi aiuta a imparare tutte le tecnologie e le metodologie dell'azienda. Tuttavia, c'è così tanto nuovo materiale da imparare mentre faccio questo progetto che ho molte domande. In genere faccio domande tramite messaggi istantanei o e-mail (queste sono le principali modalità di comunicazione per la mia azienda).

Sto cercando di stare attento a non fare troppe domande: non voglio diventare noioso o stupido. Quante domande è opportuno porre? Una volta ogni ora? Di Più? Di meno? Tieni presente che il mio mentore è anche un collega programmatore che ha le sue responsabilità.

Sii rispettoso del tempo del tuo tutor mantenendo un elenco di domande e ponendole in lotti, per quanto possibile. Non interrompere effettivamente il tuo mentore fino a quando non puoi letteralmente fare progressi in avanti senza aiuto.

Molte volte imparerai molto lottando per trovare la risposta da solo, anche nei casi in cui il tuo mentore può insegnarti qualcosa in 10 secondi. Ad esempio, se vuoi sapere dove si trova qualcosa nel codice, puoi chiedere loro (10 secondi), oppure puoi passare quattro ore a studiare il codice e provare a capirlo da solo. Il vantaggio dell'opzione "quattro ore" è che imparerai in realtà 200 nuove cose sul codice, che ti aiuteranno in seguito. Lottare per trovare le proprie risposte può essere una perdita di tempo, ma può anche essere un modo per imparare una grande base di codice complicata.

Inutile dire che se si tratta di una domanda di programmazione che non riguarda il codice proprietario della tua azienda, dovresti provare a capirlo da solo utilizzando Internet.

Come senior che ha visto juniors fare ogni tipo di domanda, direi che non si tratta della frequenza con cui lo chiedi, ma di ciò che chiedi .

Devi sentirlo da solo, ma generalmente la regola è: mostrare il tuo interesse e la tua capacità di pensare e lavorare in modo indipendente .

È OK porre domande generali per stabilire il contesto dell'indagine di dettaglio di basso livello che tu stesso esegui.

È OK porre domande su tutto ciò che non è codice e non è documentato : processo, cultura del team, ecc.

Qualunque cosa tu faccia, mostra che ci hai pensato e fatto uno sforzo per capire o risolvere il problema da solo.

Non aver paura di chiedere però! Puoi usarlo per mostrare interesse e un pensiero più profondo , oltre a risparmiare un po 'di dolore alla squadra non seguendo le loro pratiche o prendendo decisioni inadeguate che richiederanno tempo per districarsi in seguito.

Basta non attraversare la linea e chiedere loro di codificare per te, dirti esattamente cosa fare ogni volta, spiegare la sintassi e copiare la documentazione, e così via.

Penso che molte delle risposte fornite finora siano esatte: non aver paura di fare domande (questo è lo scopo dei tirocini, dopo tutto), ma chiarisci che hai cercato di trovare la risposta da solo prima di chiedere . Io per primo non mi dispiace affatto per le domande, ma mi vengono in mente domande in cui è chiaro che la persona che le sta chiedendo è solo perché è più conveniente per loro interrompere qualcun altro. Va bene fare una semplice domanda se ci hai provato, purché non accada troppo spesso, ma non va bene nemmeno provare prima tu stesso. E anche con domande semplici, sono pronti sia una custodia semplificata che i dettagli cruenti. Pensa SSCCE -Short, Self Contained, Correct/Compilable Example. Ho avuto qualcuno che si fermava e iniziava a chiedere informazioni su SQL dinamico, quando la vera domanda era sull'estrazione di dati dal codice eseguito tramite un SQL EXEC. Questa è una differenza abbastanza grande.

Un altro punto da considerare: puoi usare la posta elettronica o qualche altra forma di comunicazione non invasiva (o meno) per alcune delle tue domande? Quindi, il tuo mentore può rispondere via e-mail o (più probabilmente) fermarsi alla tua scrivania per discutere delle cose quando ne hanno la possibilità. Questo vale anche per i consigli di "raggruppamento delle domande" già forniti, ma trovo personalmente più semplice gestire una singola domanda per messaggio di posta elettronica, piuttosto che un lungo elenco di domande che hanno poco o nulla a che fare l'una con l'altra tutte raggruppate. insieme in un messaggio. Si può spesso rispondere a uno in un minuto o due, l'altro può diventare molto facilmente una cronometro di mezz'ora.

Non mi preoccuperei troppo di fare (troppe) domande. Un buon mentore ti dirà in modo amichevole quando è il momento di smettere di chiedere e iniziare a praticare. Dopotutto, il mentore è stato assegnato al tuo mentore e questo incarico di solito prevede un budget temporale.

Sono d'accordo che sia una buona idea preparare una serie di domande e chiedere l'attenzione del tutor per discuterle tutte in una volta. D'altra parte, può anche essere molto frustrante (specialmente per i principianti) provare a capire come funzionano le cose per ore quando una semplice domanda e risposta risolverebbe letteralmente il problema in pochi secondi.

Cerca di imparare dall'esperienza e sviluppa l'abilità di "leggere" il tuo mentore per capire quando c'è una buona opportunità e come comunicare la tua mancanza di attenzione. Lo sviluppo del software riguarda tanto l'interazione con le persone quanto il fissare il codice sorgente.

In una nota correlata, l'incoraggiamento e l'entusiasmo funzionano in entrambi i modi, dal mentore al tirocinante e dal tirocinante al mentore.

Questa è probabilmente una situazione che abbiamo attraversato tutti. Essere il nuovo ragazzo, che si tratti di un tirocinante o di un dipendente regolare, è difficile. Implica sempre il problema dell'avviamento a freddo, poiché ti trovi in ​​un posto nuovo, con nuove persone, nuove tecnologie, nuove metodologie. Capisco perfettamente l'ansia di non sapere qualcosa e di voler conoscerlo perfettamente, in modo da diventare presto produttivo.

Avere domande è del tutto naturale. E puoi essere certo che i tuoi colleghi sanno che lo fai e che avranno domande. Sono stati anche nella tua posizione ad un certo punto, giusto? E credimi, DOVREBBE ottenere un aiuto da qualche parte.

La parte difficile è che non tutti sono sempre disponibili, per rispondere a qualsiasi domanda tu possa avere. Il mio solito trucco quando si esaminano codici o documenti, è tenere appunti di cose che non sono immediatamente chiare e organizzare un paio di brevi incontri al giorno, per discuterne con i miei anziani. Prima di porre una domanda, è sempre una buona idea fare una piccola "ricerca" al riguardo, cercare di ottenere quante più informazioni e suggerimenti possibili. Siti come StackOverflow sono oro. Potresti persino ottenere la risposta esatta che stai cercando. I tuoi colleghi apprezzeranno lo sforzo e saranno più felici di aiutarti.

Sforzati, studia sodo, sii curioso e fai domande. Ricorda, tutti sono stati nella tua posizione e tutti sono sopravvissuti :)

Penso che incontrerai diversi tipi di domande.

Per la mia risposta, mi concentrerò su ciò che considero PERCHÉ le domande. Questi tipi di domande ti aiutano a capire perché ti viene chiesto di fare qualcosa in un certo modo. (es. Perché utilizziamo lo standard di codifica X?)

Penso che sarebbe positivo per te chiedere al tuo mentore di riservare un po 'di tempo ogni settimana per affrontare questo tipo di domande. Un'idea sarebbe quella di riservare da 1 a 2 pause caffè a settimana. Avendo un tempo prestabilito per questo tipo di domande mostri al tuo mentore che apprezzi il loro tempo e che desideri imparare perché qualcosa viene fatto in un certo modo.

Finché il tuo mentore sa che hai provato a trovare prima la risposta e hai cercato di trovare una risposta alla domanda.

Un suggerimento su quando porre domande può essere quando il tuo mentore va alla macchina del caffè, quindi sai che stai interrompendo il suo "flusso".

Sono praticamente nella tua situazione esatta in questo preciso momento. Il mio supervisore è piuttosto impegnato e ho colto le mie interruzioni non essendo stato accolto molto presto. Nel mio caso, però, sono arrivato non conoscendo molte tecnologie utilizzate. Quindi quello che ho fatto è, ogni volta che ho una domanda, la annoto. Se ho bisogno di una risposta per continuare il mio compito, faccio qualcos'altro per un po '. Ho letto della documentazione per qualche altra tecnologia che so che userò abbastanza presto. A meno che la domanda non sia fondamentale per completare l'attività su cui devo lavorare e non posso continuare senza una risposta, la metto in coda.

Se è il codice che stai scrivendo, ad esempio, puoi scrivere un commento "todo" in quella parte e continuare a scrivere il resto del codice. Puoi tornare indietro per compilare il todo più tardi.

Quindi, ogni volta che incontro il mio supervisore, scarico tutte le domande contemporaneamente. A quel punto alcune delle domande alle quali ho già risposto da solo! Alcune delle domande sembrano anche stupide dopo essere state scritte per un po ', quindi non le fai.

Un'altra cosa che dovresti assolutamente fare è semplicemente parlarne con il tuo mentore. In effetti questa è la prima cosa che ho fatto. Ho semplicemente chiesto "Sto facendo troppe domande?" Mi ha dato un feedback diretto e potrei smettere di preoccuparmi se e rilassare o risolvere il problema.

Nota: quanto sopra vale solo per domande che non sono tecniche o relative alla programmazione. Dedico molto tempo a Google / Stack Overflow alla ricerca di risposte tecniche e dovresti farlo anche tu. In effetti, se non stai cercando su Google nuove informazioni ogni giorno, direi che non stai imparando abbastanza :)

1. Non preoccuparti di chiedere troppo. Non importa che tu non sappia sth, ma capacità di studiare questioni.
2. Pensa e Google prima di chiedere.
3. Dato che comunichi tramite messaggistica istantanea ed e-mail, cerca di assicurarti che il tuo tutor capisca bene le tue domande.
4. Una volta risolto un problema, sono necessarie note. Non riusciamo a ricordare tutto ciò che apprendiamo in dettaglio.

Penso che Casey non sia una questione di domande ... è che sei un tirocinante .. devi supporre di fare domande. E personalmente sento che mettere in discussione le cose ha sempre il suo vantaggio. Anche se in questo caso non utilizzi Google, il tuo mentore dovrebbe dirti che devi studiarlo da solo. Ricorda che non ti frustrare o non essere sopraffatto dal nuovo ambiente di lavoro con una base di codice enorme. È solo il momento che devi dare e dovresti mettere in discussione praticamente tutto quello che vuoi.

felice interrogatorio :) :)

Sai, se sei educato e allegro puoi chiedere chiedi via.

Ma non porre quelle domande che sembrano disfattiste o che implicano che potresti essere sconsiderato,