Fotograma 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 y los idiotas están llenos de confianza.
Charles Bukowski
Recientemente, realicé otra lección de programación uno a uno. A diferencia de las clases ordinarias, el tema no era la construcción del lenguaje ni el problema para resolver el problema. El estudiante compartió sus preocupaciones sobre el empleo futuro. El estudiante mismo era bastante inteligente. Uno de los que vienen a los cursos pasa por todo el programa más rápido que nadie y con soluciones originales, pero siempre se subestima sinceramente. En mi opinión, tales dudas surgen solo de la falta de información. Traté de llenar este vacío improvisado durante la lección.
Las preguntas fueron algo como esto:
- Cada año, muchos estudiantes se gradúan de las universidades y todos van a buscar trabajo. Esta es mucha gente. Probablemente tomarán lo mejor, pero 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 estúpido y echado?
Este estudiante no fue la primera persona a la que respondí preguntas similares. Muchas personas los tienen, y generalmente tienen que hablar sin preparación. Esta vez decidí escribir mi monólogo en un cuaderno. Pensé que resultaría un par de párrafos, pero escribí en un artículo completo.
El artículo describe la vista desde mi punto de vista y según mi experiencia. Sin embargo, nuestro mundo es muy diverso y suceden cosas sorprendentes. Si no está de acuerdo con algo o su experiencia es de alguna manera diferente, por favor escriba un comentario.
El artículo fue escrito de desarrollador en desarrollador. Sin embargo, si planea hacer pruebas, administración o cualquier otra cosa en TI, algunos de los consejos también le serán útiles.
No contratarán en absoluto
Cuando imagina que cientos de estudiantes se gradúan de muchas universidades cada año, se vuelve incómodo. ¿Cómo competir con una multitud tan grande?
Desafortunadamente, no todos los graduados tienen suficiente capacitación técnica. Intenta preguntarle a algún estudiante universitario que conozcas: ¿cómo consiguen las personas de su grupo la admisión a los exámenes en disciplinas como la "base de datos" o "los conceptos básicos de algoritmo y programación"? En un grupo de 30 personas, en el mejor de los casos, hay 3-5 chicos "avanzados" que realmente hicieron todo por sí mismos. El resto simplemente los descarta, bison las respuestas a las preguntas y pasa.
Fue entonces cuando me estudié a mí mismo. Sin embargo, mi experiencia podría no ser representativa. Por lo tanto, hice esta pregunta a varios estudiantes diferentes. La respuesta fue casi la misma. Los encuestados eran de diferentes universidades y colegios. Dejaré discusiones sobre las razones más allá del alcance de este artículo. No soy suficiente para un estudio completo, por lo que sacaré una conclusión de los hechos disponibles.
Entre cientos de graduados, solo un par de docenas son de interés para los empleadores
Pocos graduados pueden hacer una competencia real para un estudiante capaz con buena preparación. Sin embargo, incluso si estudiaste de buena fe, después de la primera entrevista lo más probable es que no te contraten. Después del segundo, probablemente también. Todo puede funcionar bien, pero es mejor no sintonizar un asalto, sino asediarlo. Un intento fallido de instalarse es solo una excusa para trabajar en los errores e intentar nuevamente. No hablaré sobre la preparación para entrevistas. Ya se ha escrito mucho sobre este tema en Internet. Solo puedo decir que hay matices al pasar entrevistas, por lo que es poco probable que se asigne tiempo para explicar su programa de capacitación. 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 un cambio
Albert Einstein
Para garantizar que la entrevista no se convierta en locura, después de cada nuevo intento, debe mejorar. Recuerde o escriba las preguntas que le hicieron durante la entrevista. Al regresar a casa, navegue por esta lista y compruébelo usando Internet. Entonces comprenderá dónde se equivocó, dónde: el entrevistador. Esto también pasa. Repite o estudia temas en los que respondiste mal e inténtalo de nuevo.
Además, existe una marcada estacionalidad del mercado laboral. Las compañías competentes planean la contratación en función de las fechas de graduación de las instituciones educativas. En la primavera de vacantes para principiantes más que el resto del tiempo. Sin embargo, la competencia en este momento es mayor.
Tonto - ser despedido
Cuando una persona es contratada sin experiencia, hay expectativas correspondientes para ella.
De un recién llegado al trabajo, espere:
- Conocimiento de la base técnica general.
- Estudiar las características del área temática de la empresa.
- Dominar las herramientas y prácticas utilizadas
Algunas organizaciones ofrecen a los principiantes cursos de capacitación sobre tecnologías, herramientas y prácticas locales. Por ejemplo, las reglas de buena forma cuando se usa el correo corporativo, el procedimiento para cambiar documentos en una wiki, las características locales de trabajar con VCS y un rastreador de errores.
Todavía hay cursos de iniciación técnica, pero su utilidad es dudosa. Si se trata de empleo, los empleadores se aseguraron de que tengas un nivel de conocimiento suficiente. Es mejor simplemente tomar tales cursos de buena fe, como una pequeña formalidad. Tal vez realmente sean algo útil.
Cuando llegue al trabajo, recuerde que el principiante no se encargará de resolver la tarea urgente, compleja y al mismo tiempo importante. Lo más probable es que solo haya una de estas propiedades. O simple, pero urgente: corrija el diseño, envíe un archivo a alguien, reproduzca el problema. O difícil, pero sin ninguna esperanza de finalización, para que el principiante recoja más rake. O importante, pero experimental. Por ejemplo, un proyecto que todo el mundo ha querido desde hace tiempo, pero que no puede asignar tiempo para la implementación.
Las tareas para el desarrollo de herramientas serán "complejas" y artificiales. Lo más probable es que sea una versión simplificada del sistema principal. En tales tareas, se utiliza la misma pila de tecnología y los mismos términos de dominio que en todo el proyecto. Sin embargo, el resultado de la ejecución no se dará al usuario final. Puede desmotivar, pero es mejor resistir este estado de ánimo. Una tarea artificial debe hacerse de buena fe, como si el destino del proyecto dependiera de ello.
El resultado de resolver su primera tarea será la primera impresión sobre usted de parte de colegas que no estuvieron en la entrevista.
Otra versión de la tarea para dominar el kit de herramientas es "ejecutar el proyecto en la máquina local / entorno de prueba". Algunas veces este proceso se describe en las instrucciones. Pero generalmente son viejos y a veces irrelevantes. Puede aportar beneficios reales al proyecto si escribe una nueva instrucción con aclaraciones sobre los problemas que han surgido. Seguramente en la universidad tuve que escribir un RGR para informar sobre algunas disciplinas. Es casi lo mismo aquí. El documento debe reflejar las acciones que se deben realizar para ejecutar.
Por lo general, los pasos para lanzar el producto en un entorno de prueba son aproximadamente los siguientes:
- clonar un repositorio, cambiar a alguna rama o etiqueta
- distinguir algún archivo de configuración
- preparar la estructura de la base de datos
- llenarlo con datos de prueba
- Construir o compilar un proyecto
- ejecutar un conjunto de scripts de consola en una secuencia específica
En el proceso de iniciar el sistema, inevitablemente ocurrirán problemas locales a nivel local.
Las soluciones encontradas a los problemas deben agregarse a las instrucciones de implementación. Luego, la próxima vez que siga las instrucciones, estos problemas ya no surgirán. Al completar los archivos de configuración y las secuencias de comandos de llamada, debe prestar atención a qué valor se utiliza dónde y con qué debe coincidir. Por ejemplo, si un proyecto se crea utilizando el sistema CI y luego se inicia mediante un script, es importante comprender dónde escribir el nombre de la sucursal o el número de confirmación. Sucede que la secuencia de comandos implica la transferencia de una dirección IP o nombre DNS de la base de datos, su nombre de usuario y contraseña. En este caso, debe saber qué dirección usar 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 desarrolladores experimentados y causar dificultades a los alumnos. Este es un hecho normal.
Los desarrolladores tienen que resolver problemas técnicos todos los días. Los empleados experimentados ya han resuelto muchos problemas antes, y los recién llegados aún tienen que lidiar con ellos. La mejor táctica será anotar todos los errores encontrados en el documento "Solución de problemas con $ {nombre de tarea}". Para cada problema, debe formular una hipótesis sobre la causa, encontrar soluciones en Internet y probarlas por turno. El resultado de cada intento también necesita ser registrado.
Hacer su investigación en forma de documento le permitirá:
- descargue piezas pequeñas de su cabeza. Por ejemplo, parámetros de configuración, direcciones DNS / IP, comandos de consola y consultas SQL.
- recuerde "qué hice ayer" cuando la tarea se alargó durante varios días
- No deambules. Siempre puede leer lo que hizo antes y comprender que ha vuelto al problema original.
- responde claramente la pregunta: "¿qué hiciste hoy?" incluso si aún no hay una solución preparada.
Debe poder comunicar el estado de sus tareas a sus colegas.
De vez en cuando, los colegas estarán interesados en sus éxitos y compartirán los suyos. Se asigna un poco de tiempo para esto diariamente o semanalmente.
Si no realiza un seguimiento de los problemas encontrados y resueltos, la descripción de sus éxitos se verá así: "Traté de hacer la tarea, pero no puedo. Estoy buscando una solución hasta ahora ". De tal historia no está claro si el aprendiz hizo algo o simplemente se sentó a leer. ¿Necesita ayuda? ¿Ha cambiado la situación desde ayer?
Si mantiene un documento con una búsqueda de soluciones, puede decir: “Estoy tratando de hacer esta tarea. Tuve tales errores. Entonces decidí así. Todavía no lo he logrado. Existen tales hipótesis y soluciones. Ahora los estoy revisando ".
Si la tarea se puede medir al menos de alguna manera, los números deberían sonar en el estado. Por ejemplo, para la tarea "escribir pruebas unitarias para un módulo", podemos decir "planeo hacer 20 pruebas, ahora escribí 10".
Cuantos más detalles proporcione, mejor comprenderán sus colegas lo que estaba haciendo. Esto formará una actitud positiva hacia los colegas y les permitirá comprender si necesita ayuda o no.
Siéntase libre de pedir ayuda.
Escribí anteriormente que cuando surge un problema, debe formular una hipótesis sobre sus causas y soluciones. Sin embargo, sucede que las hipótesis no están justificadas, y las soluciones encontradas independientemente para el problema no funcionan. En este caso, es mejor pedir ayuda. Para no abusar de la atención de los colegas, debe ocuparse de cada problema usted mismo. Si en un par de horas no fue posible encontrar una solución, es hora de buscar el consejo de camaradas más experimentados.
Es mejor comenzar con la pregunta: "¿Alguien ha encontrado un problema antes?" con una breve descripción del problema Es recomendable adjuntar un mensaje de error o una captura de pantalla. Esta es la primera vez que es mejor enviarlo a un chat general para trabajar. Entonces no interrumpes el trabajo de aquellos que están realmente ocupados. Al mismo tiempo, los colegas gratuitos verán su mensaje y podrán ayudarlo.
Si nadie ayudó después de un mensaje en el chat general, intente atrapar a un colega experimentado durante el descanso: almuerzo, té / café, un partido de tenis o un descanso para fumar. Si esto no funcionó, informe sus dificultades sobre la marcha o de pie.
Al resolver problemas conocidos, esto puede terminar. Si el problema es nuevo, se iniciará una investigación, donde será necesario actuar de acuerdo con las circunstancias.
Las tareas "importantes" para principiantes que el usuario final necesita serán aburridas y pequeñas. Por ejemplo, "agregue una columna adicional al informe" o "corrija un error tipográfico en forma impresa" o "implemente un método modelo para cargar los atributos del cliente desde un DBMS". El objetivo de tales tareas es que el principiante se familiarice con el área temática y se integre en el trabajo diario.
Es importante no solo resolver técnicamente el problema, sino también ampliar el conocimiento del área temática.
En la descripción de la tarea, en chats y conversaciones, se encontrarán términos. Pueden parecer sustantivos familiares largos. Sin embargo, dentro del marco del sistema de información, tienen un significado especial y más preciso. El significado de los términos detectados se escribe mejor en un documento especial: un glosario de términos. Al agregar al diccionario, es suficiente para escribir su comprensión de la palabra, y para una transcripción real, es mejor contactar al analista. Si él está ausente, entonces a los veteranos del proyecto. Mantener un glosario de términos es una de las formas más sencillas de familiarizarse con el área temática del proyecto.
Tan pronto como encuentre un lenguaje común con sus colegas, comenzarán a ver en usted no un aprendiz novato, sino un especialista igual.
Hay tareas especiales, por ejemplo, "escribir pruebas unitarias para un módulo". Difícilmente se puede atascar durante mucho tiempo con la búsqueda de soluciones. Además, ella es lo suficientemente seria y se le da no solo para entrenar al aprendiz. Las pruebas escritas aumentan la estabilidad del proyecto al reducir los errores en la aplicación y el tiempo de prueba por parte de las personas. En un mundo ideal, las pruebas unitarias se escriben inmediatamente durante el desarrollo, pero la realidad es diferente como siempre. Sucede que el desarrollador del módulo lo tiene completamente en la cabeza y no ve la necesidad de escribirlos. "Todo es obvio, ¿qué hay para probar?" A veces, los módulos se escriben en modo de emergencia y no queda tiempo para las pruebas unitarias. Entonces, en el mundo real, las pruebas unitarias pueden no serlo. Por lo tanto, la tarea de escribir pruebas unitarias se confía a un principiante. Por lo tanto, el aprendiz podrá acostumbrarse rápidamente al proyecto, y el proyecto ahorrará el tiempo de especialistas mejor pagados.
Sucede que a los pasantes y principiantes se les asigna el papel de probadores de pleno derecho. Por lo general, antes de esto, debe implementar el producto localmente y leer los requisitos. Como resultado del nuevo empleado se espera:
- preguntas como “si te gusta esto, entonces resultará así. Esto no es obligatorio en los requisitos. ¿Cómo debería ser?
- tareas en el rastreador de errores "en los requisitos se escribe así, pero de hecho es diferente".
Las pruebas son un área de actividad demasiado amplia para este artículo. Si se le asignó una tarea similar, busque en Internet la mejor manera de lograrlo.
Nakosyachite - ser despedido
En una organización normal, si de repente sucede que un empleado sin experiencia obtiene acceso a algo crítico y arruina algo, entonces el que cometió esto será el culpable. Porque el novato por defecto no tiene acceso a infraestructura crítica. Con una orientación adecuada, todos los perros no serán decepcionados por un aprendiz sin experiencia.
Si algo sucede repentinamente, no serán despedidos debido a un incidente. La gente aprende de los errores. El aprendiz de carrera recibió una valiosa lección y esto es muy diferente de otros aprendices. Si descarta el portazo, otro vendrá en su lugar y cortará de la misma manera.
Lo principal es aprender de los errores y no repetirlos nuevamente.
Si una persona no saca conclusiones de sus errores, entonces tratarán de decirle adiós. Sin embargo, el mundo es diverso. En alguna organización de gángsters pueden tirar inmediatamente por la ventana por el primer error. Pero es mejor evitar esas empresas, por lo que primero debe consultar o averiguar más durante la entrevista.
Es mejor evitar incidentes
Incluso si no es despedido personalmente por la jamba, dicho incidente causará problemas indeseables para su equipo y el proyecto en su conjunto. Por lo tanto, tenga especial cuidado con las operaciones de eliminación o creación de tablas en la base de datos, archivos, instancias de servicio y documentos en la base de conocimiento del proyecto. Si conoce la dirección de la nueva conexión, verifique con al menos dos personas diferentes qué puede hacer allí. Verifique sus derechos en entornos no por prueba y error, sino por comandos apropiados. Por ejemplo, el derecho a eliminar archivos usando el comando `ls`, el derecho a trabajar con tablas en mysql usando el comando` SHOW GRANTS FOR 'user' @ 'host'; `, y similares. En casi cualquier instrumento tendrá una oportunidad similar.
Al editar archivos, por si acaso, conserve una copia del original.
Se construyen varias barreras entre el interno y el usuario final.
Si pudiera entregar inmediatamente su producto al consumidor, no podría conseguir un trabajo, sino embarcarse en un "baño libre". Pero si bien no tiene esa oportunidad (y al mismo tiempo responsabilidad), debe pasar por varias etapas de control del proyecto.
El primero es un cheque de mentor. Evalúa la solución del principiante desde un punto de vista técnico. Si no se ha designado un mentor, entonces debe encontrarlo. Para hacer esto, debe elegir a alguien de los veteranos del proyecto y en el descanso pedirle que vea la solución: ¿el problema se resolvió correctamente? Si comienza a mirar y responder, se encuentra un mentor. Si lo ignora, debería preguntarle a alguien más.
La siguiente etapa es la garantía de calidad. En ruso - probadores. En soviético: control estándar y control de calidad. Deben asegurarse de que el resultado del trabajo del interno corresponda a la tarea asignada a él. Raramente serán leídos en el código. Muy a menudo, los evaluadores verificarán el proyecto ensamblado, que el desarrollador guarda en el sistema de control de versiones.
La tercera etapa es el administrador de versiones. Puede que no haya una persona individual para esta tarea, pero alguien aún juega el papel. Comprueba que los evaluadores han confirmado que el proyecto puede ser lanzado. , .
. - . .
, .
, . , . . . ? , «» , «» .
, . .
.