🥇Superando el miedo al primer empleo

Escena de la película «Harry Potter y el prisionero de Azkaban»

El problema de este mundo es que las personas educadas están llenas de dudas, mientras que los idiotas están llenos de confianza.
Charles Bukowski

Recientemente, tuve otra clase individual de programación. A diferencia de las lecciones habituales, el tema no fue la estructura del lenguaje ni la resolución de problemas. El estudiante compartió su preocupación sobre su futura empleabilidad. El alumno era bastante inteligente. Uno de esos que llega a los cursos, completa todo el programa más rápido que nadie y con soluciones originales, pero constantemente subestima sus habilidades. En mi opinión, tales dudas surgen solo por falta de información. Intenté llenar ese vacío al azar durante la clase.

Las preguntas eran aproximadamente las siguientes:

Cada año, muchas universidades graduan a numerosos estudiantes y todos ellos van a buscar trabajo. Son muchas personas. Seguramente contratarán a los mejores, y yo no tendré lugar.
¿Qué pasa si cometo un error y me despiden de inmediato?
¿Qué pasa si en el trabajo se dan cuenta de que soy tonto y me echan?

Este estudiante no fue la primera persona a la que respondí con preguntas similares. Estas dudas surgen en muchas personas, y generalmente tengo que contarles sin preparación. Esta vez decidí escribir mi monólogo en una libreta. Pensé que resultaría en un par de párrafos, pero terminó convirtiéndose en un artículo completo.

En el artículo se describe mi perspectiva y experiencia. Sin embargo, nuestro mundo es muy diverso y ocurren cosas sorprendentes. Si no estás de acuerdo con algo o tu experiencia es diferente, por favor, deja un comentario.

El artículo está escrito por un desarrollador para desarrolladores. Sin embargo, si planeas trabajar en pruebas, administración u otra cosa en TI, parte de los consejos también te serán útiles.

No te contratarán en absoluto.

Cuando imaginas que anualmente muchas universidades graduan a cientos de estudiantes, resulta incómodo. ¿Cómo competir con tal multitud?

Desafortunadamente, no todos los graduados tienen la preparación técnica necesaria. Intenta preguntar a algún conocido estudiante de la universidad: ¿cómo obtienen las personas en su grupo el acceso a los exámenes en disciplinas como 'bases de datos' o 'fundamentos de algoritmización y programación'? En un grupo de 30 personas, en el mejor de los casos, habrá de 3 a 5 colegas 'avanzados' que realmente hicieron todo por sí mismos. Los demás simplemente copian de ellos, memorizan respuestas a preguntas y aprueban.

Así era cuando yo estudiaba. Sin embargo, mi experiencia podría no ser representativa. Por eso hice esta pregunta a varios estudiantes diferentes. La respuesta fue más o menos la misma. Los que respondieron eran de diferentes universidades y colegios. Dejaré las reflexiones sobre las causas fuera de este artículo. No tengo tiempo para un estudio completo, así que sacaré conclusiones a partir de los hechos disponibles.

Entre cientos de graduados, solo unas pocas decenas representan un interés para los empleadores.

Pocos graduados pueden competir realmente con un estudiante capaz bien preparado. Sin embargo, incluso si estudiaste con diligencia, es probable que no te contraten después de la primera entrevista. Puede que tampoco después de la segunda. Todo puede salir bien, pero es mejor prepararse no para un asalto, sino para un asedio. Un intento fallido de conseguir empleo es solo una oportunidad para aprender de los errores y volver a intentarlo. No hablaré sobre la preparación para entrevistas. Ya se ha escrito mucho al respecto en Internet. Solo diré que hay matices en la realización de entrevistas que probablemente no tienen espacio en tu plan de estudios. Busca esta información por tu cuenta, puede reducir la cantidad de intentos.

La locura es repetir exactamente la misma acción una y otra vez, con la esperanza de un cambio.
Albert Einstein

