Perguntas de Entrevista para Engenheiro de Software

Resposta-modelo

No meu último cargo, desenhei uma plataforma de processamento de pagamentos que integrava vários fornecedores. Comecei pelo levantamento de requisitos com as equipas de negócio e de segurança, defini uma arquitetura de microserviços com filas de mensagens para desacoplar a receção do processamento e estabeleci limites de responsabilidade claros entre serviços. Implementei observabilidade desde o início, com métricas e registos centralizados, o que permitiu detetar problemas antes de afetarem os utilizadores.

Resposta-modelo

Combino várias práticas: revisão de código obrigatória em cada alteração, testes automatizados com metas de cobertura realistas, análise estática integrada no pipeline de CI/CD e uma definição clara de 'pronto' para cada tarefa. Além das ferramentas, procuro promover uma cultura em que a equipa se sente responsável pela qualidade e em que o feedback nas revisões é construtivo.

Resposta-modelo

Optei por manter um monólito modular em vez de migrar de imediato para microserviços num produto ainda em fase inicial. A complexidade operacional dos microserviços não se justificava com a dimensão da equipa e do tráfego. O compromisso foi aceitar algum acoplamento em troca de velocidade de entrega. Definimos limites internos claros para facilitar uma futura separação, que acabou por acontecer 18 meses depois, já com dados que a justificavam.

Resposta-modelo

Começo por reunir evidências antes de formular hipóteses: registos, métricas, rastreios distribuídos e o padrão temporal das ocorrências. Tento reproduzir o problema num ambiente controlado e, quando não é possível, aumento a observabilidade na zona suspeita. Isolo variáveis de forma sistemática, documento cada passo e, ao encontrar a causa raiz, acrescento um teste ou um alerta que evite a regressão.

Resposta-modelo

Leio regularmente documentação técnica e artigos de engenharia de empresas de referência, acompanho projetos de código aberto e participo em comunidades e encontros técnicos em Lisboa e no Porto. Sempre que possível, experimento novas ferramentas em projetos pessoais antes de as propor no trabalho, para avaliar com base em experiência real e não em modas.

No processamento síncrono, o chamador espera pela resposta; no assíncrono, a tarefa é colocada numa fila e processada mais tarde. Uso o síncrono quando a resposta imediata é indispensável, por exemplo numa validação de credenciais. Recorro ao assíncrono para tarefas demoradas ou tolerantes a latência, como o envio de mensagens ou o processamento de imagens, o que melhora a resiliência e a escalabilidade do sistema.

Depende dos requisitos. Quando é aceitável, prefiro consistência eventual com padrões como o outbox transacional e idempotência nos consumidores. Quando o domínio exige consistência forte, por exemplo num saldo financeiro, recorro a transações ou a mecanismos como o padrão saga com compensações. O essencial é tornar explícitas as garantias que cada operação oferece.

Primeiro analiso o plano de execução para perceber onde está o custo. Depois avalio índices adequados, reescrevo a consulta para reduzir varrimentos de tabela, limito as colunas devolvidas e, se necessário, pondero desnormalização ou cache para leituras frequentes. Meço sempre antes e depois para confirmar a melhoria com dados.

Uma operação idempotente produz o mesmo resultado quer seja executada uma ou várias vezes. É essencial numa API porque as redes falham e os clientes repetem pedidos; sem idempotência, uma repetição poderia, por exemplo, cobrar duas vezes um pagamento. Costumo implementá-la com chaves de idempotência guardadas do lado do servidor.

Apresentaria a minha posição com dados e alternativas, num contexto adequado e não perante toda a equipa. Se, depois de ouvidos os argumentos, a decisão se mantivesse, apoiá-la-ia de forma profissional, deixando eventualmente registada a minha preocupação. O objetivo é o melhor resultado para o produto, não ter razão.

A prioridade seria repor o serviço, recorrendo a rollback ou a uma correção rápida. Só depois investigaria a causa raiz com calma, sem procurar culpados. Faria uma análise post-mortem sem culpabilização, documentaria as lições e implementaria salvaguardas, como testes, alertas ou validações, para evitar a repetição.

Falaria primeiro em privado, de forma respeitosa, para perceber o contexto e oferecer apoio, por exemplo através de programação em par ou de revisões mais próximas. Se o padrão persistisse, envolveria o gestor de engenharia. Procuraria sempre separar o problema técnico da pessoa e apoiar a melhoria.

Não avançaria com pressupostos silenciosos. Formularia perguntas concretas às partes interessadas, proporia exemplos ou um protótipo para clarificar expectativas e documentaria os requisitos acordados antes de investir esforço significativo na implementação.