Firefox about:blank

(\ (\
( • •)
━∪∪━━━━
ᵇʸ ᴬˡᵉᶠᵘᵉⁿᵗᵉˢ

Stefanini | Perguntas sobre Teste Técnico

Este é o seu Guia Mestre de Preparação para a Entrevista na Stefanini. Reuni e refinei todas
as perguntas, dicas e justificativas técnicas que discutimos durante a construção do seu projeto.

Foi projetado para transformá-lo de um "candidato que sabe programar" em um "Engenheiro

Sênior que sabe tomar decisões de negócio".

Terá perguntas com respostas teóricas e de forma verbal.

DICA FINAL: Ao explicar o código, mova o mouse pelas pastas (domain, application,
infrastructure). Mostre que você sabe navegar na sua própria estrutura. Boa sorte, você tem
tudo para vencer!

DICAS FINAIS PARA O DIA 30/12/2025:

1. Navegação Visual: Ao explicar a arquitetura, não diga "no domínio", mostre a pasta no VS Code.
Que vejam que você sabe se mover pela sua estrutura.
2. O Diagrama é seu amigo: Se tiver oportunidade, abra o [Link] e mostre os diagramas Mermaid.
Isso impressiona visualmente e esclarece ideias rápido.
3. Mostre os Logs: Não há nada mais "Sênior" do que abrir o terminal e mostrar os dados se movendo.
Isso prova que não é "mágica", mas engenharia real.
4. Sinceridade Técnica: Se perguntarem algo que você não sabe, use a frase: "Nesta implementação
optei por X pela simplicidade do desafio, mas em um ambiente produtivo de maior escala consideraria
Y...".
5. A Stefanini é uma consultoria, portanto não só avaliam o que você fez, mas como o vende. Um
desenvolvedor Sênior deve soar seguro, pragmático e focado no negócio.

1 of 19 1/4/2026, 7:34 PM
Firefox about:blank

CATEGORIA 1: ARQUITETURA E DESIGN (O "POR QUÊ" DE

TUDO)(Hexagonal & DDD)
1. Por que você escolheu a Arquitetura Hexagonal para um projeto tão pequeno?

Teórica: Permite o desacoplamento entre o núcleo do negócio e as tecnologias externas (DB, API, UI).
Verbal: "Olha, embora seja um To-Do List, o projetei com mentalidade empresarial. Queria
demonstrar que posso proteger o código de negócio. Se amanhã a Stefanini me pedir para trocar o SQL
Server por um banco de dados NoSQL, o coração do sistema não fica sabendo. É investir agora para
economizar custos de manutenção depois".

2. Por que você escolheu Arquitetura Hexagonal para um To-Do List?

Teórica: Para desacoplar o Domínio (lógica de negócio) da Infraestrutura (detalhes técnicos como SQL
Server ou Angular), seguindo o princípio de Portas e Adaptadores.
Verbal: "Embora o requisito seja simples, o abordei com mentalidade corporativa. A Arquitetura
Hexagonal garante que, se a Stefanini decidir trocar o banco de dados ou migrar para outra tecnologia,
o coração do negócio permanece intacto. É um investimento em manutenibilidade a longo prazo."

3. Que diferença há entre uma Porta (Port) e um Adaptador (Adapter)?

Teórica: A porta é uma interface (contrato) e o adaptador é a implementação técnica.

Verbal: "A Porta é o que o domínio diz: 'preciso salvar uma tarefa'. O Adaptador é o cabo que
conectamos: 'aqui está a implementação com JPA e SQL Server'. É como um plugue universal".

Teórica: A Porta é uma interface (contrato) definida pelo domínio. O Adaptador é a implementação
técnica externa.

Verbal: "A Porta é o 'buraco' que o domínio deixa para se conectar ao mundo. O Adaptador é o 'cabo'
real. Por exemplo, minha porta de saída diz 'preciso de persistência', e meu adaptador JPA com SQL
Server é o cabo que conecto ali."

4. Por que você colocou as interfaces de Repositório no Domínio?

Teórica: Pelo Princípio de Inversão de Dependência (DIP).

Verbal: "Para que o domínio seja o chefe. Ele define o que precisa. Assim, a infraestrutura depende do
domínio e não o contrário. Se colocasse a interface na infraestrutura, meu negócio estaria 'escravizado'
pelo banco de dados".

5. Por que você separa a pasta domain da infrastructure?

Teórica: Para aplicar a Regra de Dependência: as camadas internas não devem conhecer nada das
externas.
Verbal: "Para que o negócio seja puro. Minha pasta domain não tem nem uma anotação do Spring ou
Hibernate. Isso me permite testar as regras de negócio sem precisar levantar bancos de dados ou
servidores, o que torna o desenvolvimento muito mais ágil e seguro."

6. Seu modelo de domínio é "Anêmico" ou "Rico"?

Teórica: O modelo anêmico só tem dados; o rico tem comportamento.

2 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Verbal: "Busquei um modelo rico. Minha entidade Task não é só um saco de dados; ela mesma
gerencia suas mudanças de estado e valida suas regras de negócio básicas. Evito que os serviços se
transformem em 'scripts' gigantes, distribuindo a responsabilidade corretamente."

7. O que é a "Linguagem Ubíqua" no seu projeto?

Teórica: O uso de termos do negócio no código.

Verbal: "Uso termos como Task, PENDING, COMPLETED. Se um analista de negócio ler meu código,
entende o que está acontecendo porque o código fala o idioma do processo, não só o idioma técnico".

8. Por que você cria DTOs (TaskRequest/Response) e não devolve a Entidade de Domínio diretamente?

Teórica: Para proteger o contrato da API e evitar o acoplamento entre o cliente e o domínio.
Verbal: "Para ter controle total sobre o que exponho ao Frontend. Ao usar DTOs (Java Records), posso
mudar a estrutura interna do meu banco de dados ou do meu domínio sem quebrar a interface que o
time de Angular consome. É uma camada de segurança e estabilidade."

9. Seu modelo de domínio é "Anêmico" ou "Rico"?

Teórica: O modelo anêmico só tem dados; o rico tem comportamento.

Verbal: "Tentei que fosse rico. Por exemplo, a entidade Task tem lógica para se validar ou mudar seu
estado. Não é só um saco de dados com getters e setters; tem regras de negócio dentro".

3 of 19 1/4/2026, 7:34 PM
Firefox about:blank

CATEGORIA 2: JAVA 21 & SPRING BOOT 3.5

1. Por que você usou Java 21 e não a versão 17 ou 11?

Teórica: Pelas melhorias em desempenho (Virtual Threads) e as novas estruturas de linguagem

(Records, Pattern Matching).
Verbal: "Java 21 é a versão LTS atual. Aproveitei os Records para que os DTOs sejam imutáveis e o
código muito mais limpo. Além disso, está pronto para usar Virtual Threads se precisássemos escalar
para milhares de usuários".

2. Quais vantagens reais você aproveitou do Java 21?

Teórica: Uso de Records, Pattern Matching e preparação para Virtual Threads.

Verbal: "Usei Java 21 principalmente pelos Records, que tornam os DTOs imutáveis e o código muito
mais limpo. Além disso, ao usar esta versão LTS, o projeto está otimizado para Virtual Threads,
permitindo escalar para milhares de requisições com um consumo de memória mínimo."

3. Por que você usa @MockitoBean em vez de @MockBean?

Teórica: @MockitoBean é a nova anotação no Spring Boot 3.4 que substitui a obsoleta @MockBean.

Verbal: "Quis manter o projeto dentro dos últimos padrões. O Spring Framework 6.2 introduziu um
novo sistema de 'Bean Overriding', e @MockitoBean é a forma recomendada agora. Demonstra que não
só uso o framework, mas sigo sua evolução técnica."

Teórica: É a nova anotação no Spring Boot 3.4 para substituir a obsoleta @MockBean.

Verbal: "Como usei Spring Boot 3.5, quis seguir as últimas recomendações. @MockBean está se
tornando obsoleto e @MockitoBean é a forma moderna de injetar mocks no contexto do Spring.
Demonstra que estou atualizado com o framework".

4. Para que servem os Java Records na sua API?

Teórica: São classes imutáveis projetadas para transportar dados.

Verbal: "Usei-os para os DTOs de entrada e saída. Eles me poupam de escrever construtores, getters e
equals/hashCode. Além disso, garantem que os dados não mudam enquanto viajam entre o controlador
e o serviço".

5. Por que você prefere WebClient em vez de RestTemplate?

Teórica: RestTemplate está em manutenção (deprecated); WebClient é não bloqueante e moderno.

Verbal: "RestTemplate é tecnologia do passado. WebClient é a solução oficial do Spring hoje em dia.
É reativo, suporta programação fluida e nos permite gerenciar chamadas a APIs externas de forma
muito mais eficiente e escalável."

6. Como você gerencia o ciclo de vida das métricas em um ambiente de teste?

Teórica: Os métodos @PostConstruct não são executados em testes unitários com @InjectMocks.
Verbal: "Tive que lidar com isso com cuidado. Como as métricas do Prometheus são inicializadas em
um @PostConstruct, nos testes unitários optei pela instanciação manual no setUp. Isso me permitiu
injetar um SimpleMeterRegistry real e garantir que os contadores não fossem nulos, assegurando testes
robustos."

4 of 19 1/4/2026, 7:34 PM
Firefox about:blank

7. Como você gerencia as transações na sua arquitetura?

Teórica: Mediante a anotação @Transactional na camada de Aplicação.

Verbal: "As gerencio nos serviços da camada de Aplicação. Assim, asseguro que, se algo falhar ao
salvar a tarefa ou ao enviar um evento, o banco de dados faça um rollback completo e não fiquem
dados corrompidos".

8. Por que você usa WebClient em vez de RestTemplate?

Teórica: WebClient é não bloqueante e é o padrão atual do Spring.

Verbal: "RestTemplate já está em modo manutenção. WebClient é o futuro: é reativo, mais poderoso e
gerencia muito melhor a concorrência. Embora aqui seja simples, deixa a porta aberta para uma
arquitetura não bloqueante".

5 of 19 1/4/2026, 7:34 PM
Firefox about:blank

CATEGORIA 3: FRONTEND (ANGULAR 20)

1. O que significa que sua aplicação é "Zoneless"?

Teórica: Que não depende do [Link] para detectar mudanças.

Verbal: "Significa que o Angular já não tem que vigiar cada clique ou movimento do mouse para ver
se atualiza a tela. É muito mais leve e rápido porque só se atualiza quando os Signals avisam
explicitamente".

Teórica: Para eliminar a dependência do [Link] e melhorar o desempenho da detecção de mudanças.

Verbal: "Zoneless é o futuro do Angular. Ao remover [Link], a aplicação fica mais leve e rápida. Não
há mais um processo global revendo toda a DOM sempre que um evento ocorre; agora o Angular só
atualiza o que os Signals indicam, otimizando a experiência do usuário."

2. Por que você usou Signals em vez de Observables do RxJS?

Teórica: Os Signals oferecem reatividade granular; RxJS é para fluxos de eventos assíncronos.

Verbal: "Os Signals são mais simples de ler e mais eficientes para o estado da UI. O Angular sabe
exatamente qual pedacinho do HTML mudar sem revisar toda a página. Deixei o RxJS apenas para as
requisições HTTP com HttpClient".

Teórica: Signals oferecem reatividade granular e síncrona; RxJS é melhor para fluxos assíncronos
complexos.

Verbal: "Os Signals tornam o código muito mais legível e previsível. O Angular sabe exatamente qual
pedaço do HTML deve mudar sem re-renderizar o componente todo. Reservo o RxJS apenas para as
requisições HTTP, onde seu poder para gerenciar fluxos assíncronos ainda é imbatível."

*3. Por que você usa o novo Controle de Fluxo (@for, @if) em vez das diretivas antigas (ngIf)?

Teórica: Melhor desempenho e tipagem, sem necessidade de importar CommonModule.

Verbal: "É muito mais limpo. Você já não precisa de *ngIf. Por ser nativo do compilador, é mais
rápido e me permite usar o bloco @empty que é ótimo para mostrar uma mensagem quando não há
tarefas".

Teórica: É nativo do compilador, mais rápido e não requer importar CommonModule.

Verbal: "É muito mais limpo e tem desempenho superior. O que mais gosto é o bloco @empty; me
permitiu lidar com o estado de 'sem tarefas' de forma elegante e sem lógica extra no componente."

4. Como você gerencia a segurança de tipos (Type Safety) nos templates?

Verbal: "Evito o uso de any. Por exemplo, na listagem de tarefas, exponho os Enums do Java
diretamente para o componente do Angular. Assim, o compilador me avisa se tento usar um estado que
não existe, evitando erros em produção."

5. Como você configurou a comunicação com o Backend em desenvolvimento?

Teórica: Usando um arquivo de configuração de Proxy ([Link]).

6 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Verbal: "Configurei um proxy no Vite. Assim, quando o front pede /api, o navegador acredita que é o
mesmo site e não tenho problemas de CORS, redirecionando tudo para a porta 8080 do Java".

6. O que é um Componente "Standalone"?

Teórica: Um componente que se gerencia sozinho sem necessidade de estar em um NgModule.

Verbal: "É a nova forma de trabalhar. Cada componente declara suas próprias dependências. Isso faz
com que o app seja modular e que o 'Lazy Loading' seja muito fácil de implementar para que carregue
rápido".

7 of 19 1/4/2026, 7:34 PM
Firefox about:blank

BLOCO 4: PERSISTÊNCIA E SQL SERVER

1. Por que você usa Flyway em vez de ddl-auto: update?

Teórica: Para versionar o esquema e assegurar implantações determinísticas.

Verbal: "Em produção, o update automático do Hibernate é perigoso e imprevisível. Com Flyway,
cada mudança é um script SQL versionado. Isso garante que meu banco de dados no local, no CI/CD e
no Azure seja exatamente o mesmo."

2. Por que você usa Flyway e não deixa o Hibernate criar as tabelas?

Teórica: Para ter controle de versões sobre o esquema do banco de dados.

Verbal: "Em produção, deixar o Hibernate deletar ou criar tabelas é perigoso. Com Flyway, cada
mudança é um script SQL versionado. Assim, todos os desenvolvedores e o pipeline de CI/CD têm
exatamente o mesmo banco de dados".

3. Como você implementou a paginação no servidor?

Teórica: Usando o objeto Pageable do Spring Data JPA.

Verbal: "Não trago todos os dados e depois corto a lista. Peço ao SQL Server apenas os 5 registros de
que preciso usando offset e fetch. É a única forma de o sistema ser escalável se chegarmos a ter
milhões de tarefas".

4. Como você implementou a paginação para que fosse escalável?

Teórica: Usando Pageable do Spring Data JPA no backend para realizar consultas com OFFSET e FETCH.
Verbal: "Implementei paginação de ponta a ponta. O backend só traz os 5 registros que o usuário está
vendo. Isso economiza memória no servidor e largura de banda na rede. No front, uso um Computed
Signal para gerar a navegação dinamicamente com base no que o servidor me reporta."

5. Por que você usa UUID em vez de IDs numéricos autoincrementais?

Teórica: Desacoplamento do banco de dados e prevenção de ataques de enumeração.

Verbal: "O UUID permite que o domínio gere a identidade da tarefa antes de tocar no banco de dados.
Além disso, é mais seguro: ninguém pode adivinhar quantas tarefas temos simplesmente mudando um
número na URL (IDOR attacks)."

6. Por que você usa UUID em vez de um ID autoincremental?

Teórica: Para evitar colisões em sistemas distribuídos e melhorar a segurança.

Verbal: "O ID numérico é previsível e pode ser um risco de segurança. Com UUID, o ID é gerado
antes de chegar ao banco de dados, o que facilita a integração e evita ataques de enumeração na API".

7. Como você assegura que o Enum seja salvo como String no banco de dados?

Teórica: Usando a anotação @Enumerated([Link]).

Verbal: "Salvo como texto. Se amanhã eu mudar a ordem dos estados no código, o banco de dados não
quebra, porque o valor 'PENDING' continua sendo o mesmo texto. É muito mais sustentável do que
usar números".

8. O que seu script [Link] faz no Docker?

8 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Teórica: Automa a criação do banco de dados se ele não existir.

Verbal: "É para que o projeto seja 'conectar e usar'. O script detecta se stefaninidb existe e, se não, a
cria. Assim, ninguém tem que abrir o gerenciador de banco de dados manualmente para começar a
trabalhar".

9 of 19 1/4/2026, 7:34 PM
Firefox about:blank

BLOCO 5: DEVOPS & QUALIDADE, CI/CD E DOCKER

1. Como você garante o princípio de "Idempotência" no seu ambiente de desenvolvimento?

Teórica: Mediante o uso de contêineres Docker e scripts de inicialização.

Verbal: "Utilizo Docker Compose para que qualquer desenvolvedor (ou o pipeline de CI) tenha
exatamente o mesmo ambiente. Minha configuração inclusive cria automaticamente o banco de dados
stefaninidb se ele não existir, eliminando o clássico 'na minha máquina funciona'."

2. Quais dificuldades você teve com o SQL Server no Docker e como as resolveu?

Verbal: "O maior desafio foi a latência de inicialização. O SQL Server leva alguns segundos para ficar
pronto. Resolvi implementando um Side-car Script no Docker Compose com um loop de retentativa.
O script espera o motor estar 'saudável' antes de tentar criar o banco de dados, garantindo que a
inicialização seja sempre bem-sucedida."

3. Para que serve o Health Check no seu pipeline de GitHub Actions?

Teórica: Para assegurar a disponibilidade de serviços dependentes antes de executar os testes.

Verbal: "É minha rede de segurança. O pipeline não tenta compilar ou testar até que o contêiner do
SQL Server responda positivamente. Isso evita falsos negativos no CI/CD causados pela lentidão dos
serviços de infraestrutura."

4. Por que você inclui um volume nomeado (sql_data) no seu Docker?

Verbal: "Para separar os dados do ciclo de vida do contêiner. Se paro ou deleto o contêiner, minhas
tarefas criadas não são perdidas. Além disso, no Windows, os volumes nomeados têm um desempenho
de leitura/escrita superior às pastas compartilhadas."

5. O que é a Idempotência no seu pipeline de CI/CD?

Teórica: Que o resultado seja sempre o mesmo não importa quantas vezes seja executado.
Verbal: "Meu pipeline recria tudo do zero em contêineres. Não importa se você roda hoje ou em um
ano, o ambiente do SQL Server será idêntico. Isso me dá a segurança de que o código que passou nos
testes no GitHub Actions funcionará igual em produção".

6. Por que você separa os Testes Unitários dos de Integração?

Teórica: Por velocidade e cobertura. Os unitários testam lógica; os de integração testam a "fiação".
Verbal: "Os unitários são rápidos e testam minhas regras de negócio com Mockito. Os de integração
são mais lentos porque levantam o Spring e o banco de dados, mas são vitais para assegurar que os
JSONs e as consultas SQL funcionam de verdade".

7. Como você gerencia o fluxo de branches no projeto?

Teórica: Sigo o padrão do GitFlow.

Verbal: "Uso GitFlow. Nada vai para a main sem passar por um Release. As funcionalidades são
desenvolvidas em feature/ e integradas em develop. É a forma mais organizada de trabalhar em times
grandes como os da Stefanini".

8. Para que serve o Health Check que você colocou no Docker Compose?

10 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Teórica: Para que os serviços dependentes esperem até que o banco de dados esteja pronto.
Verbal: "O SQL Server leva alguns segundos para inicializar. Sem o Health Check, o script de
inicialização falharia por 'conexão recusada'. Com isso, o Docker espera até que o motor esteja
'saudável' antes de tentar criar o banco de dados".

9. Como você garante o "Clean Code" neste projeto?

Teórica: Aplicando os princípios SOLID, nomes descritivos e funções pequenas.

Verbal: "Aplico o princípio da Responsabilidade Única. Cada classe faz uma coisa só. Meus
controladores só recebem dados, meus serviços orquestram e meu domínio manda. Se o código é fácil
de ler, é fácil de manter".

11 of 19 1/4/2026, 7:34 PM
Firefox about:blank

CATEGORIA 6: GERAL & SOFT SKILLS

1. Como você utilizou a IA neste desafio? (Pergunta obrigatória do enunciado).

Teórica: Como assistente de arquitetura e gerador de boilerplate sob supervisão.

Verbal: "A usei como um 'Senior Copilot'. Ela me ajudou a estruturar rapidamente as pastas da
arquitetura hexagonal e a gerar o CSS do Tailwind. Mas atenção: cada linha foi revisada e refatorada
por mim para assegurar que cumpra com SOLID. A IA acelera o processo, mas o critério é meu".

2. O que você faria se o cliente te pedisse uma nova funcionalidade amanhã?

Teórica: Seguir o fluxo do GitFlow e adicionar um novo Caso de Uso.

Verbal: "Criaria uma branch feature/nova-funcionalidade, definiria a porta no domínio,
implementaria o caso de uso e depois o controlador. Graças à arquitetura hexagonal, sei exatamente
onde tocar sem quebrar o que já funciona".

3. Qual foi o maior desafio técnico que você teve aqui?

Verbal: "Sincronizar a paginação de ponta a ponta. Assegurar que o objeto Page do Spring fosse
mapeado corretamente para minha PaginatedResponse de domínio e que o Angular atualizasse os
Signals sem perder a integridade. Foi um desafio de design de contratos".

4. Como você escalaria esta aplicação para milhões de tarefas?

Verbal: "No backend usaria Virtual Threads do Java 21 para o I/O. No banco de dados adicionaria
índices aos campos de busca e talvez um cache com Redis. No front, o Angular 20 Zoneless já está
preparado para gerenciar milhares de nós no DOM sem se abalar".

5. Por que deveríamos contratá-lo com base neste código?

Verbal: "Porque este código não é apenas uma solução para um problema; é uma demonstração de
padrões de engenharia. Domino desde o pipeline de DevOps até a reatividade moderna do frontend,
sempre priorizando a manutenibilidade e a arquitetura limpa. Estou pronto para contribuir com
qualidade desde o primeiro dia na Stefanini".

12 of 19 1/4/2026, 7:34 PM
Firefox about:blank

BLOCO 7: METODOLOGIA E SOFT SKILLS

1. Como você utilizou a IA durante este desenvolvimento? (Pergunta CHAVE do desafio).

Verbal: "A utilizei como um Senior Copilot. Ela me ajudou a acelerar a criação da estrutura de pastas
e o CSS do Tailwind. Entretanto, cada linha de código gerada passou por minha revisão manual para
assegurar que cumpria com SOLID, Clean Code e as restrições da minha Arquitetura Hexagonal. É
uma ferramenta para ganhar produtividade, mas o critério técnico é 100% meu."

2. Por que você aplica GitFlow em um projeto individual?

Verbal: "Porque desenvolvo como se estivesse em um time profissional da Stefanini. O uso de

branches de feature e releases me obriga a ter disciplina, assegura que a branch main esteja sempre
estável e deixa um histórico do Git que conta uma história clara de como o software evoluiu."

3. Como você gerencia as revisões de código (Code Reviews)?

Verbal: "Através de Pull Requests no GitHub. Mesmo neste desafio, não fiz merges diretos. Publiquei
minhas branches de feature e deixei o pipeline de CI validar o código antes de integrá-lo. É a única
forma de garantir a qualidade total."

4. O que você faria se o Kafka falhasse no meio do salvamento de uma tarefa?

Verbal: "Implementei um bloco try-catch com log no serviço. A prioridade é o negócio (salvar a tarefa
no banco de dados). Se a notificação assíncrona falhar, logamos o erro para que o Suporte aja, mas não
bloqueamos o usuário. Isso é projetar para a Resiliência."

5. Como você escalaria este monorepo se o time crescesse para 50 pessoas?

Verbal: "Poderíamos migrar para microserviços reais. Como o backend já usa Arquitetura Hexagonal,
o 'Domínio' já está isolado. Seria simples extrair a lógica de tarefas para seu próprio repositório. O
monorepo foi uma decisão inicial para manter a consistência do contrato API-Front."

6. Qual é o maior valor da sua solução?

Verbal: "Não é só que o app funciona. É que é uma solução Enterprise-Grade. Está documentada
com diagramas Mermaid, monitorada com Prometheus, desacoplada com Kafka e protegida com um
pipeline de CI/CD automático. Está pronta para ser colocada em produção hoje mesmo."

13 of 19 1/4/2026, 7:34 PM
Firefox about:blank

SIMULADO DE ENTREVISTA TÉCNICA (Stefanini Brasília)

Para terminar com chave de ouro, aqui está o Simulado de Entrevista Final consolidado. Estas são as
perguntas "pegadinhas" que um arquiteto da Stefanini poderia fazer e como você deve responder usando o
projeto que acabou de construir.

Vejo que você usou Arquitetura Hexagonal. Não acha que é complexidade demais para um To-Do List?

Resposta Sênior: "Se o objetivo fosse apenas um CRUD rápido, sim. Mas para a Stefanini, projetei
uma solução Enterprise-Ready. A Arquitetura Hexagonal assegura que, se amanhã o cliente pedir
para trocar o SQL Server pelo CosmosDB ou migrar de uma API REST para gRPC, 80% do código (o
Domínio) não muda. É um investimento em manutenibilidade e escalabilidade."

Que vantagem real você aproveitou do Java 21?

Resposta Sênior: "Utilizei os Java Records para garantir a imutabilidade dos DTOs e facilitar o
mapeamento nas portas da arquitetura. Além disso, o projeto está preparado para Virtual Threads, o
que permitiria escalar para milhares de requisições concorrentes de forma eficiente sem sobrecarregar a
memória do servidor."

Por que você escolheu o modo Zoneless em vez do padrão com [Link]?

Resposta Sênior: "Porque o Angular 20 foi projetado para ser eficiente. Ao usar Signals, a detecção
de mudanças é granular: o Angular sabe exatamente qual parte da DOM atualizar. Ao ser Zoneless,
eliminamos a sobrecarga de interceptar todos os eventos assíncronos do navegador, o que resulta em
uma aplicação mais leve e com uma resposta muito mais rápida para o usuário."

Como você gerencia a segurança dos seus dados no pipeline de CI/CD?

Resposta Sênior: "Utilizo Service Containers do Docker no GitHub Actions. Isso me permite
levantar uma instância real do SQL Server durante o pipeline. A criação do banco de dados
stefaninidb está automatizada por meio de scripts

Por que você escolheu Arquitetura Hexagonal para um To-Do List?

Teoria: O padrão busca desacoplar a lógica de negócio (Domínio) dos detalhes técnicos
(Infraestrutura).
Verbal: "Olha, embora um To-Do List pareça simples, o projetei pensando em escalabilidade
empresarial. A Arquitetura Hexagonal me permite que o negócio não seja 'escravo' da tecnologia. Se
amanhã a Stefanini decidir migrar do SQL Server para o MongoDB, 80% do meu código não muda. É
um investimento em manutenibilidade."

Qual diferença há entre uma Porta (Port) e um Adaptador (Adapter)?

Teoria: A porta é a interface (contrato) e o adaptador é a implementação concreta.

Verbal: "A Porta é o 'buraco' que o domínio deixa para se conectar; é uma interface pura. O Adaptador
é o cabo real que conectamos aí. Meu TaskRepositoryPort é o buraco, e meu TaskPersistenceAdapter
com JPA é o cabo."

14 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Por que você colocou as interfaces de repositório no Domínio?

Teoria: Para aplicar a Inversão de Dependência (DIP).

Verbal: "Para que o domínio seja o dono do contrato. Assim, a infraestrutura depende do domínio e
não o contrário. Se colocasse a interface na infraestrutura, minha lógica de negócio estaria acoplada ao
banco de dados, violando o isolamento."

Seu modelo de domínio é "Anêmico" ou "Rico"?

Teoria: O modelo rico inclui lógica de negócio; o anêmico só tem getters e setters.
Verbal: "Busquei um modelo rico. Minha entidade Task tem lógica para mudar seu estado e se validar.
Não é apenas um objeto que transporta dados; tem comportamento próprio, o que facilita a manutenção
e evita serviços gigantes de 500 linhas."

Como você garante que o domínio não se contamine com Spring ou JPA?

Teoria: Mantendo a pasta domain livre de dependências externas.

Verbal: "Se você abrir minha pasta domain, verá que é Java puro. Não tem @Entity, não tem @Column. O
mapeamento para o banco de dados é feito exclusivamente na camada de Infrastructure por meio de
mappers e entidades JPA separadas. Assim, o coração do sistema é agnóstico à tecnologia."

Qual vantagem real você aproveitou do Java 21 neste projeto?

Teoria: Imutabilidade dos Records e eficiência do JDK moderno.

Verbal: "Principalmente os Java Records. Usei-os para todos os DTOs e eventos do Kafka. Eles me
dão imutabilidade por padrão e um código muito mais limpo. Além disso, o projeto está preparado para
Virtual Threads, o que permitiria escalar para milhares de requisições com pouca RAM."

Para que servem os Records na sua arquitetura?

Teoria: São classes projetadas exclusivamente para transportar dados de forma imutável.
Verbal: "Usei-os para os contratos de entrada e saída (DTOs). Por serem imutáveis, garanto que os
dados não sejam modificados acidentalmente enquanto viajam entre o controlador e o serviço. É
segurança e legibilidade ao mesmo tempo."

O que é @MockitoBean e por que você não usou @MockBean?

Teoria: É a nova anotação no Spring Boot 3.4 para substituir a obsoleta @MockBean.
Verbal: "Usei @MockitoBean porque é o novo padrão do Spring Framework 6.2. Como desenvolvedor
Sênior, me mantenho atualizado com a evolução do framework. @MockBean está se tornando obsoleto e
quis que o projeto da Stefanini nascesse com as melhores práticas atuais."

Por que você usa WebClient em vez de RestTemplate?

Teoria: RestTemplate está em modo de manutenção; WebClient é reativo e moderno.

Verbal: "RestTemplate é tecnologia do passado. WebClient é a aposta oficial do Spring. Embora aqui
o use para uma chamada simples, me permite ter uma base reativa e não bloqueante, o que melhora a
escalabilidade do sistema."

15 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Como você gerencia as exceções de forma global?

Teoria: Uso de @RestControllerAdvice para centralizar o tratamento de erros.

Verbal: "Implementei um GlobalExceptionHandler. Assim, qualquer erro de negócio (como uma tarefa
não encontrada) é traduzido automaticamente para um código HTTP correto (404) com um JSON
amigável. Centralizar isso evita ter blocos try-catch repetidos em todos os controladores."

