Migrando de Carreira para Engenharia de Software Sem Graduação em CC: O Que Realmente Funciona

Recrutador não contrata diploma. Contrata evidência de que você consegue resolver o tipo específico de problema que o time dele tem. Uma graduação em ciência da computação é uma forma de gerar essa evidência — anos de disciplinas, um TCC, talvez um projeto de pesquisa. Não é a única forma, e para boa parte dos engenheiros que estão trabalhando hoje, nem foi o caminho. O que de fato convence alguém a apostar em você é muito mais estreito e muito mais aprendível do que "conseguir um diploma": um portfólio que prova que você entrega, e uma narrativa que transforma sua trajetória não tradicional em ativo, não em algo para se desculpar.

Pare de tratar o portfólio como um currículo com prints

O erro mais comum de quem está migrando de carreira é montar um portfólio que lista projetos do jeito que um currículo lista empregos: título, uma linha, stack, próximo. Esse formato funciona quando quem lê já confia nas suas credenciais. Não funciona quando quem lê está decidindo se confia em você.

O que realmente prende atenção é especificidade sobre uma decisão real que você tomou. Não "criei uma API REST com FastAPI" — e sim algo como "a API precisava sobreviver a um serviço terceiro caindo no meio de uma requisição, então adicionei uma camada de retry com backoff e um caminho alternativo que degrada bem em vez de devolver 500." Essa frase faz mais trabalho do que cinco bullet points, porque mostra julgamento técnico, não só familiaridade com sintaxe. Escolha dois ou três projetos e, para cada um, esteja pronto para explicar um problema que você enfrentou e que não estava em nenhum tutorial.

O que recrutadores e engenheiros que entrevistam realmente procuram

Na prática, a leitura é rápida e baseada em padrões:

• O código parece mantido, não só funcional? Nomenclatura consistente, um README que explica por quê, não só o quê, e nenhum bloco morto comentado esquecido no meio do código.
• Existe evidência de que você termina o que começa? Uma dezena de repositórios pela metade passa pior impressão do que dois ou três projetos completos e no ar. Estar no ar importa — uma URL viva elimina qualquer dúvida sobre se aquilo realmente funciona.
• Você consegue explicar um trade-off? Não "por que você usou X", mas "o que você faria diferente hoje". Essa pergunta separa quem seguiu um tutorial de quem entende o que construiu.

Nada disso exige graduação em CC. Exige ter construído algo além do ponto em que era fácil.

Como falar sobre uma trajetória não tradicional sem se desculpar

O instinto é começar com uma desculpa: "eu não tenho uma formação tradicional, mas...". Tire o "mas". Trate a transição como evidência de direção, não como uma lacuna a ser justificada. Se você veio de outra área, nomeie a habilidade específica que aquela área te ensinou e que um recém-formado em CC geralmente ainda não teve que praticar — falar com stakeholders não técnicos, trabalhar sob prazo comercial apertado, depurar um processo em vez de só código. Depois conecte isso a algo concreto que você construiu.

Uma estrutura útil para o momento "me fale sobre você":

1. O que você fazia antes, em uma frase — sem pedir desculpas.
2. O momento específico em que código virou a ferramenta que você buscava.
3. Um projeto que prove que você já consegue fazer trabalho de engenharia de verdade.
4. O que você está buscando agora, dito de forma direta.

São quatro frases, não uma autobiografia. Quem entrevista está procurando padrões de competência e autoconsciência, não um arco de redenção.

A parte que ninguém conta: constância vale mais que intensidade

Um sprint de três meses com dias de 12 horas seguido de burnout produz um portfólio pior do que seis meses de commits menores e constantes. O histórico do Git é visível, e uma sequência longa de commits pequenos e reais passa a impressão de alguém que consegue sustentar o ritmo — que é, não por acaso, exatamente o que um gestor de contratação está tentando prever. Você não precisa de um diploma em CC para convencer alguém de que você ainda vai estar entregando código daqui a um ano. Precisa de um histórico, mesmo que curto, que já mostre você fazendo isso.