Como passei de novato a engenheiro de software em nove meses trabalhando em tempo integral

Artigo original: How I Went from Newbie to Software Engineer in 9 Months While Working Full Time

Neste artigo, vou compartilhar como passei do quase zero para uma oferta de trabalho como engenheiro de software em nove meses, com um salário acima dos 100 mil dólares ao ano, mesmo trabalhando em tempo integral e sendo autodidata.

Sempre que eu começava a ler uma história de sucesso, eu procurava imediatamente o histórico do autor, esperando que coincidisse com o meu. Nunca encontrei alguém que tivesse o mesmo histórico que eu e, muito provavelmente, o meu não corresponderia exatamente ao seu.

No entanto, espero que minha história inspire outros e atue como uma fonte de informação valiosa, que possa ser adicionada aos seus dados sobre histórias de sucesso.

Para fins de transparência completa

Eu fiz um curso de Visual Basic for Applications (VBA) no ensino médio (há nove anos). Em meu curso de engenharia para calouros (há sete anos), aprendi um pouco de C, Python, Matlab e Labview. Eu me formei em uma boa universidade com um diploma de engenharia química e uma boa média geral (há três anos). Eu não havia feito programação fora da escola, no ensino médio ou na faculdade até que decidi que queria aprender no ano passado.

Depois da faculdade, consegui um emprego como Engenheiro de Processos em uma refinaria. Trabalhei lá até mudar de carreira para Engenharia de Software.

Por que eu quis mudar de carreira

Eu gostava de resolver problemas técnicos, mas sabia que, em algum momento, eu queria entrar no mundo dos negócios/criação de empresas. Sempre tive a ideia de um MBA no fundo da minha mente, mas toda vez que olhava para os valores das melhores escolas, meu interesse diminuía.

Em 27 de maio de 2017, eu me encontrei novamente pesquisando no Google sobre MBAs. De algum modo, eu achei por acaso a engenharia de software. Parecia um ajuste perfeito.

Os engenheiros de software estão em demanda crescente, os salários são ótimos e é o setor perfeito para se entrar sem precisar de muito capital inicial. Tudo o que você precisa é de um computador e suas oportunidades são ilimitadas (mais ou menos).

Em nenhuma outra área da engenharia você pode simplesmente ter uma ideia, começar a construí-la, mostrá-la aos usuários e ir desenvolvendo aos poucos, com pouco capital e com baixas dificuldades de início. Na engenharia química, você precisa essencialmente de uma fábrica em funcionamento ou muito dinheiro para projetar uma fábrica se você tiver uma ideia para um novo produto.

Eu já tinha ouvido falar de pessoas que deixaram seus empregos e participaram de bootcamps, mas quanto mais eu lia sobre isso on-line, mais eu percebia que você pode aprender tudo por conta própria, desde que esteja comprometido e focado.

Você pode argumentar que está perdendo a rede de contatos e conselhos de carreira fornecidos por um bootcamp. Isso pode ser verdade, mas eu tive a sorte de viver na Bay Area, o que me permitiu assistir a vários meetups (encontros de profissionais da área). Portanto, acabei fazendo meu networking desse modo.

No fim, na pior das situações, eu perceberia que não poderia fazer isso sozinho e, então, deixaria meu emprego para participar de um bootcamp.

O objetivo

Você precisa ter um objetivo, especialmente se estiver tentando aprender enquanto trabalha em tempo integral. É fácil deixar que seu aprendizado se arraste se você não tiver nenhuma pressão externa empurrando você. Portanto, é preciso criar uma pressão interna. Seu objetivo deve ser simples e quantitativo. Você deve fazer pesquisas o suficiente para chegar a um objetivo razoável. O meu foi o seguinte:

Obter um emprego em engenharia de software dentro de um ano com o mesmo salário ou com um salário melhor do que o que eu já estava ganhando naquele momento.

O plano

Quando você encontrar um objetivo, precisará de um plano para ajudá-lo a chegar lá. É aqui que você consome o máximo de histórias de sucesso que puder. Nenhuma delas corresponderá exatamente à sua situação, mas você pode aceitar alguns conselhos de cada uma delas. Eu desenvolvi (e criei várias versões do) meu plano usando recursos como o subreddit de aprendizagem de programação, o fórum do freeCodeCamp e o Medium.