O que significa que seu Angular seja "Zoneless"?

Teoria: Que não depende do [Link] para detectar mudanças.

Verbal: "Significa desempenho puro. Ao eliminar [Link], o Angular já não precisa vigiar cada clique
ou movimento do mouse globalmente. A aplicação é mais leve e rápida, já que só se atualiza quando os
Signals avisam explicitamente."

Por que você usou Signals em vez de apenas Observables (RxJS)?

Teoria: Os Signals oferecem uma reatividade granular e síncrona mais eficiente para o estado da UI.
Verbal: "Os Signals tornam o código muito mais legível. O Angular sabe exatamente qual pedacinho
da tela mudar sem revisar toda a árvore de componentes. Reservei o RxJS apenas para as requisições
HTTP, onde seu poder para gerenciar fluxos de dados assíncronos continua sendo o melhor."

Qual vantagem tem o novo Controle de Fluxo (@for, @if)?

Teoria: É nativo do compilador, mais rápido e reduz o bundle.

Verbal: "É muito mais limpo. Já não preciso importar CommonModule em cada componente standalone
para usar um simples loop. Além disso, o bloco @empty é uma joia; me permitiu gerenciar o estado de
'sem tarefas' de forma nativa e elegante."

Como você gerencia a segurança de tipos (Type Safety) no Front?

