--- title: "Backend Python Júnior: O Que Estudar, Projeto e Como Buscar Vagas" url: "https://python.dev.br/carreira/backend-python-junior/" markdown_url: "https://python.dev.br/carreira/backend-python-junior.MD" description: "Veja o que estudar para backend Python júnior, como montar uma API de portfólio com FastAPI, SQL e testes e onde buscar vagas no Brasil em 2026. Guia prático." date: "2026-08-29" author: "Equipe Python Dev BR" --- # Backend Python Júnior: O Que Estudar, Projeto e Como Buscar Vagas Veja o que estudar para backend Python júnior, como montar uma API de portfólio com FastAPI, SQL e testes e onde buscar vagas no Brasil em 2026. Guia prático. Para conseguir uma vaga de **backend Python júnior**, você precisa provar que consegue construir a parte de servidor de uma aplicação pequena: receber uma requisição HTTP, validar os dados, aplicar regras, persistir informações, responder com erros claros e testar o comportamento principal. A base mais útil é **Python, Git, HTTP, API REST, SQL, testes e um framework**, como FastAPI ou Django. Docker, logs, segurança básica e deploy entram depois para tornar o projeto reproduzível. Você não precisa começar por microsserviços, Kubernetes ou arquitetura distribuída. Para uma posição de entrada, uma API simples e bem acabada costuma demonstrar mais maturidade do que cinco projetos complexos copiados de tutoriais. Escolha um problema, limite o escopo, escreva o código, adicione testes, documente as decisões e aprenda a explicar o caminho completo de uma requisição. Ao procurar oportunidades, não use apenas “backend Python júnior”. Pesquise também por **desenvolvedor Python**, **software engineer Python**, **analista de desenvolvimento de sistemas**, **desenvolvedor de APIs**, **full stack Python**, **Django**, **FastAPI**, **integrações** e **automação backend**. No mercado brasileiro, a linguagem pode estar nos requisitos sem aparecer no título da vaga. ## O que uma pessoa desenvolvedora backend faz Backend é a parte da aplicação que executa regras, conversa com bancos e serviços e entrega dados para interfaces web, aplicativos ou outros sistemas. Dependendo da empresa, uma pessoa júnior pode trabalhar em tarefas como: - criar e ajustar endpoints de uma API; - validar dados enviados pelo cliente; - consultar e gravar informações no banco; - implementar regras de cadastro, autorização e status; - integrar serviços externos por HTTP; - corrigir bugs e escrever testes de regressão; - analisar logs de uma falha; - documentar contratos e decisões; - revisar código com apoio da equipe; - acompanhar deploys e verificar se a aplicação continua saudável. A rotina não é apenas escrever rotas. Uma API precisa lidar com entrada inválida, registro inexistente, duplicidade, indisponibilidade de dependência, permissão e mudança de dados. É por isso que tratamento de erros, testes e banco de dados aparecem tão cedo na trilha. Em uma equipe pequena, o mesmo cargo pode incluir frontend, automação ou infraestrutura. Em uma estrutura maior, backend trabalha junto de produto, frontend, QA, dados, plataforma e segurança. Leia a descrição da vaga para entender o recorte real, não apenas o nome do cargo. ## Roadmap de backend Python júnior A ordem abaixo evita estudar ferramentas avançadas antes dos fundamentos que elas tentam resolver. ### 1. Python bem compreendido Antes do framework, domine: - tipos básicos e coleções; - condicionais e laços; - funções, parâmetros e retorno; - módulos e pacotes; - classes quando fizerem sentido; - exceções; - leitura de JSON e arquivos; - type hints; - ambientes virtuais; - instalação e declaração de dependências; - testes de funções. Você não precisa conhecer todo o Python. Precisa escrever funções legíveis, separar responsabilidades e investigar erros. O [roadmap Python 2026](/carreira/roadmap-python-2026/) ajuda a revisar essa base antes de entrar em web. ### 2. Git e colaboração Aprenda a criar branch, fazer commits claros, atualizar seu trabalho, resolver um conflito simples e abrir uma pull request. Também saiba ler um diff antes de enviar código. No portfólio, o histórico deve representar a evolução real: configuração inicial, primeira rota, persistência, testes e documentação. Evite um único commit chamado “projeto pronto” e também não crie dezenas de commits artificiais apenas para movimentar o perfil. ### 3. HTTP e API REST Frameworks escondem parte do protocolo, mas você precisa entender: - método `GET`, `POST`, `PUT`, `PATCH` e `DELETE`; - URL, rota, query parameter e corpo da requisição; - headers e `Content-Type`; - JSON; - códigos `200`, `201`, `204`, `400`, `401`, `403`, `404`, `409`, `422` e `500`; - autenticação e autorização; - idempotência; - paginação; - timeout em integrações externas. Uma pergunta comum em teste técnico é: “qual resposta a API deve retornar quando o recurso não existe?”. Decorar todos os códigos é menos importante do que justificar uma resposta consistente. ### 4. FastAPI ou Django FastAPI facilita o primeiro contato com APIs, type hints, Pydantic e documentação OpenAPI. Django oferece uma estrutura mais completa, com ORM, autenticação, migrations, painel administrativo e muitas convenções. Django REST Framework costuma ser usado para expor APIs em projetos Django. A decisão prática é: | Se você quer aprender primeiro | Escolha inicial | | --- | --- | | API pequena, tipada e focada em JSON | FastAPI | | Sistema web com cadastro, admin e autenticação | Django | | Empresa-alvo já usa um framework | O framework da empresa | | Você ainda não sabe | FastAPI para fundamentos de API ou Django para estrutura completa | Veja o [comparativo FastAPI vs Django](/comparacoes/fastapi-vs-django/) antes de escolher. Depois, siga um caminho por algumas semanas. Trocar de framework toda vez que surge um tutorial novo atrasa a entrega do portfólio. ### 5. SQL e banco de dados Uma pessoa backend precisa entender o que acontece com os dados. Estude: - tabelas, colunas e tipos; - chave primária e chave estrangeira; - `SELECT`, `INSERT`, `UPDATE` e `DELETE`; - `WHERE`, `ORDER BY`, `LIMIT`, `JOIN` e agregações; - restrição única; - índice em nível introdutório; - transação; - migration; - diferença entre carregar um registro e carregar milhares. SQLite é ótimo para uma primeira versão local. PostgreSQL aproxima o projeto de muitos ambientes profissionais. O tutorial de [PostgreSQL com Python](/blog/python-e-postgresql/) explica a integração, enquanto o guia de [Docker Compose com PostgreSQL](/blog/python-docker-compose-postgres-ambiente-local/) ajuda a criar um ambiente reproduzível. Não esconda SQL totalmente atrás do ORM. Use o ORM, mas aprenda a inspecionar a consulta gerada e a reconhecer problemas como consultas repetidas dentro de um laço. ### 6. Testes e qualidade Comece testando regras e endpoints principais. Uma API de candidaturas, por exemplo, deveria verificar: - criação com dados válidos; - rejeição de campo obrigatório ausente; - conflito quando há duplicidade; - resposta `404` para ID inexistente; - alteração permitida de status; - filtro e paginação; - comportamento quando o banco falha, se isso fizer parte do escopo. O guia de [testes com pytest](/guias/testes-com-pytest/) mostra como estruturar casos e fixtures. Não busque uma porcentagem perfeita de cobertura; proteja primeiro as regras que mudam o resultado do sistema. ### 7. Docker, configuração e observabilidade Depois que a aplicação roda localmente, torne o ambiente repetível: - use variáveis de ambiente para configuração; - não publique senhas ou tokens; - adicione `Dockerfile` e `docker-compose.yml` quando forem úteis; - crie logs com contexto, sem dados sensíveis; - implemente uma rota simples de health check; - documente como iniciar, testar e parar o ambiente. Docker não corrige uma aplicação desorganizada. Ele empacota o que já existe. Primeiro faça o projeto rodar e passar nos testes; depois coloque em container. ## Projeto de portfólio: API de acompanhamento de candidaturas Uma boa peça de portfólio é uma API para registrar candidaturas a vagas. O domínio é fácil de explicar e permite demonstrar CRUD, filtros, validação, banco, testes e regras sem usar dados reais. ### Escopo da primeira versão Cada candidatura terá: - empresa; - cargo; - URL opcional; - status; - data da candidatura; - observações opcionais. As operações serão: 1. criar candidatura; 2. listar com filtro por status; 3. buscar por ID; 4. alterar status; 5. remover registro de demonstração. Não adicione login, fila, IA, notificações e dashboard antes dessa versão funcionar. Escopo controlado é uma competência de engenharia. ### Estrutura sugerida ```text api-candidaturas/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── models.py │ ├── schemas.py │ └── database.py ├── tests/ │ └── test_candidaturas.py ├── .env.example ├── docker-compose.yml ├── pyproject.toml └── README.md ``` Para uma demonstração mínima, você pode começar em memória e migrar para banco depois. O exemplo abaixo mostra a regra principal com FastAPI e Pydantic: ```python from datetime import date from enum import StrEnum from fastapi import FastAPI, HTTPException, status from pydantic import BaseModel, Field, HttpUrl class StatusCandidatura(StrEnum): enviada = "enviada" triagem = "triagem" entrevista = "entrevista" proposta = "proposta" encerrada = "encerrada" class CandidaturaEntrada(BaseModel): empresa: str = Field(min_length=2, max_length=120) cargo: str = Field(min_length=2, max_length=160) url: HttpUrl | None = None data_candidatura: date class Candidatura(CandidaturaEntrada): id: int status: StatusCandidatura = StatusCandidatura.enviada app = FastAPI(title="API de Candidaturas") banco: dict[int, Candidatura] = {} proximo_id = 1 @app.post( "/candidaturas", response_model=Candidatura, status_code=status.HTTP_201_CREATED, ) def criar_candidatura(dados: CandidaturaEntrada) -> Candidatura: global proximo_id duplicada = any( item.empresa.casefold() == dados.empresa.casefold() and item.cargo.casefold() == dados.cargo.casefold() for item in banco.values() ) if duplicada: raise HTTPException( status_code=status.HTTP_409_CONFLICT, detail="Candidatura já cadastrada para empresa e cargo", ) candidatura = Candidatura(id=proximo_id, **dados.model_dump()) banco[proximo_id] = candidatura proximo_id += 1 return candidatura @app.get("/candidaturas/{candidatura_id}", response_model=Candidatura) def buscar_candidatura(candidatura_id: int) -> Candidatura: candidatura = banco.get(candidatura_id) if candidatura is None: raise HTTPException(status_code=404, detail="Candidatura não encontrada") return candidatura ``` Essa versão ainda não é uma aplicação pronta para produção. O dicionário perde os dados quando o processo reinicia e o contador global não funciona como estratégia de persistência. Isso é aceitável na primeira etapa se o README deixar a limitação explícita. A evolução seguinte é trocar o armazenamento por SQLite ou PostgreSQL, criar migrations e separar rota, serviço e persistência. Você pode usar SQLAlchemy ou SQLModel; o guia de [SQLModel com FastAPI](/blog/sqlmodel-fastapi-python/) apresenta uma opção compacta para aprender. ### Teste do comportamento principal Com o cliente de testes do FastAPI: ```python from fastapi.testclient import TestClient from app.main import app, banco client = TestClient(app) def setup_function() -> None: banco.clear() def test_cria_e_busca_candidatura() -> None: resposta = client.post( "/candidaturas", json={ "empresa": "Empresa Exemplo", "cargo": "Backend Python Júnior", "url": "https://example.com/vaga/123", "data_candidatura": "2026-08-29", }, ) assert resposta.status_code == 201 candidatura_id = resposta.json()["id"] consulta = client.get(f"/candidaturas/{candidatura_id}") assert consulta.status_code == 200 assert consulta.json()["status"] == "enviada" def test_rejeita_candidatura_duplicada() -> None: dados = { "empresa": "Empresa Exemplo", "cargo": "Backend Python Júnior", "data_candidatura": "2026-08-29", } assert client.post("/candidaturas", json=dados).status_code == 201 assert client.post("/candidaturas", json=dados).status_code == 409 ``` Ao migrar para banco, substitua o estado global por uma base isolada para testes. O ponto não é decorar a biblioteca, e sim garantir que criar, consultar e rejeitar duplicidade continuem funcionando. ### O que colocar no README Seu README deve responder rapidamente: - qual problema a API resolve; - quais tecnologias usa; - como instalar dependências; - como configurar o `.env` a partir do `.env.example`; - como iniciar aplicação e banco; - onde abrir a documentação da API; - como rodar os testes; - quais decisões foram tomadas; - quais limitações ainda existem; - quais dados são fictícios; - quais seriam os próximos passos. Inclua um diagrama simples do fluxo e exemplos de `curl` ou screenshots da documentação. Não use dados reais de processos seletivos sem necessidade. Empresas, URLs e observações fictícias são suficientes para demonstrar o sistema. ## FastAPI ou Django no portfólio? Não existe uma resposta universal. Avalie o que você quer provar. Use FastAPI se o destaque for: - contrato de API; - validação com Pydantic; - documentação automática; - código assíncrono quando necessário; - integração com frontend ou serviço externo. Use Django se o destaque for: - modelagem com ORM integrado; - autenticação e permissões; - painel administrativo; - aplicação web com muitas entidades; - convenções de um framework completo. Uma estratégia eficiente é implementar a API de candidaturas em um deles e explicar como faria no outro. Isso mostra compreensão sem duplicar o projeto inteiro. Quando uma vaga citar Django, um projeto FastAPI ainda demonstra HTTP, SQL e testes, mas vale construir ao menos um exercício menor no framework pedido antes da entrevista. ## Como apresentar o projeto no currículo Evite descrições genéricas como “API feita em Python”. Use problema, decisões e evidências: > Desenvolvi uma API REST para acompanhamento de candidaturas com Python, FastAPI e PostgreSQL, incluindo validação com Pydantic, filtros, tratamento de duplicidade, migrations, testes com pytest e ambiente Docker Compose documentado. Se ainda usa SQLite: > Criei API de candidaturas com FastAPI e SQLite, cobrindo cadastro, consulta, alteração de status, validação e testes de endpoints. Documentei instalação, decisões e migração planejada para PostgreSQL. Não chame um projeto local de “sistema escalável” ou “pronto para milhões de usuários”. Uma descrição precisa passa mais confiança. Adapte o [currículo Python para vaga júnior](/carreira/curriculo-python-vaga-junior/) e mantenha o link direto para o repositório. ## Como procurar vagas backend Python Crie alertas com diferentes títulos: - backend Python júnior; - desenvolvedor Python júnior; - software engineer Python; - analista de sistemas Python; - analista de desenvolvimento Python; - desenvolvedor Django; - desenvolvedor FastAPI; - desenvolvedor de APIs; - full stack Python; - integração de sistemas Python; - backend Python remoto; - Python SQL Docker. Pesquise também sem o nível “júnior”. Algumas empresas publicam apenas “desenvolvedor Python” e informam a senioridade no corpo. Em outras, uma vaga de analista de sistemas inclui desenvolvimento backend, banco e APIs. No [radar de vagas Python](/vagas/), observe quais combinações aparecem nos anúncios ativos. Em vez de tentar estudar toda tecnologia citada, conte as recorrências. Se Python, SQL, Git, Django e Docker aparecem repetidamente nas oportunidades compatíveis, essa combinação deve orientar o próximo projeto. Ao ler uma descrição, separe: - requisitos obrigatórios; - itens desejáveis; - responsabilidades; - senioridade real das tarefas; - modalidade e localização; - qualidade da supervisão; - etapa técnica do processo. Não desista automaticamente por não cumprir todos os itens desejáveis. Mas seja honesto: se a vaga exige experiência profissional avançada com arquitetura, liderança e operação crítica, ela provavelmente não é uma posição de entrada, mesmo que o título esteja confuso. ## O que costuma aparecer em teste técnico Para backend júnior, prepare-se para: - manipular listas e dicionários; - escrever uma função com regra clara; - consumir ou criar um endpoint; - modelar uma ou duas tabelas; - escrever uma consulta SQL; - validar uma entrada; - tratar registro inexistente; - explicar autenticação e autorização; - criar um teste; - ler um trecho de código e apontar um problema; - executar o projeto seguindo um README. Em um case de API, entregue primeiro o fluxo obrigatório. Depois acrescente qualidade: mensagens de erro, testes, migration, Docker e documentação. Não gaste metade do prazo criando arquitetura sofisticada antes de o endpoint principal funcionar. O [checklist de teste técnico Python](/carreira/teste-tecnico-python/) ajuda a revisar entrega, e o [simulador de entrevista Python](/carreira/simulador-entrevista-python/) serve para praticar a explicação das decisões. ## Erros comuns de quem quer entrar em backend ### Estudar apenas framework Saber decorar `@app.get` não substitui HTTP, SQL e Python. Quando o framework muda, os fundamentos continuam. ### Criar somente CRUD sem regra CRUD é um começo, mas adicione ao menos uma regra explicável: impedir duplicidade, controlar transição de status ou validar data. Isso cria material para testes e entrevista. ### Começar por microsserviços Dois serviços, fila e gateway multiplicam configuração e falhas. Primeiro construa um monólito pequeno e organizado. Separe serviços quando houver um motivo que você consiga explicar. ### Ignorar o banco Uma API que só usa lista em memória ensina rotas, mas não demonstra persistência. Evolua o projeto para SQLite ou PostgreSQL antes de apresentá-lo como principal peça do portfólio. ### Publicar segredos Nunca coloque senha, token ou chave no Git. Publique `.env.example` com nomes e valores fictícios, mantenha `.env` no `.gitignore` e explique a configuração. ### Não testar instruções do README Clone o repositório em outra pasta e siga o README como se fosse outra pessoa. Dependência não declarada, comando incorreto e migration ausente derrubam a credibilidade do projeto. ### Usar IA sem conseguir explicar o código Assistentes podem ajudar a estudar e revisar, mas você deve compreender cada parte enviada. Na entrevista, esteja pronto para alterar uma regra, depurar um teste e justificar a estrutura sem depender do histórico do chat. ## Plano prático de seis semanas | Semana | Foco | Entrega | | --- | --- | --- | | 1 | Python, Git e HTTP | funções, exceções, JSON e pequeno cliente de API | | 2 | FastAPI ou Django | rotas, validação e documentação local | | 3 | SQL e persistência | modelos, banco e migrations | | 4 | Testes e erros | casos principais, duplicidade e `404` | | 5 | Docker e documentação | ambiente reproduzível e README revisado | | 6 | Currículo e candidaturas | projeto publicado, simulação e alertas de vagas | Durante as seis semanas, leia anúncios reais. O projeto deve conversar com as oportunidades, não existir isolado do mercado. Se as vagas acessíveis pedem Django, use Django. Se pedem FastAPI, PostgreSQL e Docker, priorize esse trio. Se quase todas também pedem frontend, avalie noções básicas de HTML, CSS e JavaScript sem abandonar o foco backend. ## Checklist antes de se candidatar - [ ] Sei explicar o caminho de uma requisição na minha API. - [ ] Entendo os códigos HTTP usados no projeto. - [ ] A aplicação persiste dados em SQLite ou PostgreSQL. - [ ] Existem migrations ou instruções claras para criar as tabelas. - [ ] Os casos principais têm testes. - [ ] O projeto não contém senhas, tokens ou dados pessoais. - [ ] O README funciona em uma instalação limpa. - [ ] Consigo explicar uma limitação e um próximo passo. - [ ] Meu currículo descreve a entrega, não apenas as tecnologias. - [ ] Pesquiso títulos variados, não só “backend Python júnior”. - [ ] Registrei as candidaturas e requisitos recorrentes. ## Perguntas frequentes ### O que preciso estudar para uma vaga backend Python júnior? Priorize Python, Git, HTTP, API REST, SQL, testes e um framework. Depois adicione Docker, variáveis de ambiente, logs e deploy. Você deve conseguir construir e explicar uma aplicação pequena de ponta a ponta. ### FastAPI ou Django: qual aprender primeiro? FastAPI é direto para APIs tipadas e documentação automática. Django oferece estrutura completa, ORM, autenticação e admin. Escolha com base nas vagas e no projeto que pretende construir. Aprenda um com profundidade suficiente para terminar uma entrega antes de estudar o outro. ### Qual projeto colocar no portfólio? Uma API de candidaturas, tarefas, biblioteca ou eventos funciona bem se tiver persistência, validação, filtros, erros, testes e documentação. O domínio pode ser simples; a qualidade da execução é o diferencial. ### Preciso saber Docker e cloud para a primeira vaga? Nem sempre como requisito obrigatório. Porém, Docker Compose ajuda a demonstrar que outra pessoa consegue subir aplicação e banco. Cloud pode entrar depois, com um deploy pequeno, logs e configuração segura. ### Como procurar vagas se poucas usam o título exato? Busque por desenvolvedor Python, software engineer, analista de sistemas, desenvolvimento de APIs, Django, FastAPI, full stack e integrações. Leia o anúncio completo e procure combinações de Python, SQL, Git, banco, testes e Docker. ## Próximo passo Escolha hoje FastAPI ou Django e crie o repositório da API de candidaturas. Na primeira sessão, entregue apenas criação e consulta em memória. Na segunda, adicione teste. Depois migre para banco, implemente duplicidade, documente o ambiente e rode tudo em uma instalação limpa. Quando o projeto estiver reproduzível, compare suas habilidades com anúncios do [radar de vagas Python](/vagas/), ajuste o [currículo para vaga júnior](/carreira/curriculo-python-vaga-junior/) e use a lista de [projetos de portfólio Python](/carreira/projetos-portfolio-python/) para planejar uma segunda entrega. Entrar em backend não exige aprender toda a internet: exige demonstrar fundamentos, terminar um sistema pequeno e comunicar com clareza como ele funciona.