Em 27 de maio de 2017, decidi que começaria a programar e mergulhei de cabeça. Naquele dia, decidi começar a dedicar no máximo 40 horas por semana ao meu trabalho da época para que eu tivesse tempo de programar depois do trabalho e nos fins de semana. Felizmente para vocês, fiz um trabalho muito bom documentando meu progresso.

Meu plano, após muitas versões, acabou parecendo algo assim:

1. Fazer um curso de Introdução à Ciência da Computação para obter uma base sólida de compreensão dos conceitos centrais da computação
2. Seguir o currículo do freeCodeCamp até o momento em que eu pudesse criar por conta própria aplicações para a web em full-stack que fossem adequados a um portfólio
3. Refatorar meu código para deixá-lo limpo, adicionar testes, focar em conceitos avançados
4. Contribuir com o código aberto
5. Realizar minha preparação para entrevistas de trabalho

Para iniciar, meu plano era simples. Na época, pensei em seguir o Guia Técnico do Google. Então, comecei com o curso introdutório recomendado, a Introdução à Ciência da Computação, da Udacity.

Mês 0 - Introdução à Ciência da Computação, da Udacity, e CS50 de Harvard

O ponto alto de tomar essa grande decisão me deu muita energia. Eu começava a programar assim que chegava do trabalho e não parava até ir para a cama. Depois, novamente, programava durante todo o fim de semana. O curso de Introdução à Ciência da Computação, da Udacity, acompanhava o percentual de conclusão, o que foi um grande motivador para mim. Eu registrava minha porcentagem de finalização todos os dias após programar. Terminei os primeiros 75% em 10 dias. Os últimos 25% eram pesados e envolviam recursão. Foi um pouco mais difícil para mim. No total, levei 20 dias para terminar o curso da Udacity.

Enquanto eu fazia o curso da Udacity, havia começado a ler o subreddit de aprendizagem de programação enlouquecidamente. Li que era importante para os desenvolvedores autodidatas, que procuravam fazer uma mudança de carreira, estarem ativos on-line. Decidi fazer novas contas no Twitter, Reddit, Stack Overflow, Medium e Quora usando meu nome completo, para que eu pudesse construir uma presença on-line.

Além disso, decidi parar de ler mídias que distraem, como Instagram, Facebook e subreddits não relativos à programação. Eu só verificava meu telefone para saber das notícias e ver publicações relacionadas à programação. Isso foi crucial para ter certeza de que eu estava descobrindo os melhores caminhos e recursos de aprendizagem. Foi por causa disso que descobri o CS50 de Harvard no edX.

Eu estava, de início, satisfeito em fazer apenas um curso introdutório, mas todos pareciam recomendar o CS50. Assim, decidi mergulhar nisso também. Os estudantes de Ciência da Computação de outras áreas haviam feito esse curso e disseram que aprenderam mais no CS50 do que em um ou dois anos em suas universidades estudando Ciência da Computação. O consenso geral era de que o curso era difícil, mas que valia a pena. No final do mês 0, eu havia concluído as primeiras cinco palestras e tarefas de casa.

Mês 1 - CS50 de Harvard, Linux, 1º meetup, freeCodeCamp

Eu completei o CS50 em torno do meio do mês 1. Não vou comentar muito sobre minha experiência com o CS50, porque escrevi aqui um artigo detalhado sobre a minha experiência nele aqui (texto em inglês).

Versão resumida: é um ótimo curso, eu o recomendo demais. O David Malan é um excelente palestrante e há milhares de recursos para ajudá-lo a concluir. Você começa com C, passa por Python e termina com o desenvolvimento para a web. É muito denso e há muito material, mas acho que vale a pena.

Depois do CS50, decidi configurar o meu XPS 15 para dual boot de Windows e Ubuntu. Foi um fim de semana frustrante. Fiz uma bagunça nas minhas partições e quase estraguei o meu laptop. Eu estava perto de jogá-lo fora e comprar um novo.

Eu me afastei lentamente do Windows. No fim, estava usando apenas o Ubuntu. Eu queria me forçar a me sentir confortável com a linha de comando (algo que, na minha opinião, funcionou até certo ponto), mas ainda tenho um longo caminho a percorrer.

Comecei o desafio 100 Days of Code (100 dias de programação) para ter certeza de que ficaria focado e programando todos os dias. É importante documentar seu progresso. Se você está progredindo todos os dias, não vai parecer muito, mas quando olhar para trás, um mês ou vários meses depois, você perceberá que realmente fez bastante progresso, o que o motiva a continuar.

