¿Cuántas preguntas son apropiadas para hacer como interno? [cerrado]

Sea respetuoso con el tiempo de su mentor manteniendo una lista de preguntas y haciéndolas por lotes, en la medida de lo posible. No interrumpa realmente a su mentor hasta que, literalmente, no pueda hacer ningún progreso hacia adelante sin ayuda.

Muchas veces aprenderá mucho luchando para encontrar la respuesta, incluso en los casos en que su mentor puede enseñarle algo en 10 segundos. Por ejemplo, si desea saber dónde hay algo en el código, puede preguntar (10 segundos), o puede pasar cuatro horas estudiando el código y tratando de averiguarlo usted mismo. La ventaja de la opción de "cuatro horas" es que realmente aprenderá 200 cosas nuevas sobre el código, lo cual le ayudará más adelante. Luchar por encontrar sus propias respuestas puede ser una pérdida de tiempo, pero también puede ser una forma de aprender una base de códigos muy complicada.

No hace falta decir que si se trata de una pregunta de programación que no concierne al código de propiedad de su empresa, debe intentar resolverlo usted mismo a través de Internet.

Como estudiante de último año que ha visto a los jóvenes hacer preguntas de todo tipo, yo diría que no es una cuestión de la frecuencia con la que haces las preguntas, sino de lo que preguntas .

Necesita sentirlo usted mismo, pero en general la regla es: Muestre su interés y su capacidad de pensar y trabaje de forma independiente .

Está bien hacer preguntas generales para establecer el contexto para la investigación detallada de bajo nivel que realiza usted mismo.

Está bien hacer preguntas sobre todo lo que no es un código y no está documentado : el proceso, la cultura del equipo, etc.

Hagas lo que hagas, muestra que lo has pensado y has hecho un esfuerzo para entender o resolver el problema por ti mismo.

¡No temas preguntar! Puede usarlo para mostrar interés y pensamiento más profundo , así como ahorrarle al equipo algo de dolor al no seguir sus prácticas o tomar decisiones inapropiadas que requerirán tiempo para desentrañar más tarde.

No cruce la línea y pídales que codifiquen para usted, le digan exactamente qué hacer cada vez, explique la sintaxis y copie la documentación, etc.

Creo que muchas de las respuestas dadas hasta el momento son justas en este punto: no tenga miedo de hacer preguntas (para eso son las pasantías, después de todo), pero deje claro que ha tratado de encontrar la respuesta. usted mismo antes de preguntar. Por mi parte, no me importan las preguntas en absoluto, pero sí me importan las preguntas en las que está claro que la persona que pregunta está preguntando solo porque es más conveniente para ellas interrumpir a otra persona. Está bien venir con una pregunta simple si lo has intentado, siempre y cuando no ocurra demasiado a menudo, pero no está bien ni siquiera intentarlo por ti mismo primero. E incluso con preguntas simples, tenga a la vez un caso simplificado y los detalles sangrientos listos. Piense en SSCCE - Short, Self Contained, Correct/Compilable Example . Hice que alguien se detuviera y comenzara a preguntar sobre el SQL dinámico, cuando la pregunta real era acerca de la extracción de datos del código ejecutado a través de un SQL EXEC . Esa es una gran diferencia.

Otro punto a considerar: ¿puede usar el correo electrónico o alguna otra forma de comunicación no intrusiva (o menos) para algunas de sus preguntas? Luego, su mentor puede responder por correo electrónico o (más probablemente) detenerse en su escritorio para discutir las cosas cuando tengan la oportunidad. Esto también va con el consejo de "preguntas por lotes" ya dado, pero personalmente me parece más fácil tratar una sola pregunta por mensaje de correo electrónico, que una larga lista de preguntas que tienen poco o nada que ver entre sí. juntos en un mensaje A menudo, uno puede ser respondido en un minuto o dos, el otro puede convertirse fácilmente en un tiempo de media hora.

No me preocuparía demasiado por hacer (demasiadas) preguntas. Un buen mentor le dirá de manera amistosa cuando sea el momento de dejar de preguntar y comenzar a practicar. Después de todo, el mentor fue asignado a ser tu mentor y esta tarea generalmente viene con un presupuesto de tiempo.

Estoy de acuerdo en que es una buena idea preparar un lote de preguntas y pedir la atención del mentor para discutirlas todas de una vez. Por otro lado, también puede ser muy frustrante (especialmente para los principiantes) tratar de averiguar cómo funcionan las cosas durante horas cuando una simple pregunta y respuesta resolvería el problema en cuestión de segundos.

Intente aprender de la experiencia y desarrolle la habilidad de "leer" a su mentor para averiguar cuándo hay una buena oportunidad y cómo debe comunicar su falta de atención . El desarrollo de software se trata tanto de interactuar con las personas como de mirar el código fuente.

En una nota relacionada, el estímulo y el entusiasmo funcionan en ambos sentidos, de mentor a pasante y de pasante a mentor.

