Deshacerse del miedo a tu primer trabajo

Fotograma de la película "Harry Potter y el prisionero de Azkaban"

El problema de este mundo es que la gente educada está llena de dudas, pero los idiotas están llenos de confianza.

Charles Bukowski

Recientemente enseñé otra lección de programación individual. A diferencia de las clases regulares, el tema no era la construcción del lenguaje ni la resolución de problemas. El estudiante compartió sus preocupaciones sobre el futuro empleo. El propio estudiante era bastante inteligente. Uno de los que viene al curso completa todo el programa más rápido que nadie y con soluciones originales, pero todo el tiempo se subestima sinceramente. En mi opinión, estas dudas surgen únicamente de la falta de información. Intenté llenar este vacío de manera improvisada durante la lección.

Las preguntas eran algo como esto:

• Cada año muchos estudiantes se gradúan en las universidades y todos buscan trabajo. Son muchas personas. Probablemente contratarán a los mejores, pero yo no conseguiré un lugar.
• ¿Qué pasa si me equivoco y me despiden de inmediato?
• ¿Qué pasa si en el proceso de trabajo se dan cuenta de que soy un estúpido y me echan?

Este estudiante no fue la primera persona a quien respondí este tipo de preguntas. Mucha gente los padece y, por lo general, hay que contárselos sin preparación previa. Esta vez decidí anotar mi monólogo en una libreta. Pensé que serían un par de párrafos, pero al final me bastaron para un artículo completo.

El artículo describe la vista desde mi punto de vista y basado en mi experiencia. Sin embargo, nuestro mundo es muy diverso y en él suceden cosas asombrosas. Si no estás de acuerdo con algo o tu experiencia es de alguna manera diferente, escribe un comentario.

El artículo fue escrito por un desarrollador para desarrolladores. Sin embargo, si planea realizar pruebas, administración o cualquier otra cosa en TI, algunos de los consejos también le serán útiles.

No te contratarán en absoluto.

Cuando imaginas que muchas universidades gradúan a cientos de estudiantes cada año, resulta incómodo. ¿Cómo competir con una multitud tan grande?

Lamentablemente, no todos los graduados tienen suficiente formación técnica. Intente preguntarle a algún estudiante universitario que conozca: ¿cómo consiguen las personas de su grupo ser admitidas a 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 tipos "avanzados" que realmente hicieron todo ellos mismos. El resto simplemente los copia, abarrota las respuestas a las preguntas y las envía.

Así era cuando estudiaba por mi cuenta. Sin embargo, mi experiencia puede no ser representativa. Entonces le hice esta pregunta a varios estudiantes diferentes. La respuesta fue más o menos la misma. Los encuestados eran de diferentes universidades y colegios. Dejaré las discusiones sobre las razones fuera del alcance de este artículo. No tengo tiempo suficiente para un estudio completo, así que sacaré una conclusión a partir de los hechos disponibles.

Entre cientos de graduados, sólo un par de docenas son de interés para los empleadores.

Pocos graduados pueden ofrecer una competencia real para un estudiante capaz y con buena preparación. Sin embargo, incluso si estudiaste concienzudamente, después de la primera entrevista lo más probable es que no te contraten. Después del segundo, probablemente también. Puede que todo salga bien, pero es mejor prepararse no para un asalto, sino para un asedio. Un intento fallido de conseguir un trabajo es solo una razón para corregir sus errores y volver a intentarlo. No hablaré sobre la preparación para las entrevistas. Ya se ha escrito mucho sobre este tema en Internet. Solo diré que hay matices en las entrevistas que su programa de capacitación probablemente no se tomará el tiempo de explicar. Busque esta información usted mismo, puede reducir la cantidad de intentos.

La locura es la repetición exacta de la misma acción. Una y otra vez, esperando el cambio

Albert Einstein

