🥇Superando o medo da primeira contratação

Cena do filme 'Harry Potter e o Prisioneiro de Azkaban'

O problema deste mundo é que pessoas educadas estão cheias de dúvidas, enquanto idiotas estão cheios de confiança
Charles Bukowski

Recentemente, tive mais uma aula individual de programação. Diferente das aulas normais, o tema não foi a estrutura da linguagem ou a resolução de problemas. O aluno compartilhou suas preocupações sobre o futuro no mercado de trabalho. O próprio aluno era bastante inteligente. Um daqueles que frequentam os cursos, completam todo o conteúdo mais rápido que todos e com soluções originais, mas sempre subestimam a si mesmos. Na minha opinião, essas dúvidas surgem apenas da falta de informação. Esse vazio eu tentei preencher espontaneamente durante a aula.

As perguntas eram mais ou menos estas:

Todo ano, muitas universidades formam novos alunos que saem à procura de emprego. São muitas pessoas. Certamente, eles vão contratar os melhores, e eu não vou conseguir uma vaga.
E se eu errar e for demitido imediatamente?
E se, durante o trabalho, eles perceberem que sou burro e me mandarem embora?

Esse aluno não foi a primeira pessoa a quem respondi perguntas semelhantes. Elas surgem para muitos, e geralmente tenho que falar sem preparação. Desta vez, decidi anotar meu monólogo no bloco de notas. Pensei que resultaria em alguns parágrafos, mas acabei escrevendo um artigo completo.

O artigo descreve a minha visão e minha experiência. No entanto, nosso mundo é muito diverso e coisas surpreendentes acontecem. Se você não concorda com algo ou sua experiência é diferente, por favor, deixe um comentário.

O artigo foi escrito por um desenvolvedor para outros desenvolvedores. No entanto, se você planeja trabalhar com testes, administração ou qualquer outra coisa em TI, algumas das dicas também serão úteis para você.

Ninguém vai te contratar

Quando você imagina que anualmente muitas universidades formam centenas de alunos, fica desconfortável. Como competir com toda essa imensidão de gente?

Infelizmente, nem todos os graduados têm a preparação técnica necessária. Tente perguntar a algum amigo estudante da universidade: como as pessoas do grupo dele conseguem se apresentar para os exames em disciplinas como 'banco de dados' ou 'fundamentos de algoritmos e programação'? Em um grupo de 30 pessoas, no melhor dos casos, haverá de 3 a 5 'avançados' que realmente fizeram tudo sozinhos. Os outros apenas copiam deles, decoram respostas para as perguntas e se apresentam.

Foi assim quando eu estava estudando. No entanto, minha experiência pode não ser representativa. Portanto, fiz essa pergunta a vários estudantes diferentes. A resposta foi aproximadamente a mesma. Os respondentes eram de diferentes universidades e faculdades. As reflexões sobre as causas ficam fora do escopo deste artigo. Não terei fôlego para uma pesquisa completa, portanto, farei uma conclusão com base nos fatos disponíveis.

Entre centenas de graduados, apenas algumas dezenas despertam o interesse dos empregadores.

Poucos graduados conseguem competir verdadeiramente com um estudante capaz e bem preparado. No entanto, mesmo que você tenha estudado com diligência, após a primeira entrevista você provavelmente não será contratado. Após a segunda, provavelmente também não. As coisas podem acabar bem, mas é melhor se preparar não para um ataque, mas para um cerco. Uma tentativa malsucedida de conseguir um emprego é apenas uma razão para fazer uma autoanálise e tentar novamente. Não falarei sobre a preparação para entrevistas. Já foi escrito muito sobre isso na internet. Apenas direi que existem nuances nas entrevistas, para as quais, provavelmente, não há tempo suficiente no seu programa de estudos. Pesquise essas informações por conta própria, elas podem reduzir o número de tentativas.

Loucuras é repetir a mesma ação, repetidamente, na esperança de mudança.
Albert Einstein

Para que a passagem por entrevistas não se torne uma loucura, após cada nova tentativa, é preciso melhorar. Memorize ou anote as perguntas que lhe foram feitas durante a entrevista. Ao voltar para casa, revise essa lista e se verifique com a ajuda da internet. Assim, você entenderá onde errou e onde o entrevistador errou. Isso também acontece. Revise ou estude os temas em que você respondeu mal e tente novamente.

Além disso, há uma sazonalidade bem definida no mercado de trabalho. Empresas competentes planejam contratações com base nas datas de formatura. Na primavera, há mais vagas para novatos do que em outros períodos. No entanto, a concorrência também é maior nessa época.

Se for desprovido de habilidades, será demitido.

Quando uma pessoa sem experiência é contratada, existem expectativas correspondentes em relação a ela.

As expectativas para um novato no trabalho são:

Conhecimento da base técnica geral
Estudo das peculiaridades do setor da empresa
Domínio das ferramentas e práticas utilizadas

Em algumas organizações, cursos de formação são organizados para novatos sobre as tecnologias, ferramentas e normas locais utilizadas. Por exemplo, as regras de boa etiqueta no uso do e-mail corporativo, as diretrizes para alteração de documentos na wiki, peculiaridades locais do trabalho com VCS e sistema de rastreamento de bugs.

Às vezes há cursos introdutórios técnicos, mas sua utilidade é questionável. Se você chegou ao ponto de ser contratado, significa que os empregadores se certificaram de que você possui um nível de conhecimento suficiente. O melhor a fazer é completar esses cursos de maneira diligente, tratá-los como uma formalidade. Pode ser que haja algo realmente útil neles.

Quando você começar a trabalhar, lembre-se de que raramente um novato será encarregado de resolver uma questão urgente, complexa e ao mesmo tempo importante. É mais provável que se depare com apenas uma dessas características. Pode ser uma tarefa simples, mas urgente: corrigir a formatação, encaminhar algum arquivo a alguém, reproduzir um problema. Ou uma tarefa complexa, mas sem esperança de conclusão — apenas para que o novato possa encontrar dificuldades. Ou uma tarefa importante, mas experimental. Por exemplo, um projeto que todos já querem, mas não conseguem encontrar tempo para implementar.

As tarefas de domínio das ferramentas serão "complexas" e artificiais. Muito provavelmente, será uma versão simplificada do sistema principal. Tais tarefas usam a mesma pilha de tecnologias e os mesmos termos do setor utilizados em todo o projeto. Neste caso, o resultado do trabalho não será entregue ao usuário final. Isso pode desmotivar, mas é melhor resistir a esse sentimento. A tarefa artificial deve ser executada de maneira diligente, como se o destino do projeto dependesse dela.

O resultado da resolução da sua primeira tarefa fará uma primeira impressão sobre você entre os colegas que não estiveram na entrevista.

Outra opção de tarefa para aprender as ferramentas é "executar um projeto na máquina local/ambiente de teste". Às vezes, esse processo está descrito em um guia. Mas eles geralmente estão desatualizados em algumas partes. Você pode trazer um benefício real ao projeto se escrever um novo guia com esclarecimentos sobre os problemas que surgiram. Com certeza, na universidade você teve que escrever um PGR para um relatório de alguma disciplina. Aqui é quase a mesma coisa. O documento deve refletir as ações que precisam ser realizadas para a execução.

Normalmente, as ações para executar o produto no ambiente de teste são aproximadamente as seguintes:

clonar o repositório, mudar para algum branch ou tag
preparar algum arquivo de configuração
preparar a estrutura do banco de dados
preenchê-lo com dados de teste
realizar a construção ou compilação do projeto,
executar um conjunto de scripts de console em uma sequência específica

Durante o processo de execução do sistema localmente, inevitavelmente surgirão problemas imprevistos.

As soluções para os problemas encontrados devem ser acrescentadas ao guia de implantação. Assim, na próxima vez que você seguir o guia, esses problemas não surgirão mais. Ao preencher os arquivos de configuração e chamar os scripts, você deve prestar atenção em qual valor é usado e com o que ele deve coincidir. Por exemplo, se o projeto é construído usando um sistema CI e depois executado por um script, é importante entender onde escrever o nome do branch ou o número do commit. Às vezes, o script implica a transmissão endereços IP ou dos nomes DNS do banco de dados, seu login e senha. Nesse caso, é necessário saber qual endereço usar para o ambiente de teste, quais logins existem lá e quais senhas precisam ser especificadas.

Algumas tarefas podem parecer simples para desenvolvedores experientes e causar dificuldades aos estagiários. Isso é normal.

Os desenvolvedores enfrentam problemas técnicos todos os dias. Funcionários experientes já resolveram muitos problemas antes, enquanto os novatos ainda precisam lidar com eles. A melhor tática é registrar todos os erros encontrados no documento "solução de problemas com ${nome da tarefa}". Para cada problema, é necessário formular uma hipótese sobre a causa, encontrar opções de solução na internet e testá-las uma a uma. O resultado de cada tentativa também deve ser documentado.

Apresentar suas descobertas em forma de documento permitirá:

liberar a mente de detalhes pequenos. Por exemplo, parâmetros de configuração, endereços DNS/IP, comandos de console e consultas SQL.
lembrar "o que eu fiz ontem" quando a tarefa se estende por vários dias.
não andar em círculos. Você sempre poderá reler o que fez antes e entender que está de volta ao problema original.
responder claramente à pergunta: "o que você fez hoje?" mesmo que ainda não haja uma solução pronta.

Você precisa saber como relatar o status de suas tarefas aos colegas.

