Entrevista de Tech Lead: defenda uma decisão técnica sem esconder os riscos

Em uma entrevista de Tech Lead, explicite o custo da decisão que você defende. “Eu faria uma migração incremental” é apenas uma preferência até você explicar qual parte muda primeiro, quem consegue sustentá-la e o que acontece quando o resultado contradiz sua aposta. Inclua na defesa as condições que fariam você mudar de ideia.

Neste exercício original, uma equipe deve modernizar uma cotação de frete sem comprometer a operação atual. Você vai comparar alternativas, escrever um registro de decisão e interpretar um rollout que parece saudável no agregado, mas apresenta problemas no grupo novo. Comece por Deep-Dive Two Projects Through Technical Decisions: descreva uma decisão sua com alternativas reais, não apenas a tecnologia escolhida.

Limite da evidência: AWS, Martin Fowler e Google SRE fundamentam práticas de documentação, modernização e avaliação de releases. O sistema, as estimativas, os números e as respostas abaixo são um caso fictício de preparação. Não são relatos de candidatos nem um roteiro confirmado de contratação. Os cálculos foram verificados localmente; não executamos uma migração ou um experimento em produção.

Descubra qual problema a decisão precisa resolver

A aplicação atual consulta transportadoras e devolve uma cotação. A regra de arredondamento está misturada ao acesso externo, e mudanças pequenas exigem uma publicação ampla. O produto quer adicionar uma transportadora em oito semanas. O objetivo imediato é tornar essa integração verificável sem alterar silenciosamente o valor apresentado ao cliente.

O enunciado oferece quatro engenheiros, com dedicação planejada de 60% para a iniciativa. Os outros 40% cobrem suporte e compromissos existentes. Há uma pessoa com conhecimento profundo da integração antiga. Temos testes incompletos para arredondamento, acesso ao histórico de cotações e possibilidade de selecionar a implementação por configuração. Ainda precisamos verificar se as respostas históricas permitem reprodução fiel.

Abra com perguntas que mudam a escolha: a cotação é apenas uma estimativa ou um preço contratual? Qual prazo de validade tem a resposta externa? O sistema faz algum efeito irreversível nessa etapa? Neste caso, assumimos uma consulta sem criação de remessa ou cobrança. Se essa suposição estiver errada, o plano deve incluir reconciliação de efeitos antes de prometer retorno seguro ao código anterior.

Evite transformar “o legado é difícil” em requisito. Uma frase mais verificável seria: “Hoje não conseguimos testar uma alteração de arredondamento sem substituir o cliente da transportadora; quero criar essa fronteira antes de aumentar o número de integrações.” Ela relaciona um obstáculo observável a uma primeira entrega.

Também separe o prazo comercial da meta arquitetural. Integrar uma transportadora em oito semanas não significa eliminar o sistema antigo em oito semanas. Se o entrevistador insistir nesse resultado, mostre quais capacidades seriam retiradas do escopo ou qual compromisso de pessoal precisaria mudar. Não esconda a incompatibilidade dentro de uma estimativa otimista.

Compare alternativas sob as mesmas restrições

Considere três opções: manter o desenho atual com testes adicionais; criar uma fronteira e substituir uma integração de cada vez; reescrever todo o fluxo antes de trocar o tráfego. A primeira pode atender ao prazo com menor mudança estrutural, mas preserva acoplamentos. A segunda exige adaptação e convivência. A terceira pode simplificar o desenho final e ampliar o risco de descobrir regras antigas perto do corte.

Esses intervalos são entradas do exercício, não benchmarks de mercado. A capacidade nominal disponível é 4 × 8 × 0,60 = 19,2 engenheiro-semanas. A reescrita não cabe nessa capacidade nem no limite inferior estimado. A substituição cabe na conta nominal, mas isso não demonstra viabilidade: dependências sequenciais, revisão, ausências e concentração de conhecimento podem limitar a entrega.

