🥇Desfacerse do medo antes do teu primeiro traballo

Fotograma da película "Harry Potter e o prisioneiro de Azkaban"

O problema deste mundo é que a xente culta está chea de dúbidas, pero os idiotas están cheos de confianza.
Charles Bukowski

Hai pouco dei outra lección de programación individual. A diferenza das clases habituais, o tema non era a construción da lingua nin a resolución de problemas. O estudante compartiu as súas preocupacións sobre o futuro laboral. O propio estudante era bastante intelixente. Un dos que chega ao curso completa todo o programa máis rápido que ninguén e con solucións orixinais, pero sempre se subestima sinceramente a si mesmo. Na miña opinión, tales dúbidas xorden só da falta de información. Intentei cubrir este oco improvisado durante a lección.

As preguntas eran algo así:

Cada ano son moitos os estudantes que se gradúan nas universidades e todos van buscar traballo. Iso é moita xente. Probablemente contraten aos mellores, pero non conseguirei praza.
E se me desorde e me despiden de inmediato?
E se no proceso de traballo se dan conta de que son parvo e me botan fóra?

Esta alumna non foi a primeira persoa á que lle respondín este tipo de preguntas. Moita xente os ten, e normalmente hai que contalos sen preparación. Esta vez decidín anotar o meu monólogo nun caderno. Pensei que serían un par de parágrafos, pero acabou sendo suficiente para todo un artigo.

O artigo describe a vista desde o meu punto de vista e baseándose na miña experiencia. Non obstante, o noso mundo é moi diverso e nel acontecen cousas sorprendentes. Se non estás de acordo con algo ou a túa experiencia é diferente dalgún xeito, escribe un comentario.

O artigo foi escrito por un programador para desenvolvedores. Non obstante, se pensas facer probas, administración ou calquera outra cousa en TI, algúns dos consellos tamén che serán útiles.

Non te contratarán en absoluto

Cando imaxinas que moitas universidades gradúan centos de estudantes cada ano, faise incómodo. Como competir cunha multitude tan grande?

Desafortunadamente, non todos os titulados teñen formación técnica suficiente. Proba a preguntarlle a algún estudante universitario que coñezas: como conseguen as persoas do seu grupo a admisión a exames de disciplinas como "bases de datos" ou "fundamentos de algoritmo e programación"? Nun grupo de 30 persoas, no mellor dos casos, haberá 3-5 rapaces "avanzados" que en realidade fixeron todo eles mesmos. O resto simplemente copia deles, apila respostas ás preguntas e envía.

Así era cando estudaba pola miña conta. Non obstante, a miña experiencia pode non ser representativa. Entón fixen esta pregunta a varios estudantes diferentes. A resposta foi practicamente a mesma. Os entrevistados eran de diferentes universidades e facultades. Vou deixar discusións sobre as razóns fóra do ámbito deste artigo. Non teño tempo suficiente para un estudo completo, así que sacarei unha conclusión dos feitos dispoñibles.

Entre centos de titulados, só un par de ducias son de interese para os empresarios

Poucos graduados poden ofrecer unha competencia real para un estudante capaz e cunha boa preparación. Non obstante, aínda que estudases a conciencia, despois da primeira entrevista probablemente non te contraten. Despois do segundo, probablemente tamén. Todo pode saír ben, pero é mellor prepararse non para un asalto, senón para un asedio. Un intento infructuoso de conseguir un emprego é só un motivo para traballar nos teus erros e tentalo de novo. Non vou falar de preparar entrevistas. Xa se escribiu moito sobre este tema en Internet. Só direi que hai matices nas entrevistas que probablemente o teu programa de formación non tardará en explicar. Busca esta información ti mesmo, pode reducir o número de intentos.

A loucura é a repetición exacta da mesma acción. Unha e outra vez, esperando cambios
Albert Einstein

Para evitar que as entrevistas se convertan en loucura, cómpre mellorar despois de cada novo intento. Memoriza ou anota as preguntas que che fixeron durante a entrevista. Cando volvas a casa, mira esta lista e comproba a ti mesmo usando Internet. Deste xeito, entenderás onde cometeches un erro ti e o entrevistador. Isto tamén ocorre. Revisa ou estuda os temas nos que obtiveches un mal rendemento e téntao de novo.

Ademais, hai unha marcada estacionalidade do mercado laboral. As empresas intelixentes planifican a contratación en función das datas de graduación. Na primavera hai máis prazas de recén chegados que noutras épocas. Non obstante, a competencia é maior neste momento.

Estúpido - ser despedido

Cando se contrata unha persoa sen experiencia, hai expectativas correspondentes para el.

Espérase que un recén chegado ao traballo:

Coñecemento da base técnica xeral
Estudar as especificidades da área temática da empresa
Dominar as ferramentas e prácticas empregadas