Para evitar que las entrevistas se conviertan en una locura, es necesario mejorar después de cada nuevo intento. Memorice o escriba las preguntas que le hicieron durante la entrevista. Cuando regrese a casa, consulte esta lista y compruébelo usted mismo a través de Internet. De esta manera comprenderá dónde se equivocaron usted y el entrevistador. Esto también sucede. Revise o estudie los temas en los que tuvo un mal desempeño y vuelva a intentarlo.

Además, existe una marcada estacionalidad en el mercado laboral. Las empresas inteligentes planifican la contratación en función de las fechas de graduación. En primavera hay más vacantes para los recién llegados que en otras épocas. Sin embargo, la competencia es mayor en este momento.

Estúpido - que te despidan

Cuando se contrata a una persona sin experiencia, existen las correspondientes expectativas para él.

Se espera que un recién llegado al trabajo:

• Conocimiento de la base técnica general.
• Estudiar las particularidades del área temática de la empresa.
• Dominar las herramientas y prácticas utilizadas.

Algunas organizaciones ofrecen cursos de capacitación para recién llegados sobre las tecnologías, herramientas y procedimientos locales utilizados. Por ejemplo, buenos modales al utilizar el correo electrónico corporativo, el procedimiento para cambiar documentos en una wiki, funciones locales para trabajar con VCS y un rastreador de errores.

También existen cursos de iniciación técnica, pero su utilidad es cuestionable. En lo que respecta al empleo, los empresarios están convencidos de que usted tiene un nivel suficiente de conocimientos. Es mejor realizar estos cursos simplemente de buena fe, como una pequeña formalidad. Quizás realmente haya algo útil en ellos.

Cuando comience a trabajar, recuerde que a un principiante definitivamente no se le confiará la tarea de resolver una tarea urgente, compleja y al mismo tiempo importante. Lo más probable es que sólo exista una de estas propiedades. O simple pero urgente: arreglar el diseño, enviar un archivo a alguien, reproducir el problema. O difícil, pero sin esperanzas de completarlo, para que el principiante recoja más comisión. O importante, pero experimental. Por ejemplo, un proyecto que todo el mundo quiere desde hace mucho tiempo, pero no encuentra el tiempo para implementarlo.

Las tareas para dominar las herramientas serán “difíciles” y artificiales. Lo más probable es que sea una versión simplificada del sistema principal. Estas tareas utilizan la misma pila de tecnología y los mismos términos de dominio que todo el proyecto. En este caso, el resultado de la ejecución no se entregará al usuario final. Esto puede resultar desmotivador, pero es mejor resistirse a este sentimiento. Una tarea artificial debe hacerse a conciencia, como si de ello dependiera el destino del proyecto.

El resultado de resolver su primer problema formará la primera impresión que tendrán de usted los colegas que no estuvieron presentes en la entrevista.

Otra opción para la tarea de dominio de la herramienta es "ejecutar el proyecto en una máquina local/entorno de prueba". A veces, este proceso se describe en las instrucciones. Pero suelen ser viejos y, en algunos lugares, anticuados. Puede aportar beneficios reales al proyecto si escribe nuevas instrucciones con aclaraciones sobre los problemas que han surgido. Seguramente en la universidad tuviste que redactar un RGR para un informe sobre algunas disciplinas. Es casi lo mismo aquí. El documento debe reflejar las acciones que se deben realizar para el lanzamiento.

Normalmente, los pasos para ejecutar un producto en un entorno de prueba son algo como esto:

• clonar un repositorio, cambiar a alguna rama o etiqueta
• crear algún archivo de configuración
• preparar la estructura de la base de datos
• llenarlo con datos de prueba
• construir o compilar el proyecto,
• ejecutar un conjunto de scripts de consola en una secuencia determinada

Durante el proceso de ejecutar un sistema localmente, inevitablemente surgirán problemas inesperados.

