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


56

Entonces, acabo de comenzar una pasantía y me preocupa hacer demasiadas preguntas. Mi mentor me asigna proyectos y me ayuda a aprender todas las tecnologías y metodologías de la compañía. Sin embargo, hay tanto material nuevo que puedo aprender mientras hago este proyecto que tengo muchas preguntas. Generalmente hago preguntas por mensajes instantáneos o correo electrónico (esos son los modos principales de comunicación para mi empresa).

Estoy tratando de tener cuidado de no hacer muchas preguntas: no quiero parecer molesto o tonto. ¿Cuántas preguntas son apropiadas para hacer? ¿Una vez por hora? ¿Más? ¿Menos? Tenga en cuenta que mi mentor también es un programador compañero que tiene sus propias responsabilidades.


13
Creo que se trata menos de cuántos, pero más acerca de "cuándo". Si estoy disponible, siéntase libre. Si estoy ocupado, pregunte más tarde o a otra persona. Solo es molesto si deja de pensar por su cuenta y sigue preguntando todo: ¡siempre investigue antes de preguntar!
Vitor Py

14
Siempre puedes preguntarle a tu mentor cómo prefieren las cosas. Te darán una mejor respuesta que nosotros.
unholysampler

1
Creo que es gramaticalmente correcto de cualquier manera. Reformúlelo como una declaración y no como una pregunta: es apropiado hacer n preguntas por día. O: n preguntas son apropiadas para hacer, cada día. El segundo suena más incómodo en forma no cuestionable, pero estoy bastante seguro de que ambos son correctos.
MatrixFrog

Respuestas:


98

Sea respetuoso con el tiempo de su mentor manteniendo una lista de preguntas y haciéndolas en lotes, en la medida de lo posible. No interrumpas a tu mentor hasta que, literalmente, no puedas avanzar sin ayuda.

Muchas veces aprenderá mucho luchando por encontrar la respuesta usted mismo, incluso en los casos en que su mentor pueda enseñarle algo en 10 segundos. Por ejemplo, si desea saber dónde hay algo en el código, puede preguntarles (10 segundos) o puede pasar cuatro horas estudiando el código e intentando resolverlo usted mismo. La ventaja de la opción de "cuatro horas" es que realmente aprenderá 200 cosas nuevas sobre el código, todo 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ódigo grande y complicada.

No es necesario decir que si se trata de una pregunta de programación que no se refiere al código propietario de su empresa, debe intentar resolverlo usted mismo utilizando Internet.


44
Gracias por las sugerencias! Definitivamente me gusta la idea de los lotes y le daré una oportunidad. Sin embargo, dada la cultura de mensajería instantánea de mi empresa, me pregunto si podría ser un poco extraño dispararle 5 preguntas a la vez. También me gusta la idea de "4 horas" (definitivamente pasé por algo de eso hoy y aprendí mucho sobre su software). El único problema con la idea de "4 horas" es que me dijo que le gustaría que tuviera un proyecto terminado para el final de la semana. Dado que este es mi primer proyecto, definitivamente no quiero perder este plazo.
Casey Patton

1
+1 Nada va a ser mejor que esto
V4Vendetta

1
Eso es algo que estoy tratando de explicar a mis nuevos empleados, cuando se quejan de que están atascados y frustrados, que prefiero que investiguen por su cuenta durante una o dos horas, y solo entonces me piden ayuda, en lugar de que apunte al archivo y resuelva su problema en 5 minutos, exactamente porque aprenderán mucho más sobre la aplicación por su cuenta.
Miki Watts

1 Para defender la auto-mejora con respecto a solamente pasarlo
Kevin Laicos

@Casey Patton: Si tiene experiencia con pasantes, es probable que haya agregado tiempo para que usted se investigue y haga preguntas sobre el factor de cuándo quiere que se haga el producto. Donde trabajo, no es inusual darle a un pasante un proyecto temprano y esperar que tome una semana lo que alguien familiarizado con el código podría hacer en un par de horas. Simplemente no puede ser tan productivo antes de haber aprendido la base de código, y eso lleva tiempo.
Caleb Huitt - cjhuitt

28

Como senior que ha visto a juniors haciendo todo tipo de preguntas, yo diría que no se trata de la frecuencia con la que preguntas, sino de lo que preguntas .

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

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

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

Haga lo que haga, demuestre que lo pensó un poco y que hizo un esfuerzo por comprender o resolver el problema usted mismo.

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

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


6

Creo que muchas de las respuestas dadas hasta ahora son correctas: no tengas miedo de hacer preguntas (después de todo, para eso son las pasantías), pero deja en claro que has intentado encontrar la respuesta tú mismo antes de preguntar . Por mi parte, no me importa pregunta en absoluto, pero lo hago preguntas mente donde está claro que la persona que solicita está pidiendo sólo porque es más conveniente para ellos a otra interrupción más. Está bien venir con una pregunta simple si lo has intentado, siempre que no suceda con demasiada frecuencia, 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. Piense SSCCE -Short, Self Contained, Correct/Compilable Example. Hice que alguien se detuviera y comenzara a preguntar sobre SQL dinámico, cuando la verdadera pregunta era sobre 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 utilizar el correo electrónico o alguna otra forma de comunicación no intrusiva para algunas de sus preguntas? Luego, su mentor puede responder por correo electrónico o (más probablemente) pasar por su escritorio para discutir las cosas cuando tengan la oportunidad. Esto también va con el consejo de "preguntas de agrupamiento" ya dado, pero personalmente me resulta 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 solo mensaje. A menudo, uno puede ser respondido en un minuto o dos, el otro puede convertirse fácilmente en un disipador de tiempo de media hora.


