Livrar-se do medo do primeiro emprego

Quadro do filme “Harry Potter e o Prisioneiro de Azkaban”

O problema deste mundo é que as pessoas instruídas estão cheias de dúvidas, mas os idiotas estão cheios de confiança.

Charles Bukowski

Recentemente dei outra aula individual de programação. Diferentemente das aulas regulares, o tema não era construção de linguagem ou resolução de problemas. O estudante compartilhou suas preocupações sobre o futuro emprego. O próprio aluno era bastante inteligente. Quem vem ao curso completa todo o programa mais rápido do que qualquer outro e com soluções originais, mas sempre se subestima sinceramente. Na minha opinião, tais dúvidas surgem apenas por falta de informação. Tentei preencher essa lacuna de improviso durante a aula.

As perguntas eram mais ou menos assim:

• Todos os anos, muitos estudantes se formam nas universidades e todos procuram trabalho. Isso é muita gente. Provavelmente contratarão os melhores, mas não conseguirei uma vaga.
• E se eu errar e for demitido imediatamente?
• E se no processo de trabalho eles perceberem que sou estúpido e me expulsarem?

Este aluno não foi a primeira pessoa a quem respondi a essas perguntas. Muitas pessoas os têm e geralmente precisam ser informados sem preparação. Desta vez resolvi anotar meu monólogo em um caderno. Achei que seriam alguns parágrafos, mas acabou sendo suficiente para um artigo inteiro.

O artigo descreve a visão do meu ponto de vista e com base na minha experiência. No entanto, nosso mundo é muito diversificado e coisas incríveis acontecem nele. Se você discorda de algo ou sua experiência é diferente, escreva um comentário.

O artigo foi escrito por um desenvolvedor para desenvolvedores. No entanto, se você planeja fazer testes, administração ou qualquer outra coisa em TI, alguns conselhos também serão úteis para você.

Eles não vão contratar você de jeito nenhum

Quando você imagina que muitas universidades formam centenas de alunos todos os anos, fica desconfortável. Como competir com uma multidão tão grande?

Infelizmente, nem todos os graduados possuem formação técnica suficiente. Experimente perguntar a algum estudante universitário que você conhece: como as pessoas do grupo dele conseguem admissão em exames em disciplinas como “bancos de dados” ou “fundamentos de algoritmização e programação”? Em um grupo de 30 pessoas, na melhor das hipóteses, haverá de 3 a 5 caras “avançados” que realmente fizeram tudo sozinhos. O restante simplesmente copia deles, preenche as respostas às perguntas e envia.

Foi assim quando estudei sozinho. No entanto, minha experiência pode não ser representativa. Então fiz essa pergunta a vários alunos diferentes. A resposta foi praticamente a mesma. Os entrevistados eram de diferentes universidades e faculdades. Deixarei discussões sobre os motivos fora do escopo deste artigo. Não tenho tempo suficiente para um estudo completo, por isso tirarei uma conclusão a partir dos fatos disponíveis.

Entre centenas de graduados, apenas algumas dúzias são de interesse dos empregadores

Poucos graduados podem oferecer uma competição real para um aluno capaz e com boa preparação. Porém, mesmo que você tenha estudado com atenção, após a primeira entrevista provavelmente não será contratado. Depois do segundo, provavelmente também. Tudo pode dar certo, mas é melhor se preparar não para um ataque, mas para um cerco. Uma tentativa malsucedida de conseguir um emprego é apenas um motivo para corrigir seus erros e tentar novamente. Não vou falar sobre preparação para entrevistas. Muito já foi escrito sobre esse assunto na Internet. Direi apenas que há nuances nas entrevistas que seu programa de treinamento provavelmente não terá tempo para explicar. Procure você mesmo essas informações, pois isso pode reduzir o número de tentativas.

A loucura é a repetição exata da mesma ação. Vez após vez, esperando por mudança

Albert Einstein