Algunhas organizacións ofrecen cursos de formación para novos chegados sobre as tecnoloxías utilizadas, ferramentas e procedementos locais. Por exemplo, boas maneiras ao usar o correo electrónico corporativo, o procedemento para cambiar documentos nunha wiki, as características locais de traballar con VCS e un rastreador de erros.

Tamén hai cursos de iniciación técnica, pero a súa utilidade é cuestionable. Se se trata de emprego, os empresarios están convencidos de que tes un nivel de coñecemento suficiente. O mellor é simplemente realizar estes cursos de boa fe, como un pequeno trámite. Quizais realmente haxa algo útil neles.

Cando comeces a traballar, recorda que a un principiante definitivamente non se lle encargará resolver unha tarefa urxente, complexa e ao mesmo tempo importante. O máis probable é que só haxa unha destas propiedades. Ou sinxelo pero urxente: corrixir o deseño, enviar un ficheiro a alguén, reproducir o problema. Ou difícil, pero sen ningunha esperanza de finalización, para que o principiante recolla máis rake. Ou importante, pero experimental. Por exemplo, un proxecto que todo o mundo quería dende hai tempo, pero que non atopa o tempo para implementar.

As tarefas para dominar as ferramentas serán "difíciles" e artificiais. O máis probable é que esta sexa unha versión simplificada do sistema principal. Tales tarefas usan a mesma pila de tecnoloxía e os mesmos termos de dominio que todo o proxecto. Neste caso, o resultado da execución non se dará ao usuario final. Isto pode ser desmotivador, pero é mellor resistirse a este sentimento. Hai que facer unha tarefa artificial concienzudamente, coma se del dependese o destino do proxecto.

O resultado de resolver o teu primeiro problema formará a primeira impresión de ti entre os compañeiros que non estiveron presentes na entrevista.

Outra opción para a tarefa de dominio da ferramenta é "executar o proxecto nunha máquina/entorno de proba local". Ás veces, este proceso descríbese nas instrucións. Pero adoitan ser vellos e nalgúns lugares anticuados. Podes aportar beneficios reais ao proxecto se escribes novas instrucións con aclaracións sobre os problemas xurdidos. Seguro que na universidade tiñas que redactar un RGR para un informe sobre algunhas disciplinas. Aquí é case o mesmo. O documento debe reflectir as accións que se deben realizar para lanzar.

Normalmente, os pasos para executar un produto nun ambiente de proba son algo así:

clonar un repositorio, cambiar a algunha rama ou etiqueta
crear algún ficheiro de configuración
preparar a estrutura da base de datos
éncheo con datos de proba
construír ou compilar o proxecto,
executar un conxunto de scripts de consola nunha determinada secuencia

Durante o proceso de execución dun sistema localmente, inevitablemente xurdirán problemas inesperados.

Atopar solucións aos problemas debería engadirse ás instrucións de despregamento. Entón, a próxima vez que sigas as instrucións, estes problemas non xurdirán. Ao completar ficheiros de configuración e chamar scripts, presta atención a que valor se usa onde e con que debe coincidir. Por exemplo, se un proxecto se compila usando un sistema CI e logo se executa mediante un script, é importante entender onde introducir o nome da rama ou o número de confirmación. Ás veces, o script require pasar enderezos IP ou o nome DNS da base de datos, o seu inicio de sesión e contrasinal. Neste caso, precisa saber o enderezo específico que se debe usar para o ambiente de proba, que inicios de sesión contén e que contrasinais se deben especificar para eles.

Algunhas tarefas poden parecer sinxelas para os desenvolvedores experimentados, pero difíciles para os internos. Isto é normal.

Os desenvolvedores teñen que resolver problemas técnicos todos os días. Os empregados con experiencia xa resolveron moitos problemas antes, mentres que os recén chegados aínda teñen que facerlles fronte. A mellor táctica é rexistrar todos os erros atopados no documento "resolvendo problemas con ${nome da tarefa}". Para cada problema, cómpre formular unha hipótese sobre a causa, buscar solucións en Internet e probalas unha por unha. Tamén se debe rexistrar o resultado de cada intento.

O rexistro da súa investigación en forma de documento permitirá:

descarga pequenos detalles da túa cabeza. Por exemplo, parámetros de configuración, enderezos DNS/IP, comandos de consola e consultas SQL.
lembra "que fixen onte" cando a tarefa dura varios días
non vagues en círculos. Sempre podes ler o que fixeches antes e comprender que volveches ao problema orixinal
responde claramente á pregunta: "que fixeches hoxe?" aínda que aínda non exista unha solución preparada.

Debe ser capaz de comunicar o estado das súas tarefas aos compañeiros