Teoria: Uso estrito de interfaces TypeScript e Enums que coincidem com o Backend.
Verbal: "Evito o uso de any. Por exemplo, exportei os Enums de status para usá-los nos templates.
Assim, o compilador do Angular me avisa se tento atribuir um estado que não existe. Se o código não é
seguro em tipos, não é código profissional."

Por que você usa uma arquitetura de componentes Standalone?

Teoria: Eliminação de NgModules para modularidade e tree-shaking.

Verbal: "É a forma moderna do Angular. Cada componente se gerencia sozinho. Isso facilita muito o
Lazy Loading e os testes unitários, porque não é preciso arrastar um AppModule gigante para testar um
simples botão."

Por que você usa Flyway em vez de ddl-auto: update?

Teoria: Para controle de versões do banco de dados e implantações determinísticas.

Verbal: "Em produção, o update automático é perigoso. Com Flyway, cada mudança é um script SQL
versionado. Isso garante que meu banco de dados local, no CI/CD e na nuvem seja exatamente o
mesmo. É disciplina de engenharia."

16 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Como você implementou a paginação para que fosse eficiente?

Teoria: Paginação no lado do servidor usando Pageable do Spring Data.

Verbal: "Pagina desde o banco de dados até a UI. Não trago 1000 tarefas para mostrar 5; peço ao SQL
Server apenas os 5 registros necessários usando OFFSET. Isso economiza memória no servidor e largura
de banda na rede."