Para evitar que as entrevistas se tornem uma loucura, você precisa melhorar a cada nova tentativa. Memorize ou anote as perguntas que lhe foram feitas durante a entrevista. Ao voltar para casa, dê uma olhada nesta lista e verifique você mesmo usando a Internet. Assim você entenderá onde você e o entrevistador cometeram um erro. Isso também acontece. Revise ou estude os tópicos nos quais você teve um desempenho ruim e tente novamente.

Além disso, existe uma acentuada sazonalidade do mercado de trabalho. Empresas inteligentes planejam contratações com base nas datas de formatura. Há mais vagas para recém-chegados na primavera do que em outras épocas. No entanto, a concorrência é maior neste momento.

Estúpido - seja demitido

Quando uma pessoa sem experiência é contratada, existem expectativas correspondentes para ela.

Espera-se que um recém-chegado ao trabalho:

• Conhecimento de base técnica geral
• Estudando as especificidades da área temática da empresa
• Dominar as ferramentas e práticas utilizadas

Algumas organizações oferecem cursos de formação para recém-chegados sobre as tecnologias, ferramentas e procedimentos locais utilizados. Por exemplo, boas maneiras ao usar e-mail corporativo, procedimento para alterar documentos em um wiki, recursos locais para trabalhar com VCS e um rastreador de bugs.

Existem também cursos técnicos introdutórios, mas sua utilidade é questionável. Se se trata de emprego, os empregadores estão convencidos de que você possui um nível de conhecimento suficiente. É melhor simplesmente fazer esses cursos de boa fé, como uma pequena formalidade. Talvez haja realmente algo útil neles.

Ao começar a trabalhar, lembre-se que definitivamente não será confiado a um iniciante a solução de uma tarefa urgente, complexa e ao mesmo tempo importante. Muito provavelmente haverá apenas uma dessas propriedades. Ou simples, mas urgente: consertar o layout, enviar um arquivo para alguém, reproduzir o problema. Ou difícil, mas sem esperança de conclusão - para que o iniciante colete mais rake. Ou importante, mas experimental. Por exemplo, um projeto que todos desejam há muito tempo, mas não encontram tempo para implementar.

As tarefas de domínio das ferramentas serão “difíceis” e artificiais. Muito provavelmente esta será uma versão simplificada do sistema principal. Essas tarefas usam a mesma pilha de tecnologia e os mesmos termos de domínio de todo o projeto. Neste caso, o resultado da execução não será fornecido ao usuário final. Isto pode ser desmotivador, mas é melhor resistir a este sentimento. Uma tarefa artificial deve ser realizada com consciência, como se disso dependesse o destino do projeto.

O resultado da resolução do seu primeiro problema formará a sua primeira impressão entre os colegas que não estiveram presentes na entrevista.

Outra opção para a tarefa de domínio da ferramenta é “executar o projeto em uma máquina local/ambiente de teste”. Às vezes, esse processo é descrito nas instruções. Mas geralmente são antigos e, em alguns lugares, desatualizados. Você pode trazer benefícios reais ao projeto se escrever novas instruções com esclarecimentos sobre os problemas surgidos. Certamente na universidade você tinha que escrever um RGR para um relatório sobre algumas disciplinas. É quase a mesma coisa aqui. O documento deve refletir as ações que precisam ser realizadas para o lançamento.

Normalmente, as etapas para executar um produto em um ambiente de teste são mais ou menos assim:

• clonar um repositório, mudar para algum branch ou tag
• crie algum arquivo de configuração
• preparar a estrutura do banco de dados
• preencha-o com dados de teste
• construir ou compilar o projeto,
• execute um conjunto de scripts de console em uma determinada sequência

Durante o processo de execução local de um sistema, surgirão inevitavelmente problemas inesperados.

