Banco de perguntas de entrevista de emprego

Me explique o trade-off entre viés e variância e como ele aparece num projeto real.

Defina cada termo em uma frase e depois ancore os dois numa decisão concreta: por exemplo, você escolheu um modelo de gradient boosting mais raso porque o erro de validação subia com a profundidade enquanto o erro de treino continuava caindo. Feche contando como você diagnosticou isso (curvas de aprendizado, a diferença na validação cruzada), em vez de recitar teoria.

Como você lida com dados faltantes num conjunto de dados?

Mostre um processo de decisão, não um truque só: primeiro quantifique os dados faltantes e veja se a ausência é aleatória (MCAR/MAR/MNAR), depois escolha o remédio certo — descartar, imputar (média/mediana, com modelo) ou tratar a própria ausência como uma variável. Fale de vazamento de dados (leakage): os parâmetros de imputação devem ser ajustados só na partição de treino.

Como você avalia um modelo de machine learning além da acurácia?

Escolha as métricas pelo custo dos erros para o negócio: precisão/recall e PR-AUC para classes desbalanceadas, calibração quando as probabilidades alimentam decisões e uma comparação com uma linha de base (a classe majoritária, a heurística atual). As respostas fortes acrescentam uma análise por fatias — o desempenho por segmento, não só o número global.

Me conte sobre uma vez em que a sua análise levou a uma decisão de negócio real.

Use o método STAR com números: o que estava em jogo, o que você fez de diferente da abordagem óbvia e o resultado medido (“o modelo de churn priorizou 20% das contas, e o gasto com retenção caiu 15%”). Os entrevistadores vão investigar a continuidade — diga como você soube que o impacto era causal (grupo de controle, teste A/B, diferenças em diferenças).

Como você explicaria um modelo complexo para pessoas sem formação técnica?

Demonstre, não descreva: escolha um modelo e traduza-o na hora (“o modelo dá uma nota para cada cliente, como um score de crédito; estes três fatores são os que mais mexem nela”). Cite ferramentas que você realmente usa — resumos de SHAP transformados em fatores explicados em linguagem simples, ou um memorando de decisão de uma página em vez de um notebook.

Como você aborda a detecção de anomalias num conjunto de dados grande?

Estruture assim: primeiro defina o que é “normal” (sazonalidade, segmentos) e depois escolha um método de acordo com a disponibilidade de rótulos — limiares estatísticos ou isolation forests quando não há rótulos, modelos supervisionados quando os incidentes são rotulados. Diga como você controla o orçamento de falsos positivos, porque a fadiga de alertas mata esses sistemas.

Como você desenha e analisa um teste A/B?

Cubra o arco completo: hipótese e métrica principal definidas de antemão, análise de poder para dimensionar a amostra, unidade de randomização escolhida para evitar interferência e uma regra de parada registrada antes. Os sinais de senioridade são os modos de falha — espiar os resultados antes da hora, comparações múltiplas, efeito novidade — e um exemplo em que o resultado de um teste surpreendeu você.

Me explique passo a passo o seu processo de engenharia de features.

Ancore tudo num projeto: como o conhecimento do domínio sugeriu features candidatas, como você tratou variáveis categóricas e de tempo (target encoding, lags, janelas) e como você validou que uma feature merecia o lugar (importância mais ablação, não achismo). Fale das checagens de vazamento — features calculadas com informação do futuro são o clássico assassino silencioso.

Quando você recorre a SQL e quando prefere Python ou R?

Mostre uma divisão pragmática: SQL para extrair, juntar e agregar na origem (levar o processamento para o data warehouse), Python/R quando você precisa de estatística, modelagem ou gráficos. As melhores respostas falam em mover o trabalho entre eles de propósito — “eu prototipo em pandas e depois devolvo os groupbys pesados para o SQL” — em vez de fidelidade a uma ferramenta só.

Como você monitora um modelo em produção?

Cite as três camadas: saúde do serviço (latência, erros), drift dos dados (distribuições de entrada versus treino) e queda de desempenho (previsões versus o ground truth que chega depois). Diga o que dispara um retreino e quem é acionado. Uma história concreta — “o nosso modelo de fraude piorou depois que uma mudança no produto alterou as features” — vale mais do que uma lista de compras de ferramentas de monitoramento.