Periodicamente, os colegas vão perguntar sobre seus progressos e compartilhar os deles. Para isso, dedica-se um tempinho diariamente ou semanalmente.

Se você não rastrear os problemas encontrados e resolvidos, a descrição de seus sucessos parecerá: "Eu tentei fazer a tarefa, mas não consegui. Estou procurando uma solução." Dessa narrativa, não está claro se o estagiário fez algo ou apenas estava lendo no Habr. Ele precisa de ajuda? A situação mudou desde ontem?

Se você mantiver um documento com a busca de soluções, poderá dizer: "Estou tentando fazer esta tarefa. Encontrei esses erros. Resolvi alguns assim. Este ainda não consegui resolver. Tenho estas hipóteses e opções de solução. Agora estou testando elas."

Se a tarefa pode ser medida de alguma forma, o status deve incluir números. Por exemplo, para a tarefa "escrever testes de unidade para o módulo", você pode dizer: "planejo fazer 20 testes, agora escrevi 10."

Quanto mais detalhes você fornecer, melhor seus colegas entenderão o que você fez. Isso criará uma percepção positiva em relação a você e permitirá que eles saibam se você precisa de ajuda ou não.

Não hesite em pedir ajuda.

Como mencionei acima, ao encontrar um problema, você precisa formular uma hipótese sobre suas causas e soluções possíveis. No entanto, às vezes as hipóteses não se confirmam e as soluções que você encontrou por conta própria não funcionam. Nesse caso, é melhor pedir ajuda. Para não sobrecarregar a atenção dos colegas, é preciso refletir sobre cada problema sozinho. Se após algumas horas não conseguir encontrar uma solução, é hora de buscar conselhos de colegas mais experientes.

O melhor é começar com a pergunta: "alguém já enfrentou esse problema antes?" com uma breve descrição do mesmo. É recomendável anexar uma captura de tela ou uma parte da mensagem de erro. Esse primeiro aviso deve ser direcionado a algum chat geral de trabalho. Assim, você não interrompe aqueles que realmente estão ocupados. Colegas disponíveis verão sua mensagem e poderão ajudar.

Se ninguém ajudou após a mensagem no chat geral, tente encontrar um colega experiente durante um intervalo: almoço, pausa para chá/cafeteira, em uma partida de tênis ou durante um cigarro. Se isso não for possível, informe sobre suas dificuldades na reunião ou no stand-up.

Ao resolver problemas conhecidos, isso pode ser tudo. Mas se o problema for novo, uma investigação começará, onde você terá que agir de acordo com as circunstâncias.

As tarefas "importantes" para novatos, que são essenciais para o usuário final, serão pequenas e tediosas. Por exemplo, "adicionar uma coluna extra ao relatório" ou "corrigir um erro de digitação no formulário impresso" ou "implementar um método no modelo para carregar atributos do cliente do SGBD". O objetivo dessas tarefas é familiarizar o novato com o domínio e integrá-lo ao trabalho diário.

É importante não apenas resolver a tarefa tecnicamente, mas também expandir o conhecimento da área.

Na descrição da tarefa, nos chats e conversas, você encontrará termos. Eles podem parecer substantivos familiares. No entanto, dentro do sistema de informação, adquirem um significado específico e mais preciso. O ideal é registrar os termos encontrados em um documento especial — um dicionário de termos. Ao adicionar um termo ao dicionário, basta anotar sua compreensão da palavra; para uma definição precisa, é melhor consultar um analista. Se não houver analista, consulte os veteranos do projeto. Manter um dicionário de termos é uma das maneiras mais simples de se familiarizar com a área do projeto.

Assim que você encontrar uma boa comunicação com os colegas, eles começarão a vê-lo não como um estagiário iniciante, mas como um especialista igual a eles.

Existem tarefas específicas, como "escrever testes unitários para um módulo". Você dificilmente ficará preso a essa tarefa por muito tempo procurando soluções. No entanto, é uma tarefa bastante séria e não é destinada apenas ao aprendizado do estagiário. Os testes escritos aumentam a estabilidade do projeto, reduzindo bugs na aplicação e diminuindo o tempo de teste realizado por humanos. No mundo ideal, os testes unitários são escritos durante o desenvolvimento, mas a realidade costuma ser diferente. Às vezes, o desenvolvedor do módulo mantém tudo na cabeça e não vê necessidade de escrevê-los. "É tudo tão óbvio, o que precisa ser testado aqui?" Às vezes, os módulos são desenvolvidos de forma apressada e não há tempo para os testes unitários. Portanto, na prática, pode não haver testes unitários. Por isso, a tarefa de escrever testes unitários é delegada ao novato. Assim, o estagiário pode se familiarizar mais rapidamente com o projeto, enquanto o projeto economiza tempo dos especialistas mais bem remunerados.