As soluções encontradas para os problemas devem ser adicionadas às instruções de implantação. Então, da próxima vez que você seguir as instruções, esses problemas não surgirão mais. Ao preencher arquivos de configuração e chamar scripts, você precisa prestar atenção em qual valor é usado, onde e com o que deve corresponder. Por exemplo, se um projeto for montado usando um sistema CI e depois iniciado por um script, é importante entender onde escrever o nome do branch ou o número do commit. Acontece que o script envolve a transferência do endereço IP ou nome DNS do banco de dados, seu login e senha. Nesse caso, você precisa saber qual endereço usar para o ambiente de teste, quais logins existem e quais senhas você precisa especificar para eles.

Algumas tarefas podem parecer simples para desenvolvedores experientes, mas desafiadoras para estagiários. Isto é normal.

Os desenvolvedores precisam resolver problemas técnicos todos os dias. Funcionários experientes já resolveram muitos problemas antes, enquanto os recém-chegados ainda não conseguiram lidar com eles. A melhor tática é registrar todos os erros encontrados no documento “resolvendo problemas com ${nome da tarefa}”. Para cada problema, é necessário formular uma hipótese sobre a causa, encontrar soluções na Internet e experimentá-las uma a uma. O resultado de cada tentativa também deve ser registrado.

O registro de sua pesquisa em forma de documento permitirá:

• descarregue pequenos detalhes da sua cabeça. Por exemplo, parâmetros de configuração, endereços DNS/IP, comandos de console e consultas SQL.
• lembre-se “o que eu fiz ontem” quando a tarefa durar vários dias
• não ande em círculos. Você sempre pode ler o que fez antes e entender que voltou ao problema original
• responda claramente à pergunta: “o que você fez hoje?” mesmo que ainda não exista uma solução pronta.

Você precisa ser capaz de comunicar o status de suas tarefas aos colegas

De tempos em tempos, os colegas estarão interessados ​​em seus sucessos e compartilharão os deles. Reserve algum tempo para isso diariamente ou semanalmente.

Se você não acompanhar os problemas encontrados e resolvidos, a descrição de seus sucessos será semelhante a: “Tentei fazer a tarefa, mas não consegui. Ainda estou procurando uma solução.” A partir desta história não fica claro se o estagiário estava fazendo alguma coisa ou apenas sentado e lendo. Ele precisa de ajuda? A situação mudou desde ontem?

Se você mantiver um documento procurando soluções, poderá dizer “Estou tentando fazer esta tarefa. Eu tive erros como esse. Foi assim que decidi. Eu não lidei com isso ainda. Existem essas hipóteses e soluções. Estou verificando-os agora."

Se a tarefa puder ser medida de alguma forma, o status deverá conter números. Por exemplo, para a tarefa “escrever testes unitários para um módulo”, você pode dizer “Pretendo fazer 20 testes, agora escrevi 10”.

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

Sinta-se à vontade para pedir ajuda

Escrevi acima que quando surge um problema, é necessário formular uma hipótese sobre suas causas e possíveis soluções. No entanto, acontece que as hipóteses não são justificadas e as soluções encontradas de forma independente para o problema não funcionam. Neste caso, é melhor pedir ajuda. Para não abusar da atenção de seus colegas, você precisa resolver cada problema sozinho. Se você não conseguiu encontrar uma solução em algumas horas, é hora de procurar o conselho de camaradas mais experientes.

Um bom lugar para começar é perguntar: “alguém já encontrou esse problema antes?” com uma breve descrição do problema. É aconselhável anexar um trecho da mensagem de erro ou uma captura de tela. É melhor enviar esta mensagem pela primeira vez para algum chat geral de trabalho. Dessa forma você não distrai quem está realmente ocupado do trabalho. Colegas gratuitos verão sua mensagem e poderão ajudar.

Se depois de uma mensagem no chat geral ninguém ajudou, tente conversar com um colega experiente no intervalo: almoço, chá/café, partida de tênis ou pausa para fumar. Se não der certo, relate suas dificuldades na reunião ou stand-up.

Se os problemas conhecidos forem resolvidos, tudo isso pode acabar aí. Se o problema for novo, será iniciada uma investigação, onde será necessário atuar de acordo com as circunstâncias.

