Backend Python Júnior: O Que Estudar, Projeto e Como Buscar Vagas

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 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 é:

Veja o comparativo 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 explica a integração, enquanto o guia de Docker Compose com PostgreSQL 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 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

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:

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 apresenta uma opção compacta para aprender.

Teste do comportamento principal

Com o cliente de testes do FastAPI:

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 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, 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 ajuda a revisar entrega, e o simulador de 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

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, ajuste o currículo para vaga júnior e use a lista de projetos de portfólio 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.