5

No me preocuparía demasiado por hacer (demasiadas) preguntas. Un buen mentor le dirá de manera amigable cuándo es el momento de dejar de preguntar y comenzar a practicar. Después de todo, el mentor fue asignado para asesorarlo 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 descubrir cómo funcionan las cosas durante horas cuando una simple pregunta y respuesta literalmente resolvería el problema en cuestión de segundos.

Trate de aprender de la experiencia y desarrolle la habilidad de "leer" a su mentor para descubrir 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 interno y de interno a mentor.


4

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

Tener preguntas es totalmente natural. Y puede estar seguro de que sus colegas saben que usted sabe y tendrá preguntas. También han estado en tu posición en algún momento, ¿verdad? Y créeme, tenían que obtener ayuda de algún lado.

La parte difícil es que no todos están disponibles en todo momento, para responder cualquiera de las preguntas que pueda tener. Mi truco habitual cuando reviso códigos o documentos es tomar notas de cosas que no están claras de inmediato y organizar un par de reuniones cortas por día, para discutirlas con mis superiores. Antes de hacer preguntas, 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.

Esfuérzate, estudia mucho, sé curioso y haz preguntas. Recuerde, todos han estado en su posición, y todos finalmente sobrevivieron :)


3

Creo que te encontrarás con diferentes tipos de preguntas.

Para mi respuesta, me centraré en lo que considero por qué preguntas. Este tipo de preguntas lo ayudan a comprender por qué se le pide que haga algo de cierta manera. (ej. ¿Por qué usamos el estándar de codificación X?)

Creo que sería bueno para usted pedirle a su mentor que reserve un tiempo cada semana para analizar este tipo de preguntas. Una idea sería reservar 1 o 2 descansos para tomar café a la semana. Al establecer un horario para este tipo de preguntas, le muestra a su mentor que valora su tiempo y que desea saber por qué se hace algo de cierta manera.


3

Siempre que su mentor sepa que ha tratado de encontrar la respuesta primero y ha tratado de encontrar una respuesta a la pregunta.

Un consejo para hacer preguntas puede ser cuando su mentor va a la máquina de café, entonces sabe que está interrumpiendo su "flujo".


3

Estoy más o menos en tu situación exacta en este mismo momento. Mi supervisor está bastante ocupado y me di cuenta de que mis interrupciones no fueron bien recibidas muy temprano. Sin embargo, en mi caso, entré sin saber muchas tecnologías utilizadas. Entonces, lo que he hecho es que, cada vez que tengo una pregunta, la anoto. Si necesito una respuesta para continuar mi tarea, hago otra cosa por un tiempo. Leí documentación para otra tecnología que sé que usaré 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.

Si está escribiendo un código, por ejemplo, puede escribir un comentario "todo" en esa parte y continuar escribiendo el resto del código. Puede volver para completar el trabajo más tarde.

Luego, cada vez que me encuentro con mi supervisor, descargo todas las preguntas a la vez. ¡Para entonces algunas de las preguntas que ya he respondido por mí mismo! Algunas de las preguntas también parecen tontas después de haberlas escrito por un tiempo, por lo que no las hace.

Otra cosa que definitivamente debes hacer es simplemente hablar con tu mentor al respecto. De hecho, eso fue lo primero que hice. Simplemente pregunté "¿Estoy haciendo demasiadas preguntas?" Me dio una respuesta directa y pude dejar de preocuparme por relajarme o resolver el problema.


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


2
  1. No te preocupes por preguntar demasiado. No importa que no sepas algo, pero la capacidad de estudiar es importante.
  2. Piensa y busca en Google antes de preguntar.
  3. Como se comunica por mensajería instantánea y correo electrónico, trate de asegurarse de que su mentor comprenda bien sus preguntas.
  4. Una vez que se resuelve un problema, se necesitan notas. Simplemente no podemos recordar todo lo que aprendemos en detalle.

0

Creo que Casey no se trata de cuestionar ... algo es que eres un interno ... se supone que debes hacer preguntas. Y personalmente siento que cuestionar las cosas siempre tiene su propio beneficio. Incluso si no busca en Google en ese caso, su mentor debería decirle que necesita estudiarlo por su cuenta. Recuerde que no se frustre ni se sienta abrumado por el nuevo entorno de trabajo con una gran base de código. Es solo tiempo que necesita dar y debe cuestionar casi todo lo que quiera.

feliz cuestionamiento :) :)


0

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

Pero no hagas esas preguntas que suenen derrotistas o impliquen que puedes ser poco optimista,

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.