Por que você usa UUID em vez de IDs Long autoincrementais?

Teoria: Desacoplamento do banco de dados e prevenção de ataques de enumeração.

Verbal: "O UUID permite que o domínio gere a identidade antes de tocar o BD. Além disso, é mais
seguro: ninguém pode adivinhar quantas tarefas temos simplesmente mudando um número na URL. É
um padrão em sistemas modernos e distribuídos."

Como você gerencia as datas entre Java e Angular?

Teoria: Uso de LocalDateTime e formato ISO no JSON.

Verbal: "Uso LocalDateTime no Java e o envio como string no formato ISO. No Angular, uso os Pipes
de data para mostrá-lo ao usuário de forma legível. Mantemos o dado puro no transporte e o
formatamos apenas na visualização."

Para que serve o script [Link] que você criou?

Teoria: Automação da infraestrutura (Idempotência).

Verbal: "É para que o projeto seja 'conectar e usar'. O script detecta se o banco de dados existe e, se
não, o cria. Assim, o desenvolvedor que baixar meu código só faz um docker-compose up e tudo está
pronto para trabalhar."

Como funciona seu pipeline de GitHub Actions?

Teoria: Fluxo automatizado de Compilação, Qualidade e Testes.

Verbal: "Meu pipeline é minha rede de segurança. A cada push, ele levanta um contêiner real do SQL
Server, compila o código, executa os testes unitários e de integração. Se algo falhar, o código não é
integrado. Assim garanto que a branch develop esteja sempre estável."