Para que la realización de entrevistas no se convierta en locura, después de cada nuevo intento es necesario mejorar. Recuerda o anota las preguntas que te hicieron durante la entrevista. Al regresar a casa, revisa esta lista y驗ate a ti mismo con la ayuda de Internet. Así entenderás dónde te equivocaste y dónde el entrevistador. Esto también puede ocurrir. Repite o estudia los temas en los que respondiste mal y vuelve a intentarlo.

Además, hay una clara estacionalidad en el mercado laboral. Las empresas inteligentes planifican la contratación teniendo en cuenta las fechas de graduación. En primavera hay más ofertas para principiantes que en otros momentos. Sin embargo, la competencia también es más alta en este período.

Tonto — lo despedirán

Cuando se contrata a una persona sin experiencia, existen expectativas correspondientes hacia ella.

Se espera de un principiante en el trabajo:

Conocimientos de la base técnica general
Estudio de las particularidades del área temática de la empresa
Dominio de las herramientas y prácticas utilizadas

En algunas organizaciones, se organizan cursos de formación para principiantes sobre las tecnologías y herramientas utilizadas, así como sobre las prácticas locales. Por ejemplo, las normas de buen comportamiento al usar el correo corporativo, el procedimiento para modificar documentos en la wiki, y las particularidades locales para trabajar con VCS y sistemas de seguimiento de errores.

También hay cursos introductorios técnicos, pero su utilidad es discutible. Si se ha llegado al empleo, significa que los empleadores se han convencido de que tienes un nivel de conocimiento suficiente. Es mejor abordar esos cursos de manera honesta, como una formalidad menor. Puede que en ellos realmente haya algo útil.

Cuando empieces a trabajar, recuerda que no se le asignará a un principiante la solución de una tarea urgente, compleja y a la vez importante. Lo más probable es que tenga solo una de esas características. Puede ser algo sencillo pero urgente: corregir el maquetado, enviar un archivo a alguien, reproducir un problema. O algo complejo, pero sin ninguna esperanza de completarlo — solo para que el principiante acumule experiencia. O algo importante pero experimental. Por ejemplo, un proyecto que todos han querido, pero que no pueden destinar tiempo para realizar.

Las tareas para dominar las herramientas serán "complejas" e artificiales. Lo más probable es que sea una versión simplificada del sistema principal. En tales tareas se utiliza el mismo stack tecnológico y los mismos términos del campo temático que en todo el proyecto. Sin embargo, el resultado de estas tareas no se entregará al usuario final. Esto puede desmotivar, pero es mejor resistirse a ese sentimiento. La tarea artificial debe hacerse de manera honesta, como si el destino del proyecto dependiera de ella.

El resultado de resolver tu primer desafío dejará una primera impresión sobre ti ante tus colegas que no asistieron a la entrevista.

Otra opción para dominar las herramientas es "iniciar un proyecto en la máquina local / entorno de prueba". A veces, este proceso está documentado en las instrucciones. Sin embargo, por lo general, estas son antiguas y en algunos casos desactualizadas. Se puede aportar un valor real al proyecto escribiendo nuevas instrucciones que aborden los problemas surgidos. Seguramente en la universidad escribiste un trabajo de investigación para un informe en alguna materia. Aquí es casi lo mismo. El documento debe reflejar las acciones necesarias para iniciar.

Por lo general, las acciones para iniciar un producto en un entorno de prueba son aproximadamente las siguientes:

clonar el repositorio, cambiar a alguna rama o etiqueta
preparar algún archivo de configuración
preparar la estructura de la base de datos
llenarla con datos de prueba
realizar la construcción o compilación del proyecto,
ejecutar un conjunto de scripts de consola en un orden específico

Durante el proceso de iniciar el sistema localmente, inevitablemente surgirán problemas imprevistos.