De cando en vez, os compañeiros interesaranse polos teus éxitos e compartiranse os seus. Dedica un tempo para iso diariamente ou semanalmente.

Se non realizas un seguimento dos problemas atopados e resoltos, a descrición dos teus éxitos será así: "Intentei facer a tarefa, pero non podo facelo. Aínda estou buscando unha solución". Desta historia non queda claro se o interno estaba facendo algo ou só sentado e lendo. Necesita axuda? Cambiou a situación desde onte?

Se gardas un documento buscando solucións, podes dicir "Estou tentando facer esta tarefa. Tiven erros coma este. Así decidín. Aínda non tratei con este. Existen estas hipóteses e solucións. Estou revisándoos agora".

Se a tarefa se pode medir dalgún xeito, entón o estado debería conter números. Por exemplo, para a tarefa "escribir probas unitarias para un módulo", pode dicir "Penso facer 20 probas, agora escribín 10".

Cantos máis detalles proporciones, mellor entenderán os teus compañeiros o que fixeches. Isto creará unha actitude positiva cara a ti entre os teus compañeiros e permitiralles entender se necesitas axuda ou non.

Non dubides en pedir axuda

Escribín anteriormente que cando xorde un problema, cómpre formular unha hipótese sobre as súas causas e posibles solucións. Non obstante, ocorre que as hipóteses non están xustificadas e que as solucións atopadas de forma independente ao problema non funcionan. Neste caso, é mellor pedir axuda. Para non abusar da atención dos teus compañeiros, tes que sentarte ti mesmo en cada problema. Se non foi capaz de atopar unha solución nun par de horas, é hora de buscar o consello de compañeiros máis experimentados.

Un bo lugar para comezar é preguntar: "¿Alguén atopouse con este problema antes?" cunha breve descrición do problema. É recomendable anexar un fragmento da mensaxe de erro ou unha captura de pantalla. É mellor enviar esta mensaxe por primeira vez a algún chat de traballo xeral. Deste xeito, non distraes do traballo aos que están realmente ocupados. Os compañeiros libres verán a túa mensaxe e poderán axudar.

Se despois dunha mensaxe no chat xeral ninguén axudou, tenta atrapar a un compañeiro experimentado durante un descanso: xantar, ir a tomar un té/café, unha partida de tenis ou unha pausa para fumar. Se isto non funciona, informa das túas dificultades na reunión ou no stand-up.

Se se solucionan os problemas coñecidos, todo isto pode rematar aí. Se o problema é novo, iniciarase unha investigación, onde será necesario actuar segundo as circunstancias.

As tarefas "importantes" para principiantes que necesita o usuario final serán aburridas e pequenas. Por exemplo, "engadir unha columna adicional ao informe" ou "corrixir un erro tipográfico no formulario impreso" ou "implemente un método modelo para cargar atributos de cliente desde o DBMS". O obxectivo destas tarefas é que o principiante se familiarice coa materia e se integre no traballo diario.

É importante non só resolver tecnicamente o problema, senón tamén ampliar o coñecemento da área temática.

Os termos aparecerán na descrición da tarefa, nos chats e conversas. Poden parecer substantivos coñecidos. Porén, no marco do sistema de información, teñen un significado especial, máis preciso. O significado dos termos descubertos rexístrase mellor nun documento especial: un dicionario de termos. Ao engadir ao dicionario, abonda con escribir a súa comprensión da palabra, pero para unha decodificación real é mellor contactar cun analista. Se falta, vai aos vellos do proxecto. Manter un dicionario de termos é unha das formas máis sinxelas de familiarizarse coa área temática dun proxecto.

Unha vez que atopes unha linguaxe común cos teus compañeiros, eles comezarán a verte non como un novo en prácticas, senón como un especialista igual.

Hai tarefas especiais, por exemplo, "escribir probas unitarias para un módulo". Dificilmente pode quedar atrapado nel durante moito tempo buscando solucións. Ao mesmo tempo, é bastante serio e dáse non só para a formación de aprendiz. As probas escritas aumentan a estabilidade do proxecto reducindo erros na aplicación e reducindo o tempo para as probas humanas. Nun mundo ideal, as probas unitarias escríbense inmediatamente durante o desenvolvemento, pero a realidade sempre é diferente. Ocorre que o desenvolvedor dun módulo o mantén completamente na cabeza e non ve a necesidade de escribilos. "Todo é obvio, que hai que probar?" Ás veces, os módulos escríbense en modo rush e non queda tempo para as probas unitarias. Polo tanto, no mundo real pode que non haxa probas unitarias. Polo tanto, a tarefa de escribir probas unitarias encárgase a un principiante. Deste xeito, o estudante poderá acostumbrarse ao proxecto máis rápido, e o proxecto poderá aforrar tempo dos especialistas máis remunerados.

