Portfolio Projects for Frontend Developer

Seu portfólio tem três certificados e um clone de tutorial, e mesmo assim ninguém te chama para entrevista. Isso acontece porque certificado mostra que você assistiu a algo, não que você sabe resolver problemas. Quem contrata quer ver decisão, contexto e resultado.

A boa notícia é que três projetos bem feitos resolvem isso. Não três projetos enormes. Três projetos que mostram como você pensa.

Por que certificado pesa tão pouco#

Recrutador técnico olha seu repositório por poucos minutos. Nesse tempo, ele quer descobrir se você consegue transformar um pedido vago em algo que funciona. Certificado não responde essa pergunta.

Projeto responde. Mostra o que você escolheu, o que cortou, onde travou. Isso vale mais do que qualquer selo de conclusão de curso.

O que avaliadores procuram de verdade#

Antes de escrever qualquer linha, entenda o critério de quem vai julgar seu trabalho. Não é beleza visual. É clareza de raciocínio.

• Um problema real e explicado em duas linhas no README
• Decisões técnicas com motivo escrito, não só a stack usada
• Tratamento de estados: carregando, vazio, erro
• Responsividade em telas pequenas, testada de verdade
• Acessibilidade básica: foco, contraste, teclado
• Código organizado, commits com mensagem legível
• Um link ao vivo que funciona sem pedir login

Se o avaliador não entende o problema em trinta segundos, ele fecha a aba. Essa é a régua.

Os três projetos que funcionam#

1. Um app que consome API real e trata erro

Pegue uma API pública e construa algo com busca, filtro e paginação. Pense em: busca de filmes, cotação de moedas, clima por cidade, repositórios do GitHub.

O valor está nos estados de erro e carregamento. API falha, rede cai, usuário digita bobagem. Se seu app quebra nesses casos, ele parece exercício de curso. Se ele responde com uma mensagem clara e um botão de tentar de novo, você já está acima da média.

Não use dados mockados só para facilitar. O avaliador nota isso na hora.

2. Um projeto com autenticação e dados persistidos

Monte algo onde o usuário entra, cria conteúdo e volta depois para encontrar o que fez. Lista de tarefas com login, controle de gastos, cadastro de livros lidos, notas pessoais.

Aqui você mostra que entende estado de sessão, proteção de rota e persistência. Não precisa de backend próprio se isso travar o projeto. Firebase ou Supabase resolvem e ainda mostram que você sabe integrar serviço externo.

O erro comum é parar no CRUD. Mostre também o que acontece quando a sessão expira ou quando o usuário tenta acessar rota protegida sem login.

3. Uma refatoração real de uma interface ruim

Pegue um site público com interface confusa e refaça uma tela dele. Documente o problema original, o que você mudou e por quê. Mostre o antes e depois.

Esse projeto é o mais subestimado e o mais forte. Ele prova que você lê código de outra pessoa, que entende de experiência do usuário e que consegue justificar decisão. Tudo isso é raro em perfil júnior.

Escolha algo pequeno. Uma tela de cadastro, um fluxo de compra, um painel de busca. Não tente refazer o site inteiro.

Como apresentar no GitHub#

O README é a parte mais lida do seu repositório e a mais negligenciada. Ele precisa responder o problema, a solução, as decisões e como rodar o projeto.

• Título curto e uma frase que explica o que o app faz
• Print ou GIF da tela principal funcionando
• Stack usada, com versão quando fizer diferença
• Três ou quatro decisões técnicas e o motivo de cada uma
• Como rodar localmente, comando por comando
• O que ficou de fora e o que você faria com mais tempo

Commits também contam história. Troque "update" por "corrige paginação quando a API retorna lista vazia". Isso mostra método.

Antes de publicar, rode uma checagem de compatibilidade com sistemas de rastreamento de candidatura no que você escreve no README e no currículo. Nosso verificador gratuito de ATS mostra o que fica invisível para robô de seleção.

Como colocar no currículo#

Currículo não é galeria, é argumento. Cada projeto vira uma linha que mostra resultado, não lista de tecnologia.