Os usuários ativos diários do nosso app caíram. Como você investiga isso?

Primeiro a estrutura: esclareça o tamanho e o período da queda, descarte bugs de medição e depois segmente (plataforma, região, coorte, canal de aquisição) para isolar onde a queda está. Só então levante hipóteses de causa — um lançamento, uma pausa no marketing, sazonalidade, um concorrente. Termine com o teste mais rápido para derrubar uma hipótese, não com uma lista de tudo.

Como você prioriza as funcionalidades no roadmap de um produto?

Cite um framework (RICE, impacto/esforço), mas mostre logo os limites dele: as notas carregam suposições, então diga como você as coloca à prova — evidências de usuários para o alcance, spikes de engenharia para o esforço. As respostas fortes incluem algo a que você disse não de propósito e o motivo estratégico.

Me conte sobre uma decisão de produto em que os dados e a intuição apontavam para lados diferentes.

Esta pergunta testa o seu julgamento. Escolha um caso real: a métrica dizia uma coisa, o sinal qualitativo dizia outra; explique em qual você confiou e por quê (a métrica era um proxy, a amostra era enviesada, longo prazo versus curto prazo). O final convincente é o que você fez para resolver o conflito — um experimento barato, não um salto de fé.

Como você mede o sucesso de um produto depois do lançamento?

Amarre as métricas ao objetivo do lançamento: adoção (taxa de ativação), profundidade de engajamento (frequência, curva de retenção) e resultado de negócio (receita, custo). Diferencie indicadores antecedentes e consequentes, marque um checkpoint de revisão antes do lançamento e diga que resultado faria você voltar atrás — comprometer-se de antemão é o que separa o rigor da racionalização.

Como você lida com um pedido de funcionalidade que vai contra a visão do produto?

Mostre respeito e firmeza: investigue o problema por trás (o pedido é uma solução proposta, não a necessidade), quantifique quem mais tem esse problema e resolva a necessidade de um jeito coerente com a visão ou explique o trade-off que você está protegendo. Escale com opções e uma recomendação, nunca com um “não” seco.

Como você mantém os times de engenharia e de negócio alinhados?

Mecanismos concretos valem mais do que chavões: uma única fonte de verdade escrita para as prioridades, engenheiros nas conversas de discovery para que o contexto chegue cedo e tradução nos dois sentidos — pedidos do negócio apresentados como problemas do usuário, restrições técnicas apresentadas como escolhas de escopo e prazo. Dê um exemplo em que o alinhamento quebrou e o que você mudou.

Que métricas você definiria para um produto totalmente novo?

Estruture pelo ciclo de vida: uma métrica norte (north star) ligada ao valor entregue e, depois, métricas de apoio ao longo do funil — aquisição, ativação (defina com precisão o momento “aha”), retenção — e uma métrica de proteção que pegue você caso esteja manipulando as outras. Explique por que métricas de vaidade (downloads, visualizações de página) ficam de fora e como o conjunto muda depois do product-market fit.

Faça uma estimativa do tamanho de mercado para este produto.

O número importa menos do que a estrutura: diga qual é a sua abordagem (de cima para baixo, a partir da população, ou de baixo para cima, a partir do uso), fale as suposições em voz alta, mantenha as contas simples e confira o resultado com uma referência conhecida. Termine dizendo qual suposição mais mexe na resposta — é essa parte que os entrevistadores realmente avaliam.

Escolha um produto que você acha mal desenhado. Como você o melhoraria?

Escolha algo que você realmente usa — não o produto do entrevistador. Faça o diagnóstico com um framework (quem é o usuário, que tarefa ele quer resolver com o produto, onde o produto falha), proponha uma ou duas mudanças focadas e defina a métrica que provaria que a melhoria funcionou. Uma crítica sem métrica de sucesso soa como gosto pessoal, não como pensamento de produto.

Como você comunica os requisitos para os engenheiros?

Descreva o seu documento (PRD, one-pager) e o que ele define: o problema, o usuário, as métricas de sucesso e as restrições — deixando de propósito o “como” para a engenharia. Fale dos ciclos de feedback em volta dele: uma reunião de kickoff em que os engenheiros apontam falhas e critérios de aceite concretos o bastante para que “pronto” não vire discussão.