Eu sabia que o networking me ajudaria ou me desmotivaria por completo. Então, criei coragem para ir ao meu primeiro meetup de programação. Eu nunca havia participado de um meetup, muito menos de um meetup de programação. Eu estava tão nervoso que, depois de dirigir, estacionar e caminhar até a porta, quase dei meia volta e fui para casa.

O que ajudou foi o primeiro meetup do grupo. Percebi rapidamente que não havia razão para ficar nervoso. Ninguém se conhecia, ninguém estava julgando e todos estavam ansiosos para aprender. Este foi o início de uma série de encontros. Acabei frequentando mais de 50 encontros em 9 meses.

Estou feliz por ter começado a participar dos meetups cedo. A maioria das pessoas só começou a frequentar os meetups quando já estavam procurando emprego, mas, nesse ponto, é quase "tarde demais". Há tantas razões para começar mais cedo. Algumas que posso citar são:

1. Desenvolver relacionamentos leva muito tempo. Começar cedo significa que você tem conexões que podem atestar por você quando procurar um emprego mais tarde
2. Falar sobre programação com estranhos é uma ótima maneira de se preparar para entrevistas
3. Você pode aprender sobre novos frameworks, ferramentas e recursos de aprendizagem com as pessoas que estão à sua frente. Isso pode influenciar o seu plano de aprendizado futuro.

Eu tinha alguma incerteza naquele momento na minha jornada em programação. Ela era sobre o momento de precisar decidir que tipo de desenvolvedor de software eu queria ser.

Por fim, escolhi o desenvolvimento para a web, pois parecia haver uma alta demanda e também muitos recursos on-line. Quando percebi isso, eu precisei descobrir o que fazer a seguir. Algumas pessoas recomendaram que, nessa fase, eu pensasse em aplicações para a web que eu quisesse construir e, em seguida, começasse a trabalhar. Algumas pessoas recomendaram o Odin Project ou o freeCodeCamp.

O cara que estava apresentando o encontro semanal do qual eu estava participando conhecia Ruby e queria fazer projetos com Ruby. Essa foi uma grande razão pela qual eu tomei a decisão de participar do Odin Project.

Dois dias depois, eu abandonei essa ideia.

Essa é uma das desvantagens de seguir o caminho do autodidata. Em um minuto, você acha que sabe qual caminho deve seguir. No outro, você se pergunta se esse foi o passo certo.

Li que Ruby estava caindo em desuso e provei isso ao procurar empregos em Ruby e em JavaScript. Foi então que acabei iniciando o freeCodeCamp. A única coisa que me incomodava no freeCodeCamp era que eles tinham ideias para o projeto. Então, todo camper fazia os mesmos projetos. Isso me preocupou no início, porque eu queria me destacar para os recrutadores. No entanto, acabei amando o freeCodeCamp e agora eu o recomendo bastante. Para mais detalhes sobre minha experiência e recomendações a respeito do freeCodeCamp, confira meu artigo aqui (texto em inglês).

Mês 2 — You Don't Know JavaScript, front-end no freeCodeCamp, React

Comecei a ler You Don't Know JavaScript, porque todo mundo recomendava esse livro para complementar o freeCodeCamp. Tive que reler várias seções, pois é bastante denso, mas é um recurso perfeito para aprender o escopo léxico, closures, promises e todas as partes do JavaScript que você ouve falar e quer aprender, mas nunca o faz porque parecem difíceis.

Terminei a seção de front-end do freeCodeCamp. O formato de lista de verificação e o tempo estimado de conclusão ajudaram a me motivar a terminar rapidamente. Eu também estava ansioso para passar para a próxima seção e aprender React. No entanto, isso também significava que meus projetos tinham um estilo mínimo. Fiz o que foi necessário para cumprir as histórias de usuário e nada mais.

Em retrospectiva, talvez eu devesse ter me concentrado em tornar os projetos mais atraentes. Talvez isso me tivesse ajudado a aprender mais profundamente o CSS.

O passo seguinte foi aprender React. Eu fiquei bastante entusiasmado.