Exemplo ruim: "Projeto em React com TypeScript, Styled Components e integração de API".

Exemplo reescrito: "App de busca de filmes com filtro e paginação, tratamento de erro de API e layout responsivo, reduzindo o retrabalho de busca em testes com usuários".

A segunda versão diz o que foi feito e qual efeito teve. Mesmo sem número de produção, você consegue citar o efeito no uso: tempo de busca, cliques evitados, telas que passaram a funcionar no celular.

Coloque os três projetos numa seção própria, logo abaixo da experiência ou da formação. Cada um com link ao vivo e link do repositório. Se o link morrer, o avaliador presume que o projeto morreu junto.

Se você está mirando vaga específica, leia a descrição com um decodificador de vagas para entender o que a empresa realmente pede e ajustar a ordem dos projetos no currículo.

Como falar deles na entrevista#

Entrevistador pergunta "me conta sobre um projeto seu" para ouvir seu raciocínio, não para ver a lista de features. Estruture a resposta em problema, decisão, dificuldade, resultado.

Exemplo de resposta: "Meu app de clima buscava dados por cidade, mas a API retornava erro quando a cidade não existia. Primeiro tratei a mensagem de erro para não quebrar a tela. Depois percebi que o usuário não sabia o que digitou errado, então adicionei sugestão de cidade a partir do retorno parcial. A parte difícil foi controlar requisições em sequência quando a pessoa digitava rápido, resolvi com debounce. No fim, o fluxo de busca passou a funcionar sem travar em nenhum caso de teste que fiz".

Repare: nada de adjetivo sobre si mesmo, só problema, escolha e efeito. É esse formato que faz o entrevistador querer continuar ouvindo.

Prepare também a versão curta, de trinta segundos, para o primeiro contato com recrutador não técnico. Detalhe fica para a entrevista técnica.

Erros que fazem projeto parecer tutorial#

• README com uma linha e print genérico, sem explicar o problema resolvido
• Clone de projeto de curso, com o mesmo layout e a mesma API do instrutor
• Nenhum estado de erro ou carregamento tratado
• Layout que só funciona em tela de desktop
• Código tudo em um arquivo, sem separação de responsabilidade
• Commits feitos todos de uma vez, no dia de publicar
• Título do repositório tipo "projeto-final-curso"

Se você marcou dois ou mais itens nessa lista, refatore antes de mandar currículo. Um projeto limpo vale mais do que três apressados.

Onde achar referência e vaga#

Olhe portfólio de quem passou no processo seletivo que você quer, e leia anúncio de vaga para entender a linguagem que o mercado usa. Nosso painel de vagas reúne anúncios atuais de frontend e ajuda a calibrar o nível que pedem.

Para ideia de tema e leitura de código alheio, o acervo de artigos sobre carreira em tech tem material sobre portfólio, currículo e entrevista técnica. Leia código dos outros com frequência. É assim que o seu fica melhor.

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Quantos projetos preciso no portfólio para conseguir a primeira vaga?

Três bem feitos superam dez apressados. O avaliador abre poucos repositórios por candidato, então priorize profundidade e clareza em vez de quantidade.

Posso usar projeto de curso no portfólio?

Pode, desde que você mude o problema, a API ou o escopo e explique o que decidiu diferente. Clone fiel do que o instrutor fez parece exercício, não trabalho próprio.

Preciso ter projeto com backend próprio?

Não. Consumir API pública ou usar serviço como Firebase já mostra que você entende integração, autenticação e persistência. O que importa é o tratamento dos casos reais, não quem hospeda os dados.

Como mostro projeto se ainda não tenho experiência de trabalho?

Coloque os projetos numa seção própria do currículo, com link ao vivo e link do repositório, e escreva cada um como resultado, não como lista de tecnologia. Trate projeto como experiência: problema, decisão, efeito.

Meu projeto está no ar, mas o link caiu. Isso prejudica?

Sim, e mais do que parece. Avaliador que clica em link morto costuma simplesmente seguir para o próximo candidato, então hospede em plataforma estável e teste o link antes de enviar o currículo.