Esta es probablemente una situación por la que todos hemos pasado. Ser un tipo nuevo, ya sea un interno o un empleado regular es complicado. Siempre implica el problema del arranque en frío, ya que estás en un lugar nuevo, con gente nueva, nuevas tecnologías, nuevas metodologías. Entiendo totalmente la ansiedad de no saber algo y querer conocerlo a la perfección, para que pronto seas productivo.

Tener preguntas es totalmente natural. Y puede estar seguro de que sus colegas saben que sí y tendrán preguntas. También han estado en su posición en algún momento, ¿verdad? Y créanme, TENÍAN que obtener ayuda de algún lugar.

La parte difícil es que no todos están disponibles en todo momento, para responder a cualquiera de las preguntas que pueda tener. Mi truco habitual al revisar el código o los documentos, es anotar cosas que no están claras de inmediato y organizar un par de reuniones breves por día para discutirlas con mis superiores. Antes de hacer una pregunta, siempre es una buena idea hacer una pequeña 'investigación' al respecto, tratar de obtener la mayor cantidad de información y sugerencias posibles. Sitios como StackOverflow son de oro. Incluso puede obtener la respuesta exacta que está buscando. Sus colegas apreciarán el esfuerzo y estarán más felices de ayudarlo.

Intente arduamente, estudie mucho, sea curioso y haga preguntas. Recuerde, todos han estado en su posición, y todos eventualmente sobrevivieron :)

Creo que vas a encontrarte con diferentes tipos de preguntas.

Para mi respuesta me centraré en lo que considero las preguntas POR QUÉ. Este tipo de preguntas lo ayudan a comprender por qué le piden que haga algo de cierta manera. (por ejemplo, ¿por qué utilizamos el estándar de codificación X?)

Creo que sería bueno para usted pedirle a su mentor que dedique un tiempo cada semana para revisar este tipo de preguntas. Una idea sería reservar 1 a 2 pausas para el café a la semana. Al tener un tiempo establecido para este tipo de preguntas, le demuestra a su mentor que valora su tiempo y que desea saber por qué algo se hace de cierta manera.

Mientras tu mentor sepa que primero has tratado de encontrar la respuesta y has tratado de encontrar una respuesta a la pregunta.

Un consejo sobre cuándo hacer una pregunta puede ser cuando tu mentor va a la máquina de café, entonces sabes que estás interrumpiendo su "flujo".

Estoy bastante en tu situación exacta en este momento. Mi supervisor está bastante ocupado y detecté que mis interrupciones no fueron muy bien recibidas. En mi caso, sin embargo, llegué sin saber muchas tecnologías utilizadas. Entonces, lo que he hecho es que cada vez que tengo una pregunta, la apunto. Si necesito una respuesta para continuar mi tarea, hago algo más por un tiempo. Leí algo de documentación para alguna otra tecnología que sé que usaré lo suficientemente pronto. A menos que la pregunta sea crítica para completar la tarea en la que debo estar trabajando, y no puedo continuar sin una respuesta, la pongo en cola.

Por ejemplo, si está escribiendo un código, puede escribir un comentario "todo" en esa parte y continuar escribiendo el resto del código. Puedes volver para completar la tarea más tarde.

Luego, cada vez que me reúno con mi supervisor descargo todas las preguntas a la vez. ¡Para entonces algunas de las preguntas que ya he respondido! Algunas de las preguntas también parecen tontas después de que se escriban durante un tiempo, por lo que no las preguntas.

Otra cosa que definitivamente debes hacer es simplemente hablar con tu mentor al respecto. De hecho eso es lo primero que hice. Simplemente me pregunté "¿Estoy haciendo demasiadas preguntas?" Me dio retroalimentación directa y podría dejar de preocuparme por si me relajaba o resolvía el problema.

Nota: Lo anterior solo se aplica a las preguntas que no están relacionadas con la técnica o la programación. Pasé mucho tiempo en Google / Stack Overflow buscando respuestas técnicas y usted también debería hacerlo. De hecho, si no estás buscando información nueva cada día en Google, casi diría que no estás aprendiendo lo suficiente :)

1. No te preocupes por preguntar demasiado. No importa que no sepas algo, pero la capacidad de estudiar asuntos.
2. Piensa y busca en Google antes de preguntar.
3. Ya que se comunica por MI y correo electrónico, trate de asegurarse de que su mentor entienda bien sus preguntas.
4. Una vez que se resuelve un problema, las notas son necesarias. Simplemente no podemos recordar todo lo que aprendemos en detalle.

Creo que Casey no es cuestión de cuestionarse ... es que eres un interno ... se supone que debes hacer preguntas. Y personalmente siento que cuestionar cosas siempre tiene su propio beneficio. Incluso si no realiza Google en ese caso, su mentor le dirá que debe estudiarlo por su cuenta. Recuerde que no se frustre ni se sienta abrumado por el nuevo entorno de trabajo con una base de código enorme. Es justo el momento en que debe dar y debe cuestionar casi todo lo que quiera.

preguntas felices :) :)

Ya sabes, si eres educado y alegre, puedes preguntar preguntar preguntar lejos.

Pero no hagas esas preguntas que parezcan derrotistas o insinúas que puedes ser insensible,