As tarefas “importantes” para iniciantes que o usuário final precisa serão chatas e pequenas. Por exemplo, “adicionar uma coluna adicional ao relatório” ou “corrigir um erro de digitação no formulário impresso” ou “implementar um método modelo para carregar atributos do cliente do SGBD”. O objetivo de tais tarefas é que o iniciante se familiarize com a área temática e se integre ao trabalho diário.

É importante não apenas resolver tecnicamente o problema, mas também ampliar o conhecimento da área temática.

Os termos aparecerão na descrição da tarefa, em chats e conversas. Eles podem parecer substantivos familiares. No entanto, no quadro do sistema de informação, têm um significado especial e mais preciso. O significado dos termos descobertos é melhor registrado em um documento especial - um dicionário de termos. Ao adicionar ao dicionário, basta escrever o seu entendimento da palavra, mas para uma decodificação real é melhor entrar em contato com um analista. Se estiver faltando, vá para os veteranos do projeto. Manter um dicionário de termos é uma das maneiras mais simples de se familiarizar com a área temática de um projeto.

Depois de encontrar uma linguagem comum com seus colegas, eles começarão a vê-lo não como um novo estagiário, mas como um especialista igual.

Existem tarefas especiais, por exemplo, “escrever testes unitários para um módulo”. Dificilmente você poderá ficar preso nisso por muito tempo procurando soluções. Ao mesmo tempo, é bastante sério e não se destina apenas à formação de formandos. Os testes escritos aumentam a estabilidade do projeto, reduzindo bugs na aplicação e reduzindo o tempo para testes humanos. Em um mundo ideal, os testes unitários são escritos imediatamente durante o desenvolvimento, mas a realidade é sempre diferente. Acontece que o desenvolvedor de um módulo o mantém completamente na cabeça e não vê necessidade de escrevê-los. “Tudo é óbvio, o que há para testar?” Às vezes, os módulos são escritos em modo rush e não sobra tempo para testes de unidade. Portanto, no mundo real pode não haver testes unitários. Portanto, a tarefa de escrever testes unitários é atribuída a um iniciante. Dessa forma, o estagiário poderá se acostumar com o projeto com mais rapidez, e o projeto poderá economizar o tempo dos especialistas mais bem remunerados.

Acontece que estagiários e recém-chegados recebem o papel de testadores completos. Normalmente, antes de fazer isso, você precisa implantar o produto localmente e ler os requisitos. Como resultado, espera-se que o novo funcionário:

• perguntas como “se você fizer assim, vai acabar assim. Isso não está nos requisitos. Deveria ser?"
• tarefas no rastreador de bugs “os requisitos dizem isso, mas na realidade está escrito de forma diferente”.

O teste é uma área muito ampla para este artigo. Se você receber uma tarefa semelhante, pesquise na Internet a melhor maneira de concluí-la.

Se você errar, você será demitido

Em uma organização normal, se de repente um funcionário inexperiente tiver acesso a algo crítico e estragar alguma coisa, a culpa será de quem permitiu que isso acontecesse. Porque um iniciante, por padrão, não tem acesso à infraestrutura crítica. Com orientação adequada, eles não permitirão que todos os cães sejam desperdiçados com um estagiário inexperiente.

Se algo acontecer, eles não irão demiti-lo por causa de um incidente. As pessoas aprendem com os erros. O estagiário que errou aprendeu uma lição valiosa e é muito diferente dos demais estagiários. Se você demitir alguém que erra, outra pessoa entrará em seu lugar e errará da mesma forma.

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

Se uma pessoa não tirar conclusões de seus erros, tentará dizer adeus a ela. No entanto, o mundo é diverso. Em alguma organização de gângsteres, eles podem imediatamente jogá-lo pela janela pelo primeiro erro. Mas é melhor evitar essas empresas perguntando primeiro ou descobrindo mais durante a entrevista.

É melhor evitar incidentes