A diferença entre 19,2 e 16 é 3,2 engenheiro-semanas, não uma reserva garantida. Pergunte se as estimativas já incluem observabilidade, teste do retorno e retirada do caminho temporário. Comparar uma alternativa completa a outra que contém apenas implementação favorece artificialmente a segunda. Registre o que foi incluído antes de discutir os totais.

Na descrição de Strangler Fig, Fowler apresenta modernização gradual e visível, sem prometer facilidade. No nosso caso, a fronteira de cotação é uma hipótese de divisão útil. Ela perde valor se cada consulta exigir estado compartilhado impossível de separar com segurança. A metáfora não substitui a investigação dessa dependência.

Escreva um ADR que permita discordância útil

A orientação da AWS sobre ADRs organiza decisões em contexto, decisão e consequências. Também trata mudanças posteriores com um novo registro que substitui o anterior. Para o treino, escreva um documento curto o suficiente para ser discutido, mas específico o suficiente para ser contestado.

ADR proposto — separar a fronteira de cotação. Contexto: adicionar uma transportadora em oito semanas com capacidade nominal de 19,2 engenheiro-semanas e testes incompletos de arredondamento. Decisão: isolar um contrato de consulta, manter o sistema antigo como referência inicial e migrar primeiro uma transportadora com configuração reversível. Não alterar formatos monetários externos nesta etapa.

Alternativas consideradas: o patch é mais barato e continua disponível se a descoberta da fronteira exceder o tempo reservado. A reescrita integral é adiada porque sua estimativa mínima ultrapassa a capacidade disponível. Essa decisão não afirma que reescrever é sempre errado; afirma que o conjunto atual de prazo, pessoas e desconhecimento não sustenta essa opção.

Consequências: manteremos temporariamente duas implementações, métricas separadas e responsabilidade explícita pela remoção do adaptador. A equipe pretende testar e substituir uma integração sem alterar todo o fluxo de cotação. O custo aceito é a convivência. O risco principal é comparar respostas que foram produzidas com preços ou condições diferentes.

Critério para rever a decisão: se a descoberta mostrar efeitos de escrita escondidos, contratos incompatíveis ou uma fronteira que exige sincronização extensa, o registro volta à discussão. Registre quem decide, quem deve ser consultado e quando a equipe revisará a evidência. Não apresente o Tech Lead como alguém que resolve sozinho compromissos de produto, segurança e operação.

Uma objeção sobre o custo de convivência deve mudar o documento. Se alguém disser que o adaptador virará permanente, não responda apenas “teremos disciplina”. Nomeie um responsável, uma condição de remoção e o trabalho ainda necessário. O registro torna essa obrigação verificável, mesmo que a remoção ocorra depois da integração.

Transforme rollout e retorno em perguntas verificáveis

O Google SRE descreve canarying como exposição parcial e limitada no tempo, seguida de avaliação. Neste exercício, o primeiro grupo recebe 5% das consultas elegíveis. A comparação deve separar versão, transportadora e tipo de solicitação. Uma média global pode diluir justamente a regressão que o teste precisa revelar.

Antes de encaminhar tráfego real, compare respostas usando entradas equivalentes e um conjunto controlado de respostas externas. Não envie consultas extras indiscriminadamente à transportadora: duplicar chamadas pode consumir limites, produzir valores diferentes ou gerar custos. Um replay local de respostas registradas também não demonstra que a integração ao vivo está correta.

Defina o retorno como uma operação sobre a configuração e verifique sua compatibilidade. A versão antiga ainda consegue ler o formato atual? Existe cache que continuará servindo resultados novos? Quem pode restaurar o roteamento e como saberá que a restauração atingiu todos os nós? “Temos uma flag” não responde a essas perguntas.

Para este caso somente de leitura, restaurar a rota pode conter novas respostas incorretas. Isso não desfaz uma cotação já exibida nem elimina compromissos assumidos pelo produto. Preserve identificadores mínimos e um procedimento para localizar resultados afetados. Se houver dados pessoais nos registros, controle acesso e retenção; não copie conteúdo de clientes para uma apresentação de entrevista.