Las soluciones encontradas a los problemas deben agregarse a las instrucciones de implementación. Entonces, la próxima vez que sigas las instrucciones, estos problemas ya no surgirán. Al completar archivos de configuración y llamar scripts, debe prestar atención a qué valor se usa, dónde y con qué debe coincidir. Por ejemplo, si un proyecto se ensambla utilizando un sistema CI y luego se inicia mediante un script, entonces es importante comprender dónde escribir el nombre de la rama o el número de confirmación. Sucede que el script implica transferir la dirección IP o el nombre DNS de la base de datos, su nombre de usuario y contraseña. En este caso, necesita saber qué dirección utilizar para el entorno de prueba, qué inicios de sesión existen y qué contraseñas debe especificar para ellos.

Algunas tareas pueden parecer simples para los desarrolladores experimentados pero desafiantes para los pasantes. Esto es normal.

Los desarrolladores tienen que resolver problemas técnicos todos los días. Los empleados experimentados ya han resuelto muchos problemas antes, mientras que los recién llegados aún tienen que afrontarlos. La mejor táctica es registrar todos los errores encontrados en el documento "solucionar problemas con ${nombre de la tarea}". Para cada problema, es necesario formular una hipótesis sobre la causa, buscar soluciones en Internet y probarlas una por una. También se debe registrar el resultado de cada intento.

El registro de su investigación en forma de documento le permitirá:

• descarga pequeños detalles de tu cabeza. Por ejemplo, parámetros de configuración, direcciones DNS/IP, comandos de consola y consultas SQL.
• Recuerda “qué hice ayer” cuando la tarea dura varios días.
• no deambule en círculos. Siempre podrás leer lo que hiciste antes y comprender que has vuelto al problema original.
• Responde claramente a la pregunta: "¿Qué hiciste hoy?" incluso si todavía no existe una solución preparada.

Debe poder comunicar el estado de sus tareas a sus colegas.

De vez en cuando, sus colegas se interesarán por sus éxitos y compartirán los suyos. Reserve algo de tiempo para esto diariamente o semanalmente.

Si no realiza un seguimiento de los problemas encontrados y resueltos, la descripción de sus éxitos será así: “Traté de realizar la tarea, pero no puedo hacerlo. Todavía estoy buscando una solución”. De esta historia no queda claro si el interno estaba haciendo algo o simplemente sentado y leyendo. ¿Necesita ayuda? ¿Ha cambiado la situación desde ayer?

Si guarda un documento buscando soluciones, puede decir “Estoy intentando realizar esta tarea. Tuve errores como este. Así lo decidí. No me he ocupado de este todavía. Existen estas hipótesis y soluciones. Los estoy revisando ahora."

Si la tarea se puede medir de alguna manera, entonces el estado debe contener números. Por ejemplo, para la tarea "escribir pruebas unitarias para un módulo", puedes decir "Planeo hacer 20 pruebas, ahora he escrito 10".

Cuantos más detalles proporcione, mejor entenderán sus colegas lo que hizo. Esto creará una actitud positiva hacia usted entre sus colegas y les permitirá entender si necesita ayuda o no.

Siéntase libre de pedir ayuda

Escribí anteriormente que cuando surge un problema, es necesario formular una hipótesis sobre sus causas y posibles soluciones. Sin embargo, sucede que las hipótesis no están justificadas y las soluciones al problema encontradas de forma independiente no funcionan. En este caso, es mejor pedir ayuda. Para no abusar de la atención de sus colegas, debe ocuparse usted mismo de cada problema. Si no ha podido encontrar una solución en un par de horas, es hora de buscar el consejo de compañeros más experimentados.

Un buen punto de partida es preguntar: "¿Alguien ha encontrado este problema antes?" con una breve descripción del problema. Es recomendable adjuntar una parte del mensaje de error o una captura de pantalla. Es mejor enviar este mensaje por primera vez a algún chat general de trabajo. De esta forma no distraerás a quienes están realmente ocupados en el trabajo. Los colegas gratuitos verán su mensaje y podrán ayudarlo.