Mesmo que você pessoalmente não seja demitido por um erro, tal incidente causará problemas indesejados para sua equipe e para o projeto como um todo. Portanto, tenha especial cuidado com as operações de exclusão ou criação de tabelas no banco de dados, arquivos, instâncias de serviço e documentos na base de conhecimento do projeto. Caso você se depare com o endereço de uma nova conexão, verifique com pelo menos duas pessoas diferentes o que pode ser feito ali. Verifique seus direitos nos ambientes não por tentativa e erro, mas usando os comandos apropriados. Por exemplo, direitos para excluir arquivos usando o comando `ls`, direitos para trabalhar com tabelas no mysql usando o comando `SHOW GRANTS FOR 'user'@'host';` e similares. Em quase todas as ferramentas você terá uma oportunidade semelhante.

Ao editar arquivos, guarde uma cópia do original para você, apenas por precaução.

Várias barreiras são construídas entre o estagiário e o usuário final.

Se você pudesse entregar imediatamente seu produto ao consumidor, você não conseguiria um emprego, mas sim partiria para um “nadar grátis”. Mas até que você tenha essa oportunidade (e ao mesmo tempo responsabilidade), você precisa passar por várias etapas de controle do projeto.
A primeira delas é a verificação por um mentor. Ele avalia a decisão do novato do ponto de vista técnico. Se um mentor não tiver sido designado, você precisará encontrar um. Para isso, você precisa escolher um dos veteranos do projeto e no intervalo pedir que ele veja a solução: o problema foi resolvido corretamente? Se ele começar a procurar e responder, então um mentor foi encontrado. Se ele ignorar, vale a pena perguntar a outra pessoa.

A próxima etapa é a Garantia de Qualidade. Em russo - testadores. No estilo soviético - departamento de controle padrão e controle de qualidade. Devem garantir que o desempenho do formando é consistente com a tarefa que lhe foi atribuída. Eles raramente lerão o código. Na maioria das vezes, os testadores verificarão o projeto construído, que o desenvolvedor armazena no sistema de controle de versão.

A terceira etapa é o gerenciador de lançamento. Pode não haver uma pessoa separada para esta tarefa, mas alguém ainda desempenha o papel. Ele verifica se os testadores confirmaram que o projeto pode ser lançado. Depois disso, realiza as atividades de entrega do produto aos usuários finais.
Nas pequenas organizações, estas barreiras podem não existir por vários motivos. No entanto, eles não darão a um novato a tarefa de mudar algo importante. Porque ninguém precisa desse risco.

Você precisa se envolver na batalha primeiro e depois veremos.
Napoleão Bonaparte

Espero que este artigo o ajude a superar suas incertezas e enviar seu primeiro currículo. Claro, você deve se preparar primeiro. Mas não há necessidade de exagerar. Provavelmente você já estudou em uma universidade ou faculdade há vários anos. Para onde ir a seguir? Afinal, é melhor ouvir “não” uma vez de um especialista e corrigir os erros do que dizer “não” para si mesmo todos os dias e parar de crescer profissionalmente.

Uma vez contratado, você precisa se concentrar em passar de estagiário a membro pleno da equipe. Esse tipo de crescimento geralmente vem com um aumento no seu salário.

Desejo-lhe paciência e perseverança.

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Quais foram suas primeiras tarefas em seu primeiro emprego em TI?

• Complexo

• Importante

• Urgente

• Nenhuma das acima

75 usuários votaram. 20 usuários se abstiveram.

O que você teve que fazer no primeiro emprego?

• Instale o produto localmente

• Teste um produto existente

• Realize um treinamento, tarefa falsa

• Faça um projeto experimental e real para um cliente

63 usuários votaram. 25 usuários se abstiveram.

Quantos alunos do seu grupo conseguiram realizar tarefas de forma independente em disciplinas técnicas durante o treinamento?

• 1 de 10

• 1 de 5

• Todo segundo

• Tudo, com raras exceções

70 usuários votaram. 19 usuários se abstiveram.

Fonte: habr.com