Meu Elevator Pitch e Histórias STAR

Com base em experiências reais na Seguralta, WeFit/Porto Seguro e Zarp. Refinado com o coaching de Marie Christine Umali (Looi Consulting) e Augusto Bretas. Relacionadas: entrevista-metodo-star · entrevista-elevator-pitch · entrevista-historias-chave

Apresentação (Elevator Pitch) — ~60–90 segundos

Três perguntas para responder antes do entrevistador perguntar:

Essa pessoa se comunica com clareza?

A experiência dela se alinha com nossos problemas?

Posso confiar que ela vai ter ownership de trabalho complexo?

⚠️ Dica de entrega (feedback Marie): Memorize o fluxo, não o script. Soe como uma conversa, não uma apresentação. Se o entrevistador interromper, responda naturalmente — não tente voltar ao roteiro.

Presente — Quem sou hoje:

“Sou Desenvolvedor Front-end Sênior com mais de 20 anos de experiência em engenharia de software. Nos últimos 7 anos me especializei em construir aplicações enterprise com React, Next.js e TypeScript — com forte foco em arquiteturas micro-frontend, performance em produção e sistemas front-end escaláveis.”

Relevante — Dois projetos que comprovam:

"Na Seguralta, arquitetei do zero a plataforma de gestão da maior franquia de corretoras de seguros do Brasil. Projetei uma solução em micro-frontends com Module Federation, colaborando com uma equipe de 6 desenvolvedores juniores para entregar funcionalidades independentes por domínio — com dashboards complexos carregando em menos de 1,5 segundo.

Na WeFit / Porto Seguro, atuei como líder técnico de uma squad de 12 pessoas. Investiguei e resolvi um incidente crítico de performance — páginas levavam mais de 8 segundos para carregar — reduzindo o First Contentful Paint em 36%, enquanto trabalhei com o time para estabelecer padrões de engenharia mais consistentes e antecipar o QA para dentro da sprint."

Fechamento — convite à conversa:

“É por isso que estou aqui — é o tipo de problema que eu resolvo e o ambiente onde eu entrego meu melhor trabalho. Se quiser aprofundar em alguma dessas histórias ou discutir como minha experiência se encaixa nos desafios de vocês, fico à vontade para perguntar.”

Histórias STAR

Três histórias de três empresas diferentes. Cada uma cobre uma competência principal distinta e pode ser adaptada para múltiplas perguntas técnicas e comportamentais.

História 1 — Arquitetura do Zero e Mentoria (Seguralta)

Cobre: Micro-frontends, Module Federation, Decisão Arquitetural, Cache em Múltiplas Camadas, Mentoria de Juniores, Deploys Independentes.

Situação: A Seguralta é a maior franquia de corretoras de seguros do Brasil. Quando cheguei, todo o sistema de gestão dos franqueados rodava em papel e planilhas. O negócio precisava de uma plataforma unificada — mas com múltiplos domínios (faturamento, gestão de agentes, compliance) que precisavam desenvolver e fazer deploy de forma independente. O time montado tinha 7 pessoas, sendo 6 juniores sem experiência em sistemas complexos de produção.

Tarefa: Assumi como Tech Lead em um projeto Greenfield. Minha responsabilidade era dupla: projetar uma arquitetura robusta, escalável e de alta performance do zero — e liderar e treinar essa equipe de juniores para entregar com qualidade de produção.

Ação:

Por que Module Federation e não monolito ou iframes: Avaliei três opções. O monolito criaria gargalos de deploy — qualquer mudança bloquearia todos os times. Iframes resolvem o isolamento, mas tornam estado compartilhado e consistência visual quase impossíveis. Escolhi Module Federation porque permite compartilhamento real de código em runtime: cada time faz deploy de forma independente, o shell compõe os micro-frontends sob demanda e bibliotecas compartilhadas como o React são carregadas apenas uma vez. Projetei um orquestrador de eventos no browser para gerenciar estado e roteamento entre domínios sem acoplamento direto.
Por que Redis para cache e não cache em memória: A plataforma consumia dados pesados de corretagem. Cache em memória no Node.js seria resetado a cada deploy e não escalaria horizontalmente entre instâncias. Propus Redis como camada de cache compartilhada e persistente, com invalidação inteligente no client-side via staleTime e cacheTime do React Query. Isso manteve as páginas de relatório consistentemente abaixo de 1,5 segundo independente do tamanho do dataset.
Mentoria — Padrões de engenharia desde o primeiro dia: Estabeleci um checklist obrigatório de Code Review, sessões semanais de Pair Programming focadas em padrões React e testes E2E com Cypress, e a regra de que nenhum PR mergeava sem 80%+ de cobertura de testes. Garanti que a equipe entendesse o raciocínio por trás de cada decisão arquitetural antes de codar.

Resultado: A plataforma foi ao ar com sucesso, suportando alto volume diário de transações de seguros. Páginas de relatórios complexos carregam em menos de 1,5 segundo — medido pelo New Relic Browser e validado em staging antes do go-live. A diretoria elogiou a entrega diretamente. A equipe cresceu em autonomia, com todos os 6 juniores entregando funcionalidades completas de ponta a ponta de forma independente — o que acompanhei pelo histórico de PRs aprovados sem revisão de sênior no último mês do projeto.

Perguntas de follow-up prováveis (Marie):

Por que Module Federation e não Single-SPA?

Como você gerenciou dependências compartilhadas entre micro-frontends?

Como você versionou componentes compartilhados?

Como as equipes se comunicavam entre domínios?

Como funcionavam os deploys?

O que quebraria se dois micro-frontends usassem versões diferentes do React?

História 2 — Investigação de Performance em Produção e Liderança de Engenharia (WeFit / Porto Seguro)

Cobre: Root Cause Analysis, React Profiler, New Relic, React.memo, DataLoader, CI/CD, Padrões de Code Review, QA Shift-Left, Mentoria.

Situação: Na Porto Seguro, trabalhei em uma plataforma crítica de gestão comercial usada diariamente por corretores de seguros para acompanhar metas, agendar visitas e gerenciar pipelines de clientes. A squad tinha 12 pessoas entre front-end, back-end e QA. Tínhamos um problema grave em produção: os dashboards dos corretores levavam mais de 8 segundos para carregar nos horários de pico. Não era um inconveniente de UX — os corretores dependem desses dados em tempo real para fechar negócios. Cada segundo de lentidão custava dinheiro ao negócio. Além do problema de performance, a squad também tinha padrões de engenharia inconsistentes: PRs mergeados sem revisão adequada, poucos testes automatizados e QA envolvido apenas no final da sprint.

Tarefa: Fui designado como líder técnico com duas responsabilidades interligadas: conduzir uma investigação profunda de causa raiz do problema de performance — e melhorar a cultura de engenharia da squad para prevenir problemas futuros. Meu mandato era determinar se o problema vinha do React, da camada de API ou dos serviços de back-end, restaurar a performance dentro do SLA, e construir processos que se sustentassem sem supervisão constante de seniores.

Ação:

Investigação de performance (passo a passo):