Acontece que os pasantes e os recén chegados teñen asignado o papel de probadores completos. Normalmente, antes de facelo, cómpre implementar o produto localmente e ler os requisitos. Como resultado, espérase que o novo empregado:

preguntas como "se o fas así, vai resultar así. Isto non está nos requisitos. Debería ser?"
tarefas no rastreador de erros "os requisitos din isto, pero en realidade está escrito de forma diferente".

A proba é unha área demasiado ampla para este artigo. Se che encargan unha tarefa semellante, busca en Internet a mellor forma de realizala.

Se te desordenas, despedirás

Nunha organización normal, se de súpeto ocorre que un empregado sen experiencia accede a algo crítico e estraga algo, entón o culpable será quen permitiu que isto suceda. Porque un principiante, por defecto, non ten acceso á infraestrutura crítica. Coa orientación adecuada, non deixarán que todos os cans se desperdicien cun aprendiz sen experiencia.

Se ocorre algo, non te despedirán por mor dun incidente. A xente aprende dos erros. O interno que se desordeu aprendeu unha lección valiosa e é moi diferente dos demais internos. Se despides a alguén que desorde, outra persoa virá no seu lugar e desorde do mesmo xeito.

O principal é aprender dos erros e non repetilos.

Se unha persoa non saca conclusións dos seus erros, tentará despedirse del. Non obstante, o mundo é diverso. Nalgunha organización de gángsters poden lanzarche inmediatamente pola fiestra polo primeiro erro. Pero é mellor evitar este tipo de empresas facendo consultas primeiro ou descubrindo máis durante a entrevista.

É mellor evitar incidentes

Aínda que persoalmente non sexa despedido por un erro, tal incidente causará problemas non desexados para o seu equipo e para o proxecto no seu conxunto. Polo tanto, teña especial coidado coas operacións de eliminación ou creación de táboas na base de datos, ficheiros, instancias de servizo e documentos na base de coñecemento do proxecto. Se atopas o enderezo dunha nova conexión, consulta con polo menos dúas persoas diferentes o que se pode facer alí. Comprobe os seus dereitos en ambientes non por proba e erro, senón mediante os comandos axeitados. Por exemplo, dereitos para eliminar ficheiros usando o comando `ls`, dereitos para traballar con táboas en mysql usando o comando `SHOW GRANTS FOR 'user'@'host';` e similares. En case calquera ferramenta terás unha oportunidade semellante.

Ao editar ficheiros, garda unha copia do orixinal para ti, por se acaso.

Constrúense varias barreiras entre o alumno e o usuario final.

Se puideses entregar inmediatamente o teu produto ao consumidor, poderías non conseguir un traballo, senón saír a un "baño libre". Pero aínda que non tes esa oportunidade (e ao mesmo tempo, responsabilidade), debes pasar por varias etapas de control do proxecto.
O primeiro deles é a verificación por parte dun mentor. Avalía a decisión do novato dende o punto de vista técnico. Se non se asignou un mentor, debes atopar un. Para iso, cómpre escoller un dos vellos do proxecto e durante un descanso pedirlle que busque a solución: resolveuse o problema correctamente? Se comeza a buscar e responder, entón atopouse un mentor. Se non o fai caso, paga a pena preguntarlle a outra persoa.

A seguinte etapa é a garantía de calidade. En ruso - probadores. En estilo soviético - control estándar e departamento de control de calidade. Deberán asegurarse de que o desempeño do estudante sexa coherente coa tarefa que se lle encomenda. Raramente lerán o código. Na maioría das veces, os probadores comprobarán o proxecto construído, que o programador almacena no sistema de control de versións.

A terceira etapa é o xestor de versións. Pode que non haxa unha persoa separada para esta tarefa, pero alguén aínda desempeña o papel. Comproba que os probadores confirmaron que o proxecto se pode lanzar. Despois diso, realiza as actividades para entregar o produto aos usuarios finais.
Nas organizacións pequenas, estas barreiras poden non existir por varios motivos. Non obstante, non lle darán a un novato a tarefa de cambiar algo importante. Porque ninguén precisa deste risco.

Primeiro tes que involucrarte na batalla, e despois xa veremos.
Napoleón Bonaparte

Espero que este artigo che axude a superar a túa incerteza e a enviar o teu primeiro currículo. Por suposto, primeiro debes prepararte. Pero non hai necesidade de ampliar. Probablemente xa estudases nunha universidade ou facultade durante varios anos. Onde ir a continuación? Ao final, é mellor escoitar "non" unha vez dun especialista e traballar nos erros que dicir "non" todos os días e deixar de crecer profesionalmente.

Unha vez contratado, debes centrarte en pasar de ser un interno a un membro do equipo completo. Este tipo de crecemento adoita vir cun aumento do seu salario.

Deséxoche paciencia e constancia.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.