Si después de un mensaje en el chat general nadie le ayudó, intente ponerse en contacto con un colega experimentado durante un descanso: almorzando, tomando té o café, jugando al tenis o fumando. Si esto no funciona, informe sus dificultades en la reunión o en la reunión.

Si se resuelven los problemas conocidos, todo esto puede terminar ahí. Si el problema es nuevo, entonces se iniciará una investigación, donde será necesario actuar según las circunstancias.

Las tareas “importantes” para principiantes que necesita 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 modelo para cargar atributos del cliente desde el DBMS". 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 sólo resolver técnicamente el problema, sino también ampliar el conocimiento en el área temática.

Los términos aparecerán en la descripción de la tarea, en chats y conversaciones. Pueden parecer sustantivos familiares. Sin embargo, en el marco del sistema de información, tienen un significado especial y más preciso. El significado de los términos descubiertos se registra mejor en un documento especial: un diccionario de términos. Al agregar al diccionario, basta con escribir su comprensión de la palabra, pero para una decodificación real es mejor contactar a un analista. Si falta, vaya a los veteranos del proyecto. Mantener un diccionario de términos es una de las formas más sencillas de familiarizarse con el área temática de un proyecto.

Una vez que encuentre un lenguaje común con sus colegas, ellos comenzarán a verlo no como un nuevo pasante, sino como un especialista igual.

Hay tareas especiales, por ejemplo, "escribir pruebas unitarias para un módulo". Difícilmente puedes quedarte atrapado durante mucho tiempo buscando soluciones. Al mismo tiempo, es bastante serio y no sólo se imparte para la formación de alumnos. Las pruebas escritas aumentan la estabilidad del proyecto al reducir los errores en la aplicación y reducir el tiempo de las pruebas humanas. En un mundo ideal, las pruebas unitarias se escriben inmediatamente durante el desarrollo, pero la realidad siempre es diferente. Sucede que el desarrollador de un módulo lo guarda completamente en su cabeza y no ve la necesidad de escribirlo. "Todo es obvio, ¿qué hay que probar?" A veces, los módulos se escriben en modo urgente y no queda tiempo para las pruebas unitarias. Entonces, en el mundo real puede que no haya pruebas unitarias. Por lo tanto, la tarea de escribir pruebas unitarias se asigna a un principiante. De esta manera, el pasante podrá acostumbrarse más rápidamente al proyecto y el proyecto podrá ahorrarle el tiempo a los especialistas mejor pagados.

Sucede que a los pasantes y recién llegados se les asigna el papel de evaluadores de pleno derecho. Normalmente, antes de hacer esto, es necesario implementar el producto localmente y leer los requisitos. Como resultado, se espera que el nuevo empleado:

• preguntas como “si lo haces así, saldrá así”. Esto no está en los requisitos. ¿Debería ser?"
• tareas en el rastreador de errores "los requisitos dicen esto, pero en realidad está escrito de manera diferente".

Las pruebas son un área demasiado amplia para este artículo. Si le asignan una tarea similar, busque en Internet la mejor manera de completarla.

Si te equivocas, te despedirán

En una organización normal, si de repente sucede que un empleado sin experiencia accede a algo crítico y estropea algo, entonces el culpable será el que permitió que esto sucediera. Porque un principiante, por defecto, no tiene acceso a infraestructura crítica. Con la orientación adecuada, no permitirán que todos los perros se desperdicien con un aprendiz sin experiencia.

Si pasa algo, no te despedirán por un solo incidente. La gente aprende de los errores. El pasante que cometió un error aprendió una lección valiosa y es muy diferente de otros pasantes. Si despides a alguien que se equivoca, otro vendrá en su lugar y se equivocará de la misma manera.

Lo principal es aprender de los errores y no volver a repetirlos.

Si una persona no saca conclusiones de sus errores, intentará despedirse de él. Sin embargo, el mundo es diverso. En alguna organización de gánsteres te pueden echar inmediatamente por la ventana al primer error. Pero es mejor evitar este tipo de empresas investigando primero o averiguando más durante la entrevista.

Es mejor evitar incidentes

