Combien de questions faut-il poser en tant que stagiaire? [fermé]

Alors, je viens juste de commencer un stage et je crains de poser trop de questions. Mon mentor m'assigne des projets et m'aide à apprendre toutes les technologies et méthodologies de l'entreprise. Cependant, il y a tellement de nouveaux matériaux à apprendre pour faire ce projet que j'ai beaucoup de questions. Je pose généralement des questions par messages instantanés ou par courrier électronique (ce sont les principaux modes de communication de mon entreprise).

J'essaie de faire attention à ne pas poser trop de questions: je ne veux pas paraître ennuyeux ou stupide. Combien de questions faut-il poser? Une fois par heure? Plus? Moins? N'oubliez pas que mon mentor est également un collègue programmeur qui a ses propres responsabilités.

Respectez le temps de votre mentor en tenant une liste de questions et en les posant par lots, dans la mesure du possible. N'interrompez pas réellement votre mentor jusqu'à ce que vous ne puissiez littéralement pas progresser sans aide.

Bien souvent, vous aurez beaucoup de mal à trouver la réponse vous-même, même dans les cas où votre mentor peut vous apprendre quelque chose en 10 secondes. Par exemple, si vous voulez savoir où se trouve quelque chose dans le code, vous pouvez le demander (10 secondes) ou passer quatre heures à étudier le code et à essayer de le comprendre vous-même. L'avantage de l'option "quatre heures" est que vous allez réellement apprendre 200 nouvelles choses sur le code, qui vous aideront toutes plus tard. Se débattre pour trouver ses propres réponses peut être une perte de temps, mais peut aussi être un moyen d’apprendre une base de code complexe et complexe.

Inutile de dire que s'il s'agit d'une question de programmation qui ne concerne pas le code propriétaire de votre entreprise, vous devriez essayer de la résoudre vous-même en utilisant Internet.

En tant que senior qui a vu des juniors poser toutes sortes de questions, je dirais que ce n’est pas une question de fréquence, mais de ce que vous demandez .

Vous devez le ressentir vous-même, mais la règle générale est la suivante: Montrez votre intérêt et votre capacité à penser et à travailler de manière indépendante .

Vous pouvez poser des questions d'ordre général pour définir le contexte de l'enquête détaillée de bas niveau que vous effectuez vous-même.

C'est bien de poser des questions sur tout ce qui n'est pas du code et qui n'est pas documenté - le processus, la culture d'équipe, etc.

Quoi que vous fassiez, montrez que vous avez réfléchi et fait un effort pour comprendre ou résoudre le problème vous-même.

N'ayez pas peur de demander cependant! Vous pouvez vous en servir pour manifester de l'intérêt et approfondir votre réflexion , ainsi que pour éviter des ennuis à l'équipe en ne suivant pas ses pratiques ou en prenant des décisions inappropriées qui nécessiteront du temps pour se démêler ultérieurement.

Il suffit simplement de ne pas traverser la ligne et de leur demander de coder pour vous, de vous dire exactement quoi faire à chaque fois, d’expliquer la syntaxe et la copie de la documentation, etc.

