Como responder "o que você faria primeiro?"

O problema

Essa pergunta parece simples:

“O que você faria primeiro?”

Mas ela derruba muita gente.

Porque muita resposta vai para um de dois lados ruins:

• chute rápido demais
• abstração vaga demais

No primeiro caso, a pessoa pula direto para solução:

“Eu já abriria um PR.”

No segundo, ela se protege com linguagem bonita:

“Eu entenderia melhor o contexto, alinharia com o time e avaliaria trade-offs.”

As duas respostas podem soar fracas.

A primeira porque parece impulsiva.

A segunda porque não decide nada.

O problema real é que muita gente confunde “primeiro passo” com “primeira tarefa pesada”.

Quase nunca é isso.

Modelo mental

Pense assim:

a primeira ação certa é a menor ação que mais reduz incerteza, risco ou dano.

Essa definição ajuda bastante.

Porque ela muda o foco de:

• “qual solução eu gosto mais?”

para:

• “qual movimento me coloca em posição melhor para decidir o resto?”

Às vezes esse primeiro passo é investigar.

Às vezes é conter impacto.

Às vezes é alinhar objetivo.

Às vezes é de fato implementar alguma coisa.

Mas a lógica é sempre a mesma:

primeiro vem a ação que melhora a qualidade da próxima decisão.

Quebrando o problema

Primeiro não é o mesmo que principal

Esse erro é muito comum.

A pessoa pensa:

• “o problema é no pagamento”
• “então meu primeiro passo é corrigir o bug”

Não necessariamente.

Se você ainda não sabe:

• o tamanho do impacto
• se o problema continua ativo
• se foi causado pelo deploy mais recente
• se existe mitigação simples

então “corrigir” ainda não é o primeiro passo.

É uma etapa futura.

Existem três aberturas comuns: entender, conter ou destravar

Grande parte dos cenários cai em uma dessas aberturas:

• entender o que está acontecendo
• conter dano ou risco imediato
• destravar a próxima decisão do time

Isso já organiza bastante a resposta.

Se é incidente em produção, muitas vezes o primeiro passo é conter.

Se é problema ambíguo de produto, muitas vezes o primeiro passo é entender melhor o impacto.

Se é discussão travada entre opções, muitas vezes o primeiro passo é destravar critério.

Boa primeira ação costuma ser barata e informativa

Esse é um ótimo filtro.

A primeira ação forte normalmente:

• custa pouco
• gera aprendizado rápido
• reduz chance de piorar a situação

Exemplos:

• verificar escopo do problema antes de mexer
• checar se houve mudança recente
• ativar rollback ou feature flag
• validar com dados se a dor é real ou localizada
• alinhar o objetivo principal antes de discutir solução

Perceba a lógica.

Você ainda não está resolvendo o caso inteiro.

Está comprando clareza.

Pular direto para código costuma ser vaidade técnica

Essa frase é dura, mas útil.

Tem muita resposta que vai cedo demais para:

• refactor
• ajuste arquitetural
• implementação nova
• automação

sem antes responder:

• esse é mesmo o problema?
• esse problema é o mais urgente?
• existe forma mais barata de reduzir risco agora?

Às vezes o código vem primeiro, sim.

Mas não porque “engenheiro de verdade sai implementando”.

E sim porque aquele contexto já está claro o suficiente.

A primeira ação depende do tipo de custo que mais ameaça o caso

Isso ajuda muito a sair do genérico.

Pergunte:

• o maior risco aqui é receita?
• é confiança do usuário?
• é indisponibilidade?
• é retrabalho?
• é atraso numa janela de negócio?

Quando você identifica o custo dominante, a primeira ação fica mais óbvia.

Você para de responder em abstrato e passa a responder em contexto.

Resposta forte sempre mostra ordem

Não basta dizer a primeira ação.

O ideal é mostrar rapidamente a sequência:

1. o que eu faria primeiro
2. o que eu esperaria aprender com isso
3. o que eu faria em seguida dependendo do resultado

Isso deixa claro que sua cabeça não está só reagindo.

Ela está navegando.

Exemplo simples

Imagine a pergunta:

“Depois de um deploy, a conversão no checkout caiu. O que você faria primeiro?”

Resposta fraca:

“Eu investigaria o código do checkout.”

Pode até acontecer depois, mas ainda está cedo demais.

Resposta melhor:

“Meu primeiro passo seria confirmar se a queda é real, o tamanho do impacto e se ela começou exatamente após o deploy. Se o efeito for significativo e a correlação estiver forte, eu avaliaria rollback ou desligamento da mudança antes de entrar no código. Faço isso porque o primeiro objetivo não é provar que tenho uma hipótese técnica bonita. É reduzir dano e ganhar clareza sobre a origem.”

Essa resposta funciona porque mostra:

• leitura de impacto
• contenção antes de ego técnico
• ordem de decisão
• critério para o próximo passo

Erros comuns

• Responder com solução final em vez de primeira ação.
• Ficar genérico demais e não escolher nada.
• Pular para código quando o problema ainda está mal definido.
• Ignorar contenção de dano em cenário crítico.
• Não dizer o que a primeira ação pretende esclarecer.

Como um senior pensa

Quem tem mais maturidade costuma pensar assim:

“Antes de otimizar a solução, eu preciso melhorar a qualidade da decisão.”

Esse raciocínio parece simples, mas muda muita coisa.

Porque evita dois desperdícios clássicos:

• resolver rápido a coisa errada
• ou demorar demais para agir onde o dano já está acontecendo

Um senior não tenta parecer brilhante no primeiro minuto.

Ele tenta colocar o problema em uma forma mais governável.

Às vezes isso parece menos heroico.

Mas normalmente é mais útil.

O que o entrevistador quer ver

Quando alguém pergunta “o que você faria primeiro?”, geralmente não está testando se você decorou um playbook.

Está observando se você:

• sabe abrir um problema sem se atropelar
• consegue escolher uma primeira ação com critério
• diferencia investigar, conter e executar
• pensa em impacto antes de implementação
• mantém ordem mental mesmo com contexto incompleto

Resposta boa não precisa soar perfeita.

Precisa soar organizada.

Se você mostrar:

• o primeiro passo
• o motivo desse passo
• e o que ele destrava depois

normalmente já está jogando bem.

A primeira ação certa nem sempre resolve o problema, mas quase sempre melhora a próxima decisão.

Em entrevista, clareza de abertura vale mais do que pressa para soar decisivo.