Por que você usa Docker Service Containers no pipeline?

Teoria: Para executar testes de integração sobre infraestrutura real em vez de mocks.
Verbal: "Porque não confio em 'mocks' para o banco de dados. Usar um contêiner real do SQL Server
no pipeline me assegura que minhas consultas SQL e minhas migrações do Flyway funcionam de
verdade antes de chegar à produção."

O que é GitFlow e por que você o aplica em um projeto individual?

Teoria: Metodologia de gerenciamento de branches para releases estáveis.

Verbal: "Porque desenvolvo como se estivesse em uma equipe de 50 pessoas. O GitFlow me obriga a
ter ordem: as funcionalidades em feature/, a integração em develop e as versões estáveis em main.
Deixa um histórico do Git que conta uma história clara de qualidade."

17 of 19 1/4/2026, 7:34 PM
Firefox about:blank

Como você gerencia a persistência dos dados se o contêiner do SQL Server for apagado?

Teoria: Por meio do uso de volumes nomeados (Named Volumes).

Verbal: "Utilizo Volumes Nomeados no Docker. Isso separa o ciclo de vida dos dados do ciclo de vida
do contêiner. Você pode apagar o contêiner mil vezes, mas suas tarefas salvas continuarão lá. É uma
prática básica de resiliência."

Como você garante a idempotência do seu ambiente de desenvolvimento?

Teoria: Capacidade de executar o ambiente múltiplas vezes obtendo o mesmo resultado.

Verbal: "Graças ao Docker e aos meus scripts de inicialização. Não importa em qual máquina você
execute meu projeto; o resultado será idêntico. Eliminei o clássico erro de 'na minha máquina funciona'
automatizando toda a configuração da infraestrutura."

18 of 19 1/4/2026, 7:34 PM
Firefox about:blank

ÚLTIMAS PALABRAS
Has demostrado una gran capacidad para resolver errores de configuración, manejar divergencias en Git y
aplicar patrones de diseño complejos.

¡Mucho éxito! Tienes todo para conseguir esa vacante. ¡Estás listo! Tienes un proyecto de nivel
10/10. ¡Mucho éxito en Brasilia!

19 of 19 1/4/2026, 7:34 PM