A pergunta é simples: "me conta de uma vez em que você resolveu um problema difícil em produção". A resposta começa na terça-feira, passa pelo board vermelho, pela war room, por três ferramentas de log e por um YAML alterado duas vezes. Dois minutos depois, o entrevistador sabe muita coisa sobre o projeto. Sobre o que você decidiu, quase nada. E o resultado não chegou a aparecer.
Isso não é falta de experiência. É falta de forma. Quem conta o projeto em ordem cronológica obriga o entrevistador a garimpar sozinho o que você fez e o que mudou depois, e normalmente o tempo acaba antes. O que este texto entrega é pequeno de propósito: um cartão STAR de oito linhas e um teste de 90 segundos no gravador do celular para conferir se o resultado entra no final da fala.
As quatro letras e o relógio deste post
STAR quer dizer Situation (situação), Task (tarefa), Action (ação) e Result (resultado). Centros de carreira como o da Northwestern, Glasgow e Amherst usam a mesma estrutura para perguntas comportamentais, aquelas do tipo "conte uma vez em que…". Um recrutador sênior da Amazon também orienta que as respostas sigam esse formato. A página de carreira da University of Washington resume o que se procura: uma situação específica, o que você assumiu, o que você fez e como terminou, inclusive quando não terminou como planejado.
Nenhuma dessas fontes trata STAR como roteiro para decorar. Amherst e o recrutador da Amazon descrevem o STAR como uma forma de organizar a resposta, não como texto para recitar.
O relógio é outra conversa. Os 90 segundos, com o Result nos últimos ~20 segundos, são uma heurística editorial deste post, e não uma medida oficial de STAR. Os centros de carreira dão orientações parecidas, sem que nenhuma seja norma. A Duke fala em respostas de um a dois minutos e diz que o resultado é a parte crítica. O Illinois Tech dá como exemplo uma história de cerca de dois minutos, com uns 20 segundos de Result. A Northwestern sugere que Action ocupe metade da resposta e seja sempre a parte mais longa. A gente aperta para 90 segundos porque esse limite obriga a cortar a Situation, que é onde o tempo costuma ir embora, e ainda deixa folga dentro da faixa da Duke.
O despejo cronológico e o cartão de oito linhas
O caso abaixo é um composto editorial de um padrão comum em produção: timeout HTTP, tempestade de retries e pool de conexões pequeno demais. Não é experiência do autor, não tem cliente nem CVE, e os números que aparecem são valores de configuração do cenário, não métricas medidas.
Primeiro, a versão que reprova:
> "Começou numa terça, o board estava vermelho, alguém abriu uma war room. A API de pagamentos é um serviço Spring Boot, a gente usa RestTemplate, tinha uma Jira do trimestre passado sobre timeout. Eu puxei log no Grafana, depois no Kibana, depois entrei por ssh — quer dizer, usei o dashboard. O billing estava lento. A gente tinha retry. Acho que três retries. As threads do Tomcat estavam ocupadas. O Hikari parecia ok no começo. Aí eu lembrei de um blog sobre pool de conexão. A gente mudou um YAML, reverteu, mudou de novo. O time estava estressado. No fim acalmou. Aprendi muito sobre resiliência."
A Situation vira novela, e a Task não aparece em momento nenhum. A Action fica entre "a gente" e um passeio por ferramentas. O Result se resume a "acalmou" e "aprendi muito". No fim, o entrevistador sabe o nome de três ferramentas de observabilidade e de nenhuma decisão sua.
Agora o mesmo incidente em oito linhas:
- S: API Spring Boot que chama o billing por HTTP; a taxa de erro subiu num pico de tráfego; o dashboard do plantão mostrava timeouts, não 4xx.
- T: Restaurar o checkout sem restart às cegas e parar de amplificar a carga no billing.
- A: Eu capturei um trace com falha: timeout do cliente de 10 s, três retries imediatos, threads de request do Tomcat presas esperando.
- A: Eu reduzi os retries em voo para um, com backoff, e baixei o timeout do cliente para a thread voltar em vez de empilhar.
- A: Eu limitei o pool do cliente HTTP para o trabalho novo entrar na fila em vez de abrir mais chamadas lentas.
- R: Os timeouts pararam de subir dentro da janela do incidente; a taxa de erro do checkout voltou à linha de base de antes do pico, no mesmo dashboard.
- R: Eu abri uma mudança de acompanhamento: orçamento de retry e limite de pool em configuração, com o trace como justificativa — não um framework novo.
- R (fechamento falado, opcional): Se fizesse de novo, colocaria o orçamento de retry antes do próximo pico, não durante.
Falando em ritmo normal, as linhas 1 e 2 levam uns 15 segundos, as linhas de Action ocupam o miolo e as três últimas cabem nos 20 segundos finais. Se faltar espaço, a linha 8 pode ser absorvida pela 6 ou pela 7. O cartão também não é tutorial de resiliência nem código de produção. Ele só treina a forma da resposta.
Três conferências antes de gravar
| Conferência | Passa quando | Falha típica | Onde a orientação aparece |
|---|---|---|---|
| Action em primeira pessoa | Cada linha de Action começa com "Eu" + um verbo que o entrevistador consegue visualizar (capturei, reduzi, limitei) | "A gente alinhou com os stakeholders" | Glasgow e o recrutador da Amazon: "eu", não "nós"; UW: fale do que você fez |
| Result observável | O Result cita um dashboard, uma linha de base ou um artefato de acompanhamento | "Acalmou", "foi bem", "aprendi muito" | Duke: o resultado é crítico; UW, Amherst e Amazon: quantifique quando der |
| Task sem novela de contexto | A Task cabe em uma frase (restaurar X sem Y); a Situation, em no máximo duas | Organograma, arqueologia de ticket, war room em capítulos | Duke: contexto breve; Northwestern e Illinois Tech: Action é a parte mais longa, e a Situation é o que se corta quando a resposta passa do tempo |
O "eu" vale só para a ação que foi sua. Sistema e time podem aparecer na Situation sem problema. O que não funciona é falar "a gente" do começo ao fim, porque aí o entrevistador sai da conversa sem ninguém para contratar.
Se você não tem número, não invente um. Descrever a mudança observável ("voltou à linha de base no mesmo painel") convence mais do que um percentil inventado para soar sênior.
O experimento de amanhã: 90 segundos no gravador
Faça isso antes da próxima entrevista ou do próximo 1:1 de carreira. O protocolo é editorial e só precisa do celular.
- Escolha um incidente ou entrega que você viveu de verdade e tire os nomes. Não use o cartão acima como se fosse seu.
- Escreva o seu cartão de oito linhas, passando pelas três conferências da tabela.
- Grave um áudio de 90 segundos contando o caso.
- Ouça uma vez e anote três marcas de tempo: quando a Situation termina, quando a Action começa e quando o Result começa.
- Passa se o Result é falado nos últimos ~20 segundos, a Action está em primeira pessoa, a Task é uma frase e não houve despejo cronológico. Reprova se o Result começa depois do fim ou nem aparece, se a Action virou "a gente" ou se em 0:45 você ainda está na Situation.
- Reescreva uma vez, grave a segunda versão e pare.
Parar na segunda gravação é de propósito. Da terceira em diante, o cartão vira texto decorado, que é justamente o que Amherst e o recrutador da Amazon desaconselham. Se tiver um colega por perto, toque o áudio e faça uma pergunta só: "em que momento começou o resultado?".
Quando usar o cartão, e quando não
Use o cartão quando a pergunta for comportamental, do tipo "conte um caso…" ou "fale de uma vez em que…". Ele não serve para diagnosticar senioridade nem para ensinar stack. Se a pergunta for "como você projetaria isso?", você está em outra conversa, e o cartão não ajuda.
Também não é uma revisão de carreira. O texto Carreira técnica em 2026: o próximo passo não é outro framework procura evidências verificáveis de senioridade; aqui o problema é bem mais estreito: fazer o resultado caber nos últimos 20 segundos de uma resposta.
Os 90 segundos, os 20 segundos finais e as oito linhas são escolhas editoriais, não padrão de mercado. Nenhum cartão garante aprovação. O que ele garante é que, quando o tempo acabar, o entrevistador já terá ouvido o que você fez e o que mudou depois.