Las soluciones a los problemas encontrados deben añadirse a la instrucción de despliegue. De esta manera, la próxima vez que se siga la instrucción, estos problemas ya no surgirán. Al completar los archivos de configuración y al ejecutar scripts, es importante prestar atención a qué valor se utiliza dónde y con qué debe coincidir. Por ejemplo, si el proyecto se compila mediante un sistema CI y luego se inicia con un script, es crucial entender dónde introducir el nombre de la rama o el número del commit. A veces, el script implica la transmisión IP o el nombre DNS de la base de datos, su nombre de usuario y contraseña. En este caso, es necesario saber qué dirección utilizar para el entorno de prueba, qué nombres de usuario existen y cuáles son las contraseñas que se deben especificar.

Algunas tareas pueden parecer simples para los desarrolladores experimentados y causar dificultades a los pasantes. Esto es un fenómeno normal.

Los desarrolladores enfrentan problemas técnicos a diario. Los empleados experimentados ya han resuelto muchos de estos problemas, mientras que los novatos aún tienen que enfrentarlos. La mejor táctica será registrar todos los errores encontrados en el documento 'solución de problemas con ${nombre de la tarea}'. Para cada problema, se debe formular una hipótesis sobre la causa, buscar en Internet opciones de solución y probarlas una por una. El resultado de cada intento también debe ser registrado.

Presentar sus investigaciones en forma de documento permitirá:

sacar de la cabeza los pequeños detalles. Por ejemplo, los parámetros de configuración, direcciones DNS/IP, comandos de consola y consultas SQL.
recordar 'qué estaba haciendo ayer' cuando la tarea se extiende por varios días.
no dar vueltas sin sentido. Siempre podrás leer lo que hiciste antes y entender que volviste al problema original.
responder claramente a la pregunta: '¿qué hiciste hoy?' incluso si aún no hay una solución lista.

Necesitas ser capaz de comunicar el estado de tus tareas a tus colegas.

De vez en cuando, los colegas estarán interesados en tus éxitos y compartirán los suyos. Para esto, se debe dedicar un poco de tiempo a diario o semanalmente.

Si no sigues los problemas encontrados y resueltos, la descripción de tus logros se verá como: 'Intenté hacer la tarea, pero no puedo. Todavía estoy buscando una solución'. De este relato no queda claro si el pasante hizo algo o simplemente estaba leyendo en Habr. ¿Necesita ayuda? ¿Ha cambiado la situación desde ayer?

Si llevas un documento con la búsqueda de soluciones, podrás decir: 'estoy intentando hacer esta tarea. Tuve estos errores. Los resolví así. Con este aún no he podido. Tengo estas hipótesis y opciones de solución. Ahora las estoy verificando'.

Si la tarea se puede medir de alguna manera, el estado debe incluir cifras. Por ejemplo, para la tarea 'escribir pruebas unitarias para el módulo', puedes decir 'planeo hacer 20 pruebas, ahora he escrito 10'.

Cuantos más detalles compartas, mejor entenderán tus colegas lo que hiciste. Esto generará una actitud positiva hacia ti y les permitirá entender si necesitas ayuda o no.

No dudes en pedir ayuda.

Anteriormente mencioné que al surgir un problema, debes formular una hipótesis sobre sus causas y posibles soluciones. Sin embargo, a veces las hipótesis no se justifican y las soluciones encontradas de forma independiente no funcionan. En ese caso, es mejor pedir ayuda. Para no abusar de la atención de los colegas, es importante dedicar un tiempo a cada problema por tu cuenta. Si después de un par de horas no has podido encontrar una solución, es hora de buscar consejo de compañeros más experimentados.

Lo mejor es comenzar con la pregunta: "¿alguien ha tenido este problema antes?" acompañada de una breve descripción del mismo. Es recomendable adjuntar un fragmento del mensaje de error o una captura de pantalla. Es preferible enviar este mensaje por primera vez a un grupo de chat general en el trabajo. De esta manera, no interrumpes a aquellos que están realmente ocupados. Los colegas disponibles verán tu mensaje y podrán ayudar.