Eu tinha ouvido falar muito sobre ele e estava pronto para fazer parte da "turma dos conhecidos da escola". Entretanto, eu estava um pouco hesitante, dadas as questões de licenciamento na época. Estou realmente feliz que isso não seja mais um problema. Aprender o React foi difícil para mim. Eu não estava ciente de nenhum bom tutorial na época (parece que, agora, existem milhares deles).

Tentei ler a documentação e acompanhei com o tutorial do Jogo da Velha, do Facebook, mas não o entendi muito bem. Disseram-me que, se isso não estava funcionando para mim, significava que eu não entendia JavaScript o suficiente. Então, voltei a ler You Don't Know JavaScript, mas tudo continuava muito denso para mim.

Mês 3 - React no freeCodeCamp, CodeClub, início de back-end no freeCodeCamp

Por fim, decidi que trabalharia no meus projetos em React do freeCodeCamp para ver como era. O código era feio, mas me ajudou a entender um pouco melhor o React.

Aquele meetup do qual eu participava toda semana decidiu criar projetos com JavaScript em full-stack em vez de Ruby. Eles decidiram que o primeiro projeto seria construir um site para o grupo de encontros, o CodeClub.Social.

Desenvolvi cards usando o React e a API do Meetup, que permitiam que o usuário se inscrevesse para os próximos três meetups a partir do nosso site. Foi um pouco difícil fazer uma pausa rápida no freeCodeCamp para fazer isso, mas era uma oportunidade que eu não podia deixar passar. Fiquei feliz por estar trabalhando em um projeto com um pequeno grupo de pessoas. Isso também me ajudou a aprender Git e Github.

Antes do fim do mês, comecei a trabalhar na certificação de back-end do freeCodeCamp.

Mês 4 - Término do back-end do freeCodeCamp, Yeggle

Trabalhei em todos os projetos de API do FreeCodeCamp, mas comecei a me desviar de lá no projeto de camada de abstração de busca de imagens.

Estava ansioso para fazer aplicações de full-stack. Assim que vi o título desse projeto, tive uma ideia para um projeto próprio. Eu faria um aplicativo em Node que armazenaria URLs de imgur aleatórias em um banco de dados e depois faria um front-end que produziria um número especificado pelo usuário dessas imagens aleatórias. O que todos dizem é verdade: você trabalha mais e tem mais sucesso quando está trabalhando em um projeto que foi sua própria ideia.

Quando fiz o projeto funcionar, fiquei muito orgulhoso de mim mesmo. Era feio e desajeitado, mas funcionava.

Como eu estava fazendo o currículo inteiro do freeCodeCamp, estava aprendendo sobre quais projetos estariam dentro das minhas capacidades. Naquela época, eu estava correndo regularmente, de modo que eu tinha ideias durante as minhas corridas e as anotava quando chegava em casa. Desse modo, eu teria uma lista de ideias de projetos quando estivesse pronto.

Finalmente, senti que estava pronto para começar a fazer minhas próprias aplicações full-stack para a web, úteis e bem-feitas, para compartilhar com os usuários e colocá-las em meu portfólio. Eu estava pronto para começar.

Ao procurar um novo restaurante, eu sempre me via abrindo o Yelp para verificar as críticas e depois abria o Maps para verificar as críticas de lá. Se eu fizesse um aplicativo que comparasse as críticas de ambos, lado a lado, como seria?

Foi assim que eu criei o Yeggle. Usei Node/Express/React juntamente com as APIs do Google Maps e do Yelp. Havia alguns obstáculos que eu não achava que seria capaz de superar, mas, no final, terminei e fiquei muito orgulhoso da minha aplicação. Depois, coloquei-o no Reddit e ninguém se importou. Foi um pouco frustrante, mas não deixei que isso me derrubasse.

Mês 5 - StockIT

Não fiz muito durante esse mês, pois comecei o mês com duas semanas de férias do meu trabalho, no Japão e na Tailândia!

No entanto, comecei e completei meu próximo projeto. Eu continuava lendo sobre como era difícil conseguir um emprego como desenvolvedor autodidata. Então, eu achava que precisava fazer algo único. Lembrei-me de um jogo onde um gráfico de ações da Dow Jones começou a ser tendência e você tinha a oportunidade de comprar e vender. A meta era vencer o mercado. O objetivo do jogo era mostrar a você como era difícil vencer o mercado.

Minha ideia era fazer um jogo semelhante a esse, mas, ao invés do mercado, você estaria jogando contra um algoritmo de aprendizagem de máquina. Por isso, criei o StockIT.