Me conte sobre uma campanha de marketing de sucesso que você conduziu.

Estrutura: objetivo → insight sobre o público → escolha de canal → resultado com atribuição. O diferencial é o insight (“descobrimos que os cadastros disparavam a partir de buscas comparativas, então criamos conteúdo comparativo”) e a honestidade sobre o que você faria diferente. Uma história de campanha sem grupo de controle ou linha de base soa como enfeite.

Como você mede a eficácia de uma campanha?

Apresente o funil que você instrumentou: alcance → engajamento → conversão → retenção/LTV, com o KPI principal definido antes do lançamento. Encare a atribuição de frente (disciplina com UTMs, regiões de controle, testes de incrementalidade versus último clique) — reconhecer os limites da sua medição é o que os entrevistadores seniores querem ouvir.

Como você faz a segmentação de mercado e a definição do público-alvo?

Mostre uma segmentação real: os dados que você usou para agrupar (comportamento vale mais que demografia), como você validou que os segmentos eram acionáveis (uma mensagem, um canal ou um preço diferente realmente mexe com eles) e como a segmentação mudou o investimento. Evite respostas de livro com quatro quadrantes e nenhum dado por trás.

Quais ferramentas e plataformas de marketing digital você usa, e por que essas?

Agrupe por função em vez de listar logos: análise (GA4 + uma ferramenta de product analytics), SEO (Search Console + uma ferramenta de ranking e palavras-chave), automação/CRM e testes de criativos. Para cada uma, uma frase sobre uma decisão que a ferramenta realmente mudou — ferramentas que você não consegue ligar a uma decisão soam como enchimento de currículo.

Como você usa dados para otimizar uma campanha que está abaixo do esperado?

Mostre a ordem do diagnóstico: primeiro verifique o rastreamento, depois decomponha o funil para achar a etapa quebrada (CTR bom, mas conversão ruim → o problema está na landing page, não no anúncio). Descreva um teste estruturado que você fez (público, criativo ou oferta — uma variável por vez), o resultado e os critérios de corte que você definiu antes.

Como você já otimizou conteúdo para os buscadores, para SEO?

Mostre o ciclo completo: pesquisa de palavras-chave e de intenção, conteúdo alinhado à intenção (sem encher de palavras-chave), higiene técnica (títulos, links internos, velocidade da página) e evolução medida em impressões e posição ao longo de meses. Ganha pontos quem conta o que não funcionou — histórias de SEO só com vitórias soam emprestadas.

Como você divide o orçamento entre marketing de marca e de performance?

Mostre que você entende a tensão: performance é mensurável e de ciclo curto; marca gera efeito acumulado, mas resiste à atribuição. Ancore a sua divisão no estágio da empresa e na conta do payback (no início, quase tudo em performance até o CAC se estabilizar; depois, ajustar à medida que os canais saturam). Diga como você mediria a marca mesmo assim — volume de buscas, tráfego direto, testes geográficos de incrementalidade.

Como você montaria uma estratégia de conteúdo do zero?

Apresente a sequência: primeiro, pesquisa de público e de intenção; uma arquitetura de temas focada (poucos pilares, não cinquenta posts dispersos); uma cadência de produção que você consiga sustentar; distribuição planejada para cada peça; e um ciclo de medição que corta o que não funciona. O diferencial é a lógica de priorização — por que esses temas primeiro —, não a lista de canais.

Você tem 10 mil dólares para o lançamento de um produto. Para onde vai esse dinheiro?

Resista a gastar tudo em anúncios. As respostas fortes distribuem a verba de acordo com o objetivo: uma parte para a qualidade do criativo e da landing page, uma verba de testes em dois ou três canais com critérios de corte explícitos e uma reserva para dobrar a aposta no vencedor. Mostre a conta por canal (CPC esperado → conversões) e o que você faria diferente com 100 mil dólares.

Como seriam os seus primeiros 90 dias nesta função?

Estruture em três partes: aprender (auditar os funis, conversar com vendas e produto, ler os dados antes de mudar qualquer coisa), ganhos rápidos (uma ou duas correções com impacto visível — muitas vezes a higiene do rastreamento ou uma página com desempenho fraco) e, depois, um plano com responsáveis e métricas. Esta pergunta avalia julgamento e humildade; chegar com um manual rígido não demonstra nenhum dos dois.