Distribua responsabilidades antes do primeiro grupo: uma pessoa conduz a mudança, outra observa métricas e confirma o retorno, e o responsável de produto esclarece o tratamento de cotações afetadas. A pessoa que conhece o legado deve revisar o contrato com outra pessoa. Esse pareamento reduz dependência de conhecimento; não torna os dois automaticamente capazes de operar todos os incidentes.

Leia os números antes de promover a versão

O pacote fictício contém 10.000 consultas: 200 na versão nova e 9.800 no controle. Encontramos oito erros na nova e 49 no controle. A taxa nova é 8/200 = 4%; a do controle é 49/9.800 = 0,5%. O agregado é 57/10.000 = 0,57%. Concluir que o rollout está bom porque o agregado ficou abaixo de 1% ignora uma regressão no grupo exposto.

Há uma segunda armadilha: 200 de 10.000 consultas representam 2%, apesar da configuração anunciar 5%. A configuração pode atuar apenas sobre tráfego elegível, ou o roteamento pode estar incorreto. Falta o denominador elegível para concluir. Antes de aumentar exposição, investigue a diferença entre a intenção da configuração e a população observada.

O exercício define uma regra operacional ilustrativa: com pelo menos 100 consultas na versão nova, pausar se a taxa de erro ultrapassar 1% ou a divergência de cotação ultrapassar 0,5%. Duas divergências em 200 são 1% e também acionam pausa. Os valores são escolhas do caso, não limites oficiais, um teste de significância ou garantia de segurança.

Com 20 consultas e nenhum erro, a conclusão é “dados insuficientes para a regra”, não “aprovado”. Se faltarem métricas do controle, a comparação também está incompleta. Uma automação que converte ausência de dados em zero pode aprovar uma versão sem observações válidas. Ao apresentar a resposta, diga qual informação falta e mantenha o avanço bloqueado até existir evidência adequada.

Verificamos localmente seis condições: capacidade nominal, diferença de capacidade, taxas dos dois grupos, agregado, proporção observada de tráfego e divergência. Os cálculos confirmam a aritmética do pacote. Não validam distribuição aleatória, equivalência das populações, confiabilidade da coleta ou poder estatístico. Essas são perguntas adicionais para uma operação real.

Defenda a decisão sem transformar risco em desculpa

Uma resposta inicial pode ser: “Eu escolheria separar a cotação por uma fronteira, começando por uma transportadora. A alternativa cabe na capacidade nominal fornecida, mas depende de confirmar que a consulta não produz efeitos de escrita. Aceito a convivência temporária e atribuo a retirada do adaptador. Não promoveria o rollout do pacote: o grupo novo tem 4% de erros, e a exposição observada não corresponde ao percentual anunciado.”

Se perguntarem “por que não microserviços?”, volte à necessidade: testar e substituir integrações com menor alcance. A fronteira pode existir dentro da aplicação inicialmente. Criar um serviço separado adiciona rede, operação e contratos de implantação. Pode ser uma escolha posterior, mas o enunciado ainda não demonstrou que esse custo compra um benefício necessário.

Se o prazo cair para quatro semanas, refaça a capacidade e proponha reduzir escopo, obter apoio ou usar o patch com dívida explícita. Não dobre a velocidade esperada sem evidência. Se a pessoa especialista sair, priorize transferência de conhecimento e testes de comportamento antes de ampliar o alcance. A decisão muda quando mudam as restrições.

Para usar uma experiência real, substitua os números fictícios por fatos que você consegue sustentar. Diga onde participou, quem aprovou e qual resultado foi observado. Separe “depois da mudança” de “por causa da mudança”. Quando não houver medição, descreva a limitação e o próximo instrumento de verificação em vez de inventar uma redução percentual.

Use estas questões para aprofundar a defesa técnica e sua responsabilidade:

Continue com Legacy Payroll System Migration Plan. Antes de escolher a tecnologia, escreva uma condição que inviabilizaria seu plano e a evidência que permitiria detectar essa condição cedo.

Sources and Further Reading

• AWS Prescriptive Guidance — Architectural decision record process.
• Martin Fowler — Strangler Fig.
• Google SRE Workbook — Canarying Releases.