Fiz um tutorial em vídeo sobre o Pandas e o Scikit Learn que cobriu diversas técnicas de aprendizagem de máquina. Originalmente, eu queria fazer algumas técnicas legais de aprendizagem profunda (Deep Learning, em inglês), mas percebi que isso exigia grandes conjuntos de dados e mais tempo do que eu queria gastar.

Em vez disso, eu me agarrei a um simples modelo de regressão linear. Pensei que essa seria a parte mais difícil, mas não foi. Conseguir fazer com que o D3 funcionasse com o React era a parte mais difícil. As duas bibliotecas queriam controlar o DOM. Algumas outras bibliotecas ajudaram a juntar as duas, mas eu senti que elas estavam muito inchadas. Acabei usando o D3 para gerar os SVGs e o React para lidar com o DOM, o que funcionou muito bem para mim.

Dessa vez, quando eu compartilhei a minha aplicação no Reddit, todos adoraram!

Acontece que o pessoal no Reddit é apaixonado pela aprendizagem de máquina. Todo o amor que eu recebi no Reddit foi um grande motivador para mim. As pessoas estavam jogando o meu jogo e gostando dele!

Mês 6 - jobSort(), preparação para buscar um emprego

Depois do StockIT, entrei diretamente no meu próximo projeto pessoal. Eu queria fazer um quadro de empregos que agregasse os menores sites de listagem de empregos com foco em tecnologia, como o Stack Overflow, o Github e o Hacker News. Para adicionar meu estilo próprio, decidi que ele se basearia nas tecnologias que o usuário queria em um emprego e no quanto eles desejavam cada uma delas.

Por exemplo, digamos que eu estivesse procurando um emprego que procurasse alguém que soubesse JavaScript, React e/ou Python. Eu realmente queria trabalhar com JavaScript e React, mas não me importava tanto com Python. Então, eu poderia dar ao JavaScript um três, ao React um três e talvez um para o Python. As listagens seriam, então, ordenadas de acordo.

Encontrei vários obstáculos com esse projeto e tive que mudar de rumo algumas vezes, mas acabei com um produto com o qual eu estava feliz. Minha stack de tecnologias final foi React/Node/Express/MySQL. Coloquei o projeto no subreddit de perguntas sobre carreira em computação e obtive 650 visualizações antes de ser retirado do ar, porque eles não permitem projetos pessoais.

O produto "final" está aqui. Se estiver interessado em saber mais sobre meus desafios e toda a refatoração, confira meu artigo aqui (em inglês).

Devido aos problemas, o jobSort() ocupou uma boa parte do mês. Acabei tomando café com um amigo que conheci no meu primeiro meetup e ele me aconselhou a começar a me candidatar a empregos agora. Li em todo lugar que todos dizem que esperaram muito tempo para se candidatar. Além disso, sempre que eu via um artigo perguntando quando se candidatar, o comentário que vinha logo após era sempre "agora".

Na minha cabeça, eu trabalharia no meu plano estruturado para construir meu portfólio com projetos pessoais e depois trabalharia em contribuições ao código aberto. Depois, me prepararia para entrevistas. Finalmente, começaria a me candidatar a empregos. Esse amigo me convenceu a abandonar este plano e a começar a me candidatar. Assim, nesse mês, fiz um portfólio e um currículo. No mês seguinte, eu começaria a me candidatar.

Mês 7 - Testes e a procura de um emprego

Nesse mês, me concentrei em retocar meus projetos e me candidatei a empregos. Eu também queria aprender testes e Redux.

Adicionei o flexbox ao CodeClub.Social para torná-lo mais ágil. Melhorei a UX para dispositivos móveis do jobSort(). Adicionei testes ao jobSort() com mocha/chai/enzyme que eram difíceis de configurar, fáceis de começar e, depois, difíceis de obter 100% de cobertura.

Até o final do mês, eu tinha me candidatado a 63 empregos. Eu vi isso como uma autoavaliação. Meu portfólio/currículo era bom o suficiente? Em caso afirmativo, no que eu precisava trabalhar para me preparar para as entrevistas? No início, me candidatei com o Hacker News: Who's Hiring e no Indeed.

No Hacker News, eu usei o jobSort() para determinar quais listagens solicitar. Na verdade, eu tentei empresas que não eram de software para ver se eu poderia até mesmo receber uma chamada ou uma entrevista em qualquer lugar.