Me explique passo a passo uma análise de fluxo de caixa descontado, o DCF.

Cubra a mecânica na ordem — projetar os fluxos de caixa livres, escolher a taxa de desconto (o WACC e como você chegou a ele), o valor terminal (crescimento perpétuo ou múltiplo de saída), descontar e somar — e depois mostre julgamento: a qual suposição o valuation é mais sensível e como você o confere com múltiplos. Mecânica sem análise de sensibilidade soa decorada.

Como você analisa as demonstrações financeiras para avaliar a saúde de uma empresa?

Conecte as três demonstrações em vez de listar índices: a tendência da rentabilidade (DRE), a conversão em caixa (fluxo de caixa versus lucro líquido — a divergência é o clássico sinal de alerta) e a alavancagem e a liquidez (balanço patrimonial). Cite os 3–4 índices com que você realmente começa e uma vez em que um índice contou uma história enganosa.

Fale sobre a sua experiência com orçamento e previsões financeiras.

Descreva o ciclo pelo qual você respondia (orçamento anual, forecast contínuo), o seu método (baseado em direcionadores é melhor do que extrapolar linha a linha) e a precisão: as análises de variação que você fez, o maior erro e a mudança de processo que ele provocou. Os entrevistadores investigam se as suas previsões alimentavam decisões reais ou só apresentações.

Me conte sobre um problema de negócio complexo que você analisou. Qual foi o seu processo?

Escolha um problema com ambiguidade de verdade. Mostre a estrutura: defina a pergunta com precisão, decomponha-a em direcionadores, reúna os dados (e trate as lacunas com honestidade), teste a hipótese principal e chegue a uma recomendação que alguém colocou em prática. A frase que você quer merecer: “isto é o que eu teria errado sem os dados”.

Como você garante a precisão e a confiabilidade das suas análises?

Liste hábitos concretos: conciliar totais com uma fonte independente, embutir checagens de sanidade nos modelos (checagem de balanço, testes de ordem de grandeza), versionar e documentar as suposições e pedir para outra pessoa tentar quebrar o seu modelo antes de entregá-lo. Admitir um erro que você pegou tarde — e a checagem que acrescentou — convence mais do que dizer que nunca errou.

Que ferramentas você usa nas suas análises, e como escolhe entre elas?

Combine a ferramenta com a tarefa: Excel para modelos que outras pessoas precisam auditar, SQL para extrair e remodelar dados na origem, Python/R quando a análise exige estatística ou automação, BI (Tableau/Power BI) para visões recorrentes de autoatendimento. Uma história de migração (“passei um relatório semanal do Excel para SQL + dashboard e economizei N horas”) prova isso.

Descreva a consulta SQL mais complexa que você já escreveu.

Escolha uma com estrutura de verdade — CTEs em várias etapas, funções de janela ou uma deduplicação complicada — e conte a pergunta de negócio que ela respondeu, não só a sintaxe. Explique uma decisão de desempenho (por que você filtrou cedo, quanto custou a ordem dos joins) e como você conferiu o resultado com um total conhecido. Complexidade sem verificação é sinal de alerta, não motivo de orgulho.

Me explique passo a passo uma análise de variação que você fez.

Mostre disciplina na decomposição: realizado versus planejado, dividido em preço, volume e mix (ou os direcionadores equivalentes na sua área), isolando a contribuição de cada fator. Depois, a camada de julgamento — quais variações eram ruído e quais eram sinal, e que decisão a análise mudou. Termine contando como o processo melhorou o ciclo de previsão seguinte.

Como você monta um dashboard de KPIs que os executivos realmente usam?

Comece pelas decisões, não pelos dados: entreviste o público para descobrir as três perguntas que eles fazem toda semana, coloque essas no topo com metas e tendências e mande todo o resto para os detalhamentos. Fale da metade operacional — dados atualizados, um único responsável pela definição de cada métrica e apagar os gráficos que ninguém abre. A adoção é a métrica de sucesso do próprio dashboard.

Me conte sobre uma vez em que a sua análise estava errada.

Escolha um erro que tinha consequências, explique como ele passou (um join errado, viés de sobrevivência, uma suposição desatualizada) e — a parte que está sendo avaliada — como ele foi descoberto e que checagem existe hoje por causa dele. Assumir o erro e institucionalizar a correção soa sênior; dizer que você nunca entregou um número errado soa como falta de autocrítica.