Je pense que beaucoup des réponses données jusqu'ici sont exactes: n'ayez pas peur de poser des questions (c'est à quoi servent les stages, après tout), mais précisez que vous avez essayé de trouver la réponse vous-même avant de demander . Pour ma part, cela ne me dérange pas du tout de poser des questions, mais cela ne me dérange pas non plus lorsqu'il est clair que la personne qui pose la question ne le demande que parce qu'il est plus commode pour eux d'interrompre quelqu'un d'autre. Si vous avez essayé, vous pouvez poser une question simple, à condition que cela ne se produise pas trop souvent, mais il n'est pas correct de ne pas essayer par vous-même en premier. Et même avec des questions simples, ayez à la fois un cas simplifié et les détails sanglants à portée de main. Pensez SSCCE -Short, Self Contained, Correct/Compilable Example. J'avais quelqu'un qui m'arrêtait et commençais à poser des questions sur le SQL dynamique, alors que la vraie question concernait l'extraction de données à partir de code exécuté via un SQL EXEC. C'est une grosse différence.

Autre point à considérer: pouvez-vous utiliser le courrier électronique ou une autre forme de communication non (ou moins) intrusive pour certaines de vos questions? Ensuite, votre mentor peut soit répondre par courrier électronique, soit (plus vraisemblablement) passer à votre bureau pour discuter de choses lorsque cela se présente. Cela va également de pair avec les conseils de "mise en lots" déjà donnés, mais je trouve personnellement qu'il est plus facile de traiter une seule question par message électronique qu'une longue liste de questions qui n'ont que peu ou rien à voir les unes avec les autres. ensemble en un seul message. On peut souvent répondre à l'une d'elles en une minute ou deux, l'autre peut facilement devenir une demi-heure.

Je ne m'inquiéterais pas trop de poser (trop) de questions. Un bon mentor vous dira amicalement quand il sera temps d'arrêter de demander et de commencer à vous entraîner. Après tout, le mentor était chargé de vous guider et cette tâche est généralement assortie d’un budget de temps.

Je conviens que c'est une bonne idée de préparer un lot de questions et de demander à l'attention du mentor de les aborder en une fois. D'un autre côté, il peut aussi être très frustrant (surtout pour les débutants) d'essayer de comprendre comment ça marche pendant des heures lorsqu'une simple question et une réponse régleraient littéralement le problème en quelques secondes.

Essayez d'apprendre de l'expérience et développez l'habileté de "lire" votre mentor pour savoir quand il y a une bonne opportunité et comment vous devez communiquer votre manque d'attention. Le développement logiciel consiste autant à interagir avec les gens qu’à regarder le code source.

Sur une note connexe, encouragement et enthousiasme vont dans les deux sens, de mentor à stagiaire et de stagiaire à mentor.

C'est probablement une situation que nous avons tous vécu. Être le nouveau type, qu'il s'agisse d'un stagiaire ou d'un employé régulier, est délicat. Cela implique toujours le problème du démarrage à froid, car vous êtes dans un nouvel endroit, avec de nouvelles personnes, de nouvelles technologies, de nouvelles méthodologies. Je comprends tout à fait l’angoisse de ne pas savoir quelque chose et de vouloir le connaître parfaitement, pour que vous deveniez rapidement productif.

Avoir des questions est totalement naturel. Et vous pouvez être sûr que vos collègues savent que vous avez et aurez des questions. Ils ont également été à votre position à un moment donné, non? Et croyez-moi, ils devaient obtenir de l'aide de quelque part.

Le problème, c’est que tout le monde n’est pas disponible à tout moment pour répondre à vos questions. Mon astuce habituelle lorsque je consulte un code ou des documents consiste à noter des choses qui ne sont pas immédiatement claires et à organiser deux ou trois petites réunions par jour pour en discuter avec mes aînés. Avant de poser une question, c'est toujours une bonne idée de faire une petite "recherche" à ce sujet, essayez d'obtenir autant d'informations et de conseils que possible. Des sites comme StackOverflow sont en or. Vous pourriez même obtenir la réponse exacte que vous recherchez. Vos collègues apprécieront l'effort et seront plus heureux de vous aider.

Essayez fort, étudiez fort, soyez curieux et posez des questions. N'oubliez pas que tout le monde a été à votre place et que tout le monde a finalement survécu :)

Je pense que vous allez rencontrer différents types de questions.

Pour ma réponse, je me concentrerai sur ce que je considère comme des questions POURQUOI. Ces types de questions vous aident à comprendre pourquoi on vous demande de faire quelque chose d'une certaine manière. (ex. Pourquoi utilisons-nous la norme de codage X?)

Je pense qu'il serait bien que vous demandiez à votre mentor de réserver un peu de temps chaque semaine pour poser ce genre de questions. Une idée serait de prévoir 1 à 2 pauses café par semaine. En fixant un temps déterminé pour ce type de questions, vous montrez à votre mentor que vous appréciez son temps et que vous souhaitez savoir pourquoi une chose est faite d'une certaine manière.

Tant que votre mentor sait que vous avez essayé d’abord de trouver la réponse et d’essayer de trouver une réponse à la question.

Un conseil pour poser une question peut être lorsque votre mentor se rend à la machine à café, alors vous savez que vous interrompez son "écoulement".

Je suis à peu près dans votre situation exacte en ce moment même. Mon superviseur est très occupé et j'ai remarqué que mes interruptions n'étaient pas très bien accueillies assez tôt. Dans mon cas cependant, je suis arrivé sans connaître beaucoup de technologies. Donc, ce que j'ai fait est que, chaque fois que j'ai une question, je la note. Si j'ai besoin d'une réponse pour continuer ma tâche, je fais autre chose pendant un moment. J'ai lu de la documentation sur une autre technologie que je saurais utiliser assez tôt. À moins que la question ne soit cruciale pour terminer la tâche sur laquelle je dois travailler et que je ne puisse pas continuer sans réponse, je la file.

Si c'est du code que vous écrivez par exemple, vous pouvez écrire un commentaire "todo" dans cette partie et continuer à écrire le reste du code. Vous pouvez revenir pour compléter la tâche plus tard.

Ensuite, chaque fois que je rencontre mon superviseur, je décharge toutes les questions en même temps. A ce moment-là, certaines des questions auxquelles j'ai déjà répondu moi-même! Certaines des questions semblent aussi stupides après avoir été écrites pendant un moment, de sorte que vous ne les posez pas.

Une autre chose que vous devriez absolument faire est tout simplement d’en parler à votre mentor. En fait c'est la première chose que j'ai faite. J'ai simplement demandé directement "Est-ce que je pose trop de questions?" Cela me donnait un retour direct et je pouvais cesser de me demander si je pouvais me calmer ou résoudre le problème.

Remarque: Ce qui précède s'applique uniquement aux questions qui ne sont pas techniques ou liées à la programmation. Je passe beaucoup de temps sur Google / Stack Overflow à la recherche de réponses techniques, et vous devriez le faire aussi. En fait, si vous ne googez pas chaque jour avec de nouvelles informations, je dirais presque que vous n'en apprenez pas assez :)

1. Ne vous inquiétez pas pour demander trop. Peu importe que vous ne sachiez pas ça, mais la capacité d'étudier est importante.
2. Pensez et Google avant de demander.
3. Puisque vous communiquez par messagerie instantanée et par courrier électronique, essayez de vous assurer que votre mentor comprend bien vos questions.
4. Une fois le problème résolu, des notes sont nécessaires. Nous ne pouvons tout simplement pas nous souvenir de tout ce que nous apprenons en détail.

Je pense que Casey, ce n’est pas une question de questionnement. Rien, c’est que vous soyez stagiaire, vous êtes supposé poser des questions. Et personnellement, j'estime que remettre en question les choses a toujours ses avantages. Même si vous n'avez pas Google dans ce cas, votre mentor devrait vous dire que vous devez étudier cela vous-même. Rappelez-vous qu'il ne faut pas être frustré ou ne pas être submergé par un nouvel environnement de travail avec une base de code énorme. C’est juste le temps de donner et de remettre en question à peu près tout ce que vous voulez.

bon questionnement :) :)

Vous savez, si vous êtes poli et enjoué, vous pouvez demander, demander, demander.

Mais ne posez pas ces questions qui semblent défaitistes ou qui impliquent que vous êtes peut-être insolent,