No início, eu estava me candidatando rapidamente e não personalizando meu currículo/carta de apresentação. Então, decidi personalizar minha carta de apresentação e meu currículo. Depois, tentei enviar um e-mail para alguém da empresa. Esse método era claramente melhor do que a abordagem de tentar me candidatar a tudo ao mesmo tempo.

Recebi cinco ligações naquele mês – duas de empresas de recrutamento e três de empresas de software – que incluíam:

• um contrato para trabalho como DevOps/testador em uma empresa dotcom
• uma empresa de análise de alimentos e
• uma empresa startup bastante grande e bem-sucedida, que foi recentemente comprada por uma grande corporação

Consegui passar pela análise do RH em duas delas, mas nenhuma delas garantiu uma entrevista no local. Fiquei bastante satisfeito com as três ligações e aprendi muito com elas.

Todas mencionaram on-line que não se espera que os desenvolvedores júniores saibam tanto no início. Eles só precisam ser apaixonados e entusiasmados para aprender. Então, eu pensei, era fácil. Estou apaixonado e entusiasmado para aprender. O que aprendi com essas ligações, no entanto, foi que ninguém estava procurando por um desenvolvedor júnior. Eles esperam que você saiba o que está fazendo desde o primeiro dia.

Essas ligações me ensinaram o que eu precisava

• ser bom o suficiente para adicionar valor desde o primeiro dia
• estar confiante o suficiente para convencê-los de que posso adicionar valor desde o primeiro dia

Mês 8 - Turno da noite, Redux, código aberto, entrevista no local

Comecei esse mês trabalhando no turno da noite por um período de quarenta dias no meu trabalho de tempo integral – seis dias por semana, doze horas por dia, das cinco da tarde às cinco da manhã. Que sacrifício!

Eu sabia que não seria capaz de fazer tanto esse mês, mas eu tinha um objetivo e queria cumpri-lo. Por isso, não podia tirar um mês de folga.

Eu refatorei o jobSort() para que usasse o Redux, o que, surpreendentemente, não foi tão difícil quanto eu pensava que seria. Ouvi muitos podcasts e li blogs sobre ele. Nunca fez muito sentido para mim até começar a usá-lo.

Eu realmente gosto do fluxo de dados com o Redux. É interessante, agora, ver as pessoas reclamando sobre o Redux. Acho que não estou qualificado para dar minhas opiniões com toda veemência, mas gosto do padrão reducer.

Esse deveria ter sido o mês de código aberto para mim. Eu faria minha primeira contribuição ao código aberto e seria uma grande contribuição para uma biblioteca fantástica. Eu contribuiria com o React!

Todos disseram que era uma base de código difícil de ler e mais ainda de contribuir para ela. Porém, eu precisava me destacar. Eu precisava ser único. Eu sabia que a minha contribuição não seria significativa, mas, mesmo assim, eu queria fazer isso.

Eu começaria lendo a documentação até o fim e depois analisando a base de código. Observei cada issue, cada PR. Ler a documentação do React na íntegra foi um grande exercício e estou feliz por ter feito isso. Rapidamente, contudo, percebi que o problema de contribuir para o React é o fato de que não há muitos "bons problemas para iniciantes". Quando havia algum, eles sumia rapidamente.

Em um dos meetups dos quais participei, Anthony Ng recomendou que eu experimentasse o Downshift, uma biblioteca de autopreenchimento de Kent C. Dodds. Isso mudou tudo para mim. Eu estava no lugar certo. A dificuldade era a certa, a quantidade de issues em que eu poderia ajudar era a certa, não havia muitos colaboradores, o gestor ajudava demais, o código era limpo e bem testado. Além de tudo isso, foi uma solução perfeita para alguns problemas que eu estava tendo com a minha aplicação do JobSort().

Na metade do mês, recebi um e-mail de uma das empresas às quais me candidatei no mês anterior. Eles montaram uma primeira verificação por telefone. Depois, uma entrevista técnica, também por telefone. As tecnologias que eles estavam procurando eram exatamente o que eu havia aprendido - React, Redux e D3. Eu só falei sobre meus projetos e sobre os motivos de tomar certas decisões. Depois disso, eles me pediram para ir ao local para uma entrevista. Minha primeira entrevista no local!