Si después de publicar en el chat general nadie ayuda, intenta hablar con un colega experimentado durante un descanso: en el almuerzo, yendo por té/café, durante una partida de tenis o en un receso para fumar. Si no puedes, informa sobre tus dificultades en la reunión de equipo o el stand-up.

Al abordar problemas conocidos, aquí puede terminar todo. Sin embargo, si el problema es nuevo, comenzará una investigación, y deberás actuar según las circunstancias.

Las tareas 'importantes' de los principiantes que son necesarias para el usuario final serán aburridas y pequeñas. Por ejemplo, ‘agregar una columna adicional al informe’ o ‘corregir un error tipográfico en el formulario impreso’ o ‘implementar un método de modelo para cargar atributos de clientes desde la base de datos’. El objetivo de estas tareas es que el principiante se familiarice con el área temática y se integre en el trabajo diario.

Es importante no solo resolver la tarea técnicamente, sino también expandir el conocimiento en el área temática.

En la descripción de la tarea, en los chats y conversaciones, habrá términos que pueden parecer sustantivos conocidos. Sin embargo, en el contexto del sistema de información, adquieren un significado especial y más preciso. Es mejor registrar el significado de los términos encontrados en un documento especial: un glosario de términos. Al añadir a este glosario, basta con escribir tu entendimiento de la palabra, pero para una interpretación real, es mejor consultar al analista. Si no está disponible, consulta a los veteranos del proyecto. Mantener un glosario de términos es una de las maneras más sencillas de integrarse en el área temática del proyecto.

Una vez que encuentres un lenguaje común con tus colegas, comenzarán a verte no como un novato, sino como un igual, un especialista.

Hay tareas especiales, como 'escribir pruebas unitarias para un módulo'. En ellas, es poco probable que te quedes atascado buscando soluciones por mucho tiempo. Sin embargo, son bastante serias y no solo se dan para la capacitación de un aprendiz. Las pruebas escritas aumentan la estabilidad del proyecto al reducir los errores en la aplicación y disminuir el tiempo de pruebas manuales. En un mundo ideal, las pruebas unitarias se escriben a medida que se desarrolla, pero la realidad es diferente. A veces, el desarrollador del módulo tiene todo en su cabeza y no ve la necesidad de escribirlas. '¿Es obvio que aquí no hay nada que probar?' A veces, los módulos se escriben en modo de emergencia y no queda tiempo para las pruebas unitarias. Así que, en el mundo real, puede no haber pruebas unitarias. Por ello, la tarea de escribir pruebas unitarias se le asigna a un novato. De esta manera, el aprendiz podrá familiarizarse más rápidamente con el proyecto, y el proyecto podrá ahorrar tiempo en especialistas más costosos.

A veces, a los aprendices y nuevos empleados se les asigna el rol de testers completos. Normalmente, antes de esto, es necesario desplegar el producto localmente y leer los requisitos. Se espera que el nuevo empleado produzca:

preguntas como 'si hago esto, obtendré esto. Esto no se menciona en los requisitos. ¿Cómo debería ser?'
tareas en el seguimiento de errores 'en los requisitos dice esto, pero en realidad es diferente'.

La prueba es un área de actividad excesivamente amplia para este artículo. Si te asignaron una tarea similar, busca en Internet cómo realizarla de la mejor manera.

Si cometes errores, te despedirán.

En una organización normal, si de repente ocurre que un empleado inexperto tiene acceso a algo crítico y lo perjudica, la culpa recaerá sobre quien permitió tal acceso. Porque por defecto, un novato no tiene acceso a la infraestructura crítica. Con una supervisión adecuada, no se culpará desproporcionadamente al aprendiz inexperto.