Incluso si no lo despiden personalmente por un error, un incidente de este tipo causará problemas no deseados a su equipo y al proyecto en su conjunto. Por tanto, tenga especial 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 conocimiento del proyecto. Si encuentra la dirección de una nueva conexión, consulte con al menos dos personas diferentes qué se puede hacer allí. Verifique sus derechos en entornos no mediante prueba y error, sino utilizando los comandos adecuados. Por ejemplo, derechos para eliminar archivos usando el comando `ls`, derechos para trabajar con tablas en mysql usando el comando `SHOW GRANTS FOR 'user'@'host';`, y similares. En casi cualquier herramienta tendrás una oportunidad similar.

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

Se construyen varias barreras entre el alumno y el usuario final.

Si pudiera entregar inmediatamente su producto al consumidor, no podría conseguir un trabajo, sino emprender un “nado libre”. Pero hasta que no tenga esa oportunidad (y al mismo tiempo la responsabilidad), debe pasar por varias etapas de control del proyecto.
El primero de ellos es la verificación por parte de un mentor. Evalúa la decisión del novato desde un punto de vista técnico. Si no se ha asignado un mentor, entonces es necesario encontrar uno. Para ello, es necesario elegir a uno de los veteranos del proyecto y durante un descanso pedirle que mire la solución: ¿se resolvió el problema correctamente? Si empieza a mirar y responder, entonces ha encontrado un mentor. Si lo ignora, entonces vale la pena preguntarle a alguien más.

La siguiente etapa es la Garantía de Calidad. En ruso - probadores. Al estilo soviético: departamento de control estándar y control de calidad. Deben asegurarse de que el desempeño del alumno sea coherente con la tarea que se le ha asignado. Rara vez leerán el código. La mayoría de las veces, los evaluadores verificarán el proyecto creado, que el desarrollador almacena en el sistema de control de versiones.

La tercera etapa es el administrador de lanzamientos. Puede que no haya una persona separada para esta tarea, pero aun así alguien desempeña el papel. Comprueba que los evaluadores hayan confirmado que el proyecto puede publicarse. Posteriormente, realiza las actividades para entregar el producto a los usuarios finales.
En organizaciones pequeñas, estas barreras pueden no existir por varias razones. Sin embargo, no le darán a un principiante la tarea de cambiar algo importante. Porque nadie necesita este riesgo.

Primero debes involucrarte en la batalla y luego ya veremos.
Napoleon Bonaparte

Espero que este artículo te ayude a superar tu incertidumbre y enviar tu primer currículum. Por supuesto, primero debes prepararte. Pero no hay necesidad de extenderse demasiado. Lo más probable es que ya hayas estudiado en una universidad o colegio durante varios años. ¿A dónde ir ahora? Al final, es mejor escuchar un “no” una vez de un especialista y trabajar en los errores que decirse “no” todos los días y dejar de crecer profesionalmente.

Una vez contratado, debes concentrarte en pasar de ser un pasante a un miembro de pleno derecho del equipo. Este tipo de crecimiento suele venir acompañado de un aumento de sueldo.

Te deseo paciencia y perseverancia.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Cuáles fueron sus primeras tareas en su primer trabajo en TI?

• Complejo

• Importante

• Urgente

• Ninguna de las anteriores

75 usuarios votaron. 20 usuarios se abstuvieron.

¿Qué tuviste que hacer al principio en tu primer trabajo?

• Instalar el producto localmente

• Probar un producto existente

• Realizar un entrenamiento, tarea falsa.

• Hacer un proyecto experimental y real para un cliente.

63 usuarios votaron. 25 usuarios se abstuvieron.

¿Cuántos estudiantes de su grupo pudieron completar tareas de materias técnicas de forma independiente durante la capacitación?

• 1 de 10

• 1 de 5

• Cada segundo

• Todo, salvo raras excepciones.

70 usuarios votaron. 19 usuarios se abstuvieron.

Fuente: habr.com