Reprodução: Usei o React DevTools Profiler e o painel de Performance do Chrome para reproduzir o problema. O flame graph revelou re-renders em cascata disparados por uma única atualização de estado na raiz do dashboard.
Coleta de evidências: Analisei traces do New Relic simultaneamente. Eles expuseram um padrão de N+1 queries — o dashboard fazia dezenas de chamadas individuais por corretor ao invés de agregar. Front-end e back-end tinham problemas independentes.
Descartando outras causas: Isolei a rede com mock service workers para confirmar que mesmo com respostas de API instantâneas, os re-renders eram excessivos — provando que o problema de front-end era independente.
Por que React.memo antes de virtualização: Virtualização como react-window resolve renderização de listas em escala, mas não endereça re-renders desnecessários por referências instáveis. Priorizei React.memo e useMemo primeiro para o maior ganho com menor risco, e adicionei virtualização para as tabelas grandes dos corretores em uma segunda passagem.
Por que Recharts e não a biblioteca legada: A biblioteca de gráficos existente não era tree-shakeable e adicionava ~180 KB ao bundle inicial. O Recharts é composável, tree-shakeable e tem suporte nativo a memoização. Validei a migração em um dashboard antes de aplicar aos demais.
Por que DataLoader para agrupamento de API: O DataLoader agrega múltiplas requisições concorrentes em um único tick do event loop e envia uma única requisição agrupada. Trabalhei com o time de back-end para implementá-lo, eliminando o N+1 na fonte.
Verificação antes da produção: Monitorei o fix em staging via New Relic browser agent — confirmei que o FCP caiu de 8+ segundos para menos de 2 segundos antes do release em produção.
Prevenção no CI/CD: Adicionei performance budgets no GitHub Actions — o pipeline agora bloqueia merges se o bundle exceder um threshold definido ou se os scores do Lighthouse caírem abaixo do baseline.

Melhorias de cultura de engenharia:

Padrões de Code Review: Documentei um checklist obrigatório cobrindo corretude, implicações de performance, cobertura de testes e legibilidade. Nenhum PR mergeava sem revisão de um sênior e CI verde. Escrevi comentários educativos explicando o porquê das mudanças — não apenas apontando problemas.
Mentoria: Sessões semanais de Pair Programming com juniores focadas em limites de useCallback, padrões de seletor com Zustand e memoização. Mantive um documento compartilhado de “anti-padrões encontrados em produção” com exemplos reais do nosso codebase.
QA shift-left: Trouxe os engenheiros de QA para o planejamento da sprint. Passaram a validar features durante a sprint, não apenas no final — capturando regressões mais cedo e eliminando o gargalo de última hora.
Testes no CI: Introduzi testes E2E com Cypress para fluxos críticos e configurei GitHub Actions para rodar linters, testes unitários (Vitest) e E2E em todo PR. Merges para main bloqueados se a cobertura caísse abaixo de 75%.

Resultado: O New Relic confirmou uma redução de 36% no First Contentful Paint (de 8+ segundos para menos de 2 segundos) — rastreado via New Relic Browser Agent, monitorado em staging antes do release. Os dashboards ficaram fluidos durante os horários de pico. A velocidade da squad aumentou conforme decompomos epics grandes em entregas menores com o time. Incidentes em produção por regressões de front-end caíram a quase zero nas duas sprints seguintes. O NPS da plataforma melhorou 19 pontos percentuais — métrica reportada pelo time de Produto com base em pesquisa NPS enviada aos corretores. Dois juniores que trabalharam comigo e receberam mentoria foram promovidos a mid-level em seis meses.

Perguntas de follow-up prováveis (Marie):

Por que React.memo antes de virtualização?

Como você identificou o N+1 query?

Por que DataLoader?

Como você verificou que o React também contribuía para o problema?

Como você monitorou a solução depois do deploy?

Por que DataLoader em vez de batching via GraphQL?

História 3 — Decisão Arquitetural ISR vs SSR e Impacto de Negócio (Zarp)

Cobre: Next.js, ISR, SSR, Separação de Domínios, Estratégia de SEO, CI/CD, Conversão Orgânica.

Situação: No Zarp, estávamos construindo uma plataforma que conectava motoristas que precisavam de um carro com opções de aluguel — essencialmente um Uber para aluguel de carros. O produto tinha dois requisitos muito diferentes convivendo no mesmo codebase: páginas públicas de busca e catálogo que precisavam de SEO de alto nível para gerar tráfego orgânico no Brasil, e um funil de conversão e painel do usuário logado que exigiam dados 100% em tempo real e específicos de sessão. O codebase monolítico tornava deploys isolados arriscados — uma mudança em uma área podia quebrar a outra, e o tempo de build combinado criava fricção nas entregas entre times.