Fale um pouco sobre você.

Presente → passado → futuro, em 90 segundos: o que você faz hoje (uma frase, com a dimensão do seu trabalho), as duas ou três experiências que construíram a habilidade que esta vaga exige e por que esta vaga é o próximo passo lógico. Adapte a parte do meio à descrição da vaga; não recite o seu currículo em ordem cronológica.

Escreva a sua a partir do seu currículo com o gerador gratuito →

Me conte sobre uma vez em que você fracassou.

Escolha um fracasso real, com consequências reais (não “eu trabalho demais”), assuma a sua parte específica nele e use a maior parte da resposta para falar do sistema que você mudou depois. O entrevistador está testando se você transforma fracasso em processo — termine com uma vitória posterior que usou o novo processo.

Descreva um conflito com um colega de trabalho e como você o resolveu.

Mantenha a história no campo da divergência profissional, não do drama pessoal. Mostre que você primeiro buscou entender o raciocínio da outra pessoa, encontrou o objetivo em comum e partiu para um mecanismo de resolução (dados, um teste, levar uma decisão clara para cima). Nunca transforme a outra pessoa em vilã — os entrevistadores se imaginam no lugar desse colega.

Por que você quer trabalhar aqui?

Duas camadas: algo específico da empresa que você só saberia tendo feito o dever de casa (a direção do produto, um lançamento, um post do time de engenharia), ligado à sua própria trajetória. Elogios genéricos (“ótima cultura”) mostram um candidato que se candidatou em massa; ser específico é o jogo inteiro.

Me conte sobre uma vez em que você liderou sem ter autoridade formal.

Escolha uma situação que envolvia várias áreas: você viu a lacuna, construiu alinhamento facilitando os objetivos dos outros (e não escalando logo de cara) e entregou um resultado que dá para quantificar. Esta pergunta avalia a sua capacidade de influência — a mecânica de COMO você convenceu importa mais do que o resultado.

Onde você se vê daqui a cinco anos?

Mostre direção sem um roteiro rígido: a capacidade que você quer aprofundar, o escopo que você quer assumir e como esta vaga contribui para isso. As empresas estão avaliando o risco de você sair e o seu autoconhecimento, não uma previsão exata do organograma.

Qual é o seu maior ponto fraco?

Escolha um ponto fraco real e que não elimine você (nada de falsa modéstia) e depois use dois terços da resposta no sistema para lidar com ele: o hábito ou processo concreto que você criou e um sinal mensurável de que está funcionando. A pergunta testa autoconhecimento e capacidade de melhorar — “sou perfeccionista” falha nas duas coisas.

Me conte sobre uma vez em que você discordou do seu gestor.

Mostre uma discordância produtiva: você discordou no conteúdo, apresentou os seus argumentos com evidências e em particular e depois — fosse qual fosse a decisão — se comprometeu totalmente com ela. Inclua um caso em que você estava errado e admitiu. Os entrevistadores querem ver firmeza e abertura para feedback; histórias com vilão não funcionam.

Me conte sobre uma vez em que você teve que entregar algo com um prazo muito apertado.

A habilidade testada é cortar escopo, não heroísmo. Conte como você reduziu o trabalho ao essencial, comunicou os trade-offs cedo e entregou o que importava — e o que você arrumou depois. Histórias de virar a noite sem uma decisão de priorização dentro soam como mau planejamento, não como dedicação.

Por que você está saindo do seu emprego atual?

Olhe para a frente: uma frase honesta e neutra sobre o limite que você atingiu (escopo, crescimento, direção) e depois passe para o que esta vaga oferece e a atual não pode oferecer. Nunca fale mal do empregador — o entrevistador projeta o que você disser na forma como um dia você vai falar dele. Fique abaixo de trinta segundos.

Me conte sobre um sistema que você projetou de ponta a ponta. O que você mudaria hoje?

Comece pela restrição que guiou o projeto (perfil do tráfego, orçamento de latência, tamanho do time, prazo), não pela lista de tecnologias. O sinal de senioridade é uma coisa que quebrou em produção e o que isso ensinou a você, mais um limite específico que você traçaria de outro jeito hoje.

