Março e abril de 2026: o desafio na mesa

Em março e abril de 2026, entre conversas de recolocação e triagem de oportunidades, surgiu um teste prático enviado por uma empresa de TI de Jaraguá do Sul, SC. O enunciado pedia uma API REST de cadastro e consulta de veículos — e, ao mesmo tempo, deixava claro que o que mais pesava era arquitetura, organização, separação de responsabilidades e clareza. O cenário corporativo permanece anonimizado; o que importa aqui é o mapa mental que qualquer banca espera ver.

Nota sobre o tempo: Na prova real foi dada uma janela de quatro horas. A página índice da série explica se isso é factível e em que condições; neste episódio o recado é direto: com prazo curto, os primeiros minutos investidos em ler o PDF — em vez de abrir o IDE às cegas — são os que mais compram margem para o resto do desafio.

O problema por trás da etapa

A pressa de codar é uma armadilha elegante. Ela parece produtividade, mas muitas vezes é apenas ansiedade com sintaxe. Quando o PDF chegou, a primeira vontade natural era abrir o Spring Initializr, marcar dependências e sair criando a entidade Veículo. O problema é que o próprio enunciado avisava, ainda que com outras palavras, que o funcionamento da aplicação era importante, mas não era o centro da avaliação.

O foco estava em arquitetura, organização do código, clareza, separação de responsabilidades, domínio das tecnologias e funcionamento. Essa lista muda completamente o jeito de encarar o desafio. Não estamos apenas entregando endpoints que respondem 200: estamos entregando uma pequena demonstração de como pensamos, onde colocamos as regras, como nomeamos as peças e como evitamos que uma solução simples vire um bloco único difícil de explicar.

Neste primeiro episódio, a meta é fazer o que quase nunca aparece no commit final: ler o problema com calma. O desafio pedia Java 17 ou superior, Spring Boot ou Quarkus, OpenAPI/Swagger, API REST, JPA/Hibernate, H2 em memória, migrations com Flyway ou Liquibase e Bean Validation. Também exigia organização mínima em camadas: Web, Application, Domain e Infra. Esses nomes não são decoração: são um mapa do que a banca espera encontrar.

A decisão técnica

A primeira decisão foi escolher a trilha. Entre Spring Boot e Quarkus, optei por Spring Boot por uma razão pragmática: ele é familiar nesse tipo de teste, combina de forma direta com Spring Web, Spring Data JPA, Bean Validation, H2, Flyway e springdoc-openapi, e permite gastar energia no desenho da solução em vez de defender escolhas de infraestrutura.

Essa escolha não torna Quarkus pior — em outro contexto, seria ótima. Mas para um teste cujo avaliador provavelmente quer abrir, rodar, acessar o Swagger e entender rapidamente a arquitetura, Spring Boot reduz atrito. Atrito é inimigo silencioso de boas entregas técnicas.

A segunda decisão foi desenhar a estrutura antes de escrever classe. A camada Web ficaria responsável por HTTP: controllers, DTOs de entrada e saída, documentação OpenAPI e tratamento de erros de borda. A camada Application concentraria os casos de uso. A camada Domain guardaria o modelo de veículo, enumeradores e contratos. A camada Infra implementaria persistência, configuração do H2, migrations e adapters concretos.

Implementando com critério

Essa separação é simples, mas poderosa. Evita que o controller saiba demais sobre banco; evita que a entidade dependa de anotações ou objetos de transporte que só fazem sentido na API; evita que regra de negócio fique perdida em método privado de controller.

O desafio não pedia microsserviços, mensageria, cache distribuído nem autenticação. Funcionalidades extras são bem-vindas apenas se não comprometerem simplicidade e clareza. A arquitetura precisa parecer madura, não inchada.

Com isso, o plano de ataque fica evidente: base do projeto com dependências certas; domínio de Veículo; persistência com JPA, H2 e Flyway; camada de aplicação com casos de uso; por fim, endpoints, validação, erros e Swagger.

Fechamento da etapa

Vale transformar o PDF em checklist: compilar, executar, manual de arranque em README.md (Swagger, H2 e como subir), CRUD com paginação, HTTP 400 em validação, controllers delegando à aplicação. Quando esse checklist existe desde o primeiro dia, ele guia o desenvolvimento.

A pergunta de fundo não será só “isso funciona?”, mas também “isso está no lugar certo?”, “alguém entenderia em cinco minutos?” e “eu defenderia isso em entrevista técnica?”. O desafio vira pequena história de engenharia: ler, decidir, construir, validar, documentar e entregar.

Como defender essa etapa

Mostre que o plano nasceu do enunciado: camadas, controllers simples, application, domain e infra não são capricho — são resposta ao texto do PDF. Explique o que ficou de fora (auth, mensageria…) como foco, não como lacuna de conhecimento.

Cada episódio desta série amarra uma parte do checklist. O código deixa de ser pasta solta e passa a ser sequência de decisões — exatamente o que uma recolocação em 2026 precisa demonstrar sob pressão.

Reflexão final: A pausa antes do primeiro commit é vantagem competitiva silenciosa. No próximo episódio, preparamos o terreno com Spring Boot, dependências e estrutura inicial.

---

Nota: Cenário anonimizado; conteúdo técnico reutilizável (Fiction-Based Technical Insights).