Tarefa: Fui responsável por desacoplar a arquitetura para que áreas distintas do produto evoluíssem de forma independente, e por implementar estratégias avançadas de renderização para atingir as metas de Core Web Vitals e posicionamento orgânico.

Ação:

Por que ISR para páginas de catálogo e não SSR: Aplicar SSR em páginas de catálogo com alto tráfego atingiria o servidor em cada requisição, aumentando o custo de infraestrutura e introduzindo latência em escala. O ISR gera páginas de forma estática e as revalida em background a um intervalo configurado — entregando velocidade de CDN (quase instantâneo para o usuário) com conteúdo razoavelmente atualizado. Defini um intervalo de revalidação de 60 segundos com base na frequência real de atualização do inventário de aluguel. O resultado são FCP e scores do Lighthouse excelentes sem carga adicional nos servidores.
Por que SSR para o funil de conversão e não ISR ou CSR: O checkout e o painel do usuário exigem dados específicos de sessão e 100% em tempo real. Uma página cacheada pelo ISR poderia mostrar preço desatualizado ou disponibilidade incorreta — inaceitável em uma transação financeira. O CSR exporia a lógica de sessão ao cliente. Apliquei SSR com validação rigorosa de sessão via cookie HTTP-only: o servidor valida a sessão antes de renderizar, garantindo que nenhum dado sensível seja exposto no bundle do cliente.
Por que separação de domínios e não monolito modular: Um monolito modular ainda compartilha o pipeline de build — uma mudança de CSS em uma área pode disparar um build completo de toda a aplicação. Separei o codebase em projetos focados por subdomínio (catálogo público, funil do usuário, ferramentas internas) — cada um com seu próprio pipeline de CI/CD, seu próprio cadência de deploy e seu próprio orçamento de Lighthouse. Isso eliminou conflitos de build entre times e reduziu os tempos de build individuais.

Resultado: A latência percebida pelos usuários nas páginas de entrada caiu a quase zero após a adoção de CDN via ISR — validado por scores do Lighthouse (acima de 90) e Core Web Vitals no Google Search Console. Conflitos de build entre times foram eliminados. A plataforma alcançou primeiro lugar no ranking orgânico para os principais termos de busca de aluguel de carros no Brasil. A conversão orgânica cresceu 2,7x — acompanhada pelo time de Growth via Google Analytics, comparando o período pré e pós-lançamento com tráfego orgânico controlado. Os pipelines separados também aumentaram a confiança nas entregas — cada time passou a deployar sem medo de quebrar um domínio não relacionado.

Perguntas de follow-up prováveis (Marie):

Por que ISR em vez de SSR?

Por que não CSR?

Como funcionou a invalidação de cache?

Quais páginas usaram cada estratégia de renderização?

Como você equilibrou SEO com dados em tempo real?

O que você faria diferente hoje?

Fluxo com IA — Spec-Driven Development

Em vez de uma história STAR tradicional, o uso de IA é melhor comunicado respondendo às preocupações comuns dos entrevistadores:

P: Como você integra IA ao seu fluxo de trabalho? R: Uso o que chamo de Spec-Driven Development. Em vez de pedir para a IA gerar código solto, escrevo especificações arquiteturais rígidas em Markdown — definindo modelos de dados, contratos de componentes, estados de erro e critérios de aceitação. A IA consome a especificação e gera a implementação base.
P: Como você evita código ruim ou “alucinações”? R: Estabelecendo guardrails e loops de validação. A IA não commita nada diretamente. Ela é forçada a rodar linters e testes unitários. Se algo quebrar, ela lê o output do console e refatora até os testes passarem (exit code 0). Faço a revisão humana final verificando que os padrões do projeto foram respeitados.
P: E para entender projetos complexos ou legados? R: Uso o NotebookLM para ingerir documentações pesadas e repositórios antigos. Ele atua como assistente de Discovery, me ajudando a mapear regras de negócio e dependências antes de escrever uma linha de código.
P: O uso intensivo de IA não gera alto custo de tokens ou infraestrutura? R: Sim, e para mitigar isso desenvolvi um interceptador de terminal chamado RTK (Rust Token Killer). Ele filtra os outputs longos de comandos bash da IA, reduzindo o consumo de tokens em até 90% sem perder contexto.