Me conte sobre o bug mais difícil que você já depurou.

O valor está no método, não no sintoma: como você foi estreitando a busca (bisect, logs, uma reprodução confiável) e qual suposição acabou se mostrando errada. Termine com o que você mudou para que esse tipo de bug apareça mais rápido da próxima vez.

Como você decide entre entregar rápido e fazer do jeito certo?

Responda com um trade-off real que você fez e o teste de reversibilidade por trás dele: uma porta de mão única merece a semana a mais; uma reversível, geralmente não. Diga se a limpeza que você prometeu aconteceu de fato — admitir que não aconteceu é mais convincente do que fingir.

Descreva uma revisão de código em que você discordou de quem escreveu o código.

Mostre que você separa gosto de substância. Recorra a algo externo — uma classe de bugs, um contrato, um benchmark — em vez de preferência, e diga como a discordância terminou: um teste que resolveu a questão, uma sessão de pair programming ou você cedendo.

Como você aborda os testes de um código que não foi você que escreveu?

Primeiro, testes de caracterização para fixar o comportamento atual; depois, cobertura nos caminhos que realmente carregam risco. Diga o que você decidiu NÃO testar: tratar a cobertura como um orçamento, e não como uma meta, é a resposta de quem tem experiência.

Me conte sobre um incidente em produção pelo qual você foi responsável.

Conte a linha do tempo com o relógio na mão: detecção, mitigação, causa raiz, prevenção. Os entrevistadores querem ouvir se você estancou o sangramento antes de entender totalmente a causa — o que geralmente é a ordem certa — e um item de prevenção que chegou a ser entregue.

Como você evita que uma refatoração grande fique travada no meio do caminho?

Descreva como manter tudo entregável a cada passo: migrar uma fatia de cada vez atrás de uma interface, rodar os dois caminhos, apagar o antigo. Cite a métrica que mostrou que estava funcionando e a parte que você deixou sem migrar de propósito.

De qual decisão técnica do seu time você discorda?

Escolha uma real e apresente o outro lado com justiça, incluindo por que o time a escolheu. Terminar com o experimento que resolveria a questão convence mais do que certeza.

Como você valida um conjunto de dados que nunca viu antes?

Dê o checklist que você realmente usa: contagem de linhas comparada à origem, unicidade das chaves, cobertura de datas, perfil de nulos e outliers e, por fim, conciliação com um número em que alguém já confia. A habilidade de verdade é o que você faz quando a conciliação falha, então fale essa parte em voz alta.

Uma métrica do dashboard caiu 20% de um dia para o outro. Me conte o que você faz na primeira hora.

Verifique a instrumentação antes do negócio: uma falha no pipeline e uma queda real ficam idênticas num gráfico. Depois segmente — plataforma, região, usuários novos versus recorrentes — e compare com o calendário de lançamentos e campanhas. Levantar primeiro a hipótese de bug de rastreamento é o que denuncia a experiência.

Como você decide com qual métrica um time deve se preocupar?

Ligue a métrica a uma decisão que ela vai mudar. Uma resposta forte nomeia a métrica, a forma como ela pode ser manipulada e a métrica de proteção que você coloca ao lado dela para que ninguém otimize o negócio até um beco sem saída.

Me conte sobre uma vez em que a sua análise fez alguém mudar de ideia.

Use o método STAR e mantenha a resistência na história: quem discordava, qual evidência específica convenceu essa pessoa e o que você teria feito se não tivesse convencido. Uma análise que não encontrou nenhum atrito raramente fez diferença.

Como você explica incerteza estatística para alguém sem formação técnica?

Traduza para a linguagem da decisão — mais ou menos qual é a faixa de resultados e o que você faria em cada extremo — em vez de colocar um p-valor num slide. Diga explicitamente o que um resultado nulo significaria para o plano.

Uma consulta que rodava em segundos agora leva minutos. O que você faz?

Leia o plano de execução antes de reescrever qualquer coisa: filtre cedo, indexe o que você filtra, reduza as linhas antes dos joins e materialize o que roda todo dia. Cite o caso em que a correção certa estava antes, no modelo do data warehouse, e não na consulta.

Como você lida com um pedido que os dados não conseguem responder?