Às vezes, estagiários e novatos recebem a função de testadores plenos. Normalmente, antes disso, é necessário implantar o produto localmente e ler os requisitos. Como resultado, espera-se que o novo funcionário apresente:

perguntas como "se eu fizer assim, então assim ocorrerá. Isso não está nos requisitos. Como deve ser?"
tarefas no rastreador de bugs como "nos requisitos está escrito assim, mas na prática é diferente".

Atestagem é uma área excessivamente ampla para este artigo. Se você recebeu uma tarefa assim, procure na internet como executá-la da melhor maneira.

Se você errar — será dispensado.

Em uma organização normal, se um funcionário inexperiente tiver acesso a algo crítico e estragar, a culpa será de quem permitiu isso. Porque, por padrão, um novato não tem acesso à infraestrutura crítica. Com uma liderança adequada, não se deve culpar o estagiário inexperiente.

Se algo acontecer, não se demitirá alguém por um único incidente. As pessoas aprendem com os erros. O estagiário que cometeu um erro aprendeu uma valiosa lição e isso o diferencia muito de outros estagiários. Se demitirem aquele que errou, outro ocupará seu lugar e cometerá o mesmo erro.

O principal é aprender com os erros e não repeti-los.

Se uma pessoa não aprende com seus erros, então tentarão se despedir dela. No entanto, o mundo é diverso. Em uma organização criminosa, poderiam te jogar pela janela ao primeiro erro. Mas é melhor evitar essas empresas, para isso, faça uma pesquisa ou descubra mais durante a entrevista.

É melhor não permitir incidentes.

Mesmo que você pessoalmente não seja demitido por um erro, tal incidente causará problemas indesejados à sua equipe e ao projeto como um todo. Portanto, tenha cuidado especial com operações de exclusão ou criação de tabelas em bancos de dados, arquivos, instâncias de serviços e documentos na base de conhecimento do projeto. Se encontrar um endereço de nova conexão, confirme com pelo menos duas pessoas diferentes o que pode ser feito ali. Verifique seus direitos nos ambientes, não por tentativa e erro, mas por comandos apropriados. Por exemplo, verifique os direitos para excluir arquivos com o comando `ls`, os direitos para trabalhar com tabelas no MySQL com o comando `SHOW GRANTS FOR 'user'@'host';` e assim por diante. Em praticamente qualquer ferramenta, você terá essa possibilidade.

Ao editar arquivos, salve uma cópia do original, por precaução.

Entre o estagiário e o consumidor final, são criadas várias barreiras.

Se você pudesse entregar seu produto diretamente ao consumidor, poderia não precisar se empregar e navegar em "navegação livre". Mas enquanto você não tem essa capacidade (e também responsabilidade), precisará passar por várias etapas de controle no projeto.
A primeira delas é a avaliação do mentor. Ele analisa a solução do novato do ponto de vista técnico. Se o mentor não foi designado, é necessário encontrá-lo. Para isso, escolha alguém entre os veteranos do projeto e, durante o intervalo, peça que dê uma olhada na solução: a tarefa foi resolvida corretamente? Se ele começar a olhar e responder, significa que o mentor foi encontrado. Se ignorá-lo, vale a pena perguntar a alguém mais.

A próxima fase é a Garantia de Qualidade. Em português, são os testadores. No passado, eram chamados de controle de qualidade e OTK. Eles devem garantir que o resultado do trabalho do estagiário corresponde à tarefa definida para ele. Raramente prestarão atenção ao código. Na maioria das vezes, os testadores verificarão o projeto compilado que o desenvolvedor salva no sistema de controle de versões.

A terceira fase é o gerente de lançamento. Pode não haver uma pessoa dedicada a essa tarefa, mas alguém desempenhará esse papel. Ele verifica se os testadores confirmaram que o projeto pode ser lançado. Depois disso, ele realiza as ações de entrega do produto aos usuários finais.
Em pequenas organizações, essas barreiras podem não existir por diversos motivos. No entanto, eles não darão ao novato uma tarefa para modificar algo importante. Porque esse risco não é desejável para ninguém.

É preciso primeiro entrar na luta, e então veremos.
Napoleão Bonaparte

Espero que o artigo ajude você a superar a insegurança e enviar seu primeiro currículo. Claro, você deve se preparar primeiro. Mas não demore demais. Você provavelmente já passou alguns anos na universidade ou no colegial. Até onde você pode ir? Afinal, é melhor ouvir um "não" de um especialista uma vez e aprender com os erros do que dizer "não" a si mesmo todos os dias e estagnar no crescimento profissional.

Após ser contratado, você deve se concentrar em crescer de estagiário para membro pleno da equipe. Esse tipo de crescimento geralmente é acompanhado de um aumento em sua remuneração.

Desejo paciência e persistência.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.