Lembretes de Entrega (Feedback Marie)

Esses pontos não são sobre o conteúdo das histórias — são sobre como você vai soar na hora H.

Não soe ensaiado. Se cada frase parecer decorada, o entrevistador vai interromper e aprofundar. Memorize: o problema → sua responsabilidade → por que sua abordagem → o resultado.
Se interromperem, responda naturalmente. Não tente voltar ao roteiro. A conversa deve ser flexível.
Esteja pronto para defender cada decisão técnica. Tudo que você mencionar (Module Federation, Redis, DataLoader, React.memo, ISR, Recharts) pode virar pergunta. Isso é oportunidade, não risco.
Saiba explicar cada métrica. Para qualquer número: de onde veio, como foi calculado, quem mediu. Se não tiver certeza, descreva a melhoria de forma honesta em vez de superestimar a precisão.
Balance ownership com colaboração. Em vez de “eu transformei a cultura”, diga “eu introduzi práticas e trabalhei com o time para estabelecê-las”.
Desacelere. Quando falar sobre arquitetura, pause ocasionalmente. Dê ao entrevistador tempo para absorver e espaço para perguntar.

Perguntas para o Entrevistador

Prepare 2–3 perguntas focadas. O objetivo é sinalizar curiosidade de engenharia — não apenas curiosidade sobre o cargo. Pergunte sobre o ambiente, não sobre o que já está na descrição da vaga.

Bloco 1 — Desafios técnicos (sinaliza: você pensa além do seu próprio ticket)

“Quais são os maiores desafios técnicos de front-end que o time do Web Portal está tentando resolver agora?” Por que é poderosa: Mostra que você se preocupa com os problemas reais de engenharia, não apenas com os requisitos listados.
“Como é a arquitetura atual do front-end — e onde você enxerga ela evoluindo no próximo ano?” Por que é poderosa: Demonstra curiosidade arquitetural e te posiciona como alguém que pensa no longo prazo.

Bloco 2 — Cultura de engenharia (sinaliza: você valoriza qualidade e colaboração)

“Como front-end, back-end, QA e Produto colaboram no design e entrega de uma nova feature — do kickoff até a produção?” Por que é poderosa: Mostra que você entende entrega cross-funcional e está avaliando se o processo do time bate com os seus padrões.
“Como é o processo de Code Review nesse time — há critérios documentados ou é mais informal?” Por que é poderosa: Revela seu compromisso com qualidade de código. Se o time tem bons padrões, você sinaliza alinhamento. Se não tem, abre uma conversa interessante.

Bloco 3 — Ownership e crescimento (sinaliza: você pensa em impacto, não apenas em tarefas)

“Que responsabilidades de produção os engenheiros front-end têm depois que uma feature é entregue — on-call, resposta a incidentes, monitoramento?” Por que é poderosa: Mostra maturidade em produção e que você está confortável em ser dono do seu trabalho de ponta a ponta.
“O que diferencia os engenheiros que se destacam nesse time?” Por que é poderosa: Ajuda a entender os critérios reais de sucesso e sinaliza ambição. A resposta também revela muito sobre os valores reais do time.

Relacionadas: entrevistas-moc · entrevista-metodo-star · entrevista-historias-chave · entrevista-elevator-pitch · entrevista-feedback-ingles