Diga isso cedo e depois ofereça a pergunta mais próxima que os dados conseguem responder, mais o custo de responder a pergunta real — instrumentação, uma pesquisa, um grupo de controle. Entregar em silêncio um proxy enganoso é o modo de falha aqui.

Me conte sobre um relatório que você criou e que ninguém usou.

Seja honesto e depois faça o diagnóstico: não tinha dono, a frequência estava errada ou ele respondia a uma pergunta pela qual ninguém é cobrado. A melhor versão termina com o que você descontinuou ou com o que o substituiu.

Me conte sobre um projeto que atrasou. O que você fez?

Diga quando você soube, para quem contou e o que cortou. Escalar cedo e com opções é melhor do que heroísmo no fim, e os entrevistadores querem saber qual dos dois você fez.

Como você faz uma atualização de status que as pessoas realmente leiam?

Decisões primeiro, riscos com responsáveis e datas definidos e depois o que mudou desde a última vez. Diga como você mantém a honestidade quando a notícia é ruim — um status que fica verde até virar vermelho ensina as pessoas a ignorá-lo.

Dois times precisam do mesmo engenheiro na próxima sprint. O que você faz?

Leve o trade-off a quem é dono da prioridade, com o custo de cada opção em datas, e não em adjetivos. Evite a não resposta de conversar com os dois lados e torcer para dar certo.

Como você lida com um stakeholder que não para de aumentar o escopo?

Deixe o trade-off visível em vez de recusar: sim, e a data passa para tal dia — qual dos dois você prefere? Cite o registro escrito de mudanças que impede que a mesma conversa se repita.

Descreva um risco que você identificou antes de ele virar um problema.

Como você o encontrou importa: mapeamento de dependências, um pre-mortem ou um engenheiro calado que você fez se sentir seguro para falar. Depois, a mitigação e o que ela custou.

Como você sabe que um projeto está realmente no caminho certo?

Prefira indicadores antecedentes — dependências em aberto, tempo de revisão, mudanças de escopo — às cores de status, e observe que uma demo funcionando vale mais do que um percentual de conclusão.

Me conte sobre uma vez em que você teve que dar uma má notícia para a liderança.

Estrutura: manchete, causa, opções com custos, a sua recomendação. Diga como você evitou enterrá-la no slide catorze.

Como você encerra um projeto?

Critérios de aceite verificados, um responsável definido para o trabalho que continua e uma retrospectiva que mudou exatamente uma coisa. Projetos que nunca são encerrados são a forma como os times acumulam trabalho invisível.

Me conte sobre um negócio que você perdeu, e por quê.

Diga o motivo real em vez do preço, que geralmente é só o sintoma. A versão convincente termina com o que você mudou na qualificação para que a mesma perda não se repita.

Como você qualifica uma oportunidade?

Use o seu framework como checklist, não como roteiro: quem assina, o que quebra se eles não fizerem nada e a data que força uma decisão. Diga quais negócios você desqualificou e quanto tempo isso devolveu.

Um cliente em potencial some depois de uma demonstração ótima. O que você faz?

Parta do princípio de que as prioridades dele mudaram, e não de que foi falta de educação. Descreva como você abre conversa com um segundo stakeholder, um contato realmente útil e o fechamento honesto — perguntar se é para encerrar o assunto muitas vezes rende uma resposta.

Como você contorna a objeção de que vocês são caros demais?

Reenquadre a conversa a partir do custo de deixar tudo como está, quantificado com os números do próprio cliente, e nunca dê desconto sem receber algo em troca. Citar um negócio do qual você abriu mão torna isso crível.

Me conte sobre a negociação mais difícil que você já fez.

Separe a posição do cliente do interesse dele e depois diga qual concessão você trocou e qual recusou. Os entrevistadores querem ouvir se você protegeu o relacionamento e a margem.

Como você constrói pipeline num território totalmente novo?

Segmente, escolha a brecha em que você ganha mais rápido e depois sequencie a prospecção. Dê os seus números reais — contatos, taxa de resposta, reuniões —, porque respostas vagas sobre atividade soam como falta de resposta.

Como são os seus primeiros 30 dias com um produto novo?

Leia os últimos cinco negócios ganhos e perdidos, aprenda o momento da demo que conquista o cliente e encontre um parceiro técnico. Diga o que você seria capaz de fazer sozinho até o dia 30.