Eu não tinha me preparado para as entrevistas. Então, entrei com a expectativa de que não conseguiria o emprego, mas ganharia uma valiosa experiência em entrevistas. Eu também estava dormindo apenas três horas por dia, já que ainda estava trabalhando no turno da noite, o que não ajudou. Felizmente, a parte técnica não era programar em um quadro branco, apenas uma sessão de uma hora de pair programming (programação em pares). Foi um desafio bastante simples, mas eu estava muito nervoso.

No início, eu estava preocupado em ter a certeza de que sabia tudo sem consultar. Quando vi que não terminaria o desafio, percebi que precisava parar de me preocupar com o que o entrevistador pensava de mim e apenas procurar no Google/Stack Overflow para encontrar respostas. Eu acabei não terminando e pensei que tinha dado tudo errado.

Como eu pensava ter me saído mal no pair programming, senti-me relaxado pelo resto da entrevista. Por fim, deixei a entrevista orgulhoso de mim mesmo. No pior dos casos, tive uma experiência valiosa em entrevistas. No melhor dos casos, receberia minha primeira oferta de emprego.

Mês 9 - Oferta de emprego

Acabei recebendo a minha primeira oferta de emprego 9 meses e 7 dias depois daquele primeiro dia – quando decidi que mergulharia de cabeça na programação com a intenção de mudar de carreira. Senti-me confiante, já que recebi uma oferta após a minha primeira entrevista no local, mas, ao mesmo tempo, se eu não aceitasse a oferta? O que aconteceria se essa fosse a única oferta que eu receberia por vários meses? Acabei aceitando a oferta e estou feliz com a minha decisão. Eu queria ser pago para programar!

Conselho

Até esse ponto, eu venho compartilhando minha história e dando alguns conselhos aos poucos. Provavelmente, se você estiver lendo isso, deve estar pensando em mudar de carreira ou está aprendendo a programar com a intenção de mudar de carreira. Espero que os conselhos abaixo o ajudem a desenvolver um plano ou a manter o plano atual e alcançar seu objetivo.

1. Descubra o que o motiva e use isso a seu favor. Para mim, foram as listas de verificação, documentar meu progresso e interagir com várias comunidades de programação. Se você não está motivado para atingir seu objetivo, nada mais importa, porque você não vai conseguir.
2. Estabelecer metas e cumpri-las. Eu diria que você deve ter metas mensais e, até mesmo, metas diárias. Metas mensais servem para você ter a certeza de que está no caminho certo para atingir sua meta principal. Metas diárias servem para ter certeza de que você realmente avança diariamente. Uma estratégia que funcionou para mim foi a de fazer minhas metas diárias na noite anterior. Desse modo, você não poderá fazer trabalho improdutivo o dia todo e sentir que progrediu quando, realmente, não o fez. Isso o obriga a comparar suas realizações diárias com as suas metas diárias.
3. Vá a meetups muito antes de pensar que você está pronto. Ir a meetups pode parecer assustador, mas, como mencionei acima, em geral, todos são simpáticos e dispostos a ajudar. Você pode encontrar pessoas que não estão interessadas em conversar com você, mas elas são a minoria e ninguém vai julgar você. Além disso, todos gostam de dar conselhos (como eu estou fazendo agora).
4. Contribua com o código aberto antes de pensar que você está pronto. Quando você começa a programar pela primeira vez, o Github parece ser este lugar assustador onde você nunca quer estar. Na verdade, é muito acolhedor para iniciantes e é um ótimo lugar para ver um bom código e ter seu próprio código revisado. Se você ainda não está convencido, confira meu artigo, Why you should contribute to open source right now ("Por que você deve contribuir com o código aberto agora mesmo", em inglês).
5. Comece a se candidatar a empregos antes que achar que está pronto. Essa foi difícil para mim, porque eu pensava que era diferente. Pensei que não precisava testar o mercado para ter uma ideia do que deveria trabalhar. Pensei que saberia quando estaria pronto para me candidatar. Deixe-me adiantar isso para você agora mesmo. Você não saberá quando se candidatar. Portanto, é melhor começar agora. Você não deve enlouquecer e se candidatar em 300 empresas antes de aprender a fazer laços, mas deve saber que a melhor maneira de saber o que você precisa aprender é se candidatando e testando o mercado.

Agora, vá lá e comece a programar!