Si por alguna razón sucede algo, no se despedirá a alguien por un solo incidente. Las personas aprenden de sus errores. Un aprendiz que comete un error ha recibido una lección valiosa y eso lo diferencia notablemente de otros aprendices. Si despides a uno que ha cometido un error, vendrá otro que hará lo mismo.

Lo principal es aprender de los errores y no repetirlos.

Si una persona no aprende de sus errores, entonces intentarán despedirlo. Sin embargo, el mundo es diverso. En alguna organización criminal, podrían arrojarte por la ventana por un primer error. Pero es mejor evitar tales empresas, para lo cual es recomendable investigar o averiguar más durante la entrevista.

Es mejor no permitir incidentes.

Incluso si no te despiden personalmente por un error, tal incidente traerá problemas no deseados a tu equipo y al proyecto en general. Por lo tanto, ten mucho cuidado con las operaciones de eliminación o creación de tablas en la base de datos, archivos, instancias de servicios y documentos en la base de conocimientos del proyecto. Si encuentras una dirección de nueva conexión, consulta al menos a dos personas diferentes sobre lo que se puede hacer allí. Verifica tus permisos en los entornos no por ensayo y error, sino utilizando los comandos adecuados. Por ejemplo, los permisos para eliminar archivos con el comando `ls`, los permisos para trabajar con tablas en MySQL con el comando `SHOW GRANTS FOR ‘user’@’host’;` y similares. Prácticamente en cualquier herramienta tendrás esta posibilidad.

Al editar archivos, guarda una copia del original por si acaso.

Se establecen varios barreras entre el aprendiz y el consumidor final.

Si pudieras entregar tu producto al consumidor de inmediato, no tendrías que conseguir un trabajo, sino que podrías navegar 'en libertad'. Pero mientras no tengas esa posibilidad (y por ende también la responsabilidad), necesitas pasar por varias etapas de control en el proyecto.
La primera de ellas es la evaluación por un mentor. Él evalúa la solución del novato desde el punto de vista técnico. Si no se ha asignado un mentor, hay que buscar uno. Para esto, se debe elegir a alguien veterano del proyecto y pedirle durante un descanso que revise la solución: ¿está resuelta correctamente la tarea? Si comienza a revisar y responde, significa que se ha encontrado un mentor. Si lo ignora, entonces vale la pena preguntar a otra persona.

La siguiente etapa es el Aseguramiento de Calidad. En español, esto se traduce como testers. En la época soviética, se conocía como control normal y OTK. Ellos deben asegurarse de que el resultado del trabajo del pasante cumpla con la tarea que se le asignó. Rara vez se sumergirán en el código. La mayoría de las veces, los testers revisarán el proyecto compilado que el desarrollador guarda en el sistema de control de versiones.

La tercera etapa es el gerente de lanzamiento. Puede que no haya una persona dedicada a esta tarea, pero alguien cumple este rol. Él verifica que los testers hayan confirmado que el proyecto se puede lanzar. Después de esto, realiza las acciones necesarias para entregar el producto a los usuarios finales.
En organizaciones pequeñas, estas barreras pueden no existir por diversas razones. Sin embargo, no le asignarán al novato la tarea de cambiar algo importante. Porque este riesgo no es necesario para nadie.

Primero hay que entrar en la batalla, y luego ya se verá.
Napoleón Bonaparte

Espero que este artículo te ayude a superar tu inseguridad y enviar tu primer currículum. Por supuesto, primero debes prepararte. Pero no te demores demasiado. Es probable que ya hayas pasado varios años en la universidad o en un colegio. ¿Qué más puedes esperar? Al final, es mejor escuchar un "no" de un especialista y trabajar en tus errores, que decirte "no" a ti mismo todos los días y detenerte en tu crecimiento profesional.

Después de conseguir empleo, hay que concentrarse en crecer de pasante a miembro pleno del equipo. Este crecimiento generalmente va acompañado de un aumento en tu salario.

Te deseo paciencia y perseverancia.

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.