Me conte sobre uma previsão de vendas que você errou.

Explique como você separa o compromisso firme do melhor cenário, qual sinal você supervalorizou e a disciplina que acrescentou depois. Honestidade na previsão é a maior parte do trabalho.

Me conte sobre um cliente irritado que você conseguiu reconquistar.

Reconheça o problema, assuma o prazo e depois diga o que realmente mudou — uma correção, um crédito, um processo. A parte que mais interessa aos entrevistadores é o acompanhamento depois que o incêndio foi apagado.

Como você prioriza quando cinco chamados são todos urgentes?

Impacto vezes alcance do estrago, comparado com os compromissos contratuais. Diga a quem você avisou sobre os que ficaram para depois, porque despriorizar em silêncio é o que transforma uma fila em reclamação.

Um cliente pede uma funcionalidade que nunca vai ser desenvolvida. O que você diz?

Seja direto em vez de dar esperança e depois resolva a necessidade por trás com o que já existe hoje. Registre o pedido com o impacto no negócio anexado, para que o time de produto veja o padrão, e não um desejo.

Como você percebe que uma conta está prestes a cancelar?

Queda de uso entre os administradores, a saída do seu principal defensor dentro do cliente, mudança de tom nos chamados, reuniões de revisão puladas. Depois descreva uma intervenção que realmente funcionou e uma que não funcionou.

Me conte sobre uma vez em que você bateu de frente com a sua própria empresa por um cliente.

Conte o argumento interno e as evidências que você levou, mais o que você prometeu ao cliente enquanto a questão não se resolvia. Não prometer nada que você não pudesse controlar é a versão madura.

Como você conduz uma reunião de revisão que o cliente valoriza?

Comece pelos resultados pelos quais ele é cobrado, não pela sua lista de funcionalidades. Leve uma recomendação e um pedido — uma reunião sem pedido é só uma atualização de status.

Me conte sobre um erro que custou a confiança de um cliente.

O que você contou a ele, com que rapidez e o que você mudou no processo depois. A rapidez em revelar o problema é a resposta inteira.

Como você lida com um problema que não consegue resolver hoje?

Uma previsão honesta de prazo, ou a admissão honesta de que ela não existe, uma solução alternativa e uma frequência combinada de retornos que você cumpre. Contas se perdem por silêncio muito mais do que por bugs.

Me conte sobre uma decisão de design que você errou.

Diga como você descobriu — pesquisa, analytics, a fila do suporte —, o que mudou e com que rapidez. Histórias de portfólio em que nada nunca dá errado soam como ficção.

Como você decide o que pesquisar antes de começar a desenhar?

Escolha a suposição mais arriscada e combine o método com ela: cinco entrevistas para entender um porquê, analytics para um quantos, um questionário para uma distribuição. Diga o que você teria entregado sem essa pesquisa.

Um stakeholder quer algo que prejudica a usabilidade. O que você faz?

Reformule o objetivo dele, proponha uma alternativa que o atenda e ofereça um teste barato em vez de um debate sobre gosto. Diga em que ponto você escala quando a discordância continua.

Como você lida com o feedback numa sessão de crítica de design?

Separe a reação do diagnóstico e pergunte pelo problema, e não pela solução proposta. Descreva como você conduz uma crítica quando é você quem dá o feedback.

Como você mede se um design funcionou?

Combine uma métrica de comportamento com uma medida de sucesso na tarefa ou de esforço, e diga o que você faria se o número mudasse pelo motivo errado — mais cliques nem sempre é melhor.

Me conte sobre um projeto em que você teve que desenhar com uma restrição técnica pesada.

Nomeie a restrição, as opções de que você abriu mão e onde você investiu de propósito a flexibilidade que sobrou. É nas restrições que o entrevistador enxerga as suas prioridades.

Como você evita que um design system vire uma camisa de força?

Regras sobre quando um desvio é permitido, um caminho de contribuição que é usado de verdade e uma auditoria que pega os desvios antes que virem um segundo sistema.

O que acessibilidade significa no seu dia a dia de trabalho?

Seja concreto: contraste, ordem de foco, tamanho das áreas de toque, rótulos que um leitor de tela consegue usar e uma coisa que você pegou numa revisão no mês passado. Um compromisso vago é